- ghc-steering-committee

Type applications in patterns
by Simon Peyton Jones 17 Nov '20

17 Nov '20

Dear Steering Committee You may remember that we approved the Type Applications in Patterns<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0126-t…> proposal, some time ago. Cale has been implementing it (see ticket 11350<https://gitlab.haskell.org/ghc/ghc/-/issues/11350> and MR 2464<https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2464>). It's nearly done. But in doing so, one design choice came up that we did not discuss much, and I'd like to consult you. Consider first the existing pattern-signature mechanism (not the new feature): data T a where MkT :: forall a b. a -> b -> T a f1 :: forall p. T [p] -> blah f1 (MkT (x :: a) pi) = blah f2 :: forall p. T [p] -> blah f2 (MkT (x :: p) pi) = blah In f1, the pattern (x :: a) brings 'a' into scope, binding it to the type [p]. But in f2, since p is already in scope, the pattern (x :: p) does not bring anything new into scope. Instead it requires that x have type p, but actually it has type [p], so f2 is rejected. Notice that a pattern signature brings a new variable into scope only if it isn't already in scope. Notice how this differs from the treatment of term variables; the 'pi' in the pattern brings 'pi' into scope unconditionally, shadowing the existing 'pi' (from the Prelude). OK, now let's look at the new feature. Consider g1 :: forall p. T [p] -> blah g1 (MkT @a x y) = blah g2 :: forall p. T [p] -> blah g2 (MkT @p x pi) = blah Question: should the variables free in these type arguments be treated like pattern signatures, or like term variables? 1. Like pattern signatures. In this design, in g1, 'a' is not in scope, so this brings it into scope, bound to [p]. But in g2, 'p' is in scope, so this is rejected (because MkT is instantiated at [p] not p. 2. Like term variables. In this design, all the variables free in type patterns are fresh, and brought into scope. In g2, a new 'p' is brought into scope, shadowing the existing 'p'; indeed the new 'p' is bound to [old_p]. The original paper, and hence the accepted proposal, adopts (A). But Cale likes (B). Indeed John Ericson wrote a Proposal 291: simplify scoping for type applications in pattens<https://github.com/ghc-proposals/ghc-proposals/pull/291> to advocate this change. (The proposal is not easy to understand, but advocating (B) is its payload. This is not a terribly big deal, but it would be good to settle it. The right place to have debate is on Proposal 291<https://github.com/ghc-proposals/ghc-proposals/pull/291>. This email is just to alert you to it, and ask for your opinions. Simon

4 3

We have a nudger!
by Simon Peyton Jones 16 Nov '20

16 Nov '20

Friends Our GHC proposals process says * A shepherd will make a recommendation within 2 weeks * Committee will make a decision with 4 weeks after that But we sometimes drop the ball and we have no recovery mechanism, which isn't really fair on authors. At our ICFP meeting we decided to appoint a "Nudger" to watch the timetable (weekly perhaps) give the shepherds a polite nudge. If successive nudges don't work (e.g. perhaps a committee member has been overtaken by an emergency) then s/he can alert the Secretary to appoint a new shepherd. I'm happy to say that Tom Harding has agreed to act as our Nudger, for six-month term. Thank you Tom! You may want to check with Joachim about exactly what's in flight. Shepherds: note that it's fine to have an active dialogue with the author about content, before making your recommendation. That might take longer than 2 weeks, but make sure the author knows that is what you are doing. Thanks Tom! Simon

2 1

Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding
by Joachim Breitner 16 Nov '20

16 Nov '20

Dear Committee, this is your secretary speaking: DuplicateRecordFields without ambiguous field access was proposed by Adam Gundry https://github.com/ghc-proposals/ghc-proposals/pull/366 https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/pro… I’ll propose Tom Harding 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/

7 9

Re: [ghc-steering-committee] GHC 20xx process
by Richard Eisenberg 16 Nov '20

16 Nov '20

This is an effective argument; you've changed my mind. I'm now in favor of Joachim's simpler process. Thanks for writing this all out! Richard > On Nov 6, 2020, at 4:02 AM, Joachim Breitner <mail(a)joachim-breitner.de> wrote: > > Hi, > > we may be repeating points here, but I am still strongly leaning > towards a more lightweight process. At least initially, so that we can > iterate towards something more heavy in later rounds, rather than going > the other way (in general easier to add process than remove process). > > You mention that discussions will pop us elsewhere. I don’t find that > bad! We committee members are here to represent the community, and I > expect that enough of us are “in touch” with the community to pick up > useful signal, even if it happens on reddit or twitter, and will carry > that into their votes and rationales. There will be discussion in > reddit and twitter and mailing lists _anyways_! > > What I want to avoid is sending a signal to the community to say “we > are going to do about 100 individual decisions soon and, by the way, we > really encourage you to comment on all of them (why else would we give > you the explicit space). > I’d rather send the signal “we are going to > make 100 individual decisions, here you can follow the process, and if > you _really_ think we are missing something, this PR is where your > input is welcome.” > > Also, speaking as the secretary, managing a separate repo and expecting > all of us to following many different issues seems out of proportion of > what we want to achieve here. > > > Maybe popping up a bit: It’s worth noting that the first round will be > very different than all the subsequent roads. In the first round we > have a _large_ number of low-hanging fruit to pluck. In fact, it’s so > many of them, that I expect we simply don't have the capacity to do > very careful deliberation of each of them. > > This implies that the first round, we should aim _low_, and be very > conservative, knowing that the following rounds we have less to > discuss, and can then be more careful discussions about those > extensions that need those discussions. > > So what does this mean for community involvement? There are two cases > for a given extension FooBar: > > * Our vote initially doesn’t include FooBar. > > Yes, for almost every extension there will be a few people who think > that it should be in. This is not very useful signal! > > In fact, in this case, we’d likely say “thanks for your input! For > the first round, we are going to be conservative, and we didn’t > include FooBar for now. But maybe next year!” > > I don’t think we or the community benefits from first making space > for that discussion, to then only cut it off politely. > > * Our vote initially includes FooBar. > > Then, maybe, someone has a good argument why FooBar is actually less > harmless than we have thought. That _is_ useful signal! > > But I expect this to be rare: It only applies to the already > filtered list of extensions, not all 100, and if we do our job good, > only a few cases like this arise. Thus a normal discussion on the PR > on our normal repository, just like with any other proposal, > suffices to get that signal. > > I am making a few assumptions here about how we want to run this > (aiming for a conservative list of extensions in the first round, and > trying to be efficient with our own resources), and with these > assumption the more lightweight process seems more appropriate to begin > with. > > One can of course disagree with these assumption (e.g. aiming for a > very elaborate process to pick a very “complete” set right away), and > then deduce that Alternative 2 is needed. > > > 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

6 8

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