On Mon, Aug 9, 2010 at 3:42 PM, Job Vranish <job.vran...@gmail.com> wrote: > For monads like StateT, WriterT, ReaderT, the order doesn't matter (except > perhaps for some pesky performance details). However, for monad transformers > like ErrorT or ListT, the order _does_ matter.
Is it really correct to say that order doesn't matter for the transformers you mention? More precise would be to say that order doesn't matter when two or more of those are stacked *consecutively*. Unless a function is completely independent of what other functions do with the state values, it can matter a great deal what order two State transformers occur in if there happens to be a ContT sandwiched between them. Furthermore, MonadState doesn't even promise that much; an arbitrary transformer that provides state operations may not "commute" generally with a StateT. Imagine, for instance, a state transformer augmented with error checking and transactions, that rolls back to a checkpoint if something 'put's an invalid state value. A polymorphic function with multiple monad typeclasses is thus effectively asserting that it does something sensible and well-defined for any set of transformers providing those classes, for any ordering of those transformers in the stack, and with any other possible transformers inside, outside, or amidst them. Combinatorics are not your friend here. Monad transformer polymorphism leads all too easily into a pit of despair. Don't go there unwisely. - C. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
