Hi
On the other hand, having something available in the containers package for everyone to experiment with seems a good way to evolve towards a better design.
I'd still vote for adding the module, and flag it with "experimental" stability if there are worries of instability.
If you want to mark it as experimental, it should not be in the core libraries. Evolving designs are great, but libraries@ should not be the maintainer of such a module. I'm not sure if that is a general policy, but I would be surprised to hear if it was a minority opinion.
Well if this is the common agreement then I will withdraw my proposal. Maintaining a single module package floating around is too much effort for me. I prefer to keep a local copy in the projects that need it instead of maintaining an extra dependencies and to force the users to download extra software. I am sorry for the wasted time and effort.
I think that's a real shame. Maintaining a cabal package is relatively little effort. I have several packages which are just one module long (see for example Safe - which is not only one module, but every definition within it is only one line!). With cabal-install, the extra effort to install dependencies is literally nothing - its all handled automatically. And once you've got some users, and some varied experience of using the library, then I think making a library proposal would be a good idea. Thanks Neil