- ghc-steering-committee

Status (complete)
by Joachim Breitner 27 Oct '20

27 Oct '20

[previous message was sent prematurely, sorry] Dear Committee, another “regular” status update. So what has happened in the last two months? * Lots of discussion about GHC2020. Enough to make it rather GHC2021. * Richard refines the bylaws in #360. Maybe everybody has a second look now and then we can merge this? * we were asked to review these proposals: #356: Linear Types arrow, shepherd: Richard #351: NoIncomplete, shepherd: Iavor #364: Unify Nat and Natural, shepherd: Alejandro #283: Local modules, Shepherd: Arnaud #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow #369: Add sumToTag# primop, Shepherd: Eric * we have a recommendation from the shepherd about: #302: \of (rec: reject) #356: Linear Types arrow (rec: vote) #364: Unify Nat and Natural (rec: accept) #281: Visible 'forall' in types of terms (rec: accept) #283: Local modules (rec: accept) * we have sent the following proposals back to revision #281: Visible 'forall' in types of terms * we decided about the following proposals #356: Linear Types arrow (accept) #364: Unify Nat and Natural (accept) We currently have to act on the following 5 proposals, up by 3. ## Waiting for committee decision #283: Local modules, Shepherd: Arnaud Mostly positive, may need more revision though #302: \of, Shepherd: Cale Mostly negative, but still discussion going on. ## Waiting for Shepherd action #313: Delimited continuation primops, Shepherd: Simon Marlow This one is aging. Simon, are you on this? #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow Still rather new. #369: Add sumToTag# primop, Shepherd: Eric Still rather new. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Re: [ghc-steering-committee] GHC 2020
by Alejandro Serrano Mena 27 Oct '20

27 Oct '20

I would really like this effort not to die, so I've given the proposal another push. Following the comments from Simon and Joachim, I've re-framed the proposal as laying down a process to create new "language versions" yearly. The idea is to have one of these every year (or 2, or 3, whatever is decided), coinciding with the spring release of GHC. https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-20… I think it's important for the community to be involved in the process. If it's clear that an extension is loved by most of the community, that's a big plus for acceptance. In addition, if we come with a list ourselves, we risk having made choices which only show our (biased) point of view. Since in the first round the possible list of extensions may be quite big, we might introduce a "fast-lane process" for this one time, for extensions like EmptyDataDecls or different number formats which seem to have unanimous support. Looking forward to hearing from all of you, Alejandro El lun., 5 oct. 2020 a las 12:07, Joachim Breitner (< mail(a)joachim-breitner.de>) escribió: > Hi, > > Am Montag, den 05.10.2020, 10:21 +0100 schrieb Simon Marlow: > > > Personally, I would also like to come up with general guidance. Do > > > we expect *any* extension fulfilling the criteria to be included? > > > > > > > Let's be conservative: if there's controversy around a particular > > extension, default to not including it in GHC2020. > > that was a core idea of my original process proposal: > > Without long, time-consuming and process-heavy debate around each > extension, let’s all of us individually assemble a list of extensions, > and turn that into GHC2020. (Maybe for extensions that were not on the > list by only one or two give them a chance to reconsider). > > This way there is still a chance that it'd become GHC2020, and not > GHC2021 or GHC2022, or just fizzle… > > And it would hopefully be the a GHC2020 that contains all the low- > hanging, non-controversial fruit. This also means that GHC2020 has a > good chance of actually getting used. Which means for the work for > GHC2021, picking the next set of extensions, is actually relevant and > meaningful. > > > And if something doesn’t make it into GHC2020 that maybe should have? > No big deal, as Simon says. > > Cheers, > Joachim > > > > -- > 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 >

5 16

Re: [ghc-steering-committee] Please review #281: Visible 'forall' in types of terms
by Spiwack, Arnaud 15 Oct '20

15 Oct '20

