First of all, I totally agree that the proposed syntax is better. However, TBH, I don’t think it is a particularly good idea to change syntactic warts by way of a language extension. If we were discussing actually changing the language definition, that would be a different matter. But we are not. We just add an alternative and potentially cause confusion. Hence, I think, this is a bad idea. Cheers, Manuel

Am 08.03.2019 um 09:31 schrieb Simon Marlow :

Proposal #190 is about accepting the syntax

import A.B.C qualified

instead of (or in addition to) the existing syntax

import qualified A.B.C

I think it's widely accepted that the original syntax was a mistake. I don't need to rehash the rationale for the change here, iit's described pretty well in the proposal and elaborated in the discussion.

The question for us is really: is it worth changing? There are costs: - A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand) - new code using the extension doesn't compile with older compilers - all the existing code in the world uses the old convention - etc.

Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.

Personally, the current syntax annoys me almost every day. It's already a small cost on everyone, and I think we need to move forwards even if there are costs in migrating. So, I'm going to recommend that we accept this proposal.

We might want to reconsider the name of the extension: QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?

Cheers Simon

On Mon, 4 Mar 2019 at 12:09, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee,

this is your secretary speaking:

Module qualified syntax has been proposed by Shayne Fletcher https://github.com/ghc-proposals/ghc-proposals/pull/190 https://github.com/ghc-proposals/ghc-proposals/pull/190 https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-sy... https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-sy...

Simon Marlow has already volunteered to shepherd.

Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you.

Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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/

On Fri, 8 Mar 2019 at 09:29, Joachim Breitner wrote:

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

This never bothered me personally, but I have no strong feeling about it either way. On Fri, Mar 8, 2019 at 6:30 AM Vitaly Bragilevsky wrote:

Hello,

I am in favor of this proposal. As for the name of the extension, my suggestion is 'FlexibleImports', then we could allow even more flexibility in import declarations in the future. Anyway, I am also ok with the current versions (although the shorter the better).

Regards, Vitaly

On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow wrote:

...

Proposal #190 is about accepting the syntax

import A.B.C qualified

instead of (or in addition to) the existing syntax

import qualified A.B.C

I think it's widely accepted that the original syntax was a mistake. I don't need to rehash the rationale for the change here, iit's described pretty well in the proposal and elaborated in the discussion.

The question for us is really: is it worth changing? There are costs: - A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand) - new code using the extension doesn't compile with older compilers - all the existing code in the world uses the old convention - etc.

Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.

Personally, the current syntax annoys me almost every day. It's already a small cost on everyone, and I think we need to move forwards even if there are costs in migrating. So, I'm going to recommend that we accept this proposal.

We might want to reconsider the name of the extension: QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?

Cheers Simon

On Mon, 4 Mar 2019 at 12:09, Joachim Breitner wrote:

...

Dear Committee,

this is your secretary speaking:

Module qualified syntax has been proposed by Shayne Fletcher https://github.com/ghc-proposals/ghc-proposals/pull/190

https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-sy...

Simon Marlow has already volunteered to shepherd.

Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you.

Thanks, 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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, let’s see. Currently, we issue an *error* error: Illegal lambda-case (use -XLambdaCase) your idea would turn that into a warning warning [-Wmissing-LambdaCase] : Illegal lambda-case (use -XLambdaCase) It is odd that now -Wno-missing-LambdaCase and -XLambdaCase are essentially the same. But how about we add a single warning category: warning [-Wmissing-langauge] : Illegal lambda-case (use -XLambdaCase) We could even leave the default as -Werror=missing-langauge matching existing behavior. People who want to play around more liberally can use -Wwarn=missing-language and get notified which extensions they might want (maybe a good default for ghci?), and those who really don't care can use -Wno-missing-language And then the question is: Do this only only for benign extensions? Only for those where we can easily issue warnings? For all? Not sure how useful it is, but it might be. Cheers, Joachim Am Freitag, den 08.03.2019, 12:37 -0500 schrieb Richard Eisenberg:

