Working on permuted monad transformer stack

Question

One of the problems with monad transformers I find is the need to lift the operations into the right monad. A single lift here and there isn't bad, but sometimes there are functions that looks like this:

fun = do
  lift a
  lift b
  c
  lift d
  lift e
  f

I would like to be able to write this function thus:

fun = monadInvert $ do
  a
  b
  lift c
  d
  e
  lift f

This halves the number of lifts and makes the code cleaner.

The question is: for what monads is monadInvert possible? How should one create this function?

Bonus points: define it for monad m which is an instance of MonadIO.

The title of this question speaks of permutations: indeed, how can we deal with arbitrary permutations of a monad tranformer stack?

Answer 1

You might be interested in Monads, Zippers and Views, Virtualizing the Monad Stack by Tom Schrijvers and Bruno Oliveira.

This doesn't address your point about reducing the lifts, but it's an interesting approach to your "monad permutations" problem.

Here's the abstract:

This work aims at making monadic components more reusable and robust to changes by employing two new techniques for virtualizing the monad stack: the monad zipper and monad views. The monad zipper is a monad transformer that creates virtual monad stacks by ignoring particular layers in a concrete stack. Monad views provide a general framework for monad stack virtualization: they take the monad zipper one step further and integrate it with a wide range of other virtualizations. For instance, particular views allow restricted access to monads in the stack. Furthermore, monad views can be used by components to provide a call-by-reference-like mechanism to access particular layers of the monad stack. With these two mechanisms component requirements in terms of the monad stack shape no longer need to be literally reflected in the concrete monad stack, making these components more reusable and robust to changes.

Answer 2

Well, first of all, you don't actually need so much lifting. For monad transformers the following identities hold:

lift c >>= lift . f = lift (c >>= f)
lift c1 >> lift c2  = lift (c1 >> c2)

It's not uncommon to write:

x <- lift $ do
    {- ... -}

Next is: When you use libraries like mtl or monadLib (i.e. type class based libraries instead of transformers directly), you actually can access most underlying monads directly:

c :: StateT MyState (ReaderT MyConfig SomeOtherMonad) Result
c = do
    x <- ask
    y <- get
    {- ... -}

Finally, if you really need a lot of lifting despite these two points, you should consider writing a custom monad or even use an entirely different abstraction. I find myself using the automaton arrow for stateful computations instead of a state monad.

Answer 3

I am mostly sure that what you are decribing is impossible for IO, which is always the innermost monad:

From Martin Grabmüller: Monad Transformers Step by Step, available at http://www.grabmueller.de/martin/www/pub/

Down in this document, we call liftIO in eval6 to perform I/O actions. Why do we need to lift in this case? Because there is no IO class for which we can instantiate a type as. Therefore, for I/O actions, we have to call lift to send the commands inwards

In general, for monads less restrictive than IO, (such as Error and State) order still matters for semantics, so you can't change the order of the stack just to make syntax more convenient.

For some monads, like Reader, that are central (in that they do commute in the stack), your idea seems not clearly impossible. I don't know how to write it though. I guess it would be a type class CentralMonad that ReaderT is an instance of, with some implementation...