I'm happy with your reasoning, Simon, and am also in favor of rejection. On Mon, Sep 16, 2019 at 9:23 AM Simon Marlow wrote:

Dear steering committee -

The discussion following my earlier suggestion to reject the proposal has petered out. Taking into account the discussion, it still seems to me that we should reject the proposal, so I've posted on the thread to this effect: https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-5316665...

Any further comments before we close it?

Thanks Simon

On Fri, 5 Jul 2019 at 08:19, Simon Marlow wrote:

...

Dear steering committee -

I am inclined to reject this proposal, so as per the new committee process I posted the rationale on the github thread: https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-5084146...

You may want to consider the proposal and offer opinions while we wait for the authors' rebuttal. It's a very simple proposal.

Cheers Simon

On Wed, 3 Jul 2019 at 08:55, Joachim Breitner wrote:

...

Dear Committee,

this is your secretary speaking:

QualifiedImports has been proposed by Arnaud Spiwack and Guillaume Bouchard https://github.com/ghc-proposals/ghc-proposals/pull/220

https://github.com/tweag/ghc-proposals/blob/qualified-import/proposals/0000-...

I propose Simon M as the shepherd.

Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link.

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

-- I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/

Hi Arnaud, Please rest assured I don't consider this to be an inconsequential stylistic change at all. Quite the opposite! Indeed, the fact that it has huge consequences is why I've been taking it so seriously. I don't want to rehash the debate, but let me just say that I think this has been a worthwhile conversation to have, and it might well be one that we revisit in the future. Cheers Simon On Tue, 17 Sep 2019 at 07:53, Spiwack, Arnaud wrote:

Dear all,

As one of the author of this proposal. I am, unsurprisingly, against rejecting it. Though it seems I'm rather in a minority here, let me add one last argument to try and sway the general opinion. Being understood that being an author, this argument cannot, in any way be considered as “a vote” or any such thing.

Human psychology is powerful. As it happens, we have a very strong tendency to choose whatever course of thought or action requires the least mental effort. Defaults require very little mental efforts, so we naturally will gravitate towards default. This is why, for instance, almost every Swedish worker is part of a union, while almost every French worker isn't: in Sweden, unionising is opt-out, whereas in France, it's opt-in. That's also why putting apples in front of sweet deserts in a school restaurant will result in more children eating fruits rather than cakes.

Back to our case: the overwhelming majority of Haskell packages are designed to be used unqualified (and also do almost all of their imports unqualified). Now, either unqualified import are really that much better, or the default has an enormous influence. As I previously mentioned, in Ocaml, a fairly similar language, qualified is the default, and almost every libraries are designed for qualified imports, and import their modules qualified. So I'd wager it's the default.

As a software architect, I do actually spend a bunch of my code reviews saying: you should import qualified. It would be a much more effective and powerful message to simply set the default imports as being qualified in my projects. For me, the change in this proposal would really be a very significant change.

Now, the committee may decide that this is still not worth the confusion implied by having two incompatible syntactic conventions out there. That's entirely fair! I just don't want anybody to walk out of this conversation with the feeling that this proposal is an inconsequential stylistic change.

/Arnaud

On Mon, Sep 16, 2019 at 2:04 PM Sandy Maguire wrote:

...

I'm happy with your reasoning, Simon, and am also in favor of rejection.

On Mon, Sep 16, 2019 at 9:23 AM Simon Marlow wrote:

...

Dear steering committee -

The discussion following my earlier suggestion to reject the proposal has petered out. Taking into account the discussion, it still seems to me that we should reject the proposal, so I've posted on the thread to this effect: https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-5316665...

Any further comments before we close it?

Thanks Simon

On Fri, 5 Jul 2019 at 08:19, Simon Marlow wrote:

...

Dear steering committee -

I am inclined to reject this proposal, so as per the new committee process I posted the rationale on the github thread: https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-5084146...

You may want to consider the proposal and offer opinions while we wait for the authors' rebuttal. It's a very simple proposal.

Cheers Simon

On Wed, 3 Jul 2019 at 08:55, Joachim Breitner wrote:

