On 8 June 2012 11:07, Simon Marlow
On 08/06/2012 10:41, Michael Snoyman wrote:
What's the advantage to putting this in base instead of a separate package? If it goes in base, it will make it more difficult to upgrade, and take longer for this module to be adopted at all. If possible, I'd opt for a standalone package.
Uploading it to Hackage is certainly an option, and there are arguments in both directions. My thinking was:
- it's a bit small for a package by itself. There's a lot of overhead for a package (github repo, Haskell Platform proposal, issue tracker, blah blah)
- To avoid further fragmentation, I would like this package to be more visible, especially if we go to the trouble as a community of building some consensus around it.
- The obvious package name 'async' is already taken
I am very much against putting things into base unless there is a *very* good argument to do this. If it is supposed to be *the* standard package, then it belongs into the platform, not base. If the platform process is too heavy-weight to discourage this path, then we need to do something about that rather than sneak things in through the base library. It already is a pain to work around issues in the base library (and many other core packages) since it's (a) takes a long time for an update to be released, and (b) cannot be upgraded independently from GHC (pulling in all the changes to other libraries as well). I'm glad that the name issues is resolved. If it is a small library a platform addition proposal shouldn't be too difficult either. We just have to beware of too much bike shedding. (BTW, have we had another platform proposal since the text package?)