[Haskell-cafe] strict, lazy, non-strict, eager

[Thiago Negri]

I did read other wiki pages, and I guess I finally got it.
Anyone who still feel lost, take a look at them [1,2,3,4].

If the HaskellWiki is right, then the Wikipedia article for evaluation
strategies [5] is a bit misleading, as it classifies optimistic
evaluation under "nondeterministic strategies" when it should be under
the non-strict section.
Also, it mixes the word evaluation with strict and non-strict, e.g.:
"In non-strict evaluation, arguments to a function are not evaluated
unless they are actually used in the evaluation of the function body."

This is lazy evaluation. A non-strict implementation may evaluate the
arguments of a function before calling it. The main diference is:

Strict semantics: the value of the function is 100% dependent of the
value of all arguments, any arguments yielding
bottom/error/non-termination/exception will result in the same
_error-value_ for the function.

A correct implementation of strict semantics is eager evaluation,
where all the arguments are evaluated before evaluating the function.


Non-strict semantics: the value of the function may not need it's
arguments' values to be produced, if the function can produce it's
value without the need of an argument's value, the function evaluates
correctly even if the unnused argument yields
bottom/error/non-termination/exception.

Lazy evaluation is one implementation of non-strict semantics, where
the arguments are evaluated only when they are needed.

Despite Haskell (GHC) don't do this, (0 * _|_) may yield 0 on a
non-strict implementation.


Did I got it right?


[1] http://www.haskell.org/haskellwiki/Non-strict_semantics
[2] http://www.haskell.org/haskellwiki/Strict_semantics
[3] http://www.haskell.org/haskellwiki/Lazy_evaluation
[4] http://www.haskell.org/haskellwiki/Eager_evaluation
[5] http://en.wikipedia.org/wiki/Evaluation_strategy

2011/12/28 Thiago Negri <evohunz at gmail.com>:
> I got a glimpse of understanding of what you are talking about after
> reading the wiki [1].
>
> Still difficult to reason about the difference between lazy and
> non-strict without taking a look at the text.
>
> I hope somebody will make an effort to better explain the differences
> and persist it in the wiki or in a feed (maybe planet haskell).
>
> [1] http://www.haskell.org/haskellwiki/Lazy_vs._non-strict
>
> 2011/12/28 Yves Parès <limestrael at gmail.com>:
>>> - Adjective strict can be applied both to a global evaluation method and a
>>> specific function: if applied to an eval method then it's a synonym of
>>> "strict"
>>
>> I of course meant a synonym of "eager". Sorry.
>>
>> I admit this definition might be a little liberal, but it helps understand.
>>
>>
>>
>> 2011/12/28 Yves Parès <limestrael at gmail.com>
>>>
>>> When I explain to people what strict/lazy/eager mean, I often say
>>> something like :
>>>
>>> - Adjectives eager and lazy apply only to a global evaluation method:
>>> eager is C evaluation style and lazy is that of Haskell.
>>> - Adjective strict can be applied both to a global evaluation method and a
>>> specific function: if applied to an eval method then it's a synonym of
>>> "strict", and if applied to a function f it means 'f ⊥ = ⊥' (which I detail
>>> a little more), which is true for strict State monad for istance (>>= would
>>> not allow its left argument to return ⊥).
>>>
>>> Thus explaining why datatypes such as State or Bytestring exist in strict
>>> and lazy flavours.
>>>
>>>
>>> 2011/12/28 Albert Y. C. Lai <trebla at vex.net>
>>>
>>>> There are two flavours of MonadState, Control.Monad.State.Lazy and
>>>> Control.Monad.State.Strict. There are two flavours of ByteString,
>>>> Data.ByteString.Lazy and Data.Bytestring (whose doc says "strict"). There
>>>> are two flavours of I/O libraries, lazy and strict. There are advices of the
>>>> form: "the program uses too much memory because it is too lazy; try making
>>>> this part more strict". Eventually, someone will ask what are "lazy" and
>>>> "strict". Perhaps you answer this (but there are other answers, we'll see):
>>>>
>>>> "lazy refers to such-and-such evaluation order. strict refers to f ⊥ = ⊥,
>>>> but it doesn't specify evaluation order."
>>>>
>>>> That doesn't answer the question. That begs the question: Why do
>>>> libraries seem to make them a dichotomy, when they don't even talk about the
>>>> same level? And the make-it-more-strict advice now becomes: "the program
>>>> uses too much memory because of the default, known evaluation order; try
>>>> making this part use an unknown evaluation order", and this unknown is
>>>> supposed to use less memory because...?
>>>>
>>>> I answer memory questions like this: the program uses too much memory
>>>> because it is too lazy---or nevermind "lazy", here is the current evaluation
>>>> order of the specific compiler, this is why it uses much memory; now change
>>>> this part to the other order, it uses less memory. I wouldn't bring in the
>>>> denotational level; there is no need.
>>>>
>>>> (Sure, I use seq to change evaluation order, which may be overriden by
>>>> optimizations in rare cases. So change my answer to: now add seq here, which
>>>> normally uses the other order, but optimizations may override it in rare
>>>> cases, so don't forget to test. Or use pseq.)
>>>>
>>>> I said "people, make up your mind". I do not mean a whole group of people
>>>> for the rest of their lives make up the same mind and choose the same one
>>>> semantics. I mean this: Each individual, in each context, for each problem,
>>>> just how many levels of semantics do you need to solve it? (Sure sure, I
>>>> know contexts that need 4. What about daily programming problems: time,
>>>> memory, I/O order?)
>>>>
>>>> MigMit questioned me on the importance of using the words properly.
>>>> Actually, I am fine with using the words improperly, too: "the program uses
>>>> too much memory because it is too lazy, lazy refers to such-and-such
>>>> evaluation order; try making this part more strict, strict refers to
>>>> so-and-so evaluation order".
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>