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

[Ian Lynagh]

Hi all,

I propose that we remove
    Control.Concurrent.QSem
    Control.Concurrent.QSemN
    Control.Concurrent.SampleVar
    Control.Concurrent.mergeIO
    Control.Concurrent.nmergeIO
from base.

Rationale: There is no real need for them to be in base, and they are
not being well-maintained there (e.g. see [3160]). Chris Kuklewicz has
already made a SafeSemaphore package that provides fixed versions of the
3 modules.

Patch is attached (but basically it just removes the above).


Suggested discussion deadline: Fri 22 June 2012.


[3160] http://hackage.haskell.org/trac/ghc/ticket/3160

Thanks
Ian


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Felipe Almeida Lessa]

+1

--
Felipe.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Bas van Dijk-2]

On 7 June 2012 14:46, Ian Lynagh <[hidden email]> wrote:
> I propose that we remove ... from base.

Shouldn't they first get through a deprecation cycle?

+1 for either way.

Regards,

Bas

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Bryan O'Sullivan]

On Thu, Jun 7, 2012 at 10:02 AM, Bas van Dijk <[hidden email]> wrote:

On 7 June 2012 14:46, Ian Lynagh <[hidden email]> wrote:
> I propose that we remove ... from base.

Shouldn't they first get through a deprecation cycle?

I don't see any value to that; it just adds a year of latency.

We have plenty of evidence that "this will break in the next release" warnings are ignored until after that next release, when people who update are finally forced to confront stuff being broken.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ganesh Sittampalam]

On 07/06/2012 18:21, Bryan O'Sullivan wrote:

> On Thu, Jun 7, 2012 at 10:02 AM, Bas van Dijk <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 7 June 2012 14:46, Ian Lynagh <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     > I propose that we remove ... from base.
>
>     Shouldn't they first get through a deprecation cycle?
>
>
> I don't see any value to that; it just adds a year of latency.
>
> We have plenty of evidence that "this will break in the next release"
> warnings are ignored until after that next release, when people who
> update are finally forced to confront stuff being broken.

Deprecation for a release provides a window for people who are
conscientious but would rather have a window in which to deal with this
kind of issue rather than be pressured to fix it immediately so that
their code works with the latest and greatest GHC. This is a particular
issue if you maintain a low-level library.

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.

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.

So +1 for a cycle of deprecation, -1 for immediate removal.

Ganesh

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ben Millwood]

On Thu, Jun 7, 2012 at 6:21 PM, Bryan O'Sullivan <[hidden email]> wrote:

> On Thu, Jun 7, 2012 at 10:02 AM, Bas van Dijk <[hidden email]> wrote:
>>
>> On 7 June 2012 14:46, Ian Lynagh <[hidden email]> wrote:
>> > I propose that we remove ... from base.
>>
>> Shouldn't they first get through a deprecation cycle?
>
>
> I don't see any value to that; it just adds a year of latency.
>
> We have plenty of evidence that "this will break in the next release"
> warnings are ignored until after that next release, when people who update
> are finally forced to confront stuff being broken.
>

I don't think this is fair. We don't notice the cases where people
quietly update the code without making a fuss. I'm +1 on a deprecation
cycle.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Henning Thielemann]

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?

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ian Lynagh]

On Thu, Jun 07, 2012 at 10:24:51PM +0200, Henning Thielemann wrote:
>
> +1 for deprecation cycle.

I don't think a deprecation cycle makes sense in this case:

* Only a handful of packages use these modules/functions
  (according to my very out-of-date copy of hackage, anyway).
* The code is buggy (http://hackage.haskell.org/trac/ghc/ticket/3160)
  so we would like people to stop using it sooner rather than later.
* It is harder for us: We don't have a good way to track tasks that need
  to be done at some point in the future.


Thanks
Ian


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Felipe Almeida Lessa]

Clarifying: my +1 is without deprecation cycle =).

Cheers,

--
Felipe.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Henning Thielemann]

On Thu, 7 Jun 2012, Ian Lynagh wrote:

> On Thu, Jun 07, 2012 at 10:24:51PM +0200, Henning Thielemann wrote:
>>
>> +1 for deprecation cycle.
>
> I don't think a deprecation cycle makes sense in this case:
>
> * Only a handful of packages use these modules/functions
>  (according to my very out-of-date copy of hackage, anyway).

I don't use these modules, too. But I supported the general thoughts by
Ganesh.

> * The code is buggy (http://hackage.haskell.org/trac/ghc/ticket/3160)
>  so we would like people to stop using it sooner rather than later.

The DEPRECATE pragma allows people to tell _how_ they can fix their code.

> * It is harder for us: We don't have a good way to track tasks that need
>  to be done at some point in the future.

fgrep -r DEPRECATE

?

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Edward A Kmett]