Like many on this list, I've never been bothered by the existing syntax. But I am swayed by experienced folks who very much want this.

I like Vitaly's idea of opening the door to future changes. I think there is more improvement to be found in our import/export syntax than just this one change, and so if we have a generic enough language extension, it allows us to consider smallish syntax changes without new language extensions in the future. `FlexibleImports` is as good a name as any, I think.

As to the annoyance about adding language extensions: what if we issue a *warning*, not an error, when the user writes a program without specifying the extension? This warning would be on by default (but could, naturally, be suppressed). I'd be comfortable with expanding this treatment by identifying a set of "benign" extensions. Each benign extension would have an accompanying warning, e.g., -Wmissing-FlexibleInstances. These would all be on by default, suppressed with either, e.g., -XFlexibleInstances or -Wno-missing-FlexibleInstances. (Interestingly, the semantics of -XFlexibleInstances and -Wno-missing-FlexibleInstances is identical. Hmm.)

Definition: A *benign* extension is one that, when enabled, strictly increases the set of programs GHC accepts. It never changes the meaning of any program that was accepted without the extension.

I don't feel strongly on this warning idea, but I wanted to throw it out there.

Richard

...

On Mar 8, 2019, at 11:59 AM, Iavor Diatchki wrote:

This never bothered me personally, but I have no strong feeling about it either way.

On Fri, Mar 8, 2019 at 6:30 AM Vitaly Bragilevsky wrote:

...

Hello,

I am in favor of this proposal. As for the name of the extension, my suggestion is 'FlexibleImports', then we could allow even more flexibility in import declarations in the future. Anyway, I am also ok with the current versions (although the shorter the better).

Regards, Vitaly

On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow wrote:

...

Proposal #190 is about accepting the syntax

import A.B.C qualified

instead of (or in addition to) the existing syntax

import qualified A.B.C

I think it's widely accepted that the original syntax was a mistake. I don't need to rehash the rationale for the change here, iit's described pretty well in the proposal and elaborated in the discussion.

The question for us is really: is it worth changing? There are costs: - A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand) - new code using the extension doesn't compile with older compilers - all the existing code in the world uses the old convention - etc.

Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.

Personally, the current syntax annoys me almost every day. It's already a small cost on everyone, and I think we need to move forwards even if there are costs in migrating. So, I'm going to recommend that we accept this proposal.

We might want to reconsider the name of the extension: QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?

Cheers Simon

On Mon, 4 Mar 2019 at 12:09, Joachim Breitner wrote:

...

Dear Committee,

this is your secretary speaking:

Module qualified syntax has been proposed by Shayne Fletcher https://github.com/ghc-proposals/ghc-proposals/pull/190 https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-sy...

Simon Marlow has already volunteered to shepherd.

Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you.

Thanks, 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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

I don't think this is necessary. Managing language extensions is not that hard, and can be trivial with good tooling (which at least some editors already have). That being said, I suspect that most if not all benign extensions would be good candidates for inclusion in the next language standard. On Fri, Mar 8, 2019, at 12:52, Joachim Breitner wrote:

Hi,

let’s see. Currently, we issue an *error*

error: Illegal lambda-case (use -XLambdaCase)

your idea would turn that into a warning

warning [-Wmissing-LambdaCase] : Illegal lambda-case (use -XLambdaCase)

It is odd that now -Wno-missing-LambdaCase and -XLambdaCase are essentially the same.

But how about we add a single warning category:

warning [-Wmissing-langauge] : Illegal lambda-case (use -XLambdaCase)

We could even leave the default as

-Werror=missing-langauge

matching existing behavior. People who want to play around more liberally can use

-Wwarn=missing-language

and get notified which extensions they might want (maybe a good default for ghci?), and those who really don't care can use

-Wno-missing-language

And then the question is: Do this only only for benign extensions? Only for those where we can easily issue warnings? For all?

Not sure how useful it is, but it might be.

Cheers, Joachim

