- ghc-steering-committee

#536: Type-level literals as a separate language extension, rec: accept
by Vladislav Zavialov 09 May '23

09 May '23

Dear Committee, Ross Paterson has proposed #536 "Type-level literals as a separate language extension". Read it here: https://github.com/RossPaterson/ghc-proposals/blob/literals/proposals/0000-… Currently the DataKinds extension allows us to use both type-level literals (such as "hello", 'x', and 42) and promoted algebraic data constructors (such as True, Just, and '[]). The proposal is to factor out promotion of literals into its own extension, TypeLevelLiterals. Why would one want to enable TypeLevelLiterals but not DataKinds? Because the latter can create ambiguities when it comes to name resolution. If the user defines `data Just x = ...` and they have DataKinds enabled, then suddenly it's ambiguous whether `Just` refers to a data constructor or a type constructor, and GHC starts to guess from context. Type-level literals, on the other hand, are a more conservative subset of DataKinds that does not raise any questions with regards to name resolution. While I, personally, would not use this conservative subset, I believe we shouldn't create obstacles for those who want to. I expect the maintenance costs to be minimal. Does anyone have objections? If not, I will mark the proposal accepted in 2 weeks. - Vlad

8 17

Language Extension Policy – Round 1'
by Arnaud Spiwack 18 Apr '23

18 Apr '23

