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

[Richard Eisenberg]

> 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. Maintaining subtle differences in extensions is hard work, especially when the differences are not syntactic (which are admittedly much easier). 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.

There's one unstated assumption behind all this, for me: we're very, very, very cautious about ever changing the *dynamic* semantics (i.e. runtime behavior) between releases. That's potentially disastrous. It's annoying and frustrating when one version of GHC accepts a program while another rejects. But someone downstream can work around this, either with CPP or with cabal/stack settings that dictate GHC versions. However, a runtime behavior change might go uncaught and cause real bugs. So, when I say I advocate for Simon M's (3), I really mean

4. LANGUAGE tells the compiler what extensions are required and -- if the program is accepted -- its runtime behavior, but otherwise provides no guarantees. The source file might not compile with a given version of GHC even if it supports all the extensions listed. In other words, LANGUAGE together with a GHC version range specifies the grammar and static semantics of the source file. However, LANGUAGE alone (without the version range) specifies the runtime behavior of any resulting code.

(This is just a small delta on Simon M's (3) with clarity around runtime behavior.)

I'd love feedback from the more industrial users here. It's unsurprising that, from my viewpoint, I would advocate for looser guarantees. But part of why I think looser guarantees are OK is that I thought Stack had basically solved this problem for industrial users, in that several collaborators on a project have a stack.yaml that (among other things) fixes the GHC version. 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.

Richard