When you take a top-level name for a library, the programmer is prevented from using that top-level name for modules in a program. I'd prefer to keep the top-level Monad name for monads in the current program, rather than a generic Monad library.

... So my vote goes to keeping the current Control.Monad name for the library. it seems that most people don't want the library in Monad.* so i guess we should keep it in Control.Monad.*. then the next question is when to replace the current library with the modified one. i am not sure of

hello, Simon Marlow wrote: this is a relevent point. i am not sure if it is a good idea to put all your monads in a monad directory, but i guess some programmers might want to do it. by the way i don't think this would be a problem if relative names were added to the module system, as a porgrammer could use an absolute name for the system library, and a relative name for the project monads. but we have already discussed that. the user base of the monad library, but i would rather do it sooner than later. i guess i should point out that the "new" library is not much different from the old one, and with exception of resumptions and the instances for the Monad* classes for continuations added after another transformer things should work fine (those two were not in the previous library anyways). if we keep the library under Unstable*, i doubt that anyone would use it, and this will slow down tracking of bugs etc. there is also the problem of it being available only from CVS. i could make a package available from my web-page (or some other page), but then it would clash with the library in base. do you think it would be a good idea to split it from the base package? base seems huge as it is already. bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================