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

[Eric Seidel]

On Wed, Apr 19, 2023, at 08:20, Arnaud Spiwack wrote:
> 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)

I think this is a valid use case for extensions. I don't see a connection with GHC20xx and I think that's good -- GHC20xx is supposed to be about stable 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)
> 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)
> 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 don't see a useful distinction between these categories, answering all together.)

Yes, GHC (or at least the broader ecosystem) should support these use-cases. I think they might be better served by linters or warnings, but the features are complex enough that it may make sense to bundle the lints with GHC rather than defer to external tools.


> 5. Name/refer to a particular feature when talking/writing/searching
>    about it.

No, this is not a valid use case. The Haskell Standard and the GHC User Guide can name features without introducing a formal extension for them. Algebraic Data Types and Lambdas are two examples of core named language features that do not have associated extensions.


> 7. As library authors, to signal which features the library actually
>    uses, hence which version of GHC the library is compatible with.

No, this is not a valid use case. We already have metadata in Cabal files to indicate GHC compatibility.


> 8. Retain access to deprecated features to smooth out migration over
>    the deprecation period.
> 9. Retain access to deprecated features indefinitely.

(Again, same use-case.)

No, these are not valid use-cases. We have existing deprecation mechanisms that should be preferred here. (And there's no such thing as an indefinite deprecation period. That would mean you're still supporting the feature.)


> 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?)

(This might be more controversial, but I think these are also all the same use-case, which I would dub "Change the language in a way that will never become the default".)

Yes, these are valid use-cases. But, many existing cases of this use targeted pragmas (e.g. OVERLAPPING) rather than module-level extensions. I think both should be allowed, but the targeted version is preferred unless you really do want to change the behavior module-wide.