On Thu, Jul 2, 2009 at 5:31 AM, Maciej Piechotka
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