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

Thu Oct 19 00:33:16 UTC 2017

Mathieu asked me to relay this message to the committee.

> Forwarded message
> 
> From: "Boespflug, Mathieu" <m at tweag.io>
> Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension?
> Date: 18. Oktober 2017 um 21:34:12 GMT+11
> To: Manuel M T Chakravarty <chak at justtesting.org>
> Cc: Facundo Domínguez <facundo.dominguez at tweag.io>
> 
> Hi Manuel,
> 
> don't know if I'm allowed to post to this mailing list. So would
> appreciate if you could forward the following experience report.
> 
> Facundo and I worked on the -XStaticPointers extension. It has gone
> through various improvements/generalizations for each new GHC release.
> Eg originally, (static e) evaluated to something of type StaticPtr a,
> whereas now it has type IsStatic s => s a, to allow for overloading
> (static e) literals similarly to string literals. A corresponding
> change was made to base. In the future there might be other changes,
> in particular to finally make pointer lookup type safe (it's not,
> currently), or to generalize IsStatic to a multi-param type class
> (based on real-world experience). Should we have -XStaticPointers1,
> -XStaticPointers2, etc for each new variant of this extension any time
> we make any improvement to it (which have all been backwards
> compatible so far)? That would be pretty onerous.
> 
> Now, -XStaticPointers was added as an "experimental" extension, and so
> in a strong sense we still have license to make all manner of changes
> to that extension. But aren't they all? Isn't the very reason for
> adding things as extensions first (rather than as part of the base
> language) so that we can introduce new ideas and experiment with them
> in the wild? And if the extension passes the test of widespread
> usefulness then we etch in one of the Haskell Report stone tablets?
> 
> Writing modern Haskell already entails a fair amount of bureaucracy
> (among which language extension bureaucracy). Many different
> variations of the same basic extension may well add to that
> bureaucracy a fair bit. And what's more, be intimidating to beginners.
> 
> Best,
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
> 
> 
> On 17 October 2017 at 12:30, 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
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20171019/60429da5/attachment-0001.html>