This is interesting. I find myself answering "no" to "do you believe this
use-case is best served by extensions" for almost all use-cases, the only
exception being for experimental/unstable language features and language
features with a performance impact. Everything else can be served by either
GHC20xx or warnings. Yes that means being less fine-grained in some cases,
but that might be a good tradeoff between flexibility for users and
complexity in the compiler - fewer combinations of extensions to consider
would simplify things and leave less room for bugs.
Answers below:
On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack
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)
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 2. yes 2.Y no
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. yes 2. no 2.N warnings, -Werror=feature
3. Restrict the use of novel features since the last established standard/report.
1. yes 2. no 2.N -XHaskell2010 and/or warnings
4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters)
1. yes 2. no 2.N warnings
5. Name/refer to a particular feature when talking/writing/searching about it.
1. yes 2. no - we don't need to support extensions to be able to name language features. 2.N continue to use the names we have now, but without supporting -XFoo for all extensions
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)
1. yes 2. no 2.N warnings
7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with.
1. yes 2. no 2.N GHC20xx
8. Retain access to deprecated features to smooth out migration over the deprecation period.
1. yes 2.no 2.N GHC20xx
9. Retain access to deprecated features indefinitely.
1. no
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. yes 2. no 2.N GHC20xx
11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too)
1. yes 2. no 2.N GHC20xx
12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it)
1. yes 2. yes 2.Y no
13. CPP (this one is very unique isn't it?)
1. yes 2. no 2.N it should probably be a flag
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee