[Haskell-cafe] More Flexible Monad Transformer OR Bad Coding
cam at uptoisomorphism.net
Mon Aug 9 17:25:19 EDT 2010
On Mon, Aug 9, 2010 at 3:42 PM, Job Vranish <job.vranish at 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.
More information about the Haskell-Cafe