+1 with or without a deprecation cycle.

Sent from my iPad

On Jun 7, 2012, at 8:46 AM, Ian Lynagh <[hidden email]> wrote:

>
> Hi all,
>
> I propose that we remove
>    Control.Concurrent.QSem
>    Control.Concurrent.QSemN
>    Control.Concurrent.SampleVar
>    Control.Concurrent.mergeIO
>    Control.Concurrent.nmergeIO
> from base.
>
> Rationale: There is no real need for them to be in base, and they are
> not being well-maintained there (e.g. see [3160]). Chris Kuklewicz has
> already made a SafeSemaphore package that provides fixed versions of the
> 3 modules.
>
> Patch is attached (but basically it just removes the above).
>
>
> Suggested discussion deadline: Fri 22 June 2012.
>
>
> [3160] http://hackage.haskell.org/trac/ghc/ticket/3160
>
> Thanks
> Ian
>
> <safesem.patch>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ben Millwood]

On Thu, Jun 7, 2012 at 9:24 PM, Henning Thielemann
<[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Herbert Valerio Riedel]

Henning Thielemann <[hidden email]> writes:

> Is it possible to import a module from a user package that has the
> same name as a 'base' module?

iirc, this would require the PackageImports GHC language extension[1]:

 [1]: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#package-imports

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[haskell-2]

+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
> <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ian Lynagh]

On Sat, Jun 09, 2012 at 10:26:07AM +0100, Chris Kuklewicz wrote:
>
> 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).

I'm not sure it's worthwhile. In my old copy of hackage there are 0 uses
of these functions, so I don't think they should be in base anyway. And
any change we make has the potential to introduce new bugs, however
confident in it we are.


Thanks
Ian


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ganesh Sittampalam]

On 09/06/2012 09:38, Herbert Valerio Riedel wrote:
> Henning Thielemann <[hidden email]> writes:
>
>> Is it possible to import a module from a user package that has the
>> same name as a 'base' module?
>
> iirc, this would require the PackageImports GHC language extension[1]:
>
>  [1]: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#package-imports

OK, so that's a strike against the deprecation cycle, because people
would need to use this extension in the transition period, or go for
conditional compilation anyway.

I withdraw my objection to immediate removal.

Cheers,

Ganesh

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[wren ng thornton]

On 6/7/12 2:13 PM, Ganesh Sittampalam wrote:
> So +1 for a cycle of deprecation, -1 for immediate removal.

Ditto. I don't know that any of these are actually in widespread use,
but I'm against setting the precedent.

--
Live well,
~wren

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ben Millwood]

On Sat, Jun 9, 2012 at 8:18 PM, Ganesh Sittampalam <[hidden email]> wrote:

> On 09/06/2012 09:38, Herbert Valerio Riedel wrote:
>> Henning Thielemann <[hidden email]> writes:
>>
>>> Is it possible to import a module from a user package that has the
>>> same name as a 'base' module?
>>
>> iirc, this would require the PackageImports GHC language extension[1]:
>>
>>  [1]: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#package-imports
>
> OK, so that's a strike against the deprecation cycle, because people
> would need to use this extension in the transition period, or go for
> conditional compilation anyway.
>
> I withdraw my objection to immediate removal.
>

Not if we just change the module names (note SafeSemaphore at the
moment has different module names anyway).

As a sidenote, the name SafeSemaphore is kind of silly if there's no
dangerous semaphore...

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Simon Marlow-7]

On 07/06/2012 13:46, Ian Lynagh wrote:

>
> Hi all,
>
> I propose that we remove
>      Control.Concurrent.QSem
>      Control.Concurrent.QSemN
>      Control.Concurrent.SampleVar
>      Control.Concurrent.mergeIO
>      Control.Concurrent.nmergeIO
> from base.
>
> Rationale: There is no real need for them to be in base, and they are
> not being well-maintained there (e.g. see [3160]). Chris Kuklewicz has
> already made a SafeSemaphore package that provides fixed versions of the
> 3 modules.

I was going to import Chris's STM versions from #3160 to fix the
outstanding bugs, but I'm also fine with removal.  We probably should
DEPRECATE for a cycle though, tempting as it is to just remove them
immediately.

Cheers,
        Simon

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ian Lynagh]

On Thu, Jun 07, 2012 at 01:46:28PM +0100, Ian Lynagh wrote:
>
> I propose that we remove
>     Control.Concurrent.QSem
>     Control.Concurrent.QSemN
>     Control.Concurrent.SampleVar
>     Control.Concurrent.mergeIO
>     Control.Concurrent.nmergeIO
> from base.

I've just deprecated them for now, with a message saying they'll be
removed in GHC 7.8, and pointing at SafeSemaphore.


Thanks
Ian


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries