Aaron McDaid wrote:
Apologies for referring to this old thread...
At least for me, this is not old. It is still very much on my mind.
Simply, 'undefined >> undefined' is a bit more defined than simply 'undefined'. Just like 'undefined:undefined' is at least a non-empty list; which can be matched by (_:_) for example. This explains the differing behaviour of the two seemingly equivalent actions above.
I think you are correct. And that is the problem. As a simple Haskell programmer, I am starting from the fact that seq exists and works in a certain way. Given that reality, I want to look at what monads should look like and what strictness properties they should have. Well, even with seq around, Haskell types and functions still form a nice category - except you have to be careful to use strict composition instead of regular Haskell composition when viewing Haskell functions as morphisms in the category. So then what is a monad? There is one obvious extra requirement: Monad Strictness Law: (>>=) must be strict in its second argument. That law follows from the monad law: (>>= f) .! return = f when we take f = _|_ (and we make the assumption that our monad is not degenerate - return x /= _|_ for some x). Making (>>=) strict in the second argument would be a very minor change. That change would affect few, if any, existing Haskell programs. I am becoming convinced that this should be considered a bug in IO. Unfortunately, I don't think that fixing this bug will help much with other known monad strictness problems, such as the State/StateT strictness bug. Regards, Yitz