Clarifying: my +1 is without deprecation cycle =). Cheers, -- Felipe.

On Thu, Jun 7, 2012 at 10:02 AM, Bas van Dijk wrote:

On 7 June 2012 14:46, Ian Lynagh 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.

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?

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 ?

+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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Henning Thielemann 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#pa...

On Sat, Jun 9, 2012 at 8:18 PM, Ganesh Sittampalam wrote:

On 09/06/2012 09:38, Herbert Valerio Riedel wrote:

...

Henning Thielemann 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#pa...

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...

On Thu, Jun 7, 2012 at 6:21 PM, Bryan O'Sullivan wrote:

On Thu, Jun 7, 2012 at 10:02 AM, Bas van Dijk wrote:

...

On 7 June 2012 14:46, Ian Lynagh 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.

On Sat, Jun 23, 2012 at 5:49 AM, Ian Lynagh wrote:

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.

Cabal uses QSem so I think we'll have to merge in some code from SafeSemaphore as we cannot depend on that package.

On 11/12/12 8:40 PM, Ian Lynagh wrote:

You mean cabal-install rather than Cabal, presumably?

...

so I think we'll have to merge in some code from SafeSemaphore as we cannot depend on that package. Why not? It's the same code, regardless of whether it is in base, cabal-install or SafeSemaphore. Looks like SafeSemaphore has almost the same module names too.

Sounds like a strong motivation to me to include SafeSemaphore in the Haskell platform? --Gershom