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

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 wrote:

On Wed, Oct 18, 2017 at 3:08 PM, Richard Eisenberg wrote:

...

...

On Oct 18, 2017, at 2:44 AM, Roman Leschinskiy 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