Proposal: Move the instances from Control.Monad.Instances into GHC.Base

[Edward Kmett]

I propose that we move the contents of Control.Monad.Instances into
GHC.Base where they will be picked up and distributed by the Prelude.

Discussion deadline: 2 weeks from now (November 24)

== Current State ==

Control.Monad.Instances is currently the canonical source for the following
orphan instances, which involve prelude types, but which were not thought
of at the time Haskell 98 was written.

instance Functor ((->) r) where        fmap = (.)instance Monad ((->)
r) where        return = const        f >>= k = \ r -> k (f r)
rinstance Functor ((,) a) where        fmap f (x,y) = (x, f y)instance
Functor (Either a) where        fmap _ (Left x) = Left x        fmap f
(Right y) = Right (f y)


== The Issues ==

When using almost any library, you wind up transitively importing
Control.Applicative, which imports Control.Monad.Instances and brings them
into scope, so realistically any attempt the user might make to define his
own version of these instances is doomed to failure and pain upon linking
with the larger Haskell ecosystem.

== Proposed Enhancement ==

Control.Monad.Instances has been around for years, so experienced users
have always had access to grab these but the main impact of hiding them in
Control.Monad.Instances from a
POSIWID<http://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does>
perspective
is to confuse newbies.

The potential impact of just doing this right is less than the impact of
changing Num, so I'd say we should just do it, and make
Control.Monad.Instances an empty stub that exists just to avoid breaking
code, and which can be used to support any other missing instances for
Prelude types in the future which _can't_ be merged such as the missing

instance Monoid e => Monad ((,) e) where        return a = (a, mempty)

        (w,a) >>= k = (mappend w w', b)

            where (w',b) = k a

which I'll propose separately.

This would also let us be less careful about importing Control.Applicative
in modules that get fed to the Prelude, which would be an important step in
any eventual refactoring of the Monad class hierarchy to include
Applicative anyways.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20111112/39a4eb47/attachment.htm>