March 2023 - ghc-steering-committee

Please review #579: Backward compat proposal section, Shepherd: Simon PJ
by Joachim Breitner 06 Jun '23

06 Jun '23

Dear Committee, Adam proposes adding a section on backward compatibility to the proposal template: https://github.com/ghc-proposals/ghc-proposals/pull/579 Richard said that this, even although likely uncontroverisal, should have broad committee visibility, so I’m assigning this to Simon PJ (as the chair) to shepherd this. 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 7

#330: Decorate exceptions with backtrace information, rec: accept
by Vladislav Zavialov 25 May '23

25 May '23

Dear Committee, Ben Gamari has proposed #330 "Decorate exceptions with backtrace information". Read it here: https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-ex… The proposal attaches contextual information to thrown exceptions. This information includes (but is not limited to) backtraces, making it possible to debug uncaught exceptions more effectively. This is a very nuanced change, since it modifies SomeException, throw, catch, and other exception-related definitions whose use is extremely widespread. We might end up affecting our users in unexpected ways. Because of that, I ask the committee to review the proposal with the appropriate amount of care. I am recommending acceptance because adding observability to our programs is an important part of developer ergonomics. From the proposal discussion, I have got the impression that there are numerous commercial users who would benefit from this. Please take a look at the proposal text and share your thoughts either here or directly on GitHub. - Vlad

5 9

#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

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 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