There has been conversation to this effect on the Github PR, for a day or so, starting at https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-707033… . But I wanted to point out that there are really two, interlocked, yet distinct, parts in this proposal. 1. Having a `forall a ->` construct for types of terms 2. How is `f blah` parsed if `f` has type `forall a -> …`? I am definitely sympathetic to (1). As much as I like my `f @…`s I am bound to admit that it produces error messages from the 7th Circle of Hell. And, since it's a very useful pattern, making it "official" is rather neat a plan on paper. But (2) is very very difficult, because we have really two grammars at play here: the grammar for term, and the grammar for types (I'll conflate grammar and name resolution in the following). In the `f @…` style, we switch to the type grammar to parse whatever's in the `@`. But if we want to to write type applications in the `forall a->` case as `f a`, then we sort of have to parse `a` as a term (though there is some leeway in name resolution). And that introduces all sorts of potentially weird behaviour (see the link above for a good documentation of what). Part of the difficulty, I should stress, is that, in types the apostrophe `'` means: I'm speaking of a data constructor, not a type constructor. Whereas in terms, it means: I'm opening a Template Haskell slice. Part of the impetus for the proposal actually going in the direction of parsing the type argument as a term, is the desire to eventually merge the terms and types grammars. I don't know how widespread this desire actually is (maybe this is something we should speak about). In my personal opinion, it's not a very plausibly achievable goal, nor is it particularly necessary for dependent types. (It does, of course, have a number of advantages, which is why Coq, Agda, and Idris do have a single grammar indeed). I think that I'd be happier if we had a sigil to switch between the type grammar and the term grammar. But, here, the issue is that nice sigils are harder and harder to come by. My point, though, is that while this proposal may look like it has a small scope, it actually is a fairly large and intricate proposal, and requires quite a bit of attention. /Arnaud On Mon, Oct 5, 2020 at 7:25 PM Iavor Diatchki <iavor.diatchki(a)gmail.com> wrote: > I've been following the discussion and I think we should keep it in the > "committee review" phase because > 1. The discussion is due to questions from the committee members, and > 2. Even though it seems like a lot, mostly it's been along the lines of > clarification and better phrasing of things, rather than big changes to the > proposal > > I don't feel strongly about it, so if others also think we should move it > to the discussion phase, I'd be happy to do so, I just don't want to loose > the steam we seem to have gathered :) > > Let me know, > -Iavor > > > On Mon, Oct 5, 2020 at 2:38 AM Simon Marlow <marlowsd(a)gmail.com> wrote: > >> There seems to have been a lot of ensuing discussion on this one, should >> it go back into the discussion phase? >> >> On Fri, 2 Oct 2020 at 20:06, Richard Eisenberg <rae(a)richarde.dev> wrote: >> >>> I'm in support of this proposal, but I've pushed back on a few softer >>> points. I've commented on GitHub. >>> >>> Richard >>> >>> On Oct 1, 2020, at 1:07 PM, Iavor Diatchki <iavor.diatchki(a)gmail.com> >>> wrote: >>> >>> Hello, >>> >>> Proposal #281 is ready for review by the committee. My recommendation >>> is to accept it, I've >>> written a summary of my understanding to the proposal and my >>> recommendation on the GitHub >>> thread, accessible through these links: >>> >>> https://github.com/ghc-proposals/ghc-proposals/pull/281 >>> >>> https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00… >>> >>> Let the discussion begin! >>> >>> -Iavor >>> _______________________________________________ >>> 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 >

3 2

Please review #364: Unify Nat and Natural, Shepherd: Alejandro
by Joachim Breitner 12 Oct '20

12 Oct '20

Dear Committee, this is your secretary speaking: Unify Nat and Natural has been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/364 https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-uni… I’ll propose Alejandro as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 9

List archive failure
by David Feuer 09 Oct '20

09 Oct '20

There was a serious problem on haskell.org leading to a failure to archive several days of mailing list messages. As I am not subscribed to this list, I would appreciate if someone could let me know what, if any, messages have been sent about proposal #367 since the initial request.

2 1

GHC 2020
by Iavor Diatchki 04 Oct '20

04 Oct '20

Hello, I just had some fun and went through the list of GHC extensions in the manual, thinking of which ones might make a reasonable subset for a potential GHC2020. Below is the list I came up with. My reasoning was, roughy: * I wouldn't mind if these were on all the time * It is unlikely that turning on the extension will break something dramatically * It is unlikely that using the extension might lead to errors * The extensions are somewhat coherent * I explicitly included extensions that I personally don't use much, but I've heard that others like I wonder what others think of this list? What would you add/remove? -Iavor BlockArguments EmptyCase EmptyDatadecls ExplicitNamespaces ImportQualifiedPost LambdaCase MultiWayIf StandaloneDeriving BinaryLiterals HexFloatLiterals NumericUnderscores NamedFieldPuns RecordWildCards TupleSections ApplicativeDo RecursiveDo ParallelListComp BangPatterns PatternSynonyms ViewPatterns PatternGuards ForeignFunctionInterface CApiFFI RankNTypes ExistentialQuantification ScopedTypeVariables TypeSynonymInstances ConstraintKinds StandaloneKindSignatures KindSignatures TypeOperators

8 39

Please review #281: Visible 'forall' in types of terms
by Iavor Diatchki 02 Oct '20

02 Oct '20

Hello, Proposal #281 is ready for review by the committee. My recommendation is to accept it, I've written a summary of my understanding to the proposal and my recommendation on the GitHub thread, accessible through these links: https://github.com/ghc-proposals/ghc-proposals/pull/281 https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00… Let the discussion begin! -Iavor

2 1

Please review #283: Local modules, Shepherd: Arnaud
by Joachim Breitner 01 Oct '20

01 Oct '20

Dear Committee, this is your secretary speaking: Local Modules has been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/283 https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/00… I’ll propose Arnaud as the shepherd. Please note that Richard writes > The main alternative to this proposal is #295. It is probably worth > it for at least the committee shepherd to read #295 in concert with > this current proposal, to see which approach they like more. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

The 'Char' kind
by Richard Eisenberg 21 Sep '20

21 Sep '20

Hi GHCSC, Before this committee existed, Alex Vieth submitted #11342 (https://gitlab.haskell.org/ghc/ghc/-/issues/11342 <https://gitlab.haskell.org/ghc/ghc/-/issues/11342>), requesting a kind `Char`. Serokell has now provided a patch, !3598 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598>). The chair of the CLC has signed off on this patch (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598#note_300231 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598#note_300231>). But I feel we should, too. What is a good process here? Just debate amongst ourselves? Post a GitHub Issue to call wider attention? Post a proposal? Merge without debate? Richard

3 2

Proposal #356: new syntax for linear arrows
by Richard Eisenberg 18 Sep '20

18 Sep '20

Hi committee, Mathieu Boespflug has proposed a new syntax for linear arrows: https://github.com/ghc-proposals/ghc-proposals/pull/356 Currently (from the original linear types proposal), we have #-> to denote a linear function, and # m -> to denote an arbitrary function whose argument has multiplicity m. This proposal suggests three changes: 1. Drop #-> entirely. 2. Use ^ instead of # in the second form, but require that it be a *prefix* usage of ^ (that is, the character after the ^ must not be whitespace). 3. Introduce a new lexeme ^1 that is used to denote linear functions. Alternative: use % in place of ^; % is observed to be more visually apparent in some fonts than ^. In time, the hope is that rule (3) will no longer be needed, if we gain overloaded numbers at the type level (when 1 :: Multiplicity will type-check without a special rule). Motivations for this change come from the experience within Tweag of using linear types. The change away from # also is to avoid a conflict with overloaded labels, once those are allowed in types. The hope is that we can make a decision about this in time for release with GHC 9.0. This proposal is already implemented: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4020 In conflict with our usual protocol, I will not make a recommendation on this proposal, as I am conflicted with the proposer. However, I do hope that we can come to a conclusion on this quickly, to avoid making a backward-incompatible change after a release. We have four options: A. Keep the syntax as it is. B. Choose to go with ^ C. Choose to go with % D. Choose to go with some other symbol. I don't think there is any particular preference for any one symbol over another. Richard

6 6