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

[Iavor Diatchki]

hello,

>What's the policy on adding large directory trees of 
>>experimental code to existing libraries like base?
i was wondering about that too.

>>Some obvious options:
>>
>>1) Go right ahead - no need to mark it specially
well, i though of doing that, but it seemed that there are people out 
there actually using the library and the new one is not 100% compatable 
with the old one.

>>2) Go right ahead but be sure to use an X prefix to warn 
>>people - we'll delete the X once it is finalized.
this is what i did, but i don't like it very much.

>>3) It'd be better to do the development in a separate library tree
>>    such as fptools/libraries/newmonads.
to me this also seems like the best idea.  especially since "base" is 
very big at the moment.

>>   a) And give it a name like Unsafe.Control.Monad.Cont
Unstable sugested by simon is perhaps better, as the library is not 
unsafe in the "unsefePerfomrIO" sense.

>>   b) And give it a name like Org.Diatchki.Control.Monad.Cont
i don't like this whole using people's names business. it seems to me 
kind of like if linux asked you to type "linus torvalds" every time you 
used your computer :-) i've been following the other discussion and hope 
that something better comes up.
(although having a weird name like mine helps with the uniqueness :-)

> 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.
ok, i'll do that. i am not 100% on the ghc build system, but i'll copy 
and modify some of the other make files, they seems more or less 
understandable.

> 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.
that would be great.

bye
iavor