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

[Simon Marlow]

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 <arnaud.spiwack at tweag.io>
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)
>
> 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230427/8f7ab546/attachment-0001.html>