<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 Mar 2019 at 09:29, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</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">Am Freitag, den 08.03.2019, 08:55 +0000 schrieb Simon Peyton Jones via<br>
ghc-steering-committee:<br>> My only question is: do we really need a  flag.  Suppose we simply<br>
> accepted the postfix “qualified” with no flag support.  Then a<br>
> program will be accepted that earlier compilers would have rejected –<br>
> and, absent a flag, we normally try to continue to reject programs<br>
> that weren’t legal before.  But in this case no one is going to fall<br>
> into this by mistake.  I suggest we consider simply allowing it as an<br>
> exception to our general rule, and move on.<br>
<br>
Let’s not do this. We have very few hard guidelines to help us in our<br>
work; “changes to the language needs a flag” is one of them. If we<br>
start to be lax here, we will have to justify every future flag where<br>
the extension would just be an invalid program otherwise, including<br>
things like LambdaCase etc.<br>
<br>
It is tempting, but the slope is too slippery.<br>
<br>
Most of our users (in particular the “experienced users” mentioned<br>
above) are used to managing a long list of flags, adding another will<br>
not hurt them to manage another one.<br>
<br>
And if this management becomes too long, then instead of making<br>
exceptions, we should either hope for Haskell20xx to liberally include<br>
these “convenience extensions”, or otherwise make the management of the<br>
extension list easier (e.g. maybe by picking up  <br>
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/92" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/92</a> again).<br></blockquote><div><br></div><div>Yes - everything that changes the language in some way should have an extension flag. We've been strict about this up to now, I think it would be a shame to start making exceptions. We have the nice property that if a module would fail to compile because it uses an extension that isn't supported by the compiler in use, we get a useful diagnostic rather than just a parse error. Every source file declares which language it is written in (well, together with the .cabal file), which is a nice property to have, and useful for other tooling in addition to compilers.<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers</div><div class="gmail_quote">Simon<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As for a shorter name, now about QualifiedLast?<br>
<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<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>