<div dir="ltr"><div>This is interesting. I find myself answering "no" to "do you believe this use-case is best served by extensions" for almost all use-cases, the only exception being for experimental/unstable language features and language features with a performance impact. Everything else can be served by either GHC20xx or warnings. Yes that means being less fine-grained in some cases, but that might be a good tradeoff between flexibility for users and complexity in the compiler - fewer combinations of extensions to consider would simplify things and leave less room for bugs.</div><div><br></div><div>Answers below:<br></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">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>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>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></div></blockquote><div><br></div><div>1. yes</div><div>2. yes</div><div>2.Y no<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">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></div></blockquote><div><br></div><div>1. yes</div><div>2. no <br></div><div>2.N warnings, -Werror=feature<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">3. Restrict the use of novel features since the last established<br> standard/report.<br></div></blockquote><div><br></div><div>1. yes</div><div>2. no</div><div>2.N -XHaskell2010 and/or warnings<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">4. Restrict the use to features that they don't like (e.g. controversial<br> features like RecordWildcard or ImplicitParameters)<br></div></blockquote><div><br></div><div>1. yes</div><div>2. no</div><div>2.N warnings<br></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">5. Name/refer to a particular feature when talking/writing/searching<br> about it.<br></div></blockquote><div><br></div><div>1. yes</div><div>2. no - we don't need to support extensions to be able to name language features.</div><div>2.N continue to use the names we have now, but without supporting -XFoo for all extensions<br></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">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></div></blockquote><div><br></div><div>1. yes</div><div>2. no</div><div>2.N warnings<br></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">7. As library authors, to signal which features the library actually<br> uses, hence which version of GHC the library is compatible with.<br></div></blockquote><div><br></div><div>1. yes</div><div>2. no</div><div>2.N GHC20xx<br></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">8. Retain access to deprecated features to smooth out migration over<br> the deprecation period.<br></div></blockquote><div><br></div><div>1. yes</div><div><a href="http://2.no">2.no</a></div><div>2.N GHC20xx<br></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">9. Retain access to deprecated features indefinitely.<br></div></blockquote><div><br></div><div>1. no</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">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></div></blockquote><div><br></div><div>1. yes</div><div>2. no</div><div>2.N GHC20xx<br></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">11. Extend the language in a way that is not backward compatible<br> (e.g. OverloadedList, probably some dependent Haskell things too)<br></div></blockquote><div><br></div><div>1. yes</div><div>2. no</div><div>2.N GHC20xx<br></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">12. Enable features whose mere presence has a performance impact<br> (e.g. Template Haskell, and that's probably it)<br></div></blockquote><div><br></div><div>1. yes</div><div>2. yes</div><div>2.Y no<br></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">13. CPP (this one is very unique isn't it?)</div></blockquote><div><br></div><div>1. yes</div><div>2. no</div><div>2.N it should probably be a flag<br></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">
_______________________________________________<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>