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

[Albert Y. C. Lai]

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".