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

[Iavor Diatchki]

Hello,

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.

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.

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.

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.

-Iavor















On Wed, Oct 18, 2017 at 7:08 AM 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. 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20171018/c92e350f/attachment.html>