Personal tools

Views

User talk:Benmachine/Non-strict semantics

From HaskellWiki

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.