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

[Joachim Breitner]

Hi,

Am Freitag, dem 17.02.2023 um 15:06 +0100 schrieb Arnaud Spiwack:
> I am to shepherd the making of our language extension policy

thanks for guiding us here. I owe you one for taking this up, as to
some extend I have sparked the discussion, but am glad that I don’t
have to work out the solution.


About the questions: I am struggling a bit with the meta question of
what are categorization here. Are we categorization inherent, objective
properties of language extensions (“changes meaning of syntax”, “purely
local effect”, “is guarded by syntax”) or are we already applying the
result of a policy here (“should be in a future GHC20xx”, “ought to be
a compiler flag”)

So let me answer Q5 first:

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

I think the categorization we started so far will cause confusing
discussions because they are not mutually exclusive, and it mixes
categorizing inherent properties with categorization policy to be
applied to them.

Here are some inherent, objective properties that I find relevant in
judging the fate of proposed or existing extensions:

 * Is it new-syntax-guarded (e.g. RoleAnnotations),
   or does it affect existing syntax (e.g. OverloadedStrings)
 * Is it a syntactic convenience extension, i.e. its effect can be 
   achieved using normal Haskell or other extensions
   (e.g. NamedFieldPuns, OverloadedStrings, OverlappingInstances),
   or does it add genuinely new abilities.
 * Is it module-local (e.g. OverloadedStrings, most syntactic 
   extensions), or can it affect downstream modules (e.g. LinearTypes, 
   most type system extensions)
 * (maybe more? adherence to our principles? compatibility with #378?)

With these categories safely out of the way on their own axes, we can
now look at the subjective, policy-like categories, where the list of
extensions becomes a (possibly debate heavy) judgement call, such as:
 
 * Is in GHC20xx
 * Should surely be in a future GHC20xx.
 * Yet unclear if it should be in a future GHC20xx (aka experimental)
 * Should definitely not be in a future GHC20xx, because
   - its effects can be achieved using other means and the others means
     are preferable (e.g. OverlappingInstances)
   - deprecated feature
   - should have been a flag
   - special use-case that can’t be default, but still worth supporting

With this in mind, let me try to answer the questions

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

I think we need to distinguish between

   * is in GHC20xx
   * could be in a future GHC20xx
   
as presumably we might have different stability expectations for these
two.

Furthermore, since  “experimental like LinearTypes” surely doesn’t
exclude “could be part of a future GHC20xx”, so maybe the wording
should be
 * experimental, meaning “we don’t know yet if we would want it in a
   future GHC20xx”
vs. 
 * “we are fairly sure we want this to be in a future GHC20xx”

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

Relevant, but on a separate axis (see above).



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

I don’t mind grouping 7 and 5 together.

>  Q4: In which category would you classify Strict?

That’s a tough one. It’s a language dialect that we likely don’t want
to be the default, but it’s likely useful to some. I’m leaning towards
saying “it should have been a flag”, if we don’t want a separate
“special use-case worth supporting”.

Whether we want that category at all depends on a bit on the further
discussion (e.g. whether we want to encourage language variants/forks,
or discourage them, and how strongly). So maybe let’s keep the category
for now.


Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/