...

Dear Committee,

this is your secretary speaking:

QualifiedImports has been proposed by Arnaud Spiwack and Guillaume Bouchard https://github.com/ghc-proposals/ghc-proposals/pull/220

https://github.com/tweag/ghc-proposals/blob/qualified-import/proposals/0000-...

I propose Simon M as the shepherd.

Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link.

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

-- I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I agree with Arnaud that defaults are important: switching from opt-in to opt-out for organ donation, and for pension contributions, has had a huge effect. Suppose, as in the above examples, we had a consensus that import-qualified-by-default was the way we wanted Haskell to be. Then we’d just be discussing how to switch over, what the deprecation strategy is, how many compiler releases to allow etc. Controversial as it was, the Foldable thing was like this. But that’s not the case here. We are not discussing a change to the base language, but a language extension that you can choose to use, or not. So it remains a local coding style choice: “in our company we always use `{-# LANGUAGE QualifiedImports #-}` “. But that really isn’t significantly different from saying “in our company we always use `import qualified`”. Yes, you can put the former in your .cabal file – but you could equally use HLint to enforce qualified import. I’m still not persuaded that this small change in convenience is enough to add an extension for. As I say, it’d be different if there was a consensus that we wanted to change the base language, and migrate everyone to the new default. Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 17 September 2019 22:04 To: Spiwack, Arnaud Cc: ghc-steering-committee@haskell.org; Joachim Breitner ; Sandy Maguire Subject: Re: [ghc-steering-committee] Please review #220: QualifiedImports, Shepherd: Simon M I think Arnaud's is an effective argument. It has not changed my opinion of this proposal (I'm still against), but it's moved the needle a bit for me. What it does suggest is a feature in HLint (if it doesn't already exist) that encourages this behavior. Putting this in HLint allows individuals and organizations to experiment with enforcing this style, perhaps building up further experience for retrying this in the future. After writing the above, I talked to Arnaud, and he pointed out a deadly flaw in this plan: even if qualified is the default, it might sometimes be nice to import unqualified. In the proposal, this is done via the unqualified keyword. But without this proposal, there would be no way to signal to HLint that an import is meant to be unqualified. So perhaps a much more modest proposal allowing (but not requiring) users to write `unqualified` in import statements would be worthwhile. This keyword would always be redundant today, but it might feasibly be a way forward here. Full disclosure: my immediate instinct would be to be against the "unqualified" proposal, but it wouldn't be a fork of the language (unlike the current proposal). Perhaps others could convince me otherwise. Richard On Sep 17, 2019, at 7:52 AM, Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> wrote: Dear all, As one of the author of this proposal. I am, unsurprisingly, against rejecting it. Though it seems I'm rather in a minority here, let me add one last argument to try and sway the general opinion. Being understood that being an author, this argument cannot, in any way be considered as “a vote” or any such thing. Human psychology is powerful. As it happens, we have a very strong tendency to choose whatever course of thought or action requires the least mental effort. Defaults require very little mental efforts, so we naturally will gravitate towards default. This is why, for instance, almost every Swedish worker is part of a union, while almost every French worker isn't: in Sweden, unionising is opt-out, whereas in France, it's opt-in. That's also why putting apples in front of sweet deserts in a school restaurant will result in more children eating fruits rather than cakes. Back to our case: the overwhelming majority of Haskell packages are designed to be used unqualified (and also do almost all of their imports unqualified). Now, either unqualified import are really that much better, or the default has an enormous influence. As I previously mentioned, in Ocaml, a fairly similar language, qualified is the default, and almost every libraries are designed for qualified imports, and import their modules qualified. So I'd wager it's the default. As a software architect, I do actually spend a bunch of my code reviews saying: you should import qualified. It would be a much more effective and powerful message to simply set the default imports as being qualified in my projects. For me, the change in this proposal would really be a very significant change. Now, the committee may decide that this is still not worth the confusion implied by having two incompatible syntactic conventions out there. That's entirely fair! I just don't want anybody to walk out of this conversation with the feeling that this proposal is an inconsequential stylistic change. /Arnaud On Mon, Sep 16, 2019 at 2:04 PM Sandy Maguire mailto:sandy@sandymaguire.me> wrote: I'm happy with your reasoning, Simon, and am also in favor of rejection. On Mon, Sep 16, 2019 at 9:23 AM Simon Marlow mailto:marlowsd@gmail.com> wrote: Dear steering committee - The discussion following my earlier suggestion to reject the proposal has petered out. Taking into account the discussion, it still seems to me that we should reject the proposal, so I've posted on the thread to this effect: https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-5316665... Any further comments before we close it? Thanks Simon On Fri, 5 Jul 2019 at 08:19, Simon Marlow mailto:marlowsd@gmail.com> wrote: Dear steering committee - I am inclined to reject this proposal, so as per the new committee process I posted the rationale on the github thread: https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-5084146... You may want to consider the proposal and offer opinions while we wait for the authors' rebuttal. It's a very simple proposal. Cheers Simon On Wed, 3 Jul 2019 at 08:55, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee, this is your secretary speaking: QualifiedImports has been proposed by Arnaud Spiwack and Guillaume Bouchard https://github.com/ghc-proposals/ghc-proposals/pull/220 https://github.com/tweag/ghc-proposals/blob/qualified-import/proposals/0000-... I propose Simon M as the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link. Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto: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.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto: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.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

