<div dir="ltr"><div>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:<br></div><div><ul><li>Goal: to add clarity and consistency to the process for deciding what goes into GHC20xx.</li><li>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.</li></ul><div>Cheers</div><div>Simon<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 9 Mar 2023 at 09:17, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Simon,</div><div><br></div><div>> I made a very concrete suggestion: a table whose rows are
extensions, and whose columns are described below. I think it would
help us.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Best,</div><div>Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 6 Mar 2023 at 22:27, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Arnaud,<br>
<br>
Thanks for trying to make progress on this! I've also been hesitating in <br>
replying to this thread, because I'm not sure of the big picture or what <br>
our goal is with the various categorisations. As I indicated in the <br>
document, I think we need to start by figuring out "what users need/want <br>
from extensions" (though no doubt there are various overlapping <br>
purposes). Then we can assess which of those needs are currently <br>
under-served.<br>
<br>
I guess we should also try to figure out what the crucial questions are <br>
that we expect the policy document to answer. Some that come to mind for <br>
me (but let's not try to answer them all at once!):<br>
<br>
* Should it be a goal to reduce the number of extensions and try to <br>
converge on a "single Haskell"? Or should we rather aim for many small <br>
mostly-orthogonal extensions, even at the cost of a combinatorial <br>
explosion of possible "languages"?<br>
<br>
* What are the differences in principle between extensions, warnings <br>
and other compiler flags? Where reality diverges from these principles, <br>
to what extent should fixing that be a priority?<br>
<br>
* How frequently should we produce GHC20xx editions? Are the stability <br>
expectations for GHC20xx editions different from other extensions?<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
<br>
On 06/03/2023 08:37, Arnaud Spiwack wrote:<br>
> Dear all,<br>
> <br>
> I waited a bit before answering this thread, as I got quite surprised by <br>
> the replies.<br>
> <br>
> First, the categorisation was meant as purely descriptive, and to <br>
> provide us with terminology to speak about policy. In retrospect, the <br>
> fact that I didn't manage to find a good name for category (1) and that <br>
> I resorted to name it after something the extensions might be for should <br>
> have been a tell that the conversation was not going to go as planned <br>
> (also I'm slowly realising that “experimental” may not really be a <br>
> category in that sense, and probably helped getting the conversation <br>
> confused). Let me add that, in my opinion, it would be quite premature <br>
> to actually try and categorise or grade extensions now, before we have a <br>
> policy.<br>
> <br>
> Honestly, I think that it's going to be difficult to salvage this <br>
> approach, given that there are almost as many different positions on <br>
> this than respondents. That being said, I believe that we need some <br>
> common terminology or at least a common framework to even start to <br>
> discuss policy more deeply, but far from converging, we seem to be <br>
> diverging as the conversation progresses.<br>
> <br>
> Maybe the takeaway from this conversation is that it's difficult, at <br>
> least at this stage, to find relevant axes on which to classify what <br>
> extensions are, so maybe, we ought to be building our terminology on <br>
> what extensions are for. Which we could build on the basis of Adam's <br>
> user-stories. I'll come up with a new proposal later this week.<br>
> <br>
> /Arnaud<br>
> <br>
> <br>
> <br>
> On Thu, 2 Mar 2023 at 14:38, Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a> <br>
> <mailto:<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>>> wrote:<br>
> <br>
> Yes, I think eliminating "obvious" extensions from the need for fine<br>
> scoring is a good idea. Maybe we start by figuring out which these<br>
> should be? I bet we'll kill off about half of what we have, which is<br>
> a nice savings.<br>
> <br>
> Richard<br>
> <br>
>> On Feb 28, 2023, at 11:30 AM, Simon Peyton Jones<br>
>> <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a> <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>>><br>
>> wrote:<br>
>><br>
>> Shall we start with the three columns I described, and the<br>
>> non-scoring enumerations I suggest, and see where we go? If it's<br>
>> inadequate we can elaborate. But let's not start with too many<br>
>> categories etc.<br>
>><br>
>> S<br>
>><br>
>> On Tue, 28 Feb 2023 at 14:45, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a><br>
>> <mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>>> wrote:<br>
>><br>
>> We definitely *could* assign every extension a 1-5 score on 6+<br>
>> different axes, but I have to admit the thought of actually<br>
>> doing this gives me a sinking feeling! Furthermore I'm not<br>
>> sure what we would do with the results. How do we use the<br>
>> scores to decide what goes into GHC20xx? It feels like we're<br>
>> creating a great deal of work for ourselves.<br>
>><br>
>> The idea of categorising rather than scoring is to shortcut<br>
>> the discussion. If we know that some extension is experimental<br>
>> (e.g. LinearTypes), it just goes in the experimental category<br>
>> and we don't need to think about it any more. If we have an<br>
>> extension that is enabling a deprecated feature, again we<br>
>> don't need to consider any other aspects.<br>
>><br>
>> So, perhaps these axes are useful for extensions that are<br>
>> candidates for GHC20xx and not in one of the other categories<br>
>> 2-5 in Arnaud's list. But if we're going to reject extensions<br>
>> from GHC20xx for reasons that are *not* covered by categories<br>
>> 2-5 in Arnaud's list, then we should think about what those<br>
>> reasons might be. Is "breaks too many programs" one of them?<br>
>><br>
>> Cheers<br>
>> Simon<br>
>><br>
>> On Fri, 24 Feb 2023 at 18:04, Richard Eisenberg<br>
>> <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a> <mailto:<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>>> wrote:<br>
>><br>
>> Thanks, Arnaud!<br>
>><br>
>> > Q1: Are all the categories 1–5 relevant? If you would<br>
>> like to remove<br>
>> > some categories, which and why (free form)?<br>
>><br>
>> I'm not really sure I understand Category 1. In<br>
>> particular, I think my initial categorization didn't have<br>
>> Arnaud's Category 1, but instead had<br>
>><br>
>> 8. Extensions that enable only new programs, without<br>
>> changing the semantics of any existing program<br>
>><br>
>> This was meant as a counterpoint to 6.<br>
>><br>
>> But my initial categorization was non-orthogonal: for<br>
>> example, this Category 8 overlaps with several other<br>
>> categories. In that way, Joachim's argument that we could<br>
>> imagine two axes of categorization -- one technical, one<br>
>> policy-oriented -- is intriguing. For example,<br>
>> -XDatatypeContexts belongs in Category 8 (it's a syntactic<br>
>> extension), but that doesn't mean it should be on-by-default.<br>
>><br>
>> Along similar lines, Categories 2 and 3 overlap: we might<br>
>> have an experimental language feature that violates a<br>
>> general principle. (Perhaps UndecidableSuperClasses?)<br>
>><br>
>> I tend to think that we'll have an easier time proceeding<br>
>> with 1) orthogonal categories and 2) separation between<br>
>> technical content and policy.<br>
>><br>
>> I thus propose the following taxonomy, where each<br>
>> extension gets rated along each axis.<br>
>><br>
>> A. Is the extension flag purely a language extension? That<br>
>> is, does the flag enable only new programs, without<br>
>> changing the semantics of any existing programs?<br>
>><br>
>> Possible answers: sliding scale 1-5, where 1 means<br>
>> "programs written and widely used today would break and/or<br>
>> change meaning" and 5 means "no programs at all change<br>
>> meaning". It's a sliding scale to account for the fact<br>
>> that e.g. -XTypeFamilies once upon a time meant that all<br>
>> programs retain meanings... except for ones which name a<br>
>> type variable `family`. (Now, `family` is unconditionally<br>
>> a keyword in types, so -XTypeFamilies is, I believe, a 5.)<br>
>> So if there are obscure programs that change meaning, we<br>
>> can use 2, 3, and 4 as a way of stating how obscure the<br>
>> programs are. (Higher number = more obscure.)<br>
>><br>
>> B. How stable is the extension flag?<br>
>><br>
>> Possible answers: sliding scale 1-5, where 1 means "likely<br>
>> to change soon" and 5 means "as unlikely to change as the<br>
>> definition of Monad". (That was chosen deliberately: we<br>
>> *did* change the definition of Monad!) For me, a criterion<br>
>> required to write 5 here would be the possibility of<br>
>> writing down a formal specification of the extension. (So<br>
>> -XGADTs could not be a 5.)<br>
>><br>
>> C. Would a user always want to enable this extension for<br>
>> an entire file (as opposed to for local regions)?<br>
>><br>
>> Possible answers: sliding scale 1-5, where 1 means "there<br>
>> shouldn't even be a way to enable it for a whole file" and<br>
>> 5 means "no -- a user who wants this flag would want it<br>
>> for the whole file". I would put GADTSyntax as a 5 and<br>
>> OverlappingInstances as a 1. GADTs would (for me) be a 4,<br>
>> because maybe someone wants to say that one part of a file<br>
>> is more type-y than the rest.<br>
>><br>
>> D. How much do we like the extension?<br>
>><br>
>> Possible answers: sliding scale 1-5, where 1 means "this<br>
>> shouldn't be here" and 5 means "I want this on by default<br>
>> (ignoring backward compatibility)". -XDatatypeContexts<br>
>> would be a 1: we should never have had that in the<br>
>> language. -XOverloadedStrings would be a 5: even if we<br>
>> don't want it enabled everywhere, it's a vastly useful<br>
>> extension that lots of people depend on.<br>
>><br>
>> E. Does the extension flag change the language, as opposed<br>
>> to the operation of the compiler?<br>
>><br>
>> Possible answers: sliding scale 1-5, where 1 means "purely<br>
>> about the compiler operation" and 5 means "purely about<br>
>> the language". Most extensions (e.g. -XPolyKinds) would be<br>
>> 5; -XCPP would be 1. I would put -XTemplateHaskell around<br>
>> a 4, because it's mostly about the language, but it<br>
>> impacts cross-compilation and recompilation avoidance.<br>
>> -XSafe is a 2: it affects the way instances are selected,<br>
>> I think.<br>
>><br>
>> F. How broad is the use-case for the extension?<br>
>><br>
>> Possible answers: sliding scale 1-5, where 1 means "very<br>
>> specialized" and 5 is "broadly useful in many contexts". I<br>
>> would put -XMultiParamTypeClasses at a 5 and -XMagicHash<br>
>> at a 2. I'm struggling to come up with something so<br>
>> specialized as to be worth a 1. I would say -XTypeFamilies<br>
>> and -XGADTs are 4.<br>
>><br>
>> I think these questions A-F cover the range of categories<br>
>> Arnaud proposes, while addressing Joachim's and Simon M's<br>
>> desires to keep separate things separate. Having each<br>
>> question have a sliding-scale answer is also nice: it<br>
>> means we can submit our classifications of each extension<br>
>> and just average the results. This avoids time wasted in<br>
>> debate. (You can even submit decimals in the range 1-5, if<br>
>> you like!) I would propose that we highlight and debate<br>
>> any question/extension pair where the (max - min) > 2, as<br>
>> there may be disagreement about what the extension or the<br>
>> question means. And we have a natural way to identify<br>
>> candidates for inclusion in GHC20XX: multiply (or add; I<br>
>> think multiply) the 6 scores for an extension and then set<br>
>> a threshold for acceptance. (I don't think we would do<br>
>> this blindly, at all, but it would offer a wonderful<br>
>> starting-point.)<br>
>><br>
>> Having upended the table and made a mess of things, I will<br>
>> now answer the other questions ignoring this new proposal.<br>
>><br>
>> > Q2: Is category 6 relevant?<br>
>><br>
>> Yes, but it's on the wrong axis.<br>
>><br>
>> > Q2.Y: If you found category 6 to be relevant: should it<br>
>> be its own<br>
>> > category, or should it be a subcategory of 1?<br>
>><br>
>> I see 6 and 1 not having a relationship: 6 is about<br>
>> syntax, while 1 is about whether we like an extension.<br>
>><br>
>> > Q3: Is category 7 relevant?<br>
>><br>
>> Yes.<br>
>><br>
>> > Q3.Y: If you found category 7 to be relevant: should it<br>
>> be its own<br>
>> > category or should it be a subcategory of 5?<br>
>><br>
>> Hard to say. MagicHash and UnboxedTuples could in theory<br>
>> be flags. But maybe there are other 7s that wouldn't?<br>
>><br>
>> > Q4: In which category would you classify Strict?<br>
>><br>
>> 5, in that Strict is a compiler flag, but it doesn't<br>
>> certainly change the language.<br>
>><br>
>> > Q5: Is there any category that you feel is missing from<br>
>> the list? If<br>
>> > so, please argue (free form).<br>
>><br>
>> I've done that enough already. :)<br>
>><br>
>> Richard<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>