<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 27, 2023, at 11:03 AM, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" class="">simon.peytonjones@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:tahoma,sans-serif">I am finding this discussion hard to follow. <br class=""></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul class=""><li class="">The doc has two different categorisations A, B, C, D...</li><li class="">Arnaud's email has a third, 1,2,3...</li><li class="">Richard refers to G and H but I don't know what they are.</li></ul><div class=""><b class="">Categorisation </b>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 <b class="">properties </b>of an extension. So imagine a table whose rows are extensions, and whose columns are properties.</div></div></div></div></blockquote><div><br class=""></div><div>Yes -- I had gotten to a similar place. I propose (essentially) the same structure (though different columns) in my email at <a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2023-February/003153.html" class="">https://mail.haskell.org/pipermail/ghc-steering-committee/2023-February/003153.html</a></div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Perhaps, though, I have too many columns (labeled with letters in my email).</div><div><br class=""></div><div>Richard</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:tahoma,sans-serif"><div class=""><br class=""></div><div class="">The columns might be:</div><div class=""><ul class=""><li class="">Status:<br class=""><br class=""></li><ul class=""><li class=""><b class="">Stable</b>: we might eventually expect it to be on-by-default (e.g. GADTs, PolyKinds)<br class=""></li><li class=""><b class="">Experimental</b>: might change or be deprecated (E.g. Linear)<br class=""></li><li class=""><b class="">Special-purpose</b>: stable, but will never be on-by-default (RebindableSyntax).</li><li class=""><b class="">Deprecated</b>: allow access to deprecated features, will not be on-by-default (e.g. DeepSubsumption, DatatypeContexts)<br class=""></li></ul></ul><div style="margin-left:40px" class="">I'm not sure if UnboxedTuples is Stable or Special-purpose<br class=""></div></div><div class=""><ul class=""><li class="">Backward compatibility</li><ul class=""><li class=""><b class="">Backward-compatible</b>. 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)<br class=""></li><li class=""><b class="">New-behaviour</b>. Switching on this extension may change the meaning of an existing program (e.g. Overloaded Strings, PolyKinds)</li></ul></ul><div class=""></div><div class=""><ul class=""><li class="">Module-wide: extensions that allow module-wide violation of some general principle</li></ul><div class=""><br class=""></div><div class="">This seems more straightforward. -XStrict would be <br class=""></div><div class=""><ul class=""><li class="">Special-purpose</li><li class="">New-behaviour</li><li class="">Module-wide</li></ul><div class="">Simon<br class=""></div></div></div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 17 Feb 2023 at 14:07, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" class="">arnaud.spiwack@tweag.io</a>> wrote:<br class=""></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" class="">Dear all,<br class=""><br class="">I am to shepherd the making of our language extension policy, working<br class="">off our draft document<br class="">[<a href="https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/" target="_blank" class="">https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/</a>].<br class="">As a prelude to my introduction, I first want to apologise for taking<br class="">that long to get back to this subject, time has, I'm afraid, gotten away<br class="">from me. Part of the reason, though, is that we've been pulling in<br class="">many directions, and I felt it difficult to find a path toward<br class="">consensus among all that.<br class=""><br class="">In the time since I accepted the task, I have therefore spent a lot of<br class="">time reading through the entire document multiple time, to try and<br class="">identify the points where we agree and the points where we<br class="">diverge. And try to build a methodology.<br class=""><br class="">If you go to the document, you'll see that I've separated out our<br class="">notes after a horizontal line. I will grow the document above the line<br class="">with decisions from this mailing list. Hopefully, the process will<br class="">make sure that we are in broad agreement that the text does reflect<br class="">our collective position.<br class=""><br class="">The way I'm going to proceed is to organise votes. Or maybe they<br class="">should rather be seen as surveys. They'll have a bunch of questions,<br class="">pertaining to bits of the documents that I want us to converge on. I'll<br class="">extract a broad consensus from this survey, and use it to copy<br class="">language in the document. I intend to give about a week for each<br class="">survey to complete (conveniently, I'll be very far from a computer for<br class="">the next week, so I'll be able to tally the results when I come<br class="">back). It's going to take a while, but it's a very difficult, and<br class="">sensitive, subject.<br class=""><br class="">---<br class=""><br class="">For this first round, I want us to focus on the categorisation of<br class="">language extensions as proposed by Richard and Simon M (sections 2.1<br class="">and 2.3, respectively, of our draft notes). As I feel that we will<br class="">need to have these categories identified in order to discuss the later<br class="">points.<br class=""><br class="">Here are the categories that are common to both (consult the document<br class="">for more details):<br class=""><br class="">1. Extensions that are either in GHC20xx or could be part of a future<br class=""> GHC20xx (e.g. GADTs)<br class="">2. Experimental language features (e.g. LinearTypes)<br class="">3. Extensions that allow module-wide violation of some general<br class=""> principle that holds elsewhere (e.g. OverlappingInstances)<br class="">4. Extensions that allow access to deprecated features (e.g. DatatypeContexts)<br class="">5. Extensions that should be compiler flags, which do not actually<br class=""> change the accepted language (e.g. Safe)<br class=""><br class="">Richard adds another category<br class=""><br class="">6. Extensions that change the semantics of existing constructs<br class=""> (e.g. OverloadedStrings); as opposed to most extensions, which<br class=""> create new syntax for the new feature.<br class=""><br class="">Richard's reasoning is twofold 1/ he doesn't believe that they should<br class="">be candidate for inclusion in GHC20xx 2/ he believes that they are<br class="">problematic for the same sort of reason as we've used to argue against<br class="">fork-like behaviour: that to understand the meaning of a piece of code<br class="">you need to know what language extensions have been loaded in the<br class="">file.<br class=""><br class="">Simon M adds another category<br class=""><br class="">7. Extensions for specialised use-cases (e.g. MagicHash,<br class=""> UnboxedTuples)<br class=""><br class="">Simon's reasoning is that these should not be part of GHC20xx. At the<br class="">very least they are not intended to. But they do extend the language,<br class="">like 1, and unlike 5. Hence they deserve to be categorised separately<br class="">from both.<br class=""><br class="">It is worth noting that Richard classifies Strict as a 6 and Simon M<br class="">classifies Strict as a 7.<br class=""><br class="">Now the survey.<br class=""><br class="">Keeping in mind that the goal of this categorisation is to classify<br class="">the extensions that currently exist, without judgement on whether we<br class="">want to have things in these categories or not:<br class=""><br class="">Q1: Are all the categories 1–5 relevant? If you would like to remove<br class=""> some categories, which and why (free form)?<br class="">Q2: Is category 6 relevant?<br class="">Q2.Y: If you found category 6 to be relevant: should it be its own<br class=""> category, or should it be a subcategory of 1?<br class="">Q2.N: If you found category 6 not to be relevant, in which category<br class=""> would you classify OverloadedStrings? What about PolyKinds?<br class="">Q3: Is category 7 relevant?<br class="">Q3.Y: If you found category 7 to be relevant: should it be its own<br class=""> category or should it be a subcategory of 5?<br class="">Q3.N: If you found category 7 not to be relevant: in which category<br class=""> would you classify MagicHash? What about UnboxedTuples?<br class=""> Q4: In which category would you classify Strict?<br class=""> Q5: Is there any category that you feel is missing from the list? If<br class=""><div class=""> so, please argue (free form).</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Arnaud<br class=""></div></div>
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></body></html>