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

Tue Feb 28 14:45:35 UTC 2023

We definitely *could* assign every extension a 1-5 score on 6+ different
axes, but I have to admit the thought of actually doing this gives me a
sinking feeling! Furthermore I'm not sure what we would do with the
results. How do we use the scores to decide what goes into GHC20xx? It
feels like we're creating a great deal of work for ourselves.

The idea of categorising rather than scoring is to shortcut the discussion.
If we know that some extension is experimental (e.g. LinearTypes), it just
goes in the experimental category and we don't need to think about it any
more. If we have an extension that is enabling a deprecated feature, again
we don't need to consider any other aspects.

So, perhaps these axes are useful for extensions that are candidates for
GHC20xx and not in one of the other categories 2-5 in Arnaud's list. But if
we're going to reject extensions from GHC20xx for reasons that are *not*
covered by categories 2-5 in Arnaud's list, then we should think about what
those reasons might be. Is "breaks too many programs" one of them?

Cheers
Simon

On Fri, 24 Feb 2023 at 18:04, Richard Eisenberg <lists at richarde.dev> wrote:

> Thanks, Arnaud!
>
> > Q1: Are all the categories 1–5 relevant? If you would like to remove
> >        some categories, which and why (free form)?
>
> I'm not really sure I understand Category 1. In particular, I think my
> initial categorization didn't have Arnaud's Category 1, but instead had
>
> 8. Extensions that enable only new programs, without changing the
> semantics of any existing program
>
> This was meant as a counterpoint to 6.
>
> But my initial categorization was non-orthogonal: for example, this
> Category 8 overlaps with several other categories. In that way, Joachim's
> argument that we could imagine two axes of categorization -- one technical,
> one policy-oriented -- is intriguing. For example, -XDatatypeContexts
> belongs in Category 8 (it's a syntactic extension), but that doesn't mean
> it should be on-by-default.
>
> Along similar lines, Categories 2 and 3 overlap: we might have an
> experimental language feature that violates a general principle. (Perhaps
> UndecidableSuperClasses?)
>
> I tend to think that we'll have an easier time proceeding with 1)
> orthogonal categories and 2) separation between technical content and
> policy.
>
> I thus propose the following taxonomy, where each extension gets rated
> along each axis.
>
> A. Is the extension flag purely a language extension? That is, does the
> flag enable only new programs, without changing the semantics of any
> existing programs?
>
> Possible answers: sliding scale 1-5, where 1 means "programs written and
> widely used today would break and/or change meaning" and 5 means "no
> programs at all change meaning". It's a sliding scale to account for the
> fact that e.g. -XTypeFamilies once upon a time meant that all programs
> retain meanings... except for ones which name a type variable `family`.
> (Now, `family` is unconditionally a keyword in types, so -XTypeFamilies is,
> I believe, a 5.) So if there are obscure programs that change meaning, we
> can use 2, 3, and 4 as a way of stating how obscure the programs are.
> (Higher number = more obscure.)
>
> B. How stable is the extension flag?
>
> Possible answers: sliding scale 1-5, where 1 means "likely to change soon"
> and 5 means "as unlikely to change as the definition of Monad". (That was
> chosen deliberately: we *did* change the definition of Monad!) For me, a
> criterion required to write 5 here would be the possibility of writing down
> a formal specification of the extension. (So -XGADTs could not be a 5.)
>
> C. Would a user always want to enable this extension for an entire file
> (as opposed to for local regions)?
>
> Possible answers: sliding scale 1-5, where 1 means "there shouldn't even
> be a way to enable it for a whole file" and 5 means "no -- a user who wants
> this flag would want it for the whole file". I would put GADTSyntax as a 5
> and OverlappingInstances as a 1. GADTs would (for me) be a 4, because maybe
> someone wants to say that one part of a file is more type-y than the rest.
>
> D. How much do we like the extension?
>
> Possible answers: sliding scale 1-5, where 1 means "this shouldn't be
> here" and 5 means "I want this on by default (ignoring backward
> compatibility)". -XDatatypeContexts would be a 1: we should never have had
> that in the language. -XOverloadedStrings would be a 5: even if we don't
> want it enabled everywhere, it's a vastly useful extension that lots of
> people depend on.
>
> E. Does the extension flag change the language, as opposed to the
> operation of the compiler?
>
> Possible answers: sliding scale 1-5, where 1 means "purely about the
> compiler operation" and 5 means "purely about the language". Most
> extensions (e.g. -XPolyKinds) would be 5; -XCPP would be 1. I would put
> -XTemplateHaskell around a 4, because it's mostly about the language, but
> it impacts cross-compilation and recompilation avoidance. -XSafe is a 2: it
> affects the way instances are selected, I think.
>
> F. How broad is the use-case for the extension?
>
> Possible answers: sliding scale 1-5, where 1 means "very specialized" and
> 5 is "broadly useful in many contexts". I would put -XMultiParamTypeClasses
> at a 5 and -XMagicHash at a 2. I'm struggling to come up with something so
> specialized as to be worth a 1. I would say -XTypeFamilies and -XGADTs are
> 4.
>
> I think these questions A-F cover the range of categories Arnaud proposes,
> while addressing Joachim's and Simon M's desires to keep separate things
> separate. Having each question have a sliding-scale answer is also nice: it
> means we can submit our classifications of each extension and just average
> the results. This avoids time wasted in debate. (You can even submit
> decimals in the range 1-5, if you like!) I would propose that we highlight
> and debate any question/extension pair where the (max - min) > 2, as there
> may be disagreement about what the extension or the question means. And we
> have a natural way to identify candidates for inclusion in GHC20XX:
> multiply (or add; I think multiply) the 6 scores for an extension and then
> set a threshold for acceptance. (I don't think we would do this blindly, at
> all, but it would offer a wonderful starting-point.)
>
> Having upended the table and made a mess of things, I will now answer the
> other questions ignoring this new proposal.
>
> > Q2: Is category 6 relevant?
>
> Yes, but it's on the wrong axis.
>
> > Q2.Y: If you found category 6 to be relevant: should it be its own
> >            category, or should it be a subcategory of 1?
>
> I see 6 and 1 not having a relationship: 6 is about syntax, while 1 is
> about whether we like an extension.
>
> > Q3: Is category 7 relevant?
>
> Yes.
>
> > Q3.Y: If you found category 7 to be relevant: should it be its own
> >            category or should it be a subcategory of 5?
>
> Hard to say. MagicHash and UnboxedTuples could in theory be flags. But
> maybe there are other 7s that wouldn't?
>
> >  Q4: In which category would you classify Strict?
>
> 5, in that Strict is a compiler flag, but it doesn't certainly change the
> language.
>
> >  Q5: Is there any category that you feel is missing from the list? If
> >        so, please argue (free form).
>
> I've done that enough already. :)
>
> Richard
> _______________________________________________
> 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/20230228/dd1692f9/attachment-0001.html>