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

[Arnaud Spiwack]

Simon,

Quite funny that you're writing this now, as I'm finishing writing my next
email, after a pretty long unplanned absence (apologies about that).

Thanks for forwarding Richard's suggestion, which I hadn't seen.

/Arnaud

On Thu, 30 Mar 2023 at 09:00, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> 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/40aedd9b/attachment-0001.html>