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

[Roman Leshchinskiy]

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