My preference would also be to keep to a minimum "extensions" that *change* the meaning of existing language constructs. -Iavor On Thu, Sep 19, 2019 at 11:03 AM Simon Marlow wrote:

The bigger question here is: are we happy to admit extensions that fork the language? Simon appears to be saying that he doesn't mind. I'm strongly against a fork, unless it has a clear migration path and an endpoint.

Cheers Simon

On Tue, 17 Sep 2019 at 23:56, Simon Peyton Jones via ghc-steering-committee wrote:

...

I agree with Arnaud that defaults are important: switching from opt-in to opt-out for organ donation, and for pension contributions, has had a huge effect.

Suppose, as in the above examples, we had a consensus that import-qualified-by-default was the way we wanted Haskell to be. Then we’d just be discussing how to switch over, what the deprecation strategy is, how many compiler releases to allow etc. Controversial as it was, the Foldable thing was like this.

But that’s not the case here. We are not discussing a change to the base language, but a language extension that you can choose to use, or not. So it remains a local coding style choice: “in our company we always use `{-# LANGUAGE QualifiedImports #-}` “. But that really isn’t significantly different from saying “in our company we always use `import qualified`”. Yes, you can put the former in your .cabal file – but you could equally use HLint to enforce qualified import.

I’m still not persuaded that this small change in convenience is enough to add an extension for. As I say, it’d be different if there was a consensus that we wanted to change the base language, and migrate everyone to the new default.

Simon

From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 17 September 2019 22:04 To: Spiwack, Arnaud Cc: ghc-steering-committee@haskell.org; Joachim Breitner ; Sandy Maguire Subject: Re: [ghc-steering-committee] Please review #220: QualifiedImports, Shepherd: Simon M

I think Arnaud's is an effective argument. It has not changed my opinion of this proposal (I'm still against), but it's moved the needle a bit for me. What it does suggest is a feature in HLint (if it doesn't already exist) that encourages this behavior. Putting this in HLint allows individuals and organizations to experiment with enforcing this style, perhaps building up further experience for retrying this in the future.

After writing the above, I talked to Arnaud, and he pointed out a deadly flaw in this plan: even if qualified is the default, it might sometimes be nice to import unqualified. In the proposal, this is done via the unqualified keyword. But without this proposal, there would be no way to signal to HLint that an import is meant to be unqualified. So perhaps a much more modest proposal allowing (but not requiring) users to write `unqualified` in import statements would be worthwhile. This keyword would always be redundant today, but it might feasibly be a way forward here.

Full disclosure: my immediate instinct would be to be against the "unqualified" proposal, but it wouldn't be a fork of the language (unlike the current proposal). Perhaps others could convince me otherwise.

Richard

On Sep 17, 2019, at 7:52 AM, Spiwack, Arnaud wrote:

