User talk:Benmachine/Non-strict semantics

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.