Ross Paterson
On Fri, Jul 25, 2003 at 12:40:22AM +0200, Iavor Diatchki wrote:
2. currently the monad library is under Unstable.Control.Monad, and i would like to move it to some other place, so that we can use it, without the need to later rename everything. the core of it should be more or less stable. since moving libraries at the moment is quite work intensive, it would be nice if we agreed on where to put it, so that we don't have to move it again. i propose that we put all the monads under Monad,
You're asking for a new top-level name Monad. My implession from SimonM's library document is that the intention is that top-level names are to be limited (and certainly only added by agreement).
I too would be very reluctant to allocate new top-level names. Monads already have a place in the hierarchy, so the question here is really about the process for deprecating one existing API and replacing it with a new API. I don't have a solution to this issue. However, it is clear that allocating a new namespace every time an API is improved, is a recipe for confusion amongst users when they search for "the" API without a knowledge of the social history. Iavor wants to move the library now, so that people don't have to rename their imports later. But the implication is that the library is still rather experimental, still a little unstable, and what you really want is to encourage more users to actually try it and report on their experience. So my conclusion is that the API is still likely to change anyhow, and so changing the import location later is only a very minor extra hardship. I would say let people use it first, gain more experience with it, refine the API further, and only once it has achieved stability (by the consensus of the community that uses it) should it move into the "main" hierarchy to replace the existing Control.Monad. (At that point, maybe the existing Control.Monad hierarchy should become Control.Monad.Old, with the understanding that it will disappear altogether at a later date?) Regards, Malcolm