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 <limestr...@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 <limestr...@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 <tre...@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@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe