MonadError and fundeps

[Marcin 'Qrczak' Kowalczyk]

On Fri, 11 May 2001, Lauri Alanko wrote:

> Yep, but in hugs +o the latter overrides the first one. Which is quite
> convenient.

I doubt that it works predictably in all cases (when state types are not
known statically). I can try to construct an example if you wish.

> translift :: (MonadTrans t, Monad m, Monad (t m)) 
> 	       => (m a -> m b) -> t m a -> t m b
> 	       
> translift f m = m >>= lift . f . return
> 
> instance (MonadTrans t, MonadReader r m, Monad (t m)) 
>     => MonadReader r (t m) where
>         ask = lift ask
> 	local = translift . local
> 
> instance (MonadTrans t, MonadWriter w m, Monad (t m), Monoid w) =>
>     MonadWriter w (t m) where
>         tell = lift . tell
> 	listen = translift listen
> 	pass = translift pass

This gives wrong results (but I haven't checked). For example
    listen :: Monoid w
           => ReaderT r (Writer w) a -> ReaderT r (Writer w) (a, w)
doesn't listen what the action tells, but listens to 'return' which always
tells mempty. Similarly 'local' first runs the action in the original
environment and then provides a new environment to 'return' which doesn't
look at it.

I did most monad transformer forwarding instances in ghc-5.00 and hope
that I got them right, but I haven't tested them much. It's not that
mechanical (except MonadState), and some combinations can't be done at
all.

It could be advantageous to put something like translift in an extension
of MonadTrans. AFAIR many liftings of this type are similar (but the
function must be provided separately for each state transformer), so it
would simplify making forwarding instances.

> Is it inconceivable that m might actually have multiple ParsingStates,
> and thus you really have to specify which one you want to use to get
> the input?

The idea is to use a single state and abstract over the way in which
interesting components are contained in it. It has these advantages:
* It works. I doubt that automatic recognition of the state type would work.
* It allows to have multiple components of the same type in the state.

Now I see that my simulation of a fundep without the fundep (an extra
class which generates the dependency, instantiated separately for each
monad transformer, with MonadError as a superclass) doesn't work that
well: throwError would still be ambiguous so it needs a wrapper with a
type which tells how to determine the error type using the new class.
So I'm now convinced that MonadError should have the fundep too.

Some other mechanism could be invented to make it easier to embed various
components in the same type (for MonadReader & MonadState) or various
alternatives (for MonadError). I have a rather heavy proposal for the
first case (a language extension which redesigns records). OCaml has
a dual mechanism for the second (polymorphic variants). If my records
succeed, I will try to cover variants too.

-- 
Marcin 'Qrczak' Kowalczyk