<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">>
Everything else can be served by either GHC20xx or warnings. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Let's unpack that statement a bit. I think GHC20xx is a bit of a red herring ... it doesn't change rapidly enough, and there will always be people who want a different combination.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The thing about warnings is different. I think you are suggesting that we should:<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>Remove (say) MultiParamTypeClasses as an extension</li><li>Accept programs that use MultiParamTypeClasses unconditionally</li><li>But with a warning</li><li>That can be suppressed with -fno-warn-multi-param-type-classes</li></ul><div>So a long {-# LANGUAGE X1, X2 #-} preamble will be replace with a long {-# OPTIONS_GHC -fno-warn-X1 -fno-warn-X2 #-} block.</div><div><br></div><div>Is that what you meant by "everything else best served by warnings"?<br></div><div><br></div><div>I think that is a consistent position for extensions that use new syntax. But</div><div><ul><li>Not all extensions use new syntax (e.g. -XPolyKinds).</li><li>You say "the only exception being for experimental/unstable language features and language features with a performance impact", but <br></li><ul><li>if an experimental/unstable feature uses new syntax, it would again be fine with "Warning: you are using an experimental feature"</li><li>Ditto features that use new syntax with a perf impact</li><li>what about RebindableSyntax or Strict, which change semantics but add no new syntax?<br></li></ul><li>It's not clear to me that saying `OPTIONS_GHC -no-warn-X1` is superior to `LANGUAGE X1`. In fact I mildly prefer the latter<br></li><li>It'd be a big upheaval to get from where we are, to get there</li></ul><div>But it is a consistent position. Are you advocating that change?</div><div><br></div><div>Simon<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 27 Apr 2023 at 08:35, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@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>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" 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"><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" target="_blank">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>
_______________________________________________<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>