See my response on http://hackage.haskell.org/trac/ghc/ticket/6032#comment:6 Not sure what the best path is here S | -----Original Message----- | From: Johan Tibell [mailto:johan.tibell@gmail.com] | Sent: 19 October 2012 17:39 | To: Simon Peyton-Jones | Cc: Don Stewart; Duncan Coutts; Roman Leshchinskiy; | ashley@semantic.org; cabal-devel@haskell.org; Ben Lippmeier; Manuel M T | Chakravarty; cvs-ghc@haskell.org | Subject: Re: deprecating | | Hi Simon, | | On Fri, Oct 19, 2012 at 4:49 AM, Simon Peyton-Jones | wrote: | > As discussed in Trac #6032 I am deprecating | > | > Rank2Types | > | > PolymorphicComponents | > | > in favour of the single flag | > | > RankNTypes | | I'm fine with making the changes to cabal, but before I do, I want to | make sure that we really want to do this. I did a quick investigation | of how many modules need to be updated on Hackage. It's about 775. | That will require quite a lot of work by quite a lot of people. Could | we instead have Rank2Types be an alias for RankNTypes? | | Cheers, | Johan

On Fri, Oct 19, 2012 at 09:38:44AM -0700, Johan Tibell wrote:

Hi Simon,

On Fri, Oct 19, 2012 at 4:49 AM, Simon Peyton-Jones wrote:

...

As discussed in Trac #6032 I am deprecating

Rank2Types

PolymorphicComponents

in favour of the single flag

RankNTypes

I'm fine with making the changes to cabal, but before I do, I want to make sure that we really want to do this. I did a quick investigation of how many modules need to be updated on Hackage. It's about 775. That will require quite a lot of work by quite a lot of people. Could we instead have Rank2Types be an alias for RankNTypes?

"What will be the least work?" seems a relatively poor basis for making decisions. And it really isn't "quite a lot of work". Changing "Rank2Types" to "RankNTypes" is hardly any work at all. -Brent

Based on repeated recent experience, I expect getting rid of Rank2Types to be another substantial source of make-work for library authors. The GHC upgrade path has been very bumpy indeed recently, and this seems assured to continue that unhappy trend. I respectfully request that you silently retain Rank2Types as a synonym for RankNTypes. Do you mean “silently and forever”? Deprecation simply means that everything continues to work, but you get a little nudge to change. Isn’t that what it’s for? If you treat deprecation as equivalent to error, then there isn’t much point in having it. It’s possible that making Rank2Types = RankNTypes silently and forever is the right answer. It just doesn’t feel right to me. But I’m not a library author and I don’t feel terribly strongly. Simon From: Bryan O'Sullivan [mailto:bos@serpentine.com] Sent: 22 October 2012 17:06 To: Simon Peyton-Jones Cc: johan.tibell@gmail.com; Don Stewart; Duncan Coutts; Roman Leshchinskiy; ashley@semantic.org; cabal-devel@haskell.org; Ben Lippmeier; Manuel M T Chakravarty; cvs-ghc@haskell.org Subject: Re: deprecating On Fri, Oct 19, 2012 at 11:49 AM, Simon Peyton-Jones mailto:simonpj@microsoft.com> wrote: Dear maintainers of bytestring cabal vector time dph Hi, Simon - How did you come up with this list? It is missing the vast majority of users of Rank2Types. Most people embed language pragmas directly into the source files that use them, so grepping .cabal files is going to massively undercount users of any given feature. Based on repeated recent experience, I expect getting rid of Rank2Types to be another substantial source of make-work for library authors. The GHC upgrade path has been very bumpy indeed recently, and this seems assured to continue that unhappy trend. I respectfully request that you silently retain Rank2Types as a synonym for RankNTypes. Thanks, Bryan.

On Mon, Oct 22, 2012 at 4:14 PM, Simon Peyton-Jones wrote:

Do you mean “silently and forever”?

I think that's what I mean, yes. As Johan notes, many of us run our continuous builds of our packages with -Wall -Werror in order to keep them as clean as possible. Introducing a deprecation thus forces me into some kind of response as my builds all suddenly fail: I can either turn off -Werror for a package, or edit the affected source files. I'm not arguing that the compiler shouldn't be improved, but seemingly trivial changes like the above deprecation can and do now come with surprisingly expensive consequences for users of the compiler. I noted that when catch got dropped from Prelude during the 7.6 cycle, it took me almost two weeks of spare time to fix up all of the build errors in packages I wrote, and somewhat longer to sort out build problems in packages maintained by other people. Some breaking changes are clearly worthwhile; others are clearly not; and there are plenty more on the continuum between the two. This particular one seems closer to the "clearly not worth it" end of the spectrum: not trivially obviously a bad idea, but in my opinion definitely not worth the disruption it threatens.