[ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension?

[Richard Eisenberg]

I think with one tweak, Roman and I could be in nice agreement: list only a subset of extensions as stable. For example, I think RankNTypes is nice and stable. Depending on your level of tolerance for possible problems, GADTs might also be stable. (We *don't* have a specification of that extension, despite trying.) I don't think anyone would argue that PolyKinds is stable, even before GHC 8 came along.

Would that satisfy everyone? GHC can advertise a subset of extensions for which Simon M's (1) and (2) hold; the rest of the extensions are like Simon M's (3). We, as a committee, are responsible for this labeling and for keeping it up to date. Perhaps we could even have a public place where users could request that we label some extension as stable and we could consider the request.
 
Richard

> On Oct 18, 2017, at 3:36 PM, Roman Leshchinskiy <rleshchinskiy at gmail.com> wrote:
> 
> On Wed, Oct 18, 2017 at 3:08 PM, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>> 
>>> On Oct 18, 2017, at 2:44 AM, Roman Leschinskiy <rleshchinskiy at gmail.com> wrote:
>>> 
>>> GHC commits to supporting this semantics for, say, 4 years.
>> 
>> This is a very large commitment, in my view.
> 
> It is indeed a commitment but there must be some commitment to
> stability. If the Haskell' committee came up with Haskell 2017, surely
> GHC would commit to supporting that. Alas, that isn't happening but
> there has to be a stable language which goes beyond Haskell 2010. It
> would be good if GHC took some initiative there.
> 
> I do very much appreciate that it's more work but it's something that
> an industrial-strength compiler like GHC ought to provide, in my view.
> 
> Imagine you have a very large code base, a large team working on it
> and other teams which work on bits of it. To maintain sanity, you have
> to ensure that everything is written in one dialect. You might pick
> Haskell 2010 but you'd be missing a lot of fairly crucial (at least,
> in my view) functionality. So you pick a blessed set of extensions
> which you enable by default and you disable everything else.
> 
> Now, after a couple of years you decide to upgrade GHC. This is
> already a lot of work due to changes in RTS behaviour, dynamic
> linking, memory consumption etc. You'd *really* like your code to at
> least still compile and run. At the moment, it typically doesn't,
> unfortunately.
> 
>> For example, there have been quite a few bugs in keeping -XTypeInType and -XPolyKinds separate, and I don't think we have it fully working yet.
> 
> This is (I think) exactly a case where, say, an -XPolyKinds-2017 would
> be helpful. It's not a problem if it turns on more than just
> PolyKinds. What's problematic is if a later version of GHC breaks your
> code because the meaning of the extension changed (even if it's now
> more correct than it used to be).
> 
> Note that I don't advocate bug compatibility. I'd just like to be able
> to enable -XThis and have the assurance that GHC devs will *try* to
> maintain its semantics for a few years.
> 
>> Yes, that team will occasionally want to upgrade, but upgrading will always cause some problems, problems that we as the GHC committee will work to mitigate. Until we take Java's approach to backward compatibility (I hope that's a long long way off!), upgrading will cause problems, no matter which of (1)-(4) we adopt.
> 
> There will always be some problems, yes, but problems like "20 modules
> sprinkled throughout my code base fail with weird type errors because
> -XThis no longer implies -XThat" are unnecessary and can be largely
> avoided by providing a stable dialect.
> 
> How often you can upgrade GHC directly depends on how much pain an
> upgrade causes. For at least one commercial user, that frequency is
> currently around once every 3 years solely because of how painful
> upgrades are.
> 
> Of course, the real fix for this is to have a proper language
> standard. I'm just proposing a partial workaround for not having one.
> 
> Roman