Hi, Am Freitag, dem 24.02.2023 um 18:04 +0000 schrieb Richard Eisenberg:

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.

I like these categories, they certainly add clarity! Can we include these category from my mail as well: G. To what extent is its effect new? Possible answers: 1 - Code is trivially and better written without the extension (e.g. a deprecated extension with a better mechanism around) 3 - The effect can be achieved without it, but very annoyingly (e.g. OverloadedStrings, most DerivingX extensions) 4 - The effect can be achieved without it, but needs renamer or  typechecker context (e.g. RecordWildCards) 5 - There is no way to achieve the effect another way (e.g. Role Annotations) H. Is the extension local to the module? Probably quite binary: 1 - It has no effect beyond the current module. (most syntactic extensions) 5 – It’s use can affect users of the current module (most type extensions, e.g. GADTs, LinearTypes) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi Am Montag, dem 27.02.2023 um 12:38 +0000 schrieb Richard Eisenberg:

Does there exist an extension that has no effect beyond the current module but is more than a 3 on the G scale? Maybe it's OK if the answer is "no", but somehow G and H do not seem fully orthogonal.

Hmm, maybe runST (if it were a language extension) might be an example for something that would be very new (imperative features in pure code), but not visible to downstream users. FFI could be another one.

Also: the questions in my original list were all constructed so that a higher score would, all else being equal, suggest inclusion as a default extension. I think G is similarly set up. But H is not. Again, that's probably OK, but I wanted to raise the point for others to consider as well.

Oh, yes, probably! Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

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 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 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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@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 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 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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 mailto:lists@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 mailto:simon.peytonjones@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 mailto:marlowsd@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 mailto:lists@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Donnerstag, dem 09.03.2023 um 17:41 +0000 schrieb Simon Marlow:

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.

right, but this is not just about GHC20xx, is it? Having some more objective characteristics of extensions spelled out will help us making other decisions more consistently as well (accepting proposals for new extensions, extending existing extensions, changing existing extensions etc.) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

On Feb 27, 2023, at 11:03 AM, Simon Peyton Jones wrote:

I am finding this discussion hard to follow. The doc has two different categorisations A, B, C, D... Arnaud's email has a third, 1,2,3... Richard refers to G and H but I don't know what they are. Categorisation is a blunt instrument, because it implies that an extension is in one category or another, but not both. It might be better to think in term of properties of an extension. So imagine a table whose rows are extensions, and whose columns are properties.

Yes -- I had gotten to a similar place. I propose (essentially) the same structure (though different columns) in my email at https://mail.haskell.org/pipermail/ghc-steering-committee/2023-February/0031... https://mail.haskell.org/pipermail/ghc-steering-committee/2023-February/0031... A key difference between what I proposed there and what you're suggesting is that my entries are numeric (in the range 1-5) as opposed to symbolic. This allows for the possibility of simply averaging committee members' responses, without the need for protracted debate about whether an extension is e.g. special-purpose or experimental. Perhaps, though, I have too many columns (labeled with letters in my email). Richard

The columns might be: Status:

Stable: we might eventually expect it to be on-by-default (e.g. GADTs, PolyKinds) Experimental: might change or be deprecated (E.g. Linear) Special-purpose: stable, but will never be on-by-default (RebindableSyntax). Deprecated: allow access to deprecated features, will not be on-by-default (e.g. DeepSubsumption, DatatypeContexts) I'm not sure if UnboxedTuples is Stable or Special-purpose Backward compatibility Backward-compatible. Switching on this extension will never change the meaning of an existing program that already compiles. Usually because the feature is guarded by new syntax (e.g. UnboxedTuples), but perhpas also because it accepts more program (e.g. OverlappingInstances) New-behaviour. Switching on this extension may change the meaning of an existing program (e.g. Overloaded Strings, PolyKinds) Module-wide: extensions that allow module-wide violation of some general principle

This seems more straightforward. -XStrict would be Special-purpose New-behaviour Module-wide Simon