Am Freitag, den 08.03.2019, 12:37 -0500 schrieb Richard Eisenberg:

...

Like many on this list, I've never been bothered by the existing syntax. But I am swayed by experienced folks who very much want this.

I like Vitaly's idea of opening the door to future changes. I think there is more improvement to be found in our import/export syntax than just this one change, and so if we have a generic enough language extension, it allows us to consider smallish syntax changes without new language extensions in the future. `FlexibleImports` is as good a name as any, I think.

As to the annoyance about adding language extensions: what if we issue a *warning*, not an error, when the user writes a program without specifying the extension? This warning would be on by default (but could, naturally, be suppressed). I'd be comfortable with expanding this treatment by identifying a set of "benign" extensions. Each benign extension would have an accompanying warning, e.g., -Wmissing-FlexibleInstances. These would all be on by default, suppressed with either, e.g., -XFlexibleInstances or -Wno-missing-FlexibleInstances. (Interestingly, the semantics of -XFlexibleInstances and -Wno-missing-FlexibleInstances is identical. Hmm.)

Definition: A *benign* extension is one that, when enabled, strictly increases the set of programs GHC accepts. It never changes the meaning of any program that was accepted without the extension.

I don't feel strongly on this warning idea, but I wanted to throw it out there.

Richard

...

On Mar 8, 2019, at 11:59 AM, Iavor Diatchki wrote:

This never bothered me personally, but I have no strong feeling about it either way.

On Fri, Mar 8, 2019 at 6:30 AM Vitaly Bragilevsky wrote:

...

Hello,

I am in favor of this proposal. As for the name of the extension, my suggestion is 'FlexibleImports', then we could allow even more flexibility in import declarations in the future. Anyway, I am also ok with the current versions (although the shorter the better).

Regards, Vitaly

On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow wrote:

...

Proposal #190 is about accepting the syntax

import A.B.C qualified

instead of (or in addition to) the existing syntax

import qualified A.B.C

I think it's widely accepted that the original syntax was a mistake. I don't need to rehash the rationale for the change here, iit's described pretty well in the proposal and elaborated in the discussion.

The question for us is really: is it worth changing? There are costs: - A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand) - new code using the extension doesn't compile with older compilers - all the existing code in the world uses the old convention - etc.

Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.

Personally, the current syntax annoys me almost every day. It's already a small cost on everyone, and I think we need to move forwards even if there are costs in migrating. So, I'm going to recommend that we accept this proposal.

We might want to reconsider the name of the extension: QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?

Cheers Simon

On Mon, 4 Mar 2019 at 12:09, Joachim Breitner wrote:

...

Dear Committee,

this is your secretary speaking:

Module qualified syntax has been proposed by Shayne Fletcher https://github.com/ghc-proposals/ghc-proposals/pull/190 https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-sy...

Simon Marlow has already volunteered to shepherd.

Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you.

Thanks, 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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- 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

Attachments: * signature.asc

On Wed, 17 Apr 2019 at 08:00, Joachim Breitner wrote:

Hi,

it looks like we agree on accepting this with a pragma, but need to decide upon the pragma. We had these options:

* FlexibleImports * QualifiedLast * QualifiedImportsPostpositive * ImportQualifiedPost

Simon M, as the shepherd, care to make a final recommendation about the pragma and/or ask the authors to come up with one (and amend the proposal)?

Sometimes I just want someone else to choose the actual syntax while I scowl slightly and accept it :-) Ok, would anyone be vigorously against ImportQualifiedPost? (on "FlexibleImports" I'm not very keen on adding an extension flag that we explicitly intend to mean different things in the future. That's just a way of getting around the extension flag policy. Either we think it's a good idea to have flags for every extension, or we don't. Yes I know we've discussed this in the past and there are grey areas, and we do already change the meaning of extensions sometimes. But pre-allocating a bucket for an unknown set of future extensions seems like a step too far to me.) Cheers Simon

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

Hi, accepted and merged. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/