Bug in Control.Monad.State

[Yitzchak Gale]

Hi Udo,

I am posting this response here on the libraries list,
because it is relevant to the discussion about whether
State should be lazy or strict by default.

I am also cross-posting to the haskell list, because
I think the topic may be of more general interest.

I wrote:
> > createItems :: RandomGen g => State g [Item]
> > createItems =
> >   liftM catMaybes $ runListT $
> >   flip evalStateT initialState $ runMaybeT $
> >   do
> >     item <- liftRandom $ repeatM randomItem
> >     updateState item
> >     needMoreItems >>= guard
> >     return item
> >   where
> >     liftRandom = lift . lift . lift

Udo Stenzel wrote:
> ...but this is probably broken anyway.  After
> (repeatM randomItem) presumably the state (the
> RandomGen) is _|_, but the type of createItems
> would suggest it is still usable.

No, it works. MaybeT tells ListT when to stop its
iteration. After that, the RandomGen can be used
again elsewhere.

>  I wouldn't do that.  Other than that it's a bit
> hard to see what you're trying to accomplish
> here.

Lazy monads are an important programming paradigm
in practice.

Laziness helps to completely decouple the various
ingredients of the algorithm from each other.
This helps in debugging, and in dividing tasks
among different development teams.

The monadic approach helps makes refactoring easy
(a common complaint against Haskell). For example,
it would be trivial to add exception handling,
or logging.

The algorithm is clearly specified as an iteration
of a series of steps, the way most people would
naturally think of it. Yet the calculation is
completely pure. So a compiler is not required to
follow the steps literally. It can split the
calculation across different threads, processors,
http connections, etc., if it is smart enough.

This is the way industrial software development
should be done. It is clearly far better than
imperative OO.

Regards,
Yitz