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

Thanks, Arnaud, for organizing this for us!

On Apr 19, 2023, at 8:20 AM, Arnaud Spiwack 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee