The monad-levels package

[ Tags: control, library, mit ] [ Propose Tags ]

An automatic way of adding instances to monad classes.


[Skip to Readme]

Properties

Versions 0.1.0.0, 0.1.0.1
Change log CHANGELOG.md
Dependencies base (==4.7.*), constraints (==0.4.*), transformers (>=0.2 && <0.5), transformers-compat (>=0.1 && <1) [details]
License MIT
Author Ivan Lazar Miljenovic
Maintainer Ivan.Miljenovic@gmail.com
Category Control
Home page https://github.com/ivan-m/monad-levels
Bug tracker https://github.com/ivan-m/monad-levels/issues
Source repository head: git clone git://github.com/ivan-m/monad-levels.git
Uploaded Tue Feb 3 11:11:46 UTC 2015 by IvanMiljenovic
Distributions NixOS:0.1.0.1
Downloads 393 total (34 in the last 30 days)
Rating (no votes yet) [estimated by rule of succession]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2015-02-03 [all 1 reports]
Hackage Matrix CI

Modules

[Index]

Downloads

Maintainer's Corner

For package maintainers and hackage trustees


Readme for monad-levels-0.1.0.1

[back to package description]

monad-levels

Why not mtl?

The oft-spouted problem with the standard monad transformer library mtl and similar libraries is that instances are quadratic: you need a separate instance for each valid combination of transformer + typeclass.

For end users, this isn't really a problem: after all, all the required instances have already been written for you!

But what happens if you have a custom transformer, or a custom typeclass?

What about if you want to have something like MonadIO but for a different base monad?

Then you need to write all those extra instances.

What makes it more frustrating is that many of the instance definitions are identical: typically for every transformer (using StateT s m as an example) it becomes a matter of:

  • Possibly unwrap the transformer from a monadic value to get the lower monad (e.g. StateT s m a -> m (a,s));

  • Possibly add internal values (e.g. m a -> m (a,s));

  • Wrap the lower monad from the result of the computation back up into the transformer (e.g. m (a,s) -> StateT s m a).

The solution

Ideally, instead we'd have something along the lines of (simplified):


class (Monad m) => MonadBase m where
  type BaseMonad m :: * -> *

  liftBase :: BaseMonad m a -> m a

class (MonadBase m) => MonadLevel m where

  type LowerMonad m :: * -> *

  type InnerValue m a :: *

  -- A continuation-based approach for how to lift/lower a monadic value.
  wrap :: (    (m a -> LowerMonad m (InnerValue m a)             -- unwrap
            -> (LowerMonad m a -> LowerMonad m (InnerValue m a)) -- addInternal
            -> LowerMonad m (InnerValue m a)
          )
          -> m a

With these two classes, we could then use Advanced Type Hackery (TM) to let us instead just specify instances for the transformers/monads that do have direct implementations for a typeclass, and then have the rest defined for us!

It turns out that this approach is even powerful enough to make liftBase redundant, and it isn't limited to just lifting a monad but can instead be used for arbitrary functions.

Advantages

  • Minimal specification required for adding new typeclasses: just specify the instances for monads that satisfy it, and then use the provided machinery to lift/lower methods to other transformers in the monadic stack.

  • Works even for polyvariadic functions.

  • Still allows specifying whether certain transformers do not allow some constraints to pass through (e.g. ContT does not allow access to a WriterT).

Disadvantages

  • Requires a lot of GHC extensions.

  • Requires usage of proxies when lifting/lowering typeclass methods.

  • Large usage of associated types means type errors can be difficult to decipher.

  • Due to usage of closed type-families, it is not possible to add extra instances to typeclasses (i.e. it is not possible to use a custom State monad/monad-transformer with Control.Monad.Levels.State).

  • Currently un-benchmarked; as such, it's not known how much of a performance penalty this approach takes.

  • Lowering polyvariadic functions requires specifying the type of the function using a specific grammar (though the common m a -> m a case is pre-defined).