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

[Simon Peyton Jones]

Where are we on this thread, Arnaud?

Separately Richard has suggested
<https://github.com/ghc-proposals/ghc-proposals/pull/536#issuecomment-1475395448>
:

I think *all* extensions that just enable new syntax (without changing the
> meaning of any existing programs) should be warnings.
>

That seems like a possible principle, which could form part of this
discussion.

Simon

On Fri, 17 Feb 2023 at 14:07, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230330/cd97c050/attachment.html>