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

[Yves Parès]

> - 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<http://www.haskell.org/mailman/listinfo/haskell-cafe>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111228/8699fefc/attachment.htm>