User talk:Benmachine/Non-strict semantics
Revision as of 17:07, 7 May 2012 by Benmachine
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".
I should also comment on laziness and the difference between them, because that is what people will have heard of.