<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks Arnaud.  I'm not sure of the use to which you plan to put this list - but it seems like a reasonable starting point.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">S<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 30 Mar 2023 at 10:04, 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">Dear all,<br><br>Sorry for the long silence. I was named and shamed by Joachim the<br>other day, which is fair enough. I've basically disappeared from my<br>email for a while. I am aware that not having solved this is holding<br>us back, I'll be more consistent in the future.<br><br>As I said in my last email, I'd like to start the conversation again<br>from the point of view of use-cases, as proposed by Adam, and see if<br>it helps us go forward. What I want to do, today, is to describe what<br>Haskell programmers have been using extension for. This is meant to be<br>purely a description, without judgement on whether the proposed<br>use-cases are good ideas. When the use-cases are listed, we'll turn to<br>which we want to support and how.<br><br>Without further ado, here is a list of use-cases, based on Adam's list<br>(my rephrasing), with additions by me. Haskell programmers use<br>extensions to:<br><br>1. Gain early access to experimental or unstable features<br>   (e.g. because they're working on a research prototype, or because<br>   the feature is valuable enough to them to forgo some stability)<br>2. Restrict the use of more complex features (e.g. for easier<br>   onboarding of new developers or as educators to teach a<br>   well-delimited subset of the language)<br>3. As library authors, to signal which features the library actually<br>   uses, hence which version of GHC the library is compatible with.<br>4. Retain access to deprecated features to smooth out migration over<br>   the deprecation period.<br>5. Retain access to deprecated features indefinitely.<br>6. Change the default behaviour of (part of) the language<br>   (e.g. StrictData, I think some of the dependent Haskell work falls<br>   in this category, but I can't pinpoint an example)<br>7. Extend the language in a way that is not backward compatible<br>   (e.g. OverloadedList, probably some dependent Haskell things too)<br>8. Enable features whose mere presence has a performance impact<br>   (e.g. Template Haskell, and that's probably it)<br>9. CPP (this one is very unique isn't it?)<br><br><br>(Note: Adam proposed some use-cases which are not included here: using<br>extension to ensure stability (which is the contrapositive of 1), and<br>as a GHC dev, make features available to early adopters (which is the<br>dual of 1). I didn't include them because I consider that they are<br>contained in 1, but if you disagree, please argue otherwise)<br><br>Questions:<br>1. Have we missed some use-cases, if so describe? (I'm sure we have,<br>   so I'd be surprised if nothing turns up here)<br>2. Do you think some of the use-cases above should be split into<br>   several use-cases?<br>3. Conversely, are there distinctions that don't make sense to you and<br>   you would argue should be merged?<br><br>Before answering, take note that while some of the proposed use-cases<br>can be seen as a list of extensions that behave a certain way, some<br>extensions may be used in several use-cases (4 and 5, by definition<br>concern the same set of extensions), some use-cases (like 3) are<br>independent of the behaviour of extensions. This is not a<br>classification of extension, but of how they are consumed.<br><br>I'll tally the result on Tuesday 10th April.<br><br>Best,<br>Arnaud</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>