On Fri, 17 Feb 2023 at 14:07, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote: Dear all,

I am to shepherd the making of our language extension policy, working off our draft document [https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUl... https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUl...]. As a prelude to my introduction, I first want to apologise for taking that long to get back to this subject, time has, I'm afraid, gotten away from me. Part of the reason, though, is that we've been pulling in many directions, and I felt it difficult to find a path toward consensus among all that.

In the time since I accepted the task, I have therefore spent a lot of time reading through the entire document multiple time, to try and identify the points where we agree and the points where we diverge. And try to build a methodology.

If you go to the document, you'll see that I've separated out our notes after a horizontal line. I will grow the document above the line with decisions from this mailing list. Hopefully, the process will make sure that we are in broad agreement that the text does reflect our collective position.

The way I'm going to proceed is to organise votes. Or maybe they should rather be seen as surveys. They'll have a bunch of questions, pertaining to bits of the documents that I want us to converge on. I'll extract a broad consensus from this survey, and use it to copy language in the document. I intend to give about a week for each survey to complete (conveniently, I'll be very far from a computer for the next week, so I'll be able to tally the results when I come back). It's going to take a while, but it's a very difficult, and sensitive, subject.

---

For this first round, I want us to focus on the categorisation of language extensions as proposed by Richard and Simon M (sections 2.1 and 2.3, respectively, of our draft notes). As I feel that we will need to have these categories identified in order to discuss the later points.

Here are the categories that are common to both (consult the document for more details):

1. Extensions that are either in GHC20xx or could be part of a future GHC20xx (e.g. GADTs) 2. Experimental language features (e.g. LinearTypes) 3. Extensions that allow module-wide violation of some general principle that holds elsewhere (e.g. OverlappingInstances) 4. Extensions that allow access to deprecated features (e.g. DatatypeContexts) 5. Extensions that should be compiler flags, which do not actually change the accepted language (e.g. Safe)

Richard adds another category

6. Extensions that change the semantics of existing constructs (e.g. OverloadedStrings); as opposed to most extensions, which create new syntax for the new feature.

Richard's reasoning is twofold 1/ he doesn't believe that they should be candidate for inclusion in GHC20xx 2/ he believes that they are problematic for the same sort of reason as we've used to argue against fork-like behaviour: that to understand the meaning of a piece of code you need to know what language extensions have been loaded in the file.

Simon M adds another category

7. Extensions for specialised use-cases (e.g. MagicHash, UnboxedTuples)

Simon's reasoning is that these should not be part of GHC20xx. At the very least they are not intended to. But they do extend the language, like 1, and unlike 5. Hence they deserve to be categorised separately from both.

It is worth noting that Richard classifies Strict as a 6 and Simon M classifies Strict as a 7.

Now the survey.

Keeping in mind that the goal of this categorisation is to classify the extensions that currently exist, without judgement on whether we want to have things in these categories or not:

Q1: Are all the categories 1–5 relevant? If you would like to remove some categories, which and why (free form)? Q2: Is category 6 relevant? Q2.Y: If you found category 6 to be relevant: should it be its own category, or should it be a subcategory of 1? Q2.N: If you found category 6 not to be relevant, in which category would you classify OverloadedStrings? What about PolyKinds? Q3: Is category 7 relevant? Q3.Y: If you found category 7 to be relevant: should it be its own category or should it be a subcategory of 5? Q3.N: If you found category 7 not to be relevant: in which category would you classify MagicHash? What about UnboxedTuples? Q4: In which category would you classify Strict? Q5: Is there any category that you feel is missing from the list? If so, please argue (free form).

Best, Arnaud _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon, Quite funny that you're writing this now, as I'm finishing writing my next email, after a pretty long unplanned absence (apologies about that). Thanks for forwarding Richard's suggestion, which I hadn't seen. /Arnaud On Thu, 30 Mar 2023 at 09:00, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

Where are we on this thread, Arnaud?

