Iavor Diatchki writes:
... 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 topic of relative module names is still open...
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 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.
So are you saying that it won't break much code, or it won't break any code? Either way, I'd be happy for it to be brought in without providing the old version - we make minor changes to library APIs all the time (only in new major releases of GHC, though).
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.
Definitely! Ideally I'd like to see it distributed as a completely separate package (pending progress on the library distribution work that's going on). For now, moving it into a separate package under fptools/libraries/ would be fine. Cheers, Simon