Hi, Am Mittwoch, dem 19.04.2023 um 14:20 +0200 schrieb Arnaud Spiwack:
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)
1: Yes, worthwhile usecase. 2: Yes, Extensions serve this well. 2Y: By definition GHC20xx doesn’t help, because it doesn’t touch experimental or unstable features.
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)
1: No, I don’t think that’s a task that the compiler is necessary best suited for. At least not at the current “accidential” complexity – if there was a push for real language levels as a first-class, well designed feature, things would be different. 2: No. They kinda work, but maybe warning flags are more suitable. 2N: Waring flags or, maybe better, external tools (hlint).
3. Restrict the use of novel features since the last established standard/report.
1: Yes, worthwhile to support. Although I’d phrase it dually: It’s worthwhile for GHC to support, in addition to “current GHC Haskell”, the standardized dialects. 2: Yes, kinda. 2Y: Yes, at least in the general sense that GHC20xx, like Haskell2021, selects a language dialect alltogether, instead of having to turn off and on individual flags.
4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters)
Same answers as for 2.
5. Name/refer to a particular feature when talking/writing/searching about it.
1: Yes, very useful to have names for things! 2: I’m unsure. The extension names work quite well. But if this would be come an actively supported use-case (rather than an accidential one), should we come up with names for existing things as well? (-XWhereBindings). It doens’t seem to be a good idea to couple “well- identified feature with a clear name” and “compiler flag”
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)
Again similar to 2. I don’t see anything wrong with GHC just accepting unicode syntax when it encounters them, just like it accepts non-ASCII variable names. (This is independent of whether GHC should print syntax in Unicode style unless asked to do it, but that’s not a language design question.)
7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with.
1: Yes, useful. 2: Possibly, but that would require a more defined story about backwards compatibility within an extension. Can we change extensions? Or only those that are somehow labeled to be more stable? 2Y: It could help if “being in GHC20xx” is used as a proxy for “kinda stable”, which is a prerequisite for this signallingto work reliably. 2N: That said, I don’t see much benefit of using this indirect compat signalling over just stating in the library which GHC versions it is known to work with, just like we do with library dependencies.
8. Retain access to deprecated features to smooth out migration over the deprecation period.
1: Yes, useful. Similar to question 3 2: Yes 2Y: Yes, by using an older GHC20xx one pins an older feature set, possibly including deprecated versions. This decouples “upgrading GHC” and “adopting the code base to the new dialect”, which should make life easier for developers.
9. Retain access to deprecated features indefinitely.
1: Unsure. Depends on how commonly used it is, and how expensive it is to carry around.
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)
1: I’m leaning to say no. Haskell + StrictData is a different language, and one that we can’t envision to be the default (I’d say). That use case should ideally be addressed in a different way that is a language extension, not a language change. 2: No 2N: Annotations maybe, or a new keyword?
11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too)
1: Strong yes. Barring ourselves from making changes that may affect some existing programs is no longer avoiding success at all costs. 2: Yes 2Y: Yes, definitely: It means that the programmer is in control when to apply a change like OverloadedStrings which may require some code changes.
12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it)
1: Yes. 2: No, a dedicated pragma would probably be cleaner, but willing to entertain that single odd case. It would also be more consistent to always _parse_ the TH syntax (to avoid breakage when it is enabled, and to make reading code less ambiguous), and simply fail if the pragma is not set given.
13. CPP (this one is very unique isn't it?)
1: Yes 2: Again, dedicated pragma might be cleaner. Also helps programs parsing Haskell programs if the information is _always_ local in the file. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/