Separately Richard has suggested https://github.com/ghc-proposals/ghc-proposals/pull/536#issuecomment-1475395... :

I think *all* extensions that just enable new syntax (without changing

...

the meaning of any existing programs) should be warnings.

That seems like a possible principle, which could form part of this discussion.

Simon

On Fri, 17 Feb 2023 at 14:07, Arnaud Spiwack wrote:

...

Dear all,

I am to shepherd the making of our language extension policy, working off our draft document [ https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUl... ]. As a prelude to my introduction, I first want to apologise for taking that long to get back to this subject, time has, I'm afraid, gotten away from me. Part of the reason, though, is that we've been pulling in many directions, and I felt it difficult to find a path toward consensus among all that.

In the time since I accepted the task, I have therefore spent a lot of time reading through the entire document multiple time, to try and identify the points where we agree and the points where we diverge. And try to build a methodology.

If you go to the document, you'll see that I've separated out our notes after a horizontal line. I will grow the document above the line with decisions from this mailing list. Hopefully, the process will make sure that we are in broad agreement that the text does reflect our collective position.

The way I'm going to proceed is to organise votes. Or maybe they should rather be seen as surveys. They'll have a bunch of questions, pertaining to bits of the documents that I want us to converge on. I'll extract a broad consensus from this survey, and use it to copy language in the document. I intend to give about a week for each survey to complete (conveniently, I'll be very far from a computer for the next week, so I'll be able to tally the results when I come back). It's going to take a while, but it's a very difficult, and sensitive, subject.

---

For this first round, I want us to focus on the categorisation of language extensions as proposed by Richard and Simon M (sections 2.1 and 2.3, respectively, of our draft notes). As I feel that we will need to have these categories identified in order to discuss the later points.

Here are the categories that are common to both (consult the document for more details):

1. Extensions that are either in GHC20xx or could be part of a future GHC20xx (e.g. GADTs) 2. Experimental language features (e.g. LinearTypes) 3. Extensions that allow module-wide violation of some general principle that holds elsewhere (e.g. OverlappingInstances) 4. Extensions that allow access to deprecated features (e.g. DatatypeContexts) 5. Extensions that should be compiler flags, which do not actually change the accepted language (e.g. Safe)

Richard adds another category

6. Extensions that change the semantics of existing constructs (e.g. OverloadedStrings); as opposed to most extensions, which create new syntax for the new feature.

Richard's reasoning is twofold 1/ he doesn't believe that they should be candidate for inclusion in GHC20xx 2/ he believes that they are problematic for the same sort of reason as we've used to argue against fork-like behaviour: that to understand the meaning of a piece of code you need to know what language extensions have been loaded in the file.

Simon M adds another category

7. Extensions for specialised use-cases (e.g. MagicHash, UnboxedTuples)

Simon's reasoning is that these should not be part of GHC20xx. At the very least they are not intended to. But they do extend the language, like 1, and unlike 5. Hence they deserve to be categorised separately from both.

It is worth noting that Richard classifies Strict as a 6 and Simon M classifies Strict as a 7.

Now the survey.

Keeping in mind that the goal of this categorisation is to classify the extensions that currently exist, without judgement on whether we want to have things in these categories or not:

Q1: Are all the categories 1–5 relevant? If you would like to remove some categories, which and why (free form)? Q2: Is category 6 relevant? Q2.Y: If you found category 6 to be relevant: should it be its own category, or should it be a subcategory of 1? Q2.N: If you found category 6 not to be relevant, in which category would you classify OverloadedStrings? What about PolyKinds? Q3: Is category 7 relevant? Q3.Y: If you found category 7 to be relevant: should it be its own category or should it be a subcategory of 5? Q3.N: If you found category 7 not to be relevant: in which category would you classify MagicHash? What about UnboxedTuples? Q4: In which category would you classify Strict? Q5: Is there any category that you feel is missing from the list? If so, please argue (free form).

Best, Arnaud _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee