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

[Arnaud Spiwack]

Dear all,

I am to shepherd the making of our language extension policy, working
off our draft document
[
https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/
].
As a prelude to my introduction, I first want to apologise for taking
that long to get back to this subject, time has, I'm afraid, gotten away
from me. Part of the reason, though, is that we've been pulling in
many directions, and I felt it difficult to find a path toward
consensus among all that.

In the time since I accepted the task, I have therefore spent a lot of
time reading through the entire document multiple time, to try and
identify the points where we agree and the points where we
diverge. And try to build a methodology.

If you go to the document, you'll see that I've separated out our
notes after a horizontal line. I will grow the document above the line
with decisions from this mailing list. Hopefully, the process will
make sure that we are in broad agreement that the text does reflect
our collective position.

The way I'm going to proceed is to organise votes. Or maybe they
should rather be seen as surveys. They'll have a bunch of questions,
pertaining to bits of the documents that I want us to converge on. I'll
extract a broad consensus from this survey, and use it to copy
language in the document. I intend to give about a week for each
survey to complete (conveniently, I'll be very far from a computer for
the next week, so I'll be able to tally the results when I come
back). It's going to take a while, but it's a very difficult, and
sensitive, subject.

---

For this first round, I want us to focus on the categorisation of
language extensions as proposed by Richard and Simon M (sections 2.1
and 2.3, respectively, of our draft notes). As I feel that we will
need to have these categories identified in order to discuss the later
points.

Here are the categories that are common to both (consult the document
for more details):

1. Extensions that are either in GHC20xx or could be part of a future
   GHC20xx (e.g. GADTs)
2. Experimental language features (e.g. LinearTypes)
3. Extensions that allow module-wide violation of some general
   principle that holds elsewhere (e.g. OverlappingInstances)
4. Extensions that allow access to deprecated features (e.g.
DatatypeContexts)
5. Extensions that should be compiler flags, which do not actually
   change the accepted language (e.g. Safe)

Richard adds another category

6. Extensions that change the semantics of existing constructs
   (e.g. OverloadedStrings); as opposed to most extensions, which
   create new syntax for the new feature.

Richard's reasoning is twofold 1/ he doesn't believe that they should
be candidate for inclusion in GHC20xx 2/ he believes that they are
problematic for the same sort of reason as we've used to argue against
fork-like behaviour: that to understand the meaning of a piece of code
you need to know what language extensions have been loaded in the
file.

Simon M adds another category

7. Extensions for specialised use-cases (e.g. MagicHash,
   UnboxedTuples)

Simon's reasoning is that these should not be part of GHC20xx. At the
very least they are not intended to. But they do extend the language,
like 1, and unlike 5. Hence they deserve to be categorised separately
from both.

It is worth noting that Richard classifies Strict as a 6 and Simon M
classifies Strict as a 7.

Now the survey.

Keeping in mind that the goal of this categorisation is to classify
the extensions that currently exist, without judgement on whether we
want to have things in these categories or not:

Q1: Are all the categories 1–5 relevant? If you would like to remove
       some categories, which and why (free form)?
Q2: Is category 6 relevant?
Q2.Y: If you found category 6 to be relevant: should it be its own
           category, or should it be a subcategory of 1?
Q2.N: If you found category 6 not to be relevant, in which category
            would you classify OverloadedStrings? What about PolyKinds?
Q3: Is category 7 relevant?
Q3.Y: If you found category 7 to be relevant: should it be its own
           category or should it be a subcategory of 5?
Q3.N: If you found category 7 not to be relevant: in which category
           would you classify MagicHash? What about UnboxedTuples?
 Q4: In which category would you classify Strict?
 Q5: Is there any category that you feel is missing from the list? If
       so, please argue (free form).

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