[ghc-steering-committee] Language Extension Policy – Round 1'

[Arnaud Spiwack]

Dear all,

Sorry for the long silence. I was named and shamed by Joachim the
other day, which is fair enough. I've basically disappeared from my
email for a while. I am aware that not having solved this is holding
us back, I'll be more consistent in the future.

As I said in my last email, I'd like to start the conversation again
from the point of view of use-cases, as proposed by Adam, and see if
it helps us go forward. What I want to do, today, is to describe what
Haskell programmers have been using extension for. This is meant to be
purely a description, without judgement on whether the proposed
use-cases are good ideas. When the use-cases are listed, we'll turn to
which we want to support and how.

Without further ado, here is a list of use-cases, based on Adam's list
(my rephrasing), with additions by me. Haskell programmers use
extensions to:

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)
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. As library authors, to signal which features the library actually
   uses, hence which version of GHC the library is compatible with.
4. Retain access to deprecated features to smooth out migration over
   the deprecation period.
5. Retain access to deprecated features indefinitely.
6. 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)
7. Extend the language in a way that is not backward compatible
   (e.g. OverloadedList, probably some dependent Haskell things too)
8. Enable features whose mere presence has a performance impact
   (e.g. Template Haskell, and that's probably it)
9. CPP (this one is very unique isn't it?)


(Note: Adam proposed some use-cases which are not included here: using
extension to ensure stability (which is the contrapositive of 1), and
as a GHC dev, make features available to early adopters (which is the
dual of 1). I didn't include them because I consider that they are
contained in 1, but if you disagree, please argue otherwise)

Questions:
1. Have we missed some use-cases, if so describe? (I'm sure we have,
   so I'd be surprised if nothing turns up here)
2. Do you think some of the use-cases above should be split into
   several use-cases?
3. Conversely, are there distinctions that don't make sense to you and
   you would argue should be merged?

Before answering, take note that while some of the proposed use-cases
can be seen as a list of extensions that behave a certain way, some
extensions may be used in several use-cases (4 and 5, by definition
concern the same set of extensions), some use-cases (like 3) are
independent of the behaviour of extensions. This is not a
classification of extension, but of how they are consumed.

I'll tally the result on Tuesday 10th April.

Best,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230330/5c1b3313/attachment.html>