Hello, Am Freitag, den 08.03.2019, 08:55 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:
I agree. It’s a tiny, superficial thing, but it’s clearly egregiously annoying to some pretty experience users, who use Haskell at scale. So yes, we should do this.
It never bothered me, and I would have leaned towards “not worth the bother”, but I am swayed by strong support from Neil and Simon², so I am fine with accepting this.
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). As for a shorter name, now about QualifiedLast? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/