[ghc-steering-committee] Language Extension Policy – Round 1
Simon Marlow
marlowsd at gmail.com
Thu Mar 9 17:41:09 UTC 2023
Looking forward to your proposal Arnaud. In the meantime I wanted to
comment on the purpose of categorising extensions, at least as I see it:
- Goal: to add clarity and consistency to the process for deciding what
goes into GHC20xx.
- Categorising extensions shortcuts the discussion and narrows the
search space. We've identified a bunch of reasons why extensions will not
be considered for GHC20xx, so we can just categorise those appropriately
and we've eliminated a lot of extensions from consideration while providing
clarity for users.
Cheers
Simon
On Thu, 9 Mar 2023 at 09:17, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> Simon,
>
> > I made a very concrete suggestion: a table whose rows are extensions,
> and whose columns are described below. I think it would help us.
>
> You have, and I'm not ignoring it. But it also doesn't seem to have helped
> people converge, so far. I can tell you my personal opinion on your
> proposed columns: they make a lot of sense to me, but I don't think that
> they are the right dimensions that will help answer the questions that
> Joachim initially asked.
>
> I must say that since writing my previous email, I have gotten some
> clarity on categorification (at the expense of some sleep, I'm afraid to
> say, but such are human bodies). I'll get back to it. I'm going to give a
> try to start the conversation from the “what people use extensions for”
> point of view next, though. Let's see if we can find some common ground
> there.
>
>
> Best,
> Arnaud
>
> On Mon, 6 Mar 2023 at 22:27, Adam Gundry <adam at well-typed.com> wrote:
>
>> Dear Arnaud,
>>
>> Thanks for trying to make progress on this! I've also been hesitating in
>> replying to this thread, because I'm not sure of the big picture or what
>> our goal is with the various categorisations. As I indicated in the
>> document, I think we need to start by figuring out "what users need/want
>> from extensions" (though no doubt there are various overlapping
>> purposes). Then we can assess which of those needs are currently
>> under-served.
>>
>> I guess we should also try to figure out what the crucial questions are
>> that we expect the policy document to answer. Some that come to mind for
>> me (but let's not try to answer them all at once!):
>>
>> * Should it be a goal to reduce the number of extensions and try to
>> converge on a "single Haskell"? Or should we rather aim for many small
>> mostly-orthogonal extensions, even at the cost of a combinatorial
>> explosion of possible "languages"?
>>
>> * What are the differences in principle between extensions, warnings
>> and other compiler flags? Where reality diverges from these principles,
>> to what extent should fixing that be a priority?
>>
>> * How frequently should we produce GHC20xx editions? Are the stability
>> expectations for GHC20xx editions different from other extensions?
>>
>> Cheers,
>>
>> Adam
>>
>>
>>
>> On 06/03/2023 08:37, Arnaud Spiwack wrote:
>> > Dear all,
>> >
>> > I waited a bit before answering this thread, as I got quite surprised
>> by
>> > the replies.
>> >
>> > First, the categorisation was meant as purely descriptive, and to
>> > provide us with terminology to speak about policy. In retrospect, the
>> > fact that I didn't manage to find a good name for category (1) and that
>> > I resorted to name it after something the extensions might be for
>> should
>> > have been a tell that the conversation was not going to go as planned
>> > (also I'm slowly realising that “experimental” may not really be a
>> > category in that sense, and probably helped getting the conversation
>> > confused). Let me add that, in my opinion, it would be quite premature
>> > to actually try and categorise or grade extensions now, before we have
>> a
>> > policy.
>> >
>> > Honestly, I think that it's going to be difficult to salvage this
>> > approach, given that there are almost as many different positions on
>> > this than respondents. That being said, I believe that we need some
>> > common terminology or at least a common framework to even start to
>> > discuss policy more deeply, but far from converging, we seem to be
>> > diverging as the conversation progresses.
>> >
>> > Maybe the takeaway from this conversation is that it's difficult, at
>> > least at this stage, to find relevant axes on which to classify what
>> > extensions are, so maybe, we ought to be building our terminology on
>> > what extensions are for. Which we could build on the basis of Adam's
>> > user-stories. I'll come up with a new proposal later this week.
>> >
>> > /Arnaud
>> >
>> >
>> >
>> > On Thu, 2 Mar 2023 at 14:38, Richard Eisenberg <lists at richarde.dev
>> > <mailto:lists at richarde.dev>> wrote:
>> >
>> > Yes, I think eliminating "obvious" extensions from the need for fine
>> > scoring is a good idea. Maybe we start by figuring out which these
>> > should be? I bet we'll kill off about half of what we have, which is
>> > a nice savings.
>> >
>> > Richard
>> >
>> >> On Feb 28, 2023, at 11:30 AM, Simon Peyton Jones
>> >> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>> >> wrote:
>> >>
>> >> 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
>> >> <mailto: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 <mailto: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
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> 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/20230309/20856c49/attachment-0001.html>
More information about the ghc-steering-committee
mailing list