[ghc-steering-committee] Language Extension Policy – Round 2

[Arnaud Spiwack]

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?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230419/6a4174c3/attachment.html>