cvs commit: fptools/libraries/base/Control/Monad/X Cont.hs ContT.hs Error.hs ErrorT.hs Fix.hs Identity.hs Monads.hs Nondet.hs NondetT.hs README Reader.hs ReaderT.hs Resume.hs ResumeT.hs State.hs StateT.hs Trans.hs Transformers.hs Types.hs Uti

[Simon Marlow]

=20
> On Tuesday 03 June 2003 11:26 pm, diatchki@glass.cse.ogi.edu wrote:
> >   Added files:
> >     libraries/base/Control/Monad/X Cont.hs [...]
> >   Log:
> >   Added a first version of the new monad library (experimental).
> >   Hopefully one day the "X" will disappear.
>=20
> What's the policy on adding large directory trees of=20
> experimental code to existing libraries like base?

We don't have one.  Yet ;-)

> Some obvious options:
>=20
> 1) Go right ahead - no need to mark it specially
>=20
> 2) Go right ahead but be sure to use an X prefix to warn=20
> people - we'll delete the X once it is finalized.
>=20
> 3) It'd be better to do the development in a separate library tree
>     such as fptools/libraries/newmonads.
>=20
>    a) And give it a name like Unsafe.Control.Monad.Cont
>    b) And give it a name like Org.Diatchki.Control.Monad.Cont
>    c) And give it a name like Control.Monad.Cont
>=20
> I lean towards either (1) or (3) and can't decide between 3a/b/c.
>=20
> (3) seems most in keeping with the push for a library infrastructure.

I agree with either (1) or (3).

(1) is arguably OK because these libraries are currently marked
experimental.

(3a) or (3b) is arguably better because it gives people a chance to
comment on the code before it goes in.  (3c) is the same as (1) except
that the code is physically separate in the repository: I think this is
a good idea regardless, as long as we don't envisage adding dependencies
on the new code into base at some point, which would mean moving it all
back in again.

Summary:

  - The new monad library should go in a package of its own
    (fptools/monads?).

  - I suggest putting it under Unstable for the time
    being, then moving it to the proper place in the hierarchy later,
    deleting the existing Control.Monad.Stuff at the same time.

I know that moving whole libraries around in the hierarchy is painful at
the moment.  Simon P.J. and I have been devoting some brain cycles to
this problem, and we hope to have a proposal soon.

Cheers,
	Simon