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

[Adam Gundry]

On 26/04/2023 13:23, Simon Peyton Jones wrote:
 >
> I went down the list and in every case I thought "yes, language 
> extensions allow a user to do this, if they want".   I struggled to 
> answer your questions.  Eg
> 
>   * X1 is this a use-case GHC should support.  Well it already supports
>     it.   I suppose we could debate which are active goals and which are
>     accidental, but before burning the midnight oil on that debate I'd
>     love to know where this is going.

I understand Arnaud's intention here to be that we debate what the 
purpose and goals of the extensions system should be. This might include 
saying that GHC shouldn't try to support certain use cases, or that for 
some use-cases we don't believe extensions are the right mechanism to use.

My basic position is that it is crucial for extensions to be 
well-defined and introduce orthogonal language features. This isn't 
something GHC has always been good at historically, as a few extensions 
have accreted multiple somewhat-related effects. But given that caveat, 
I'm generally in favour of keeping many extensions (including splitting 
up extensions into small simple parts where appropriate). If users are 
intimidated by long extension lists, the solution IMHO is to create 
groups of related extensions, enable them by default (as in GHC20xx), 
and document them accordingly.

With that in mind, here are my (tentative) answers...


On 19/04/2023 13:20, Arnaud Spiwack 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)


 > 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.1: Yes
1.2: Yes
1.2.Y: Yes (GHC20xx can be used as a baseline, thereby making clear 
which extensions are more experimental and avoiding the need to list the 
non-experimental ones)


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

2.1: Yes
2.2: Yes
2.2.Y: Yes

In my view, it's not the fact of features being more complex that is 
crucial; rather the point is to have a language that is built up as a 
composition of pieces that can be understood (and enabled) independently.


 > 3. Restrict the use of novel features since the last established
 >     standard/report.

3.1: Yes
3.2: Yes
3.2.Y: No

I think it would be a shame to drop support for Haskell98/Haskell2010 
unless there is a clear cost to maintaining such support.


 > 4. Restrict the use to features that they don't like (e.g.
 >     controversial features like RecordWildcard or ImplicitParameters)

4.1: No
4.2: No
4.2.N: Merely disliking a feature isn't a good reason to make an 
extension out of it; using the warnings system is better, or moving a 
check to an external linter. Though of course controversial features may 
be extensions for other reasons.


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

5.1: Yes
5.2: No
5.2.N: We should strive to use consistent terminology and document 
feature names clearly, but that doesn't by itself require an extension.


 > 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 (sorry, belatedly) think at least one use case should cover tools 
"outside the GHC ecosystem" rather than the "Haskell ecosystem"; in 
particular we should keep in mind the needs of other Haskell compilers 
and tools. On that basis:

6.1: Yes
6.2: Yes
6.2.Y: Yes


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

7.1: No
7.2: No
7.2.N: The fundamental issue here is that GHC doesn't maintain stable 
meanings for extensions over time (and it doesn't seem feasible to do 
so). Thus I think it would be better if libraries communicate supported 
GHC versions in their cabal files, and the cabal solver used that 
information directly rather than relying on the other-extensions field.


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

{8,9}.1: Yes
{8,9}.2: Yes (where the feature being deprecated is an existing language 
extension or one can be sensibly defined retrospectively, as with 
DeepSubsumption)
{8,9}.2.Y: Yes

I see the question of whether deprecated features are available only for 
a migration period or indefinitely as orthogonal to whether they are 
extensions. Instead it depends on the specific case (how widely used is 
it, how easy is the migration path, how expensive is it to continue 
support). I think it's reasonable to have a feature deprecated 
indefinitely (because we advise against its use for new code, but it 
doesn't hurt to keep it around for backwards compatibility).


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

I don't see a clear distinction between these categories. Is it that 10 
covers changes that will never be on by default, whereas 11 covers 
changes that we want to become the default but need a migration path?

{10,11}.1: Yes
{10,11}.2: Yes
{10,11}.2.Y: Yes


 > 12. Enable features whose mere presence has a performance impact
 >      (e.g. Template Haskell, and that's probably it)

12.1: Yes
12.2: No
12.2.N: Controls over (compile-time?) performance should be expressed as 
`-f...` flags (but of course TemplateHaskell is an extension for other 
reasons).


 > 13. CPP (this one is very unique isn't it?)

13.1: Yes
13.2: Yes (perhaps if we were to start again this could be its own 
pragma, but there's no point changing it now)
13.2.Y: N/A



-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England