<div dir="ltr"><div dir="ltr"><br></div><br><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">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"><br>For this first round, I want us to focus on the categorisation of<br>language extensions as proposed by Richard and Simon M (sections 2.1<br>and 2.3, respectively, of our draft notes). As I feel that we will<br>need to have these categories identified in order to discuss the later<br>points.<br><br>Here are the categories that are common to both (consult the document<br>for more details):<br><br>1. Extensions that are either in GHC20xx or could be part of a future<br> GHC20xx (e.g. GADTs)<br>2. Experimental language features (e.g. LinearTypes)<br>3. Extensions that allow module-wide violation of some general<br> principle that holds elsewhere (e.g. OverlappingInstances)<br>4. Extensions that allow access to deprecated features (e.g. DatatypeContexts)<br>5. Extensions that should be compiler flags, which do not actually<br> change the accepted language (e.g. Safe)<br></div></blockquote><div><br></div><div>Just to expand on the rationale here: the categories I proposed (1-5 + 7) are intended to be *exclusive*: each extension belongs to exactly one of them. The idea is to give us a way to explain to people why an extension is or is not part of GHC20xx.<br></div><div><br></div><div>We can have more ways to categorise extensions if we want (e.g. syntactic vs. not syntactic), and indeed that might be useful. But this one (1-5 + 7) seemed to me to be most helpful towards the goal of adding some clarity to the GHC20xx process.<br></div> <br><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">Q1: Are all the categories 1–5 relevant? If you would like to remove<br> some categories, which and why (free form)?<br></div></blockquote><div><br></div><div>Yes</div><div> <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">Q2: Is category 6 relevant?<br></div></blockquote><div><br><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">Q2.Y: If you found category 6 to be relevant: should it be its own<br> category, or should it be a subcategory of 1?</div></blockquote><div> </div></div><div><div><div>Whether an extension is syntactic or not is a useful thing to know, but it doesn't belong alongside 1-5,7
because it's not an exclusive category. Let's keep it separate. </div><div><br></div>Note that extensions that add syntax can still often break existing
programs, either because they steal keywords or they give new meaning to
existing syntax. I'm too lazy to search for examples but there are very
probably syntactic extensions that really do change the meaning of an
existing correct program, rather than just cause an existing program to
be rejected. So an extension being syntactic doesn't necessarily make it a free addition to GHC20xx although it probably does mean it's less risky.<br></div></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">Q2.N: If you found category 6 not to be relevant, in which category<br> would you classify OverloadedStrings? What about PolyKinds?<br></div></blockquote><div><br></div><div>OverloadedStrings: 1</div><div>PolyKinds: 1 or 2<br></div><div> </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">Q3: Is category 7 relevant?<br></div></blockquote><div><br></div><div>Maybe :) It might be possible to put those extensions into 1 if we can convince ourselves the breakage potential is low enough. It does seem sensible to have a category for extensions that are mature but so specialised that we don't plan to include them in GHC20xx. That's different from 2 (experimental) because we expect those to eventually mature and move to 1 (or 7, if we keep it).<br></div><div> </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">Q3.Y: If you found category 7 to be relevant: should it be its own<br> category or should it be a subcategory of 5?<br></div></blockquote><div><br></div><div>I don't understand how 7 makes sense as a subcategory of 5<br></div><div> </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">Q3.N: If you found category 7 not to be relevant: in which category<br> would you classify MagicHash? What about UnboxedTuples?<br> Q4: In which category would you classify Strict?<br></div></blockquote><div><br></div><div>5<br></div><div> </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"> Q5: Is there any category that you feel is missing from the list? If<br><div> so, please argue (free form).</div></div></blockquote><div><br></div><div>Cheers</div><div>Simon<br></div><div> </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><br></div><div>Best,</div><div>Arnaud<br></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></div>