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

[Chris Kuklewicz]

+1 for removing those modules from base, immediately.

The operations:
    Control.Concurrent.mergeIO
    Control.Concurrent.nmergeIO
I will discuss at the end of this message (TL;DR they can be fixed and left).

As the author of SafeSemaphore, I did have a patch [1] for QSem et al to fix
them.  That has been ready to go for a while.  There does not need to be a
deprecation cycle because a separate QSem et al package would be a drop-in
replacement.  The modules in SafeSemaphore are generalized and expanded.

I think removing modules from base is (nearly) always an improvement.  The only
downside is managing conflicting versions and that is what haskell-platform and
improvements to cabal are for.

[1] patch in http://hackage.haskell.org/trac/ghc/ticket/3160  (with new tests)

The mergeIO and nmergeIO operations are implicated because they use QSem.  This
is used with a quantity of max_buf_size = 1.   The pattern of usage is
'waitQSem' followed later by 'signalQSem'.  It looks like the whole QSem behaves
exactly like an MVar ().  If this is true then these could be quickly patched
and left in place.

-- 
Chris Kuklewicz

On 2012/06/08 17:48, Ben Millwood wrote:
> 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.
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries