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

[Simon Marlow]

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

>
> 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)
>

Just to expand on the rationale here: the categories I proposed (1-5 + 7)
are intended to be *exclusive*: each extension belongs to exactly one of
them. The idea is to give us a way to explain to people why an extension is
or is not part of GHC20xx.

We can have more ways to categorise extensions if we want (e.g. syntactic
vs. not syntactic), and indeed that might be useful. But this one (1-5 + 7)
seemed to me to be most helpful towards the goal of adding some clarity to
the GHC20xx process.


> Q1: Are all the categories 1–5 relevant? If you would like to remove
>        some categories, which and why (free form)?
>

Yes


> 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?
>

Whether an extension is syntactic or not is a useful thing to know, but it
doesn't belong alongside 1-5,7 because it's not an exclusive category.
Let's keep it separate.

Note that extensions that add syntax can still often break existing
programs, either because they steal keywords or they give new meaning to
existing syntax. I'm too lazy to search for examples but there are very
probably syntactic extensions that really do change the meaning of an
existing correct program, rather than just cause an existing program to be
rejected. So an extension being syntactic doesn't necessarily make it a
free addition to GHC20xx although it probably does mean it's less risky.

>
> Q2.N: If you found category 6 not to be relevant, in which category
>             would you classify OverloadedStrings? What about PolyKinds?
>

OverloadedStrings: 1
PolyKinds: 1 or 2


> Q3: Is category 7 relevant?
>

Maybe :) It might be possible to put those extensions into 1 if we can
convince ourselves the breakage potential is low enough. It does seem
sensible to have a category for extensions that are mature but so
specialised that we don't plan to include them in GHC20xx. That's different
from 2 (experimental) because we expect those to eventually mature and move
to 1 (or 7, if we keep it).


> Q3.Y: If you found category 7 to be relevant: should it be its own
>            category or should it be a subcategory of 5?
>

I don't understand how 7 makes sense as 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?
>

5


>  Q5: Is there any category that you feel is missing from the list? If
>        so, please argue (free form).
>

Cheers
Simon


>
> 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/20230224/44f40d31/attachment.html>