monad library

[Simon Marlow]

Iavor Diatchki writes:
> ... by the way i don't think this would be a problem if=20
> relative names were added to the module system, as a porgrammer could=20
> use an absolute name for the system library, and a relative=20
> name for the=20
> project monads.  but we have already discussed that.

The topic of relative module names is still open...

> it seems that most people don't want the library in Monad.*=20
> so i guess=20
> we should keep it in Control.Monad.*.   then the next=20
> question is when=20
> to replace the current library with the modified one.  i am=20
> not sure of=20
> the user base of the monad library, but i would rather do it=20
> sooner than=20
> later.  i guess i should point out that the "new" library is not much=20
> different from the old one, and with exception of resumptions and the=20
> instances for the Monad* classes for continuations added=20
> after another=20
> transformer things should work fine (those two were not in=20
> the previous=20
> library anyways).  if we keep the library under Unstable*, i=20
> doubt that=20
> anyone would use it, and this will slow down tracking of bugs etc.

So are you saying that it won't break much code, or it won't break any
code?  Either way, I'd be happy for it to be brought in without
providing the old version - we make minor changes to library APIs all
the time (only in new major releases of GHC, though).

> there is also the problem of it being available only from=20
> CVS.  i could=20
> make a package available from my web-page (or some other=20
> page), but then=20
> it would clash with the library in base.  do you think it would be a=20
> good idea to split it from the base package?   base seems=20
> huge as it is already.

Definitely!  Ideally I'd like to see it distributed as a completely
separate package (pending progress on the library distribution work
that's going on).  For now, moving it into a separate package under
fptools/libraries/ would be fine.

Cheers,
	Simon