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