RE: 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

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.
What's the policy on adding large directory trees of 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 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 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

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

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'd like to strongly recommend copying the Makefiles in the X11 library in fptools/libraries/X11. The key files are: mk/*.mk - you'll want to customize mk/version.mk with the name and version of your package Makefile - where you set the package name mention any subdirectories that contain makefiles (SUBDIRS) mention any subdirectories that contain source code but no makefile (ALLDIRS) mention any package dependencies specify a few extra compilation flags package.conf.in - which you will need to customize very slightly (drop mention of X_CFLAGS) Once you've done that, you can: make boot make all sudo make install # installs in /usr/local/${PACKAGE}-${VERSION} -- Alastair Reid
participants (3)
-
Alastair Reid
-
Iavor Diatchki
-
Simon Marlow