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

Mon May 1 01:56:10 UTC 2023

Thanks, Arnaud, for organizing this for us!

> On Apr 19, 2023, at 8:20 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> X.1: do you believe that this a use-case that GHC should support? (yes/no)

I'm going to interpret "GHC" as "the Haskell toolchain". That is, I'll answer whether some official tool should support the use-case, but my answer to X.2.N may say that some other part of the ecosystem is better suited than GHC.

> 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. Not really. Experimental extensions need to be fine-grained. 

> 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 (but not in GHC itself)
2.2. No
2.2.N. This is better suited for non-GHC tools, such as a linter or an IDE. The fine-grained approach to extensions is not so helpful here.

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

3.1. No -- it's just too expensive to keep doing this
3.2. No
3.2.N. GHC could have a Haskell2010 mode that meets the standard, and then a normal mode that doesn't. There is no need for a slew of extensions.

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

4.1. Yes (but not in GHC itself)
4.2. No
4.2.N. See 2.2.N. I don't see the difference between 2 and 4.

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

5.1. Yes
5.2. No
5.2.N. Careful documentation in the manual and consistent text in error messages.

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

6.1. Yes
6.2. No
6.2.N. This sounds like a ./configure -time flag, if GHC is being built on a platform lacking some critical support. (Programmers may want to avoid using a non-universal feature, but that sounds more like 2 or 4 than this question.)

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

7.1. Yes (but not in GHC itself)
7.2. No
7.2.N. This sounds like something a package installer should do. In some perfect world, a package could just name a set of features and then the tool finds a GHC that has those features, but GHC is just too complex in the real world -- people will just have to use version numbers.

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

8.1. Yes
8.2. Sometimes, yes
8.2.Y. No; this is essentially the dual to (1), and it wants a fine-grained approach
8.2.N. In some cases, this could be better achieved through warnings and other mechanisms. But sometimes a proper extension will be needed.

> 9. Retain access to deprecated features indefinitely.

9.1. No. If we're going to deprecate a feature, let's have the courage of our convictions.
9.2. Sometimes, yes
9.2.Y/N. Just like 8.2.Y/N.

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

10.1. Yes, but very sparingly
10.2. No
10.2.N. These are not language *extensions*. These are language *alterations*. There should be a different mechanism. But, really, we should try very hard to avoid doing this, because it makes reading code much harder -- you can read and understand code only after looking at all of these settings. In practice, this might still end up fitting into the existing language-extensions framework, but I'd rather see a way of specifying these kinds of changes locally in a region of code, so that the choice is manifest in the source file.

> 11. Extend the language in a way that is not backward compatible
>     (e.g. OverloadedList, probably some dependent Haskell things too)

I can't see the difference between 11 and 10.

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

12.1. Yes
12.2. Sure.
12.2.Y. No, because you want fine-grained control.

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

13.1. Yes
13.2. No
13.2.N. This should be a compiler flag. It's not about the language really.

Richard

> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee