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