Dear all,

As one of the author of this proposal. I am, unsurprisingly, against rejecting it. Though it seems I'm rather in a minority here, let me add one last argument to try and sway the general opinion. Being understood that being an author, this argument cannot, in any way be considered as “a vote” or any such thing.

Human psychology is powerful. As it happens, we have a very strong tendency to choose whatever course of thought or action requires the least mental effort. Defaults require very little mental efforts, so we naturally will gravitate towards default. This is why, for instance, almost every Swedish worker is part of a union, while almost every French worker isn't: in Sweden, unionising is opt-out, whereas in France, it's opt-in. That's also why putting apples in front of sweet deserts in a school restaurant will result in more children eating fruits rather than cakes.

Back to our case: the overwhelming majority of Haskell packages are designed to be used unqualified (and also do almost all of their imports unqualified). Now, either unqualified import are really that much better, or the default has an enormous influence. As I previously mentioned, in Ocaml, a fairly similar language, qualified is the default, and almost every libraries are designed for qualified imports, and import their modules qualified. So I'd wager it's the default.

As a software architect, I do actually spend a bunch of my code reviews saying: you should import qualified. It would be a much more effective and powerful message to simply set the default imports as being qualified in my projects. For me, the change in this proposal would really be a very significant change.

Now, the committee may decide that this is still not worth the confusion implied by having two incompatible syntactic conventions out there. That's entirely fair! I just don't want anybody to walk out of this conversation with the feeling that this proposal is an inconsequential stylistic change.

/Arnaud

On Mon, Sep 16, 2019 at 2:04 PM Sandy Maguire wrote:

I'm happy with your reasoning, Simon, and am also in favor of rejection.

On Mon, Sep 16, 2019 at 9:23 AM Simon Marlow wrote:

Dear steering committee -

The discussion following my earlier suggestion to reject the proposal has petered out. Taking into account the discussion, it still seems to me that we should reject the proposal, so I've posted on the thread to this effect: https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-5316665...

Any further comments before we close it?

Thanks

Simon

On Fri, 5 Jul 2019 at 08:19, Simon Marlow wrote:

Dear steering committee -

I am inclined to reject this proposal, so as per the new committee process I posted the rationale on the github thread: https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-5084146...

You may want to consider the proposal and offer opinions while we wait for the authors' rebuttal. It's a very simple proposal.

Cheers

Simon

On Wed, 3 Jul 2019 at 08:55, Joachim Breitner wrote:

Dear Committee,

this is your secretary speaking:

QualifiedImports has been proposed by Arnaud Spiwack and Guillaume Bouchard https://github.com/ghc-proposals/ghc-proposals/pull/220 https://github.com/tweag/ghc-proposals/blob/qualified-import/proposals/0000-...

I propose Simon M as the shepherd.

Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link.

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

--

I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/

_______________________________________________ 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

On Thu, 19 Sep 2019 at 22:02, Simon Peyton Jones wrote:

Simon appears to be saying that he doesn't mind.

Sorry -- I expressed myself badly. I support rejection.

I was saying IF there was a consensus that we wanted to simply to change the language to a better design, THEN there’d be a case for flags, migration strategy etc.

But there isn’t such a consensue. So it’s just a question of how those who want qualified imports can get them.

- Now: by consistently using `import qualified` - Under this proposal: by consistently using `{-# LANGUAGE QualifiedImports #-}`

Both are coding conventions that might be enforced locally within, say, a company. But the convenience benefit of moving from the former to the latter doesn’t seem justified to me.

I think I was a bit unclear too, sorry - the second bullet point is what I mean by a "fork", which is the thing I think we should strive to avoid. Why is this a fork? - It fails the test "Is this extension something that most people would be happy to enable, even if they don't want to use it?" - It fails the test "Do we think there's a reasonable chance this extension will make it into a future language standard?" The idea is that unless we can see a path to a point where everyone has the extension turned on, we're left with different groups of people using incompatible dialects of the language. A similar problem arises with extensions that are mutually incompatible. For extensions that are invasive and break a lot of code, I think we have to establish that this is the right direction to move in. Or perhaps, that this is something we think is worthwhile experimenting with (but that's debatable, because it's hard to undo later). Cheers Simon

