Proposal: Control.Concurrent.Async

[Thomas Schilling]

On 8 June 2012 11:07, Simon Marlow <marlowsd at gmail.com> wrote:
> 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?)