Proposal: Remove Control.Concurrent{QSem, QSemN, , SampleVar, mergeIO, nmergeIO} from base

[Ben Millwood]

On Thu, Jun 7, 2012 at 9:24 PM, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
>
> On Thu, 7 Jun 2012, Ganesh Sittampalam wrote:
>
>> As a more general point, a principle of breaking things immediately also
>> makes it very hard for people who want to support multiple versions of
>> GHC or the platform. Even one release worth of deprecation is quite
>> difficult if the replacement is introduced in version x and the obsolete
>> version removed completely in version x+1, since there is nothing that
>> will work in x-1, x and x+1. If you want your software to build in
>> Debian sta[b]le as well as the bleeding edge, supporting three versions
>> is often necessary.
>
>
> +1 for deprecation cycle.
>
>
>> In this case the replacement is an external library so can in theory be
>> adopted immediately, but a maintainer would need to be following this
>> list to know about the need to do so.
>
>
> Is it possible to import a module from a user package that has the same name
> as a 'base' module?
>

Well, presumably this won't be an issue - either you'll use old base
with the old module, or new base and an external package, and in each
case there's only one copy of the module. You could use Cabal to
conditionally include one or other of the packages. Alternatively we
could just change the module name.

This of course requires that we have an external package that is a
drop-in replacement ready to go. If we do that, I'm okay with us not
having a deprecation cycle.