January 2023 - ghc-steering-committee

Please review #512: NoFieldSelectors as datatype annotation, Shepherd: Baldur
by Joachim Breitner 02 Mar '23

02 Mar '23

Dear Committee, NoFieldSelectors as datatype annotation have been proposed by Matt Parsons https://github.com/ghc-proposals/ghc-proposals/pull/512 https://github.com/parsonsmatt/ghc-proposals/blob/matt/field-selectors-scop… I suggest Baldur to shepherd this proposal. 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/

9 29

Call for votes: Shall we have GHC2023
by Joachim Breitner 10 Feb '23

10 Feb '23

Hi Committee, as ~threatened~ announced, I’m calling for a vote on whether we should proceed to define the next GHC20xx _now_, as GHC2023, or wait for a year. Judging from the silence around the PR for GHC2023 I deduce that the appetite for GHC2023 is generally low, and will not bother you with complicated looking questions about which extensions might make GHC2023 worth it in an attempt to parallelize the “whether” with the “what”. Instead, please cast your vote until Apri 5 (but preferrably earlier) on the question: Should we proceed towards GHC2023? (If yay wins we’ll refine #559 and vote on that. If nay wins, I’ll stay quiet until next fall.) I am intentionally not asking for a fixed cadence at this point. We have made but one release so far, and it seems presumptious to try to predict what makes most sense next year, or the next four years to come. (I’ll follow up with my vote and justification separately.) Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

7 11

By-law change: Allow self-nominations
by Joachim Breitner 05 Feb '23

05 Feb '23

Hi, our current by-law kinda bind our hands in case some motivated comes along and would like to join the committee, and Simon PJ suggested that we should give us the discretion to hold membership votes out-of-season as well. The suggested wording change is in https://github.com/ghc-proposals/ghc-proposals/pull/572 Please discuss and cast your vote within two weeks (preferably earlier, as you can guess this change is not happening completely out of the blue.) I’m in favor. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 4

Re: [ghc-steering-committee] By-law change: Allow self-nominations
by Arnaud Spiwack 30 Jan '23

30 Jan '23

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: I've posted comments on the Github thread, to try and clarify a few points before I cast my vote. On Thu, 26 Jan 2023 at 03:02, Richard Eisenberg <lists(a)richarde.dev> wrote: > Spam detection software, running on the system "mail.haskell.org", has > identified this incoming email as possible spam. The original message > has been attached to this so you can view it (if it isn't spam) or label > similar future email. If you have any questions, see > @@CONTACT_ADDRESS@@ for details. > > Content preview: +1 from me, too > On Jan 23, 2023, at 1:27 PM, Chris > Dornan > <chris(a)chrisdornan.com> wrote: > > +1 to this proposed change to the > nominations > process. > >> On 2023-01-23, at 14:24, Joachim Breitner < > mail(a)joachim-breitner.de> > wrote: >> >> Hi, >> >> our current by-law kinda bind our hands in case > some > motivated comes >> along and would like to join the committee, and Simon > PJ suggested that >> we should give us the discretion to hold membership > votes > out-of-season >> as well. The suggested wording change is in >> > https://github.com/ghc-proposals/ghc-proposals/pull/572 > >> >> Please discuss and cast your vote within two weeks (preferably > earlier, > >> as you can guess this change is not happening completely out of the > >> > blue.) >> >> Iâm in favor. >> >> 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 > > > > ghc-steering-committee mailing list > > ghc-steering-committee(a)haskell.org > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > [...] > > Content analysis details: (5.0 points, 5.0 required) > > pts rule name description > ---- > > -0.0 SPF_HELO_PASS SPF: HELO matches SPF record > 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language > 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid > > > > > > Forwarded message > From: Richard Eisenberg <lists(a)richarde.dev> > [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 0

#555: Higher Order Patterns in Rewrite Rules, rec accept
by Joachim Breitner 23 Jan '23

23 Jan '23

Dear Committee, Jaro Reinders and Simon PJ propose to allow Higher Order Patterns in Rewrite Rules. The idea, by way of an example, {-# RULES forall f. foo (\y. f y + f y) = bar f #-} will now not only match "foo (\y. negate y + negate y)" (with f set to negate) but also "foo (\y. y*y + y*y)" (with f set to (\x. x*x)). Here "f y" is a higher-order pattern, which are restricted to a _pattern_ variable followed by a list of _local_ variable, indicating which variable the matched expression may depend on (previously, only closed expressions could be matched). An implementation is sitting ready at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9343 The design was carefully crafted to be backward-compatible and not introduce spurious etwa-expansion where there was non before. It is not guarded by a LANGUAGE pragma (but RULES themselves are not). Library authors who care about backward compat will have to deal with CPP pragmas. I’m a big fan of rewrite rules, and the proposal is straight forward and provides a feature that I'd maybe optimistically already assumed to be there already. Therefore, I’m recommending acceptance. If you disagree please speak up within two weeks, or speed up the process by indicating agreement earlier. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 7

Fwd: GHC2023
by Simon Peyton Jones 20 Jan '23

20 Jan '23

Dear Ghc-Steering-Committee, Here's an email from Tom Ellis about the GHC20xx thread. Please do read it. (Who, if anyone, is the moderator of the ghc-steering-committee mailing list?) Simon ---------- Forwarded message --------- From: Tom Ellis <tom-2019(a)jaguarpaw.co.uk> Date: Tue, 8 Nov 2022 at 08:04 Subject: Re: [ghc-steering-committee] GHC2023 To: Simon Peyton Jones <simon.peytonjones(a)gmail.com> Hello Simon, I sent this to the steering committee mailing list on Saturday but received an email in response saying it was "being held until the list moderator can review it for approval". Perhaps no moderator has had the chance to review it yet, as it hasn't yet appeared on the mailing list archive https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/thr… Perhaps you would be kind enough to forward it to the list for me directly. Thanks, Tom Thanks Simon. On reflection, I'm not particularly motivated to consult the community because the concerns I have impinge most strongly on members of the community who are distant from where a consultation could easily reach, and on non-but-potential-members of the community who are getting a false impression from afar. I will content myself with elaborating on my concerns and then leaving it to the steering committee to take them into account if they see fit. To set the scene, everything I write below is presented from the point of view of someone who wishes Haskell usage to increase and believes that we can't increase Haskell usage by appealing to people who are already comfortable with the way the Haskell ecosystem currently works: we've already got most of those people. For the ten years that I have been in the community, Haskell has had a (false) reputation, to outsiders, as a fragmented language with multiple mysterious things called "language extensions" each of which fractures the language in an incompatible way. "It's impossible to learn Haskell because there are so many incompatible Haskells" they say. It may be hard to believe that this perception exists: as users of GHC we know that there are very few extensions that introduce any incompatibility with others; extensions typically just remove unneccesary restrictions. But, for those of you who don't spend far-too-much of your time on discussion fora such as Hacker News and Reddit, I can guarantee to you that this objection to Haskell comes up *a lot*. Haskell also has, to both insiders and outsiders, a (true) reputation for being an unstable moving target. "It's impossible to learn or use Haskell because the language and libraries keep changing", they say. This one is easier to believe. GHC2021 is a wonderful way of dealing with all of the first and part of the second objection! I can now respond to complaints of language fragmentation and language instability by simply saying "Turn on GHC2021 and be happy". This is great news! (GHC2021 doesn't deal with instability in libraries of course, but I'm pleased that there are many people making efforts in that area too.) I am concerned that GHC2023 would weaken the power of my rejoinder "Turn on GHC2021 and be happy". Now I am at risk of the responses "But why not GHC2023?", "Haskell introduced a new, incompatible language just two years after standardising on GHC2021", "I just spent my precious time learning GHC2021, now I have to spend time learning GHC2023.". Sure, these responses are based on misunderstandings of the technical details. But perceptions really, really matter! If we want a large increase in Haskell usage then we have to take perceptions into account. We can't substantially increase Haskell usage any more by appealing just to our techncial excellence. If we choose to prioritise business-as-usual, that is, the incorporation of highly technically excellent features on a regular basis, with no thought to the costs, then the consequence will be Haskellers-as-usual: people who value that kind of thing in spite of the costs. We already have most of those people. We can't increase Haskell adoption that way. If we choose to change tack then we have the chance of changing the types of people we pick up as new Haskellers, from among those who would never otherwise have considered the language. To put it pithily, Joachim writes in a sibling thread "The point of the GHC20xx series is to get (proven, useful, uncontroversial) goodies into the hands of our users". Are members of the Haskell community, and indeed non-but-potential-members, screaming out for new "goodies"? Or are they screaming out for a brief respite from the unforgiving churn of the Haskell ecosystem, both real and not-real-but-perceived. My experience of the last ten years tells me it's the latter. To be clear, I personally am very much looking forward to more highly technically excellent features, including the exciting ongoing work on dependent types, WASM, GHCJS, and so on. It's one of the aspects of the community that really inspires and excites me! I personally can tolerate the churn. But I don't want those things at the *cost* of continuing to push away potential new users who are currently peering over the fence, discouraged because they can't tolerate the churn that they see, real or perceived. Now, with my stability hat on, looking from the point of view of process design, it's actually *better* for changes to happen in small increments, so maybe having GHC20xx every year is actually *better* than every five years. I don't wish to advocate for one choice or another. Rather I wish to advocate for the point of view that: Technical excellence matters. Stability and the perception of stability matter too. Tom On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <simon.peytonjones(a)gmail.com> wrote: > Another year has passed, and if we are serious with the idea that >> GHC20xx is a continuous thing, we should probably start defining >> GHC2023 – even if it is just a small delta. >> > > Indeed, we originally said we'd review GHC20xx annually, but I think we > might want to consult the community to see if that is too often. There has > been an interesting thread > <https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell > Discourse. > > The HF Stability Working Group discussed this on Monday, and I think Tom > Ellis (a member of the SWG) is willing to lead a consultation. I think > that would be great -- we have no axe to grind here, and I think we'll be > delighted to do whatever makes the maximal number of people happy. > > Tom (cc'd) will write with more info shortly. Sound OK? > > Simon > > On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <mail(a)joachim-breitner.de> > wrote: > >> Hi Committee, >> >> when we defined the process for GHC20xx, as written in >> >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-g… >> we wrote >> >> Likely, the first iteration of this process will be vastly different >> from the following ones: The first one is expected to add a large >> number of uncontroversial extensions; so the next iteration will >> likely only make a smaller, but more controversial change. >> >> Therefore, this proposal does not commit to a fixed cadence. >> Instead, 6 months after the first release of a version of GHC that >> supports a GHC20xx set, we evaluate the outcome, the process, and >> the perceived need of a next release. At that time we will refine >> the processes, if needed, and set a cadence. >> >> The first version of GHC that supported GHC2021 was 9.2, released in >> October 2022. >> >> Last fall we said that not enough time has passed to do such an >> evaluation, and we skipped defining GHC2022. >> >> Another year has passed, and if we are serious with the idea that >> GHC20xx is a continuous thing, we should probably start defining >> GHC2023 – even if it is just a small delta. This e-mail tries to >> kickstart that process. >> >> >> Last time we did a relative elaborate thing where we voted on >> essentially _every_ extension. I think that made sense for the first >> iteration, where we had to winddow down the likely extensions. But now >> we have a base line (GHC2021), and are asked to find a suitable delta, >> and I’d go for a nomination-based approach: Committee members can >> propose adding (or removing, in theory) specific extensions, and then >> we vote only on those. Does that sound reasonable? >> >> Does anyone have any insight from the real world? Has GHC2021 helped >> our users? And if not, why not? >> >> What kind of hard data would you like to see, if any? >> >> (I’m a bit wary of spending too much time writing scripts to scrape >> hackage, for example to see which extensions people tend to enable _in >> addition_ to GHC2021, only to see that libraries on hackage are >> understandably slow to use default-language: GHC2021, as that’s not >> great for backward compat for now. But I am also not sure where to look >> for good data…)

6 21

please accept "Make Symbol a newtype over String"
by Chris Dornan 20 Jan '23

20 Jan '23

While we are at it, here is another proposal that I think should be straightforward. Oleg has proposed that we do essentially the same trick Richard proposed to unify Nat and Natural, but with Symbol and String. Specifically, he is proposing that we replace @data Symbol@ with @newtype Symbol = MkSymbol String@. I won't try and encapsulate any further -- the original is concise and clear. * Oleg's "Make Symbol a newtype over String" proposal: https://github.com/ghc-proposals/ghc-proposals/blob/symbol-type/proposals/0… * For comparison, Richard's accepted "Unify Nat and Natural" proposal: https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-uni… I suggest we allow the usual two weeks to speak or forever hold your peace. Chris

4 4

GHC Steering Committee Status
by Joachim Breitner 19 Jan '23

19 Jan '23

Dear Committee, it seems we need a reminder what’s on our respective plates, so prompted by Simon let’s do another status update. I strongly assume you are always reading these (rare!) emails, especially the second half that lists all our collective or individual TODO items. So what has happened since the last one? * The discussion whether we should have GHC2023 did not take off really, and forked into a somewhat useful, but unfinished fundamental discussion about the role of extensions, over at https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jU… I’ll kick off a vote about GHC2023 in a few days (and by popular request I’ll simplify it to the simple question of whether we should have it at all; I get the feeling that my preference for frequent-over-big-changes is not shared and no need to vote on individual extensions if it won’t come that too) * we were asked to review these proposals: #523: let in types and patterns, Shepherd: Adam #555: Higher Order Patterns in Rewrite Rules, Shepherd Joachim * we have a recommendation from the shepherd about: #512: NoFieldSelectors as datatype annotations, Rec: reject #270: Support pun-free code. Recommendation: accept #546: Make Symbol a newtype over String, Rec: accept #555: Higher Order Patterns in Rewrite Rules, Rec: accept * we have sent the following proposals back to revision #330: Decorate exceptions with backtrace information * we decided about the following proposals #541: Warning pragma with categories (accept) #522: Or patterns (accept) * the authors retracted their proposal #523: let in types and patterns, Shepherd: Adam We currently have to act on the following 10 proposals, two down from last time, but still high: ## Waiting for committee decision #270: Support pun-free code, Shepherd: Chris 2022-01-01: Assigned to Chris 2022-08-24: Chris suggests acceptance 2022-12-04: Chris suggests acceptance again 2022-12-15: Last message I’ve paged out where we are on this one. Something with ExplicitNamespaces? #532: Clean up implicit binding, Shepherd: Arnaud 2022-08-23: Assigned to Arnaud Sent back for revision 2022-11-27: Resubmitted 2022-12-14: Arnaud recommends acceptance Arnaud just picked up the conversation again. Please make it converge. #515: Relaxing HasField constraints 2022-08-01: Assigned to Tom 2022-08-10: Tom suggests acceptance Tom, please drive this forward! #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad 2022-09-03: Assignd to Baldur 2022-10-02: Reassignd to Vlad 2022-11-30: Vlad recommends rejection Turned into a discussion of Modifiers. Where are we on this one? #555: Higher Order Patterns in Rewrite Rules, Shepherd Joachim 2023-01-10: Acceptance recommended Mostly silence. I expect to merge this in a week or so. #546: Make Symbol a newtype over String, Shepherd: Chris 2022-11-18: Assigned to Chris 2022-09-12: Authors gave up 2023-01-19: Chris revived (as #562) and rec’s acceptance ## Waiting for shepherd recommendation #526: Applicative Comprehensions, Shepherd: Simon M 2022-10-08: Assigned to Simon M #529: Template Haskell quotes as patterns, Shepherd: Adam 2022-11-16: Assigned to Adam (should this be “needs revision”)? #540: parallelism semaphores, Shepherd: Eric 2022-11-08: Assigned to Adam 2022-11-17: Re-assigned to Eric #556: fix signature scoping #448, Shepherd: Richard 2022-11-27: Assigned to Richard Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 3

Proposal #532: Clean up and simplify the treatment of implicit bindings. Recommendation: partially accept (maybe)
by Arnaud Spiwack 19 Jan '23

19 Jan '23

Dear all, Proposal https://github.com/ghc-proposals/ghc-proposals/pull/532 Rendered link for the proposal (although several other files are modified): https://github.com/Ericson2314/ghc-proposals/blob/type-variables/proposals/… John Ericson proposes to amend Richard's recent Modern Scoped Type Variables Proposal [ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-t… ] There are two essential parts to the change: 1. The Explicit Binding Principle is modified 2. Change the two extensions introduced by Proposal #285 [ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0285-n… ], -XImplicitForalls and -XPatternSignatureBinds (so that they can be deactivated), and consolidated in Richard's proposal (where -XPatternSignatureBinds is turned into a binding) into a single -XImplicitBinds extension --------- The new Explicit Binding Principle is now somewhat stronger, in that it requires that there is a form with an explicit binder which “regardless of the context, is unambiguously a binding site”. The Lexical Binding Principle is changed, as well, to refer to this new change but it's not substantial. I personally don't think this change to the principles is valuable, it simply blurs the distinction between the Explicit Binding Principle and the Lexical Binding Principle. I find the current phrasing more useful. And I don't think the semantics of the conjunction is actually changed. So I recommend that we reject the changes to the Principles. ------------ John makes a good point: `-XPatternSignature` being a warning has a limitation. This is pointed out in section “Unified Namespacing and extension monotonicity” of the patch to the Modern Scoped Type Variables Proposal. Namely that in t = Int (x :: t) = 0 The current semantics is to have `t` be a binder (because `t` is not bound in the type namespace). If we add a warning for pattern signatures binders, `t` will still be a binder. But we are starting to introduce a new semantics where failing to lookup `t` in the type namespace, we will fall back to look it up in the term namespace instead. The current semantics of considering `t` a binder in this case is at odds with the fallback strategy. (crucially for this recommendation, the same issue occurs in signatures where `forall`-s are implicitly inferred) (Context: At the time where #285 was proposed, I was in favour of a single extension. Simon PJ strongly pushed for two extensions.) My inclination today is that we have a choice: we can either - consider the problem above to be a serious issue, in which case we probably want to eventually deprecate both implicit foralls and pattern signature binds. If this is the case, then they should be gated behind an extension (see also the discussion on the meaning of extensions that we're currently having). I find it healthy to have a single extension for both features because the problem that the extension is solving is the same, hence, in this case, I recommend accepting the changes. - be happy that the semantics is a little quirky, with the fallback happening only when an explicit forall is specified (and never in pattern signatures). In which case both should probably be warnings, it makes sense for the warnings to be separate categories as these are two different features. In this case I recommend rejection of the proposed changes. ------------ I realise I'm leaving a big choice hanging. It's a big decision, I think, which we should weigh carefully (which is kind of funny because the proposed change itself is rather small). Personally, I'd be happy with all implicit foralls and pattern signature binds to be deprecated (so I'm actually taking a position I guess). But I'm not sure that it's super realistic considering the quantity of Haskell that has been written so far. I imagine that there are millions of implicit foralls on Hackage. PS: I'll be on holiday for the next three weeks (starting on Friday night), so you'll have a little while to debate this while I'm away.

2 2

Please review #555: Higher Order Patterns in Rewrite Rules, Shepherd Simon PJ
by Joachim Breitner 10 Jan '23

10 Jan '23

Dear Committee, Jaro Reinders proposes Higher Order Patterns in Rewrite Rules https://github.com/ghc-proposals/ghc-proposals/pull/555 https://github.com/noughtmare/ghc-proposals/blob/template-applications/prop… I suggest Simon PJ to shepherd this proposal, because everyone else already has at least one proposal on their plate (hint hint), and he already conversed on Github. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 2