Dear all, Sorry for the long silence. I was named and shamed by Joachim the other day, which is fair enough. I've basically disappeared from my email for a while. I am aware that not having solved this is holding us back, I'll be more consistent in the future. As I said in my last email, I'd like to start the conversation again from the point of view of use-cases, as proposed by Adam, and see if it helps us go forward. What I want to do, today, is to describe what Haskell programmers have been using extension for. This is meant to be purely a description, without judgement on whether the proposed use-cases are good ideas. When the use-cases are listed, we'll turn to which we want to support and how. Without further ado, here is a list of use-cases, based on Adam's list (my rephrasing), with additions by me. Haskell programmers use extensions to: 1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability) 2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language) 3. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with. 4. Retain access to deprecated features to smooth out migration over the deprecation period. 5. Retain access to deprecated features indefinitely. 6. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example) 7. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too) 8. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it) 9. CPP (this one is very unique isn't it?) (Note: Adam proposed some use-cases which are not included here: using extension to ensure stability (which is the contrapositive of 1), and as a GHC dev, make features available to early adopters (which is the dual of 1). I didn't include them because I consider that they are contained in 1, but if you disagree, please argue otherwise) Questions: 1. Have we missed some use-cases, if so describe? (I'm sure we have, so I'd be surprised if nothing turns up here) 2. Do you think some of the use-cases above should be split into several use-cases? 3. Conversely, are there distinctions that don't make sense to you and you would argue should be merged? Before answering, take note that while some of the proposed use-cases can be seen as a list of extensions that behave a certain way, some extensions may be used in several use-cases (4 and 5, by definition concern the same set of extensions), some use-cases (like 3) are independent of the behaviour of extensions. This is not a classification of extension, but of how they are consumed. I'll tally the result on Tuesday 10th April. Best, Arnaud

5 7

Please review #585: Amend Or Patterns, Shepherd: Richard
by Joachim Breitner 13 Apr '23

13 Apr '23

Dear Committee, David Knothe proposes to amend the Or Patterns proposal: https://github.com/ghc-proposals/ghc-proposals/pull/585 Since Richard shepherded the original proposal, I’d like to ask him to shepherd this one too. 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

Please review#575: Deprecated instances, Shepherd: Moritz
by Joachim Breitner 07 Apr '23

07 Apr '23

Dear Committee, Vlad proposes adding support for Deprecating Instances. https://github.com/ghc-proposals/ghc-proposals/pull/575 https://github.com/int-index/ghc-proposals/blob/int-index/deprecated-instan… I’m assigning this to Moritz as the shepherd. 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 1

Language Extension Policy – Round 1
by Arnaud Spiwack 30 Mar '23

30 Mar '23

Dear all, I am to shepherd the making of our language extension policy, working off our draft document [ https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jU… ]. As a prelude to my introduction, I first want to apologise for taking that long to get back to this subject, time has, I'm afraid, gotten away from me. Part of the reason, though, is that we've been pulling in many directions, and I felt it difficult to find a path toward consensus among all that. In the time since I accepted the task, I have therefore spent a lot of time reading through the entire document multiple time, to try and identify the points where we agree and the points where we diverge. And try to build a methodology. If you go to the document, you'll see that I've separated out our notes after a horizontal line. I will grow the document above the line with decisions from this mailing list. Hopefully, the process will make sure that we are in broad agreement that the text does reflect our collective position. The way I'm going to proceed is to organise votes. Or maybe they should rather be seen as surveys. They'll have a bunch of questions, pertaining to bits of the documents that I want us to converge on. I'll extract a broad consensus from this survey, and use it to copy language in the document. I intend to give about a week for each survey to complete (conveniently, I'll be very far from a computer for the next week, so I'll be able to tally the results when I come back). It's going to take a while, but it's a very difficult, and sensitive, subject. --- For this first round, I want us to focus on the categorisation of language extensions as proposed by Richard and Simon M (sections 2.1 and 2.3, respectively, of our draft notes). As I feel that we will need to have these categories identified in order to discuss the later points. Here are the categories that are common to both (consult the document for more details): 1. Extensions that are either in GHC20xx or could be part of a future GHC20xx (e.g. GADTs) 2. Experimental language features (e.g. LinearTypes) 3. Extensions that allow module-wide violation of some general principle that holds elsewhere (e.g. OverlappingInstances) 4. Extensions that allow access to deprecated features (e.g. DatatypeContexts) 5. Extensions that should be compiler flags, which do not actually change the accepted language (e.g. Safe) Richard adds another category 6. Extensions that change the semantics of existing constructs (e.g. OverloadedStrings); as opposed to most extensions, which create new syntax for the new feature. Richard's reasoning is twofold 1/ he doesn't believe that they should be candidate for inclusion in GHC20xx 2/ he believes that they are problematic for the same sort of reason as we've used to argue against fork-like behaviour: that to understand the meaning of a piece of code you need to know what language extensions have been loaded in the file. Simon M adds another category 7. Extensions for specialised use-cases (e.g. MagicHash, UnboxedTuples) Simon's reasoning is that these should not be part of GHC20xx. At the very least they are not intended to. But they do extend the language, like 1, and unlike 5. Hence they deserve to be categorised separately from both. It is worth noting that Richard classifies Strict as a 6 and Simon M classifies Strict as a 7. Now the survey. Keeping in mind that the goal of this categorisation is to classify the extensions that currently exist, without judgement on whether we want to have things in these categories or not: Q1: Are all the categories 1–5 relevant? If you would like to remove some categories, which and why (free form)? Q2: Is category 6 relevant? Q2.Y: If you found category 6 to be relevant: should it be its own category, or should it be a subcategory of 1? Q2.N: If you found category 6 not to be relevant, in which category would you classify OverloadedStrings? What about PolyKinds? Q3: Is category 7 relevant? Q3.Y: If you found category 7 to be relevant: should it be its own category or should it be a subcategory of 5? Q3.N: If you found category 7 not to be relevant: in which category would you classify MagicHash? What about UnboxedTuples? Q4: In which category would you classify Strict? Q5: Is there any category that you feel is missing from the list? If so, please argue (free form). Best, Arnaud

7 19

GHC Steering Committee Status
by Joachim Breitner 18 Mar '23

18 Mar '23

Dear Committee, it’s not quite yet spring time. But it is always GHC Steering Committee time. So let’s see where we are. What has happened since the last one update (January 19)? * We decided not to have GHC2023. * Arnaud took on the daunting task of writing down more concrete policies about what role language Extensions have these days, where the committee wants to steer the language to, and what implications that has for our work. * We welcomed Moritz Angerman as a new member (and changed the bylaws a bit to make that possible) Tom stepped down from the committee. Thanks Tom! * we were asked to review these proposals: #330: Decorate exceptions with backtrace information, rec: accept #536: Type-level literals as a sep language extension, Shepherd: Vlad * we have a recommendation from the shepherd about: #540: parallelism semaphores, rec: accept #330: Decorate exceptions with backtrace information, rec: accept #536: Type-level literals as a sep language extension, rec: accept * we have sent the following proposals back to revision #270: Support pun-free code #515: Relaxing HasField constraints #562 Make Symbol a newtype over String (originally #546) #529: Template Haskell quotes as patterns * we decided about the following proposals #555: Higher Order Patterns in Rewrite Rules (accept) #556: fix signature scoping #448 (accept) * we fast-tracked two amendments to existing proposals: #573: No #. label #576: Warning Category syntax We currently have to act on the following 6 proposals, 4 down. Good trend, let’s continue it! (Note that we sent 4 back to revision, which means they’ll come back…) ## Waiting for committee decision #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 2023-01-17: Arnaud picks up the conversation again. Silence since. #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad 2022-09-03: Assigned to Baldur 2022-10-02: Reassignd to Vlad 2022-11-30: Vlad recommends rejection Turned into a discussion of Modifiers, and then into silence. Where are we on this one? #540: jsem parallelism semaphores, Shepherd: Eric 2022-11-08: Assigned to Adam 2022-11-17: Re-assigned to Eric 2023-02-12: Eric recommends acceptance Lots of discussion on the list and on Github. Is this near conclusion, or should it go back to revision? #536: Type-level literals as a sep language extension, Shepherd: Vlad 2023-02-16 Assigned to Vlad 2023-03-06 Vlad recommends acceptance Some hesitancy in the committee to introduce this extension, the ongoing policy clarification process might guide us, but maybe we can resolve this earlier? #330: Decorate exceptions with backtrace information, Shepherd: Vlad 2023-03-06: Vlad recommends acceptance. Some active discussion on Github. Is this steering towards a conclusion? ## Waiting for shepherd recommendation #526: Applicative Comprehensions, Shepherd: Simon M 2022-10-08: Assigned to Simon M Simon, can you cast your recommendation? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Please review #536: Type-level literals as a separate language extension, Shepherd: Vlad
by Joachim Breitner 06 Mar '23

06 Mar '23

Dear Committee, Ross Paterson proposes Type-level literals as a separate language extension https://github.com/ghc-proposals/ghc-proposals/pull/536 https://github.com/RossPaterson/ghc-proposals/blob/literals/proposals/0000-… I suggest Vlad to shepherd this, as he has already engaged with it 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/

3 2

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

03 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

Proposal #556 recommendation: accept
by Richard Eisenberg 10 Feb '23

10 Feb '23

Hi all, Vlad has proposed https://github.com/ghc-proposals/ghc-proposals/pull/556, an amendment to recently accepted proposal #448 on scoped type variables. It adds a nuance saying that f (MkT @(a :: <<here>>)) = ... should have the same scoping behavior as f (MkT (x :: <<here>>)) = ... Note that the first is a kind signature of a visible-type-application-in-a-pattern, while the second is a pattern signature. The intended scoping rule says that the use of an in-scope type variable in these positions is an occurrence, while the use of an out-of-scope type variable brings that variable into scope. Vlad's proposal corrects the phrasing in the original proposal that aligns the treatment of the kind signature with the type it is describing, forbidding e.g. the use of a repeated variable in the kind signature. Vlad's amendment makes the proposal what I had intended when I wrote #448; I strongly recommend acceptance. I think this is a small tweak of a technical detail buried in #448 and hope this does not cause widespread debate. I will accept this proposal in a week if I don't hear objections. Thanks! Richard

4 4