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
Wed, 4 Jun 2003 12:25:27 +0100

> On Tuesday 03 June 2003 11:26 pm, 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.
> 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:
> 1) Go right ahead - no need to mark it specially
> 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.
> 3) It'd be better to do the development in a separate library tree
>     such as fptools/libraries/newmonads.
>    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
> I lean towards either (1) or (3) and can't decide between 3a/b/c.
> (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

(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.


  - The new monad library should go in a package of its own

  - 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.