2. I find writing monad transformers annoying.
Additionally if package defines transformer A and another transformer B
they need to be connected 'by hand'.

You have not given any concrete problems or examples, so it's hard for me to comment. But at first glance, I would conjecture that you are relying too heavily on monads and sequential thinking.

Consider what your code would look like without a single monad. Obviously you cannot talk to the network without IO, but your program can still be modeled purely, and then toss in IO at the last second to tie it to the network. This model may be difficult for you because it requires your brain to be rewired; feel free to mail this list with concrete modeling problems and we will help you out.

As for the pure model, throw away Reader, Writer, State -- everything, and just use pure functions. Then add monads back in at small scopes when they clean things up.

I used to approach problems by designing a monad for my whole program, using an appropriate stack of transformers. I suspect such an approach led to the claim that "monads are not appropriate for large software systems" in a popular paper a few months ago. As I have gained more experience, I found that this is the wrong way to go about using them. Now my primary use of monads is within the scope of a single function, to tie together the helper functions in the where clause.

Luke

I find a simple solution which probably is incorrect as it hasn't been
used:

instance (MonadState s n, Monad (m n), MonadTrans m) =>
MonadState s (m n) where
get = lift get
put = lift . put

(requires FlexibleInstances MultiParamTypeClasses FlexibleContexts
UndecidableInstances - two last are not extensions used by mtl)

Regards

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe