<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="gmail_default" style="font-family:tahoma,sans-serif"></span>
In this next round, I want us to give our opinion, on each of these<br>use-cases, on whether we believe that this use-case is best served by<br>extension. My goal, in this round, is not necessarily to build<br>consensus for a policy, but to discover where there is consensus, and<br>where there is controversy, so that we can discuss the relevant<br>use-cases in more detail. <br></div></blockquote><div><span class="gmail_default" style="font-family:tahoma,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif"></span></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif">I went down the list and in every case I thought "yes, language extensions allow a user to do this, if they want". I struggled to answer your questions. Eg <br></span></div><div><ul><li><span class="gmail_default" style="font-family:tahoma,sans-serif">X1 is this a use-case GHC should support. Well it already supports it. I suppose we could debate which are active goals and which are accidental, but before burning the midnight oil on that debate I'd love to know where this is going. <br></span></li><li><span class="gmail_default" style="font-family:tahoma,sans-serif">X2 is this use case best served by extensions. </span><span class="gmail_default" style="font-family:tahoma,sans-serif"></span><span class="gmail_default" style="font-family:tahoma,sans-serif">When
you say "best served" you imply that, in each case, there is a
well-defined alternative or alternatives that could be better. But I
don't know what are the alternatives that we should be comparing with.</span></li><li><span class="gmail_default" style="font-family:tahoma,sans-serif">X3 Does GHC20xx help? What do you mean by "GHC20xx". I think you mean "The occasional release of a new flag, GHC2025, say, that implies a bunch of others. That seems a rather different debate, but in general I think the idea is a good one, if not done too frequently</span></li></ul><div><div style="font-family:tahoma,sans-serif" class="gmail_default">I feel as if I'm not being very helpful, which probably means I'm missing the point somehow!</div><br></div></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 19 Apr 2023 at 13:21, 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>In Round 1', we have gathered no less than 13 use-cases (see below)<br>found in the community for Haskellers to motivate the need for<br>extensions. Some of these use-cases are specific to a pretty definite<br>list of extensions, some are not. Some extensions fall squarely in one<br>use-case, some don't. Use-cases are not a classification of<br>extensions, they're a classification of justifications for extensions<br>to exist. Surely we've missed some, but it's alright to not be fully<br>exhaustive.<br><br>In this next round, I want us to give our opinion, on each of these<br>use-cases, on whether we believe that this use-case is best served by<br>extension. My goal, in this round, is not necessarily to build<br>consensus for a policy, but to discover where there is consensus, and<br>where there is controversy, so that we can discuss the relevant<br>use-cases in more detail.<br><br>In this round, I'm asking you, for each X∈{1,…,13}, to answer the<br>following questions:<br><br>X.1: do you believe that this a use-case that GHC should support? (yes/no)<br>X.2: regardless of your answer in X.1, if GHC supports this use-case,<br> do you believe that this use-case is best served by extensions. (yes/no)<br>X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no)<br>X.2.N: if you've answered “no” to X.2: what mechanism would you rather<br> see supporting this use-case (free form)<br><br>I'll be on holiday next week, and will tally the results on the first<br>week on May.<br><br>The 13 use-cases are<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. Restrict the use of novel features since the last established<br> standard/report.<br>4. Restrict the use to features that they don't like (e.g. controversial<br> features like RecordWildcard or ImplicitParameters)<br>5. Name/refer to a particular feature when talking/writing/searching<br> about it.<br>6. Restrict the use of features which require support from outside<br> the Haskell ecosystem that can't be taken for granted (I think this<br> concerns only UnicodeSyntax)<br>7. As library authors, to signal which features the library actually<br> uses, hence which version of GHC the library is compatible with.<br>8. Retain access to deprecated features to smooth out migration over<br> the deprecation period.<br>9. Retain access to deprecated features indefinitely.<br>10. 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>11. Extend the language in a way that is not backward compatible<br> (e.g. OverloadedList, probably some dependent Haskell things too)<br>12. Enable features whose mere presence has a performance impact<br> (e.g. Template Haskell, and that's probably it)<br>13. CPP (this one is very unique isn't it?)</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>