<div dir="ltr"><div>Simon,</div><div><br></div><div>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).</div><div><br></div><div>Thanks for forwarding Richard's suggestion, which I hadn't seen.</div><div><br></div><div>/Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 30 Mar 2023 at 09:00, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.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"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Where are we on this thread, Arnaud?</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Separately <a href="https://github.com/ghc-proposals/ghc-proposals/pull/536#issuecomment-1475395448" target="_blank">Richard has suggested</a>:</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
I think <em>all</em> extensions that just enable new syntax (without changing the meaning of any existing programs) should be warnings.
</div></blockquote><div><br></div><div>That seems like a possible principle, which could form part of this discussion.</div><div><br></div><div>Simon <br></div></span>
</div></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" target="_blank">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">Dear all,<br><br>I am to shepherd the making of our language extension policy, working<br>off our draft document<br>[<a href="https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/" target="_blank">https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/</a>].<br>As a prelude to my introduction, I first want to apologise for taking<br>that long to get back to this subject, time has, I'm afraid, gotten away<br>from me. Part of the reason, though, is that we've been pulling in<br>many directions, and I felt it difficult to find a path toward<br>consensus among all that.<br><br>In the time since I accepted the task, I have therefore spent a lot of<br>time reading through the entire document multiple time, to try and<br>identify the points where we agree and the points where we<br>diverge. And try to build a methodology.<br><br>If you go to the document, you'll see that I've separated out our<br>notes after a horizontal line. I will grow the document above the line<br>with decisions from this mailing list. Hopefully, the process will<br>make sure that we are in broad agreement that the text does reflect<br>our collective position.<br><br>The way I'm going to proceed is to organise votes. Or maybe they<br>should rather be seen as surveys. They'll have a bunch of questions,<br>pertaining to bits of the documents that I want us to converge on. I'll<br>extract a broad consensus from this survey, and use it to copy<br>language in the document. I intend to give about a week for each<br>survey to complete (conveniently, I'll be very far from a computer for<br>the next week, so I'll be able to tally the results when I come<br>back). It's going to take a while, but it's a very difficult, and<br>sensitive, subject.<br><br>---<br><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><br>Richard adds another category<br><br>6. Extensions that change the semantics of existing constructs<br> (e.g. OverloadedStrings); as opposed to most extensions, which<br> create new syntax for the new feature.<br><br>Richard's reasoning is twofold 1/ he doesn't believe that they should<br>be candidate for inclusion in GHC20xx 2/ he believes that they are<br>problematic for the same sort of reason as we've used to argue against<br>fork-like behaviour: that to understand the meaning of a piece of code<br>you need to know what language extensions have been loaded in the<br>file.<br><br>Simon M adds another category<br><br>7. Extensions for specialised use-cases (e.g. MagicHash,<br> UnboxedTuples)<br><br>Simon's reasoning is that these should not be part of GHC20xx. At the<br>very least they are not intended to. But they do extend the language,<br>like 1, and unlike 5. Hence they deserve to be categorised separately<br>from both.<br><br>It is worth noting that Richard classifies Strict as a 6 and Simon M<br>classifies Strict as a 7.<br><br>Now the survey.<br><br>Keeping in mind that the goal of this categorisation is to classify<br>the extensions that currently exist, without judgement on whether we<br>want to have things in these categories or not:<br><br>Q1: Are all the categories 1–5 relevant? If you would like to remove<br> some categories, which and why (free form)?<br>Q2: Is category 6 relevant?<br>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?<br>Q2.N: If you found category 6 not to be relevant, in which category<br> would you classify OverloadedStrings? What about PolyKinds?<br>Q3: Is category 7 relevant?<br>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>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> Q5: Is there any category that you feel is missing from the list? If<br><div> so, please argue (free form).</div><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>
</blockquote></div>