- ghc-steering-committee

Is @ a name-space override, or a visibility override?
by Spiwack, Arnaud 15 Nov '20

15 Nov '20

Dear all, There is a debate which has been held in our heads for quite some time now. But we’ve never really had the conversation. This debate has been raised again in the context of proposal #281. But I’d rather make a separate thread about it. The question is the following: When I write f @t Am I using @ as a way to change an invisible argument into a visible argument? Or am I using @ to insert a type expression into a term expression? ------------------------------ The truth is that it’s doing both at the same time. So some of us have taken to believing that the One True Meaning™ of @ is to override (in)visibility. While others have taken to believing that the One True Meaning™ of @ is to insert types in term. And, in both cases, we believe the other part to be incidental. In favour of types-in-term, there is the pretty-printer for Core, which, if I’m not mistaken, uses @t to denote type applications (and all type applications are visible in Core, so there is no visibility override to be had). Whatever we think about this, it appears that the fact that this meaning ascription is implicit has caused some anguish. So I think that we should have this discussion explicitly for once. I chose to do so in a different thread than the #281 discussion, because this discussion stands on its own. Anyway, the floor is yours. /Arnaud

6 5

GHC 20xx process
by Simon Peyton Jones 04 Nov '20

04 Nov '20

Friends We are asked to consider Proposal 371: the GHC 20xx process<https://github.com/ghc-proposals/ghc-proposals/pull/372> We have discussed it quite a bit already and I recommend acceptance. It includes "Alternative1" and "Alternative2" at one point. I found Alternative 2 hard to parse (seemed very process-heavy), so I favour Alternative 1 which seemed simpler. Please respond within the next week or two, either on the discussion thread, or to this email. Thanks Simon

3 2

#283: Local modules, recommendation: accept
by Spiwack, Arnaud 03 Nov '20

03 Nov '20

Dear all, I would like to bring our own Richard Eisenberg’s proposal, #283: Local modules, to your attention. https://github.com/ghc-proposals/ghc-proposals/pull/283 The proposal is an attempt at solving the long debated issue that we can’t export qualified names out of a module (*e.g.* we may have to repeat import qualified Data.Map as Map and import qualified Data.Set as Set in every module in a project, rather than simply calling import MyPrelude which would take care of both and more), to improve scope management, and sharing names between types in the same files, while making namespaces more convenient to use in the process. It’s a pretty ambitious proposal, with quite a few interlocking pieces. Yet, in my opinion, they fit pretty well together. And I’m, as a potential consumer, very enthusiastic about it. Some highlight (though do read the whole thing): - We can define modules inside of other modules, with the syntax module Foo (some, optional, exports) where … - Like in the rest of Haskell, modules are no more than namespaces. Therefore you can open two module Foo, it will just merge the names in them - Values in local modules can be referred to, qualified, in the encompassing module - Local modules can be exported, importing them will import the name as qualified - A new import module Foo statement can be used in let and where clauses, it brings everything of the form Foo.x into scope unqualified for the scope of the let or where Additionally, there is a small point that is not integral to the rest of the proposal, where defining, say, a type data T = A | B Would create a local module named T, such that the constructors could be referred to as T.A and T.B. I mention it separately, because it causes the only (small) backward incompatibility (that is Haskell 2010 programs which stop compiling when you turn on -XLocalModules). I’m rather in favour of keeping it in, but it’s worth mentioning. I pretty much want all of these features in my daily programming, so, as I said above, I’m very enthusiastic for all of this. And I’m pretty happy with the realisation. Hence my recommending acceptance. /Arnaud

5 9

Haskell 2020 Survey
by Joachim Breitner 02 Nov '20

02 Nov '20

Hi Committee, in case you didn’t see it: The yearly “State of Haskell Survey” at https://haskellweekly.news/survey/2020.html traditionally asked for “Which language extensions would you like to be enabled by default”. In pro-active anticipation of our GHC2020 process, they have changed the survey to let the community vote in favor, against, or abstain each extension. This should be sufficient for us to gauge whether there is interest in an extension being on by default, and whether there is contention about it. Just as Simon Marlow, I see no point in doing a very similar poll shortly after, and would just use the data coming out of that for GHC2021 (assuming we do the GHC2021 thing). I’ll say so (“If there is a GHC2021 language set, then the committee will very likely take the outcome of this poll into account.”) publicly, to encourage the community to take part in the survey. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 2

Please review #372: The GHC20xx process, Shepherd: Simon PJ
by Joachim Breitner 02 Nov '20

02 Nov '20

Dear Committee, this is your secretary speaking: Alejandro and I have drafted a process for GHC20xx https://github.com/ghc-proposals/ghc-proposals/pull/372 https://github.com/ghc-proposals/ghc-proposals/blob/ghc20xx-process/proposa… propose Eric Seidel as the shepherd.b I’ll propose Simon PJ as the shepherd, as this is a procedural metaprocess that benefits from chair involvement. This is mostly the outcome of discussions we already had, so I don’t expect we need a lot of further discussion, and could maybe vote soon. Note that there are two alternatives in “2.2 Process“. They differ in the form the community is invited to be involved, and also in the overall weight of the process. The main difference is Do we want to _encourage_ broad discussion of individual extensions (the point of Alternative 2), because we believe it is useful and healthy, or do we want to avoid stirring such discussions (Alternative 1), because we don’t believe they would add much, would be distracting and time consuming, and because there is enough existing signal (the poll, reddit, the PR comment section, …). There are procedural differences that follow from that, e.g. using a separate repository (Alternative 2) or using our existing one (Alternative 1), but in a way the overall aim is the core of this alternative. Simon, once you think all interesting points have been raised (which may already be the case) I suggest you call for a ranked vote with the options “Reject”, “Alternative 1”, “Alternative 2”. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Status
by Joachim Breitner 28 Oct '20

28 Oct '20

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 #313: Delimited continuation primops, Shepherd: Simon Marlow #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow ## Waiting for Shepherd action #333: Defer Parse Errors, Shepherd: Tom Tom, is this ready for Committee consideration? #302: Layout and Guards in Lambda Expressions, Shepherd: Cale Cale, it is high time to jump into action here! Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 3

Status (complete)
by Joachim Breitner 28 Oct '20

28 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