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

Roman Leschinskiy rleshchinskiy at gmail.com
Wed Oct 18 06:44:32 UTC 2017 

How about we take Richard’s suggestion and replace version numbers by years? So we have TypeOperators-2017, TypeFamilies-2017 etc. mean exactly what they mean now. GHC commits to supporting this semantics for, say, 4 years. In 4 years, we drop support for the 2017 extensions and introduce 2021 extensions, again with a 4 year commitment. Meanwhile, just TypeOperators without a year can freely change its meaning.

This allows people who care about stability to have it while not impacting cutting edge.

Roman

> On 18 Oct 2017, at 04:19, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> 
> Yes, this is a very important question.
> 
> Naturally, (2) makes the theorist in me very happy. But I advocate for (3), regardless:
> 
> - This debate isn't only about extensions. As has been pointed out, `base` undergoes a non-trivial amount of churn between releases, and considering the compiler in a vacuum isn't realistic. Two versions of the compiler will accept (slightly) different versions of the language. (Or, in the case of GHC 7.8, drastically different versions of the language.)
> 
> - I think we're handicapping ourselves at creating a cutting-edge language if we adopt (1) or (2). (3) allows us to, well, move fast and break things, and that model has been very successful for Haskell thus far.
> 
> - Who gets hurt if we choose (3)? Surely, (3) means that, e.g., cabal files should properly specify GHC ranges. And we should aim for Simon M's original comment that evolution only adds features -- but we'll never really meet that standard, I don't think.
> 
> - We could adopt versioned extensions, as I've previously brought up. Doing so might move us more toward (1) or (2). However, I would expect a version of GHC to support only one version of a given extension, and so then a file with, say, `{-# LANGUAGE PolyKinds-3 #-}` would be acceptable by only a small compiler version range (possibly containing only one major release), and then what will we have gained?
> 
> - I like the idea of having the manual state the stability of extensions. (We should also state unambiguously the potential downside of extensions -- like declaring that UndecidableInstances may cause GHC to loop, but it doesn't allow you to shoot the gorillas.) But I don't think that an extension has to be set in stone after only two revisions. Sometimes experiments really do take years to carry out! So, I like the idea of alpha/beta/stable, but (in contrast to Manuel) I would let the feature designers choose when it's time to move the needle.
> 
> Looking forward to seeing others' thoughts on this,
> Richard
> 
>> On Oct 17, 2017, at 6:30 AM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
>> 
>> I completely agree with Simon: this is an important question.
>> 
>> I think, it would be good to have at least (1), but better (2). 
>> 
>> Why? Because Haskell’ really doesn’t get anywhere and in its absence the guarantees provided by GHC are the only language stability there is. Maybe it is unfair to put this burden on the compiler, instead of on a separate language specification, but that is how it is.
>> 
>> Now, I reckon the main obstacle to (1) and (2) is that LANGUAGE extensions, when they appear first, are in flux, because they are often parts of experiments. Hence, I’d like to suggest that we might be able to lessen the tension between experimentation and stability by formally associating a ”stability” of one of  ”alpha”, ”beta”, or ”stable” with each extension.
>> 
>> As we all know, these stability annotations don’t work at all on Hackage as nobody ever moves their packages away from ”experimental”. Hence, I suggest that we do not make this the choice of the person who proposes an extension, but part of our process. There are a few options, which might be worth considering.
>> 
>> For example, when a LANGUAGE extension is first proposed, it starts at ”alpha”. When latter a proposal is submitted to amend the extension, that amendment is approved by us only if it successfully argues that it improves the maturity of the extension such that it warrants ”beta” stability. And then, the same with ”stable” on the second amendment. Finally, ”stable” language extensions cannot be changed unless it is to fix a grave semantic error or similar.
>> 
>> Instead (or in addition) of bumping stability on every new proposal involving the extension, we could also adopt a time (or release) based scheme.
>> 
>> Cheers,
>> Manuel
>> 
>> PS: BTW, we are pushing for getting to 6 monthly release of GHC. This means that without any guarantees across versions, we would potentially increase variability, which would be bad.
>> 
>>> Simon Marlow <marlowsd at gmail.com>:
>>> 
>>> The main reason I took a position on the issue of extension flags is to force the question: what should LANGUAGE mean? I think it's important to resolve this, to inform future decisions. Here are some options:
>>> 
>>> 1. LANGUAGE fully specifies the grammar of the source file
>>> 2. LANGUAGE fully specifies the grammar and semantics of the source file
>>> 3. LANGUAGE tells the compiler what extensions are required, 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 semantics of the source file.
>>> 
>>> I think what we have right now is 3, because we change the meaning of extensions from version to version of GHC. There are advantages to 1 and 2: for example, if we had 1, then we could parse all of Hackage with haskell-src-exts (or at least identify the subset of source files that can be parsed via their LANGUAGE pragmas). If we had 2, then we could parse, rename and typecheck all of Hackage using haskell-src-exts, haskel-names, and haskell-type-exts.
>>> 
>>> Perhaps we want to say that we can only *add* syntax to an existing extension, not change or remove it. This is a variant of 3 that requires only a lower bound on the GHC version required, not an upper bound, and it provides some of the benefits of 1 and 2: you just need a sufficiently recent version of haskell-src-exts et. al.
>>> 
>>> Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE means. If we believe the implications of 1 and 2 are too onerous (never changing extensions), so what we want is 3, so be it.
>>> 
>>> Cheers
>>> Simon
>>> 
>>> 
>>>> On 10 October 2017 at 03:54, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> Hello,
>>>> 
>>>> my preference would be to add this to one of the existing extensions (either "explicit namespaces", or "type level operators").     
>>>> 
>>>> Iavor
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner <mail at joachim-breitner.de> wrote:
>>>>> Hi Committee,
>>>>> 
>>>>> the discussion has ebbed down again. I observe that a clear majority is
>>>>> in favor. I don’t think there is a need for a formal vote, so I will
>>>>> proceed with this decision.
>>>>> 
>>>>> Simon M brought up the next issue: Shall we require a separate language
>>>>> extension for this, or can it go under the hood of
>>>>> `ExplicitNamespaces`?
>>>>> 
>>>>> So far Simon M expressed a strong preference for the former, while I am
>>>>>  inclined to prefer the latter, and would like to hear a few more
>>>>> opinions on this detail (which certainly would set precedence for
>>>>> future decisions).
>>>>> 
>>>>> Richard brought up the idea of versioned language extensions; that idea
>>>>> can certainly be investigated, but better independently. We have to
>>>>> deal with this proposal with the tools we have.
>>>>> 
>>>>> Greetings,
>>>>> Joachim
>>>>> 
>>>>> 
>>>>> Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner:
>>>>> > Hi,
>>>>> >
>>>>> > the type fixity proposal
>>>>> > (https://github.com/ghc-proposals/ghc-proposals/pull/65)
>>>>> > was met with mixed reactions.
>>>>> >
>>>>> >  * I recommended rejection and Manuel strongly agrees with me.
>>>>> >  * SPJ does not have strong opinions either way.
>>>>> >  * Richard is in favor, and Iavor agrees.
>>>>> >
>>>>> >
>>>>> > Our process says “If consensus is elusive, then we vote, with the
>>>>> > Simons retaining veto power.” It looks like this might be such a case.
>>>>> > Should we go ahead and vote, or is more discussion likely to sway some
>>>>> > of us?
>>>>> >
>>>>> > (I guess I can be swayed towards acceptance, especially if this
>>>>> > proposal re-uses existing syntactic idioms from export lists with
>>>>> > ExplicitNamespaces on.)
>>>>> >
>>>>> > Greetings,
>>>>> > Joachim
>>>>> >
>>>>> >
>>>>> >
>>>>> > Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:
>>>>> > > Dear Committee,
>>>>> > >
>>>>> > > Ryan Scott’s proposal to allow fixity declaration to explicitly target
>>>>> > > values or types has been brought before us:
>>>>> > > https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst
>>>>> > > https://github.com/ghc-proposals/ghc-proposals/pull/65
>>>>> > >
>>>>> > > I (the secretary) nominates myself as the shepherd, so I can right away
>>>>> > > continue giving a recommendation.
>>>>> > >
>>>>> > > I propose to reject this proposal. The main reasons are:
>>>>> > >  * it is not clear if there is a real use case for this. Has anyone
>>>>> > >    ever complained about the status quo?
>>>>> > >    The proposal does not motivate the need for a change well enough.
>>>>> > >    (There is a related bug in TH, but that bug can probably simply be
>>>>> > >    fixed.)
>>>>> > >  * The status quo can be sold as a feature, rather than a short-coming.
>>>>> > >    Namely that an operator has a fixed fixity, no matter what namespace
>>>>> > >    it lives in.
>>>>> > >    This matches morally what other languages do: In Gallina, fixity
>>>>> > >    is assigned to names independent of their definition, AFAIK.
>>>>> > >  * There is a non-trivial implementation and education overhead, a
>>>>> > >    weight that is not pulled by the gains.
>>>>> > >
>>>>> > > If we’d design Haskell from scratch, my verdict might possibly be
>>>>> > > different (but maybe we wouldn’t even allow types and values to share
>>>>> > > names then…)
>>>>> > >
>>>>> > >
>>>>> > > Please contradict me or indicate consensus by staying silent.
>>>>> > >
>>>>> > >
>>>>> > > Greetings,
>>>>> > > Joachim
>>>>> > >
>>>>> > > _______________________________________________
>>>>> > > ghc-steering-committee mailing list
>>>>> > > ghc-steering-committee at haskell.org
>>>>> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>> >
>>>>> > --
>>>>> > Joachim Breitner
>>>>> >   mail at joachim-breitner.de
>>>>> >   http://www.joachim-breitner.de/
>>>>> >
>>>>> > _______________________________________________
>>>>> > ghc-steering-committee mailing list
>>>>> > ghc-steering-committee at haskell.org
>>>>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>> --
>>>>> Joachim Breitner
>>>>>   mail at joachim-breitner.de
>>>>>   http://www.joachim-breitner.de/
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> 
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> 
>>> 
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> 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/efae2274/attachment-0001.html>

More information about the ghc-steering-committee mailing list