On Fri, 8 Mar 2019 at 09:29, Joachim Breitner
Am Freitag, den 08.03.2019, 08:55 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:
My only question is: do we really need a flag. Suppose we simply accepted the postfix “qualified” with no flag support. Then a program will be accepted that earlier compilers would have rejected – and, absent a flag, we normally try to continue to reject programs that weren’t legal before. But in this case no one is going to fall into this by mistake. I suggest we consider simply allowing it as an exception to our general rule, and move on.
Let’s not do this. We have very few hard guidelines to help us in our work; “changes to the language needs a flag” is one of them. If we start to be lax here, we will have to justify every future flag where the extension would just be an invalid program otherwise, including things like LambdaCase etc.
It is tempting, but the slope is too slippery.
Most of our users (in particular the “experienced users” mentioned above) are used to managing a long list of flags, adding another will not hurt them to manage another one.
And if this management becomes too long, then instead of making exceptions, we should either hope for Haskell20xx to liberally include these “convenience extensions”, or otherwise make the management of the extension list easier (e.g. maybe by picking up https://github.com/ghc-proposals/ghc-proposals/pull/92 again).
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. Cheers Simon
As for a shorter name, now about QualifiedLast?
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee