The FunctorM library

Simon Marlow simonmar at microsoft.com
Thu Mar 24 04:44:00 EST 2005


On 23 March 2005 21:28, Iavor Diatchki wrote:

> Hello,
> 
> 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

  -hide-package haskell98

which removes the Haskell 98 libraries from the namespace.  

Cheers,
	Simon


More information about the Libraries mailing list