Ross Paterson wrote:
This (like StateT) gives you strictness in the pair, but doesn't give the strictness in the state that the original poster wanted.
I think the OP wanted both. If State is lazy in the pair, a long chain of the form (a >>= (b >>= (c >>= ... >>= z))) gets build up and blows the stack if it finally turns out that yes, all these steps are needed. Worse than that, there's no way to correct this without changing the definition of (>>=). Laziness in the state component is annoying at times, but not as bad. You can recover strictness by writing put $! x get >>= (put $!) . f instead of put x modify f provided that (>>=) is already strict in the pair. (It gets even more ugly if the state is a Data.Map that needs to be updated strictly, in which Data.Map.update also doesn't work, even combined with the above modifications.) -Udo -- The only problem with seeing too much is that it makes you insane. -- Phaedrus