<div dir="ltr">Hello,<div><br></div><div>in my view, there are two slightly different issues here: 1) experimenting with language changes, and 2) having a "modular language". We are using a single mechanism---`language` pragmas---to achieve both, which is where the tension lies. When language extensions are first born, they seem to be very much in use case 1) and I think we should allow ourselves to change them, improve them, and even remove them. I also find use case 2 quite useful: I sometimes think of GHC as implementing a family of languages, made out of modular blocks that all work well together, and `language` pragmas in a module document which language configuration is being used. I think that's very cool and makes GHC somewhat unique.</div><div><br></div><div>Given that we have to balance these two goals, my preference would be that we adopt option (3) where we do allow some changes to extensions, but be cautious if these might seriously conflict with options (1) and (2). So we'd have to exercise judgment on a case by case basis.</div><div><br></div><div>To be honest, I don't really like the idea of having versions for extensions---I'd rather simply have different names for them if that's what we'd like to do.</div><div><br></div><div>Here is another idea which might help with this problem somewhat (and I've wanted something like this for other reasons too): we could provide a mechanism for naming sets of language extensions. If we had such a mechanism, I'd be a lot keener on simply adding new extensions, rather than modifying old ones. This would allow us to specify various language standards succinctly---as simply a collection of language extensions, and it would also allow companies or projects to have their own sets of "approved" extensions. Finally, in GHC some extensions already behave a little like this, in that some extensions automatically enable others---it would be nice if one could look up these definitions somewhere, without having to look in the compiler's source code.</div><div><br></div><div>-Iavor</div><div><br></div><div> </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 18, 2017 at 7:08 AM Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu">rae@cs.brynmawr.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Oct 18, 2017, at 2:44 AM, Roman Leschinskiy <<a href="mailto:rleshchinskiy@gmail.com" target="_blank">rleshchinskiy@gmail.com</a>> wrote:<br>
><br>
> GHC commits to supporting this semantics for, say, 4 years.<br>
<br>
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.<br>
<br>
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<br>
<br>
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.<br>
<br>
(This is just a small delta on Simon M's (3) with clarity around runtime behavior.)<br>
<br>
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.<br>
<br>
Richard<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>