Has anyone ever encountered a Monad Transformer in the wild?

In my area of business - back office IT for a financial institution - it is very common for a software component to carry a global configuration around, to log its progress, to have some kind of error handling / computation short circuit... Things that can be modelled nicely by Reader-, Writer-, Maybe-monads and the like in Haskell and composed together with monad transformers.

But there seem to some drawbacks: The concept behind monad transformers is quite tricky and hard to understand, monad transformers lead to very complex type signatures, and they inflict some performance penalty.

So I'm wondering: Are monad transformers best practice when dealing with those common tasks mentioned above?

Solution 1:

The Haskell community is split on this issue.

• John Hughes reports that he finds it easier to teach monad transformers than to teach monads, and that his students do better with a "transformers first" approach.

• The GHC developers generally avoid monad transformers, preferring to roll up their own monads which integrate all the features they need. (I was told just today in no uncertain terms that GHC will not use a monad transformer I defined three days ago.)

To me, monad transformers are a lot like point-free programming (i.e., programming without named variables), which makes sense; after all, they are exactly programming point-free at the type level. I've never like point-free programming because it's useful to be able to introduce the occasional name.

What I observe in practice is

• The number of monad transformers available on Hackage is very great, and most of them are pretty simple. This is a classic instance of the problem where it's harder to learn a large library than to roll your own instances.

• Monads like Writer, State, and Environment are so simple that I don't see much benefit to monad transformers.

• Where monad transformers shine is in modularity and reuse. This property is beautifully demonstrated by Liang, Hudak, and Jones in their landmark paper "Monad Transformers and Modular Interpreters".

Are monad transformers best practice when dealing with those common tasks mentioned above?

I would say not. Where monad transformers are best practice is where you have a product line of related abstractions which you can create by composing and reusing monad transformers in different ways. In a case like this you probably develop a number of monad transformers that are important for your problem domain (like the one that was rejected for GHC) and you (a) compose them in multiple ways; (b) achieve a significant amount of reuse for most transformers; (c) are encapsulating something nontrivial in each monad transformer.

My monad transformer which was rejected for GHC did not meet any of the criteria (a)/(b)/(c) above.

Solution 2:

The concept behind monad transformers is quite tricky and hard to understand, monad transformers lead to very complex type signatures

I Think this is a bit of an exaggeration:

• To use a particular Monad stack of a transformer is no more difficult to use than a plain Monad. Just think about layers\stacks and you'll be fine. You almost always never need to lift a pure function (or specific IO action) more than once.
• As mentioned already hide your Monad stack in a newtype, use generalized derive and hide the data constructor in a module.
• Try not to use a particular Monad stack in function type signature, write general code with Monad type classes like MonadIO, MonadReader and MonadState (use flexible contexts extension which is standardized in Haskell 2010).
• Use libraries like fclabels to reduce boilerplate actions which access parts of record in a Monad.

Monad transformers are not your only options, you could write a custom Monad, use a continuation Monad. You have mutable references/arrays in IO (global), ST (local and controlled, no IO actions), MVar (synchronizing), TVar (transactional).

I've heard that the potential efficiency issues with Monad transformers could be mitigated just by adding INLINE pragmas to bind/return in the source of mtl/transformers library.

Solution 3:

Back when I was learning monads I built an application using a stack of StateT ContT IO to create a discrete event simulation library; the continuations were used to store monadic threads, with the StateT holding the runnable thread queue and other queues used for suspended threads waiting for various events. It worked quite well. I couldn't figure out how to write the Monad instance for a newtype wrapper, so I just made it a type synonym and that worked pretty well.

These days I would probably have rolled my own monad from scratch. However whenever I do this I find myself looking at "All About Monads" and the source of the MTL to remind me what the bind operations look like, so in a sense I'm still thinking in terms of an MTL stack even though the result is a custom monad.

Solution 4:

I recently "fell" on monad composition in the context of F#. I wrote a DSL with a strong reliance on the state monad: All components rely on the state monad: the parser (parser monad based on state monad), variable matching tables (more than one for internal types), identifier look up tables. And as these components all work together, they rely on the same state monad. Therefore there is a notion of state composition that brings together the different local states, and the notion of state accessors that give each algo their own state visibility.

Initially, the design was really "just one big state monad". But then I started needing states with only local life times, and yet still in the context of the "persistent" state (and again, all these states are managed by state monads). For that I did need to introduce state monad transformers that augment the state and adapt the state monads together. I also added a transformer to move freely between a state monad and a continuation state monad but I have not bothered to use it.

Therefore, to answer the question: yes, monad transformers exist in the "wild". Yet I would argue strongly against using them "out of the box". Write your application with simple building blocks, using small hand crafted bridges between your modules, if you do end up using something like a monad transformer, that's great; Do not start from there.

And about the type signatures: I have come to think of this type of programming as something very similar to playing blindfold chess (and I am not a chess player): your skill level needs to be at the point that you "see" your functions and types fitting together. The type signatures mostly end up being a distraction, unless you explicitly want to add type constraints for safety reasons (or because the compiler forces you to give them such as with F# records).