Evaluation order semantics..
王兵兵 wbbtiger at gmail.com wrote: Since no one else answered this, I'll take a crack at it. > The Haskell language specification states that it is a non-strict language, > but nothing about the evaluation strategy (like when and how an expression > is evaluated, and to what level). It does mention the word "evaluate" > several times when talking about pattern matching. > > I have read a wonderful tutorial ( > http://en.wikibooks.org/wiki/Haskell/Laziness http://en.wikibooks.org/wiki/Haskell/Laziness) about lazy evaluation and > weak head normal form, but it is just an implemenation strategy of some > compiler, which I should not depend on when writing codes. > > I come from a strict language background and I just don't feel right if I > don't understand how my codes are execuated. I wonder why the language > specificition does not define the evaluation strategy. > > I hope someone can enlighten me. Thanks! I think you have already achieved enlightenment - you just don't feel right about it. The language specification doesn't define the evaluation strategy because it doesn't matter. At least, it doesn't matter in pure code. You'll get the same answer no matter what order expressions are evaluated in, so long as they are evaluated by the time they are needed. Not specifying evaluation order gives the compiler freedom to arrange it to get the best possible performance. That said, there are cases where the evaluation order matters. Come to think of it, most of them fall into two categories: the order matters for performance reasons (clearly outside the purview of a specification), or you want to insure that something is evaluated before it's actually used (like doing IO), and there are tools in the language to force evaluation in those cases.
Mike Meyer
The language specification doesn't define the evaluation strategy because it doesn't matter. At least, it doesn't matter in pure code. You'll get the same answer no matter what order expressions are evaluated in, so long as they are evaluated by the time they are needed.
Is non-termination included in "pure code"? If so, then different evaluation strategies can indeed affect whether or not an expression can be evaluated "by the time it is needed", or even at all. let foo = foo in const () foo ... is an example of an expression that terminates with a sufficiently lazy evaluation strategy but doesn't terminate given a sufficiently eager evaluation strategy. Or did I misunderstand what you meant? -Keshav
2013/9/24 Mike Meyer
王兵兵 wbbtiger at gmail.com wrote:
Since no one else answered this, I'll take a crack at it.
> The Haskell language specification states that it is a non-strict
language, > but nothing about the evaluation strategy (like when and how an expression > is evaluated, and to what level). It does mention the word "evaluate" > several times when talking about pattern matching. > > I have read a wonderful tutorial ( > http://en.wikibooks.org/wiki/Haskell/Laziness http://en.wikibooks.org/wiki/Haskell/Laziness) about lazy evaluation and > weak head normal form, but it is just an implemenation strategy of some > compiler, which I should not depend on when writing codes. > > I come from a strict language background and I just don't feel right if I > don't understand how my codes are execuated. I wonder why the language > specificition does not define the evaluation strategy. > > I hope someone can enlighten me. Thanks!
I think you have already achieved enlightenment - you just don't feel right about it.
The language specification doesn't define the evaluation strategy because it doesn't matter. At least, it doesn't matter in pure code. You'll get the same answer no matter what order expressions are evaluated in, so long as they are evaluated by the time they are needed. Not specifying evaluation order gives the compiler freedom to arrange it to get the best possible performance.
That said, there are cases where the evaluation order matters. Come to think of it, most of them fall into two categories: the order matters for performance reasons (clearly outside the purview of a specification), or you want to insure that something is evaluated before it's actually used (like doing IO), and there are tools in the language to force evaluation in those cases.
Yes, if the spec does not state the evaluation order I can't predict the performance definitely. -- spockwang
participants (3)
-
Keshav Kini -
Mike Meyer -
王兵兵