The FunctorM library

[Iavor Diatchki]

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.

> >   3) rename FunctorM class to ForEach
I was suggesting here that we rename the method to "forEach" and swap
the order of the arguments.   The reason I suggested this is that I
find myself writing code like this a lot:

mapM (\x ->
  do ... some monadic ...
     ... code goes here ...
) xs

this look better in this form:

forEach xs (\x ->
  do ... some monadic ...
     ... code goes here ...
)

> As long as we remember that it's not always a distributive law (join
> law fails, e.g. for []),

I am not familiar with this law, what does it say?


> and fmapM doesn't always define a functor
> (doesn't preserve composition of Kleisli arrows).

I am not sure what you mean, why should "fmapM" define a functor?
The two constructors "f" and "m" should already be functors.

> The placement in the hierarchy is a bit wierd.  Another possibility
> (that you suggested earlier) is Data.Functor.

I have no strong feelings about where things are placed in the
hirarchy, but lately everything seems to end up under "Data".  If we
want to have things that are relevant to just functors perhaps we
should place them in a file (or directory) called "Functor".  Same for
"Monad".  The good thing about using esoteric names is that they are
not likely to clash with anything :-)

-Iavor