ApplicativeReader

[lpsmith]

The Monad constraint on MonadReader is a bit too constraining for me; I'd really like to loosen that constraint to Applicative (or looser?) while breaking the least amount of code possible.

So now that we've made Applicative a superclass of Monad, that would make such a transition considerably easier. However, simply changing Monad to Alternative, while it shouldn't break instances, would break client code that use the Monad class but don't explicitly declare (Monad m, MonadReader m) =>.

It seems fairly safe to assume there's more client code than there are instances, one possibility would be to have something like the following:

class Applicative m => ApplicativeReader r m | m -> r where
    ask :: ...
    local :: ...
    reader :: ...

class (Monad m, ApplicativeReader m) => MonadReader m
instance (Monad m, ApplicativeReader m) => MonadReader m

Then, the only thing people would have to do would be to replace the name MonadReader with ApplicativeReader in all their instances. This might cause some problems for people who don't update their instances and have have OverlappingInstances turned on; it would seem preferable to make MonadReader a closed typeclass or a typeclass synonym.

Making MonadReader a typeclass synonym is possible with ConstraintKinds, but would also require ConstraintKinds to be enabled in all code that mentions the MonadReader constraint.

[chessai]

Alternatively, how much breakage would be caused by changing the constraint, to the following?:

class Applicative m => MonadReader r m | m -> r where {...}

Also, in transformers, a lot of constraints can be relaxed to Applicative.

This is all post-AMP, of course.

[ekmett]

I think I place this in the bin of ideas for a major mtl 3 rewrite. The major concern I have is that when you go to state laws for the transformers, many of them cannot be stated for the Applicative-only form.