#4159: move Monad and MonadFix instances for Either from mtl to base

Edward Kmett ekmett at gmail.com
Wed Jun 30 17:46:27 EDT 2010


On Wed, Jun 30, 2010 at 4:24 PM, Claus Reinke <claus.reinke at talk21.com>wrote:

>
> True. That was an overstatement, based on some particular use cases
> I happen to care about, and which this proposal would break. But consider
> 'Either a' as a refinement of Maybe: the proposed new 'Monad (Either a)'
> instance is not only less defined that the current instance, it is less
> defined
> than the existing 'Monad Maybe' instance. Either having more structure
> to represent information but its Monad instance capturing less information
> than Maybe makes no sense to me.
>

But you know more about Maybe, than you do about 'Either a' namely that
there is no information in its Nothing/Left alternative.

So given just Either a and Maybe, neither subsume the other. You know you
can construct an element in the limit of Maybe: Nothing, but you don't know
that such an object exists forall a. in Either a.

You can make the same statement about particular choices of a. i.e. that
Either () might a well be Maybe except for an extra bottom, but the instance
head, being Haskell 98 has to be formed "Monad (Either a)" which means that
you have to constrain (as mtl does) all Eithers to support such an empty
value, or constrain none of them.

The version that Ross puts forward is the version that can make sense inside
of Base. It fits with the module it is moving into, it doesn't require Base
adopting whole-hog the Control.Monad.Error.Class machinery, and it drops a
value that is an instance for a prelude type into the class where it
belongs.

With that change, the mtl is no longer defining instances for any types it
doesn't own!

Both of these changes feel right from an implementation perspective, even if
they come at the cost of a switch to folks leaning on the existing mtl
semantics.

Already people using the mtl will need to ready themselves for a much
similar set of changes involving the constructor names used by all of of
State/Reader/Writer etc switching to type aliases around their transformer
versions, as mtl becomes an alias for monads-fd + transformers.

In that vein it makes sense that the basic error type used by
transformer-centric should ALSO be a type alias wrapped around ErrorT,
rather than an abuse of a prelude type.

-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20100630/75632064/attachment.html


More information about the Libraries mailing list