
| I thought the point of these extension flags was to be cross-compiler?
| So it seems a bit odd to make a change for the benefit of one compiler.
|
| Here's my interpretation: Rank2Types is not a synonym for RankNTypes.
| It's a specific requirement the source file has. When GHC comes to
| compile it, it can satisfy that requirement by switching on its
| RankNTypes. Another compiler might support Rank2Types but not
| RankNTypes, and it would also be able to compile the file.
The trouble is that it's painful to check that a program uses rank-2 *only*, which is what you might naively think of the flag. So rather than fiddle about with distinctions that no one really cares about, the idea is to abolish the distinction.
But if the will of the masses is to silently and forever make Rank2Types=RankNtypes (documented of course), that's ok with me. It just seems odd. I thought that's what deprecation was *for*.
Simon
|
| -- Ashley
|
| On 19/10/12 09:53, Simon Peyton-Jones wrote:
| > 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
| > |

On Mon, Oct 22, 2012 at 4:52 PM, Simon Peyton-Jones
But if the will of the masses is to silently and forever make Rank2Types=RankNtypes (documented of course), that's ok with me. It just seems odd. I thought that's what deprecation was *for*.
An alternative would be to have a mechanism for saying "-Wall -Werror, except for these cases". I think maybe -fwarn-warnings-deprecations is intended to do that, though really what I want to be able to say is "suppress *only* warnings about the deprecation of thing X" or perhaps "continue to issue a warning about this, but don't make it an error even if -Werror". Obviously having granularity that fine comes with a cost in implementation complexity (and it's not exactly a fun feature to work on), so I'm suggesting that this be done so much as exploring the solution space. (This is the sort of granularity that many commercial compilers provide.)
participants (2)
-
Bryan O'Sullivan
-
Simon Peyton-Jones