User talk:Benmachine/Non-strict semantics
Revision as of 22:54, 4 May 2012 by Benmachine (talk | contribs) (New page: Comments from IRC: 22:53:25 < monochrom> benmachine: in your article on non-strictness, you fall into the same fallacy that everyone else falls into, of ...)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Comments from IRC:
22:53:25 < monochrom> benmachine: in your article on non-strictness, you fall into the same fallacy that everyone else falls into, of talking about evaluation. [...] 23:06:13 < monochrom> well, you should add that innermost-first is not the only way to get strictness, and outermost-first is not the only way to get non-strictness 23:07:03 < monochrom> the evaluation orders you ever mention should be "for example the computer may do this" rather than "must do this" 23:08:25 < monochrom> it is tempting to say "in the python case we know the order" but even then, python now receives various alternative compilers, some of which may optimize and re-order. no, we no longer know python orders. 23:09:24 < monochrom> to evaluate "const x y" and get strictness, I can evaluate x first, then evaluate y, then throw it away, and go back to x 23:11:08 < monochrom> and yes, to obtain non-strictness, you can use speculative methods, evaluate more than you think you need, kill off some sub-evaluation threads later. 23:11:52 < monochrom> the next and lesser problem is bringing up "what is needed". every reader will misinterpret that some way 23:12:26 < monochrom> "if x/x == 10 then () else ()" do we "need" [sic] to evaluate x/x==10? 23:13:25 < monochrom> the Haskell Report simply decrees: if ⊥ then x else y = ⊥. end of story. no debate on the meaning of "need".