On 26/04/2023 13:23, Simon Peyton Jones wrote:
I went down the list and in every case I thought "yes, language extensions allow a user to do this, if they want". I struggled to answer your questions. Eg
* X1 is this a use-case GHC should support. Well it already supports it. I suppose we could debate which are active goals and which are accidental, but before burning the midnight oil on that debate I'd love to know where this is going.
I understand Arnaud's intention here to be that we debate what the purpose and goals of the extensions system should be. This might include saying that GHC shouldn't try to support certain use cases, or that for some use-cases we don't believe extensions are the right mechanism to use. My basic position is that it is crucial for extensions to be well-defined and introduce orthogonal language features. This isn't something GHC has always been good at historically, as a few extensions have accreted multiple somewhat-related effects. But given that caveat, I'm generally in favour of keeping many extensions (including splitting up extensions into small simple parts where appropriate). If users are intimidated by long extension lists, the solution IMHO is to create groups of related extensions, enable them by default (as in GHC20xx), and document them accordingly. With that in mind, here are my (tentative) answers... On 19/04/2023 13:20, Arnaud Spiwack wrote:
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)
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)
1.1: Yes 1.2: Yes 1.2.Y: Yes (GHC20xx can be used as a baseline, thereby making clear which extensions are more experimental and avoiding the need to list the non-experimental ones)
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)
2.1: Yes 2.2: Yes 2.2.Y: Yes In my view, it's not the fact of features being more complex that is crucial; rather the point is to have a language that is built up as a composition of pieces that can be understood (and enabled) independently.
3. Restrict the use of novel features since the last established standard/report.
3.1: Yes 3.2: Yes 3.2.Y: No I think it would be a shame to drop support for Haskell98/Haskell2010 unless there is a clear cost to maintaining such support.
4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters)
4.1: No 4.2: No 4.2.N: Merely disliking a feature isn't a good reason to make an extension out of it; using the warnings system is better, or moving a check to an external linter. Though of course controversial features may be extensions for other reasons.
5. Name/refer to a particular feature when talking/writing/searching about it.
5.1: Yes 5.2: No 5.2.N: We should strive to use consistent terminology and document feature names clearly, but that doesn't by itself require an extension.
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)
I (sorry, belatedly) think at least one use case should cover tools "outside the GHC ecosystem" rather than the "Haskell ecosystem"; in particular we should keep in mind the needs of other Haskell compilers and tools. On that basis: 6.1: Yes 6.2: Yes 6.2.Y: Yes
7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with.
7.1: No 7.2: No 7.2.N: The fundamental issue here is that GHC doesn't maintain stable meanings for extensions over time (and it doesn't seem feasible to do so). Thus I think it would be better if libraries communicate supported GHC versions in their cabal files, and the cabal solver used that information directly rather than relying on the other-extensions field.
8. Retain access to deprecated features to smooth out migration over the deprecation period. 9. Retain access to deprecated features indefinitely.
{8,9}.1: Yes {8,9}.2: Yes (where the feature being deprecated is an existing language extension or one can be sensibly defined retrospectively, as with DeepSubsumption) {8,9}.2.Y: Yes I see the question of whether deprecated features are available only for a migration period or indefinitely as orthogonal to whether they are extensions. Instead it depends on the specific case (how widely used is it, how easy is the migration path, how expensive is it to continue support). I think it's reasonable to have a feature deprecated indefinitely (because we advise against its use for new code, but it doesn't hurt to keep it around for backwards compatibility).
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)
I don't see a clear distinction between these categories. Is it that 10 covers changes that will never be on by default, whereas 11 covers changes that we want to become the default but need a migration path? {10,11}.1: Yes {10,11}.2: Yes {10,11}.2.Y: Yes
12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it)
12.1: Yes 12.2: No 12.2.N: Controls over (compile-time?) performance should be expressed as `-f...` flags (but of course TemplateHaskell is an extension for other reasons).
13. CPP (this one is very unique isn't it?)
13.1: Yes 13.2: Yes (perhaps if we were to start again this could be its own pragma, but there's no point changing it now) 13.2.Y: N/A -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England