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

Tue Feb 28 16:30:10 UTC 2023

Shall we start with the three columns I described, and the non-scoring
enumerations I suggest, and see where we go?  If it's inadequate we can
elaborate.  But let's not start with too many categories etc.

S

On Tue, 28 Feb 2023 at 14:45, Simon Marlow <marlowsd at gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/711f1383/attachment.html>