Simon

*From:* Simon Marlow *Sent:* 19 September 2019 19:03 *To:* Simon Peyton Jones *Cc:* Richard Eisenberg ; Spiwack, Arnaud < arnaud.spiwack@tweag.io>; ghc-steering-committee@haskell.org; Joachim Breitner ; Sandy Maguire *Subject:* Re: [ghc-steering-committee] Please review #220: QualifiedImports, Shepherd: Simon M

The bigger question here is: are we happy to admit extensions that fork the language? Simon appears to be saying that he doesn't mind. I'm strongly against a fork, unless it has a clear migration path and an endpoint.

Cheers

Simon

On Tue, 17 Sep 2019 at 23:56, Simon Peyton Jones via ghc-steering-committee wrote:

I agree with Arnaud that defaults are important: switching from opt-in to opt-out for organ donation, and for pension contributions, has had a huge effect.

Suppose, as in the above examples, we had a consensus that import-qualified-by-default was the way we wanted Haskell to be. Then we’d just be discussing how to switch over, what the deprecation strategy is, how many compiler releases to allow etc. Controversial as it was, the Foldable thing was like this.

But that’s not the case here. We are not discussing a change to the base language, but a language extension that you can choose to use, or not. So it remains a local coding style choice: “in our company we always use `{-# LANGUAGE QualifiedImports #-}` “. But that really isn’t significantly different from saying “in our company we always use `import qualified`”. Yes, you can put the former in your .cabal file – but you could equally use HLint to enforce qualified import.

I’m still not persuaded that this small change in convenience is enough to add an extension for. As I say, it’d be different if there was a consensus that we wanted to change the base language, and migrate everyone to the new default.

Simon

*From:* ghc-steering-committee *On Behalf Of *Richard Eisenberg *Sent:* 17 September 2019 22:04 *To:* Spiwack, Arnaud *Cc:* ghc-steering-committee@haskell.org; Joachim Breitner < mail@joachim-breitner.de>; Sandy Maguire *Subject:* Re: [ghc-steering-committee] Please review #220: QualifiedImports, Shepherd: Simon M

I think Arnaud's is an effective argument. It has not changed my opinion of this proposal (I'm still against), but it's moved the needle a bit for me. What it does suggest is a feature in HLint (if it doesn't already exist) that encourages this behavior. Putting this in HLint allows individuals and organizations to experiment with enforcing this style, perhaps building up further experience for retrying this in the future.

After writing the above, I talked to Arnaud, and he pointed out a deadly flaw in this plan: even if qualified is the default, it might sometimes be nice to import unqualified. In the proposal, this is done via the unqualified keyword. But without this proposal, there would be no way to signal to HLint that an import is meant to be unqualified. So perhaps a much more modest proposal allowing (but not requiring) users to write `unqualified` in import statements would be worthwhile. This keyword would always be redundant today, but it might feasibly be a way forward here.

Full disclosure: my immediate instinct would be to be against the "unqualified" proposal, but it wouldn't be a fork of the language (unlike the current proposal). Perhaps others could convince me otherwise.

Richard

On Sep 17, 2019, at 7:52 AM, Spiwack, Arnaud wrote:

Dear all,

As one of the author of this proposal. I am, unsurprisingly, against rejecting it. Though it seems I'm rather in a minority here, let me add one last argument to try and sway the general opinion. Being understood that being an author, this argument cannot, in any way be considered as “a vote” or any such thing.

Human psychology is powerful. As it happens, we have a very strong tendency to choose whatever course of thought or action requires the least mental effort. Defaults require very little mental efforts, so we naturally will gravitate towards default. This is why, for instance, almost every Swedish worker is part of a union, while almost every French worker isn't: in Sweden, unionising is opt-out, whereas in France, it's opt-in. That's also why putting apples in front of sweet deserts in a school restaurant will result in more children eating fruits rather than cakes.

