[ghc-steering-committee] Language Extension Policy – Round 1
Arnaud Spiwack
arnaud.spiwack at tweag.io
Thu Mar 9 09:16:21 UTC 2023
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230309/7964d74c/attachment-0001.html>
More information about the ghc-steering-committee
mailing list