On Mon, Oct 13, 2008 at 12:29 AM, Ryan Ingram wrote:

Of course, the point of this message isn't just to complain. The overlap implementation was abhorrent and it *is* better now than it was before.

I'm curious what you find abhorrent about the overlap implementation that was there before - in particular, it seems like it was designed to handle both the combinatorial explosion and the corner cases you mentioned. Did you find writing the MonadTrans instances unpleasant? Was it the presence of overlapping instances at all? On Mon, Oct 13, 2008 at 12:35 AM, Don Stewart wrote:

I just want to make one small point here encouraging people to try out new 'mtl' libraries. There are lots of *new* monad libraries,

Without knowing better myself: do any of these libraries address the issue Ryan's brought up? I know that monadLib takes the same approach the MTL does to this, and so is likely to have the same difficulties. /g -- I am in here

On Mon, Oct 13, 2008 at 3:29 AM, Ryan Ingram wrote:

On Mon, Oct 13, 2008 at 2:04 AM, J. Garrett Morris wrote:

...

Indeed - MTL seems to have been rewritten at some point in the past to prefer exhaustive enumeration to overlap.

Indeed, and I actually think this is a weakness of the current implementation. Anyone who comes up with a new transformer that provides different functionality than what is there needs to explicitly provide all the relevant instances, instead of letting MonadTrans do its thing.

(First of all, sorry for the double reply.) I'm certainly way out of my depth here, but would something like associated classes help here? I'm imagining something like this (I'm sure my syntax is all wrong, though):

class TypedMonad m where class MonadType m

instance (MonadTrans m, TypedMonad n) => (MonadType n) (m n)

So then you could write something like

instance Monad m => TypedMonad (ReaderT i m) where class MonadType (ReaderT i m) = MonadReader

and likewise for Reader, Writer(T), State(T), IO, etc... Then, for instance

instance MonadWriter (StateT s (ReaderT r (WriterT w IO)))

is fully-automatic... Or wouldn't this work, at least once associated classes is implemented? Cheers, steve

Ryan Ingram schrieb:

On Mon, Oct 13, 2008 at 2:04 AM, J. Garrett Morris wrote:

...

Indeed - MTL seems to have been rewritten at some point in the past to prefer exhaustive enumeration to overlap.

Indeed, and I actually think this is a weakness of the current implementation. Anyone who comes up with a new transformer that provides different functionality than what is there needs to explicitly provide all the relevant instances, instead of letting MonadTrans do its thing.

I long thought that it is unnecessary use of type system extensions to require multi-parameter type classes for simple monads and its transformer versions. I thought it would be enough to have atomar monads like ST, IO and Identity, and monads like State, Reader, Writer, Continuation can be offered exclusively in the transforming variant. (State s a) would have to be defined as (StateT s Identity a) instead. This way MonadState, MonadReader and the other classes become unnecessary. However, 'lift' remains important with this design.