Back to our case: the overwhelming majority of Haskell packages are designed to be used unqualified (and also do almost all of their imports unqualified). Now, either unqualified import are really that much better, or the default has an enormous influence. As I previously mentioned, in Ocaml, a fairly similar language, qualified is the default, and almost every libraries are designed for qualified imports, and import their modules qualified. So I'd wager it's the default.

As a software architect, I do actually spend a bunch of my code reviews saying: you should import qualified. It would be a much more effective and powerful message to simply set the default imports as being qualified in my projects. For me, the change in this proposal would really be a very significant change.

Now, the committee may decide that this is still not worth the confusion implied by having two incompatible syntactic conventions out there. That's entirely fair! I just don't want anybody to walk out of this conversation with the feeling that this proposal is an inconsequential stylistic change.

/Arnaud

On Mon, Sep 16, 2019 at 2:04 PM Sandy Maguire wrote:

I'm happy with your reasoning, Simon, and am also in favor of rejection.

On Mon, Sep 16, 2019 at 9:23 AM Simon Marlow wrote:

Dear steering committee -

The discussion following my earlier suggestion to reject the proposal has petered out. Taking into account the discussion, it still seems to me that we should reject the proposal, so I've posted on the thread to this effect: https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-5316665... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F220%23issuecomment-531666589&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901224188&sdata=ebgD0GeRlMEG9p9%2FmqNiIFstG8hNQqSW2RtT8W3y7fQ%3D&reserved=0

Any further comments before we close it?

Thanks

Simon

On Fri, 5 Jul 2019 at 08:19, Simon Marlow wrote:

Dear steering committee -

I am inclined to reject this proposal, so as per the new committee process I posted the rationale on the github thread: https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-5084146... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F220%23issuecomment-508414602&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901234180&sdata=Jhy3R%2B2nE2rgO8bbbr45cfVvVLT95iLPqv5Kt3U%2B1BU%3D&reserved=0

You may want to consider the proposal and offer opinions while we wait for the authors' rebuttal. It's a very simple proposal.

Cheers

Simon

On Wed, 3 Jul 2019 at 08:55, Joachim Breitner wrote:

Dear Committee,

this is your secretary speaking:

QualifiedImports has been proposed by Arnaud Spiwack and Guillaume Bouchard https://github.com/ghc-proposals/ghc-proposals/pull/220 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F220&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901234180&sdata=bONeThtWR25ADAyUjypHr1V2q4c6TWM9Z2i41n2WBo4%3D&reserved=0

https://github.com/tweag/ghc-proposals/blob/qualified-import/proposals/0000-... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftweag%2Fghc-proposals%2Fblob%2Fqualified-import%2Fproposals%2F0000-default-qualified-import.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901244176&sdata=9LyfLVT1wSTTXfgf0tsxdUfUzla2PYhU5QIgVxlrrCk%3D&reserved=0

I propose Simon M as the shepherd.

Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901244176&sdata=3cQMiAXEoUgLmnD00dLG7vlvMyG6%2BXmdliFuTKkRXlc%3D&reserved=0 In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link.

Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901254171&sdata=NqG1aixWIT%2BgIqXMH3o3SjoMdRywRUwhwQJUpOqFYC0%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901254171&sdata=X0j2AjHy2%2B7w5BnNmUF0Z9qapCR4f6ndqBGO833UO80%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901264165&sdata=ISG15bno12ixBRkYKS%2FZAe3G1gwyD1xgomEHPJDPwp0%3D&reserved=0

--

I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/ https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fisovector.github.io%2Ferdos%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901264165&sdata=8j7l5aJbGGWaCb5Y7KFjdqAQ6HnkXlGMNsprHCWOcHg%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901274160&sdata=3G8XxdVNRB9ytzgLZLstjX83hdaobo1ztmoJF5gCjok%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901274160&sdata=3G8XxdVNRB9ytzgLZLstjX83hdaobo1ztmoJF5gCjok%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C662994f33a3549cdb22908d73d2ba0f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045129901284159&sdata=QCGNnfGfP6%2FXcQvG6kr2GlFcQChTing8qqD8nb98Xd4%3D&reserved=0