- ghc-steering-committee

Our process and BIG ideas
by Manuel M T Chakravarty 15 Nov '17

15 Nov '17

In the light of the linear types proposal PR, SimonPJ’s comment https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomment-3434578… and some uncertainty about the proposal process that has been communicated to me via a side channel, it might be worthwhile clarifying our expectations for large complex proposals. (I know, we basically punted on these questions in our initial discussion on the process with the intention to revisit after we gained some experience. It seems this time has come.) Firstly, we usually require proposals to be self-contained. This makes a lot of sense for small to medium-sized proposals to limit the time needed by the committee to hunt down all the required information. However, in a case, such as the linear types work, where there is a highly polished text in the form of a research paper (or similar), it seems reasonable to refer to that existing work — not only because type rules are a lot nicer to read when rendered by LaTeX instead of Markdown. Concretely, I’d like us to give some guidance wrt to this issue to proposal authors and document that at https://github.com/ghc-proposals/ghc-proposals#ghc-proposals Secondly, Simon, you seem to suggest that a large proposal like this wouldn’t be either accepted or rejected, but put into a kind a limbo state of further evaluation as seen fit. I agree that instead of outright rejection of a proposal that we consider flawed but not hopeless, we might request further elaboration and resubmission as we have done in the past. However, if a proposal passes muster, I think, we should accept it unconditionally, even if it is a large change. (If, say, at the end, the implementation is not up to scratch, then it is up to the code reviewers to reject the patches, but I don’t think, it is this committee’s job anymore.) In any case, I think, it is important make the process as clear as possible to authors, so they know what they are in for. What do you all think? Cheers, Manuel

3 7

Please review: Deprecate STM invariant, Shepherd: Manuel M T Chakravarty
by Joachim Breitner 11 Nov '17

11 Nov '17

Dear Committee, this is your secretary speaking: Deprecate STM invariant mechanism https://github.com/ghc-proposals/ghc-proposals/pull/77 was brought before the committee, by our own Ben Gamari I propose Manuel M T Chakravarty as the Shepherd. Roman, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review: visible dependent quantification, Shepherd: Roman Leshchinskiy
by Joachim Breitner 11 Nov '17

11 Nov '17

Dear Committee, this is your secretary speaking: Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 was brought before the committee, by our own Richard Eisenberg. I propose Roman Leshchinskiy as the Shepherd. Roman, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Status
by Joachim Breitner 11 Nov '17

11 Nov '17

Dear Commmittteee, Since the last status update, we * accepted the following proposals: - Type Fixity * sent the following proposals back for further refinement - NOUNPACK on function arguments * rejected the following proposals: - /none/ * were asked to review these proposals: - underscore in numeric literals * had a discussion about language extensions stability, which has been moved to a proposal of its own at https://github.com/ghc-proposals/ghc-proposals/pull/85 and has since quieted down. It is unclear if this will happen. On our table at the moment are: Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Or Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Chakravarty Status: Manuel suggests acceptance, committee deliberation ongoing Underscores in numeric literals https://github.com/ghc-proposals/ghc-proposals/pull/76 Shepherd: Iavor Diachki Status: Iavor suggests acceptance, I sense silent agreement in the committee Besides these, there are some proposals actively under discussion. You can always check them out at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no… Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Underscores in numbers proposal
by Christopher Allen 02 Nov '17

02 Nov '17

https://github.com/ghc-proposals/ghc-proposals/pull/76#issuecomment-3399529… This appears to have near universal approval. It's certainly a feature I've been grateful for when writing Rust code. I wasn't able to find a thread about this proposal in my email archives, so I apologize if this was redundant. Could this be moved to a decision soon? Thank you, Chris Allen

3 2

Please review: underscores in numeric literals, Shepherd: Iavor Diatchki
by Joachim Breitner 02 Nov '17

02 Nov '17

Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/76 was brought before the committee, by Takenobu Tani. I propose Iavor Diachki as the Shepherd, simply because he already responded to it. Iavor, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

GHC steering committee participation
by Atze Dijkstra 23 Oct '17

23 Oct '17

Dear committee members, as you may have noticed I have not actively participated in proposal reviewing. I can wrap this in a long or short story, but at the core lies lack of time combined with my role at Standard Chartered (SC) evolving in a direction less involved with GHC and Haskell language design/implementation than I originally thought it might be. Privately, outside of SC, I also see little time and energy left for committee activities. The work on proposals seems to have started actively and vigorously and I'd rather not be this silent non-contributing participant. I feel it is important to have somebody from what can likely be called the largest Haskell based industrial development group be in contact with and contribute to what by definition is an important tool for us. After some consultation with colleagues I found Roman Leshchinskiy (rleshchinskiy(a)gmail.com) to be willing to replace me in the committee. For most of the committee members I guess he is already known from the FP community so I leave further introduction up to himself. Within SC Roman is responsible for GHC related supporting infrastructure and as such is more than I am involved in and confronted with GHC intricacies, which places him at a better position to contribute to the GHC steering committee from an industrial perspective. I am aware that stepping down might cause inconvenience, but also feel that this better can be done now than later when the committee is already on farther on its way in dealing with proposals. I am also aware that it is not really up to me to decide what to do next after me stepping down, but I feel the proposed replacement by Roman is the best option from my perspective. all the best, Atze

7 11

Proposal: Type Fixity (#65), Consensus: accept, own language extension?
by Iavor Diatchki 20 Oct '17

20 Oct '17

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(a)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-infi… > > > 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(a)haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > -- > > Joachim Breitner > > mail(a)joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee(a)haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- > Joachim Breitner > mail(a)joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee(a)haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >

9 16

Proposal: Type Fixity (#65), Recommendation: accept under ExplicitNamespaces
by Joachim Breitner 19 Oct '17

19 Oct '17

Hi committee, the other thread on this proposal has veered off into a (very useful) meta-discussion. It seems that we will likely soon have a way to bless certain language extensions as stable, but this implies that ExplicitNamespaces it not (yet) one of those. In this light, I want to make progress on the proposal at hand, so I propose that we accept the proposal https://github.com/ghc-proposals/ghc-proposals/pull/65 including the extension to WARNING pragmas etc. in https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-3349734… (which I will ask Ryan Scott to incorporate into the proposal) and under the agenda of expanding (completing) ExplicitNamespaces, rather than introducing a separate language extension. Is that fine with everyone? As always, I will take silence as a yes, and declare victory^Hconsensus after a week or so. Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Fwd: Proposal: Type Fixity (#65), Consensus: accept, own language extension?
by Manuel M T Chakravarty 19 Oct '17

19 Oct '17

Mathieu asked me to relay this message to the committee. > Forwarded message > > From: "Boespflug, Mathieu" <m(a)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(a)justtesting.org> > Cc: Facundo Domínguez <facundo.dominguez(a)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(a)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(a)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(a)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(a)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-infi… >>>>>> 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(a)haskell.org >>>>>> >>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>> >>>>> -- >>>>> Joachim Breitner >>>>> mail(a)joachim-breitner.de >>>>> http://www.joachim-breitner.de/ >>>>> >>>>> _______________________________________________ >>>>> ghc-steering-committee mailing list >>>>> ghc-steering-committee(a)haskell.org >>>>> >>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> -- >>>> Joachim Breitner >>>> mail(a)joachim-breitner.de >>>> http://www.joachim-breitner.de/ >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee(a)haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee(a)haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee(a)haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee(a)haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>

1 1