April 2023 - ghc-steering-committee

Language Extension Policy – Round 2
by Arnaud Spiwack 06 Jul '23

06 Jul '23

Dear all, In Round 1', we have gathered no less than 13 use-cases (see below) found in the community for Haskellers to motivate the need for extensions. Some of these use-cases are specific to a pretty definite list of extensions, some are not. Some extensions fall squarely in one use-case, some don't. Use-cases are not a classification of extensions, they're a classification of justifications for extensions to exist. Surely we've missed some, but it's alright to not be fully exhaustive. In this next round, I want us to give our opinion, on each of these use-cases, on whether we believe that this use-case is best served by extension. My goal, in this round, is not necessarily to build consensus for a policy, but to discover where there is consensus, and where there is controversy, so that we can discuss the relevant use-cases in more detail. In this round, I'm asking you, for each X∈{1,…,13}, to answer the following questions: X.1: do you believe that this a use-case that GHC should support? (yes/no) X.2: regardless of your answer in X.1, if GHC supports this use-case, do you believe that this use-case is best served by extensions. (yes/no) X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) X.2.N: if you've answered “no” to X.2: what mechanism would you rather see supporting this use-case (free form) I'll be on holiday next week, and will tally the results on the first week on May. The 13 use-cases are 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. Restrict the use of novel features since the last established standard/report. 4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters) 5. Name/refer to a particular feature when talking/writing/searching about it. 6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax) 7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with. 8. Retain access to deprecated features to smooth out migration over the deprecation period. 9. Retain access to deprecated features indefinitely. 10. 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) 11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too) 12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it) 13. CPP (this one is very unique isn't it?)

8 19

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

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