- ghc-steering-committee

#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

Please review #581: Namespaces-specified Imports, Shepherd: Moritz
by Joachim Breitner 25 May '23

25 May '23

Dear Committee, Adam Gundry, Artyom Kuznetsov and Chris Dornan propose Namespace-specified imports: https://github.com/ghc-proposals/ghc-proposals/pull/581 https://github.com/adamgundry/ghc-proposals/blob/namespace-specified-import… I’d like to ask Moritz to shepherd this proposal. 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/

1 0

GHC Steering Committee Status
by Joachim Breitner 24 May '23

24 May '23

Dear Committee, we had some relatively quiet two weeks on this mailing list, but that quiet doesn’t really fit to the relatively long backlog. Let’s clear it out a bit, if we can! What has happened since the last one update (March 16)? * Arnaud continues the quest to understand the roles of Extensions. * we were asked to review these proposals: #579: Backward compat proposal section, Shepherd: Simon PJ #575: Deprecated instances, Shepherd: Moritz #585: Amend Or Patterns, Shepherd: Richard #493: SPECIALISE with expressions, Shepherd: Adam * we have a recommendation from the shepherd about: #536: Type-level literals as a separate language extension, rec: accept #579: Backward compat proposal section, rec: accept * we have sent the following proposals back to revision #330: Decorate exceptions with backtrace information, Shepherd: Vlad * we decided about the following proposals #540: parallelism semaphores, rec: accept So we currently have to act on the following 8 proposals, up again by 2: ## 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? #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? #579: Backward compat proposal section, Shepherd: Simon PJ 2023-03-30: Assigned to Simon 2023-03-30: Simon recommends acceptance Adam had a question that went unanswerd. Can we resolve this? ## Waiting for shepherd recommendation #526: Applicative Comprehensions, Shepherd: Simon M 2022-10-08: Assigned to Simon M Simon, can you cast your recommendation? #585: Amend Or Patterns, Shepherd: Richard 2023-04-11: Assigned to Richard #575: Deprecated instances, Shepherd: Moritz 2023-04-06: Assigned to Moritz #493: SPECIALISE with expressions, Shepherd: Adam 2023-05-17: Assigned to Adam Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Please review #493: SPECIALISE with expressions, Shepherd: Adam
by Joachim Breitner 17 May '23

17 May '23

Dear Committee, Richard proposes that the SPECIALIZE pragma should understand expressions, not just types: https://github.com/ghc-proposals/ghc-proposals/pull/493 https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-… I’d like to ask Adam to shepherd this proposal. 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/

1 0

#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 12 Apr '23

12 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 06 Apr '23

06 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