<div dir="ltr">Good! I'm glad we're discussing where this alternative design leads. I'm not sure whether I'm 100% advocating for it - it may be that ultimately it's not enough of an improvement over extension flags to warrant the churn. But I think it's worthwhile to explore it. (to be clear I don't think the idea of using warnings was mine, I forgot who originally suggested it but it came out of the discussion on the GDoc we had earlier)<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 27 Apr 2023 at 09:07, 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 style="font-family:tahoma,sans-serif">>
Everything else can be served by either GHC20xx or warnings. <br></div><div style="font-family:tahoma,sans-serif"><br></div><div 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 style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">The thing about warnings is different. I think you are suggesting that we should:<br></div><div style="font-family:tahoma,sans-serif"></div><div style="font-family:tahoma,sans-serif"><ul><li>Remove (say) MultiParamTypeClasses as an extension</li><li>Accept programs that use MultiParamTypeClasses unconditionally</li></ul></div></div></blockquote><div>Only with GHC2021 and later<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 style="font-family:tahoma,sans-serif"><ul><li>But with a warning</li></ul></div></div></blockquote><div>which is disabled by default<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 style="font-family:tahoma,sans-serif"><ul><li>That can be suppressed with -fno-warn-multi-param-type-classes</li></ul></div></div></blockquote><div>maybe we call it -WMultiParamTypeClasses to keep the naming consistent. So -Werror=MultiParamTypeClasses would be the way to disable it.<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"><div style="font-family:tahoma,sans-serif"><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></div></blockquote><div><br></div><div>No, most use cases would be using `{-# LANGUAGE GHC2021 #-}` or whatever. Use cases that wanted to use GHC2021 but disable specific extensions would need a `{-# LANGUAGE -Werror=whatever #-}` or the equivalent in the .cabal file.<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 style="font-family:tahoma,sans-serif"><br><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></ul></div></div></div></blockquote><div>Sure, so if you want to disable PolyKinds then you must use a GHC20xx version that doesn't include it. This is of course less flexible than what we currently have. But it might be advantageous:</div><div><ul><li>We don't have to consider what happens when you turn off PolyKinds in combination with all the other extensions, and make all those combinations behave in some well-defined way (or, disallow certain combinations with an error when the combination doesn't make sense). We know that PolyKinds is only enabled along with all the other extensions in GHC2024 or whatever. Note that other languages do similar things: you can't turn off individual extensions in C++17 for example.</li><li>We're massively reducing the space of language variants to a set of a few language versions that we have carefully curated. That is, I postulate, a very good thing for most users and for the language in general.<br></li></ul></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 style="font-family:tahoma,sans-serif"><div><ul><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></ul></ul></div></div></div></blockquote><div>We could only do that for things with genuinely new syntax (not stolen syntax!). So e.g. OverloadedLists couldn't be a warning, it has to be an experimental extension.<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 style="font-family:tahoma,sans-serif"><div><ul><ul><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></ul></div></div></div></blockquote><div>Both of those cases should arguably be flags instead of language extensions. `{-# LANGUAGE -frebindable-syntax #-}`.<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 style="font-family:tahoma,sans-serif"><div><ul><ul><li></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></div></div></blockquote><div>Indeed!<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"><div style="font-family:tahoma,sans-serif"><div><div>But it is a consistent position. Are you advocating that change?</div></div></div></div></blockquote><div><br></div><div>I'm not sure, but as I said at the top, I think it's worth exploring.</div><div><br></div><div>Cheers</div><div>Simon<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"><div style="font-family:tahoma,sans-serif"><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" target="_blank">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>
</blockquote></div></div>