The FunctorM library
simonmar at microsoft.com
Thu Mar 24 04:44:00 EST 2005
On 23 March 2005 21:28, Iavor Diatchki wrote:
> On Wed, 23 Mar 2005 15:51:04 +0000, Ross Paterson
> <ross at soi.city.ac.uk> wrote:
>> On Wed, Mar 23, 2005 at 09:49:43AM -0000, Simon Marlow wrote:
>>> Does anyone else have any comments on the suggestions from Iavor and
>>> Thomas in this thread? I'm happy to make changes, but only if
>>> there's a concensus. The proposals so far seems to be
>>> 1) add dist method
>>> 2a) make Functor a superclass of FunctorM
>>> 2b) make Functor a *sub*class of FunctorM
>>> 2c) make Functor a subclass of Monad
>>> 2d) make Functor a superclass of Monad
> Just to avoid confusion I think the suggestions were:
> class Functor f => Monad f where ...
> class Functor f => FunctorM f where ...
> I know the first one differs from the Haskell report, but perhaps this
> is a flaw in the library design that should be fixed. The practical
> concern is compatability with existing programs, but if a program
> breaks at all it should be very easy to fix --- at most one line per
> monad instance, and a Haskell implementation will be able to pinpoint
> the missing instances.
This means making a pretty big step: we would be deliberately removing support for some valid Haskell 98 programs. That's a bit radical IMHO.
We could make Monad.Monad (the Haskell 98 version) a different class from Control.Monad.Monad to keep support for Haskell 98 code. This would break some code too - but maybe that's not such a bad thing, we want people to move away from the Haskell 98 non-hierarchical libraries anyway.
In fact, I think (for GHC users at least) we should be advocating writing new code using the option
which removes the Haskell 98 libraries from the namespace.
More information about the Libraries