From sandy at sandymaguire.me  Wed Sep  4 05:59:31 2019
From: sandy at sandymaguire.me (Sandy Maguire)
Date: Tue, 3 Sep 2019 22:59:31 -0700
Subject: [ghc-steering-committee] Please review #258:
 TopLevelKindSignatures -> StandaloneKindSignatures , Shepherd: Chris
In-Reply-To: <aecc8839c72dcb9b971e1aaefc879c779ad4b42c.camel@joachim-breitner.de>
References: <aecc8839c72dcb9b971e1aaefc879c779ad4b42c.camel@joachim-breitner.de>
Message-ID: <CADRtjwYy9tCTjLbNofSgeQgHuvKfAkeWvwqmeUP4WnSZTw0wAg@mail.gmail.com>

Hi all,

It's been two weeks since this was given to the committee. We haven't heard
anything from Chris, but it's a tiny change and everyone is already in
support. Let's just merge it and save the bureaucracy for proposals with
real consequences behind them.

Best,
Sandy

On Tue, Aug 20, 2019 at 7:43 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> TopLevelKindSignatures -> StandaloneKindSignatures
> has been proposed by Krzysztof Gogolewski
> https://github.com/ghc-proposals/ghc-proposals/pull/258
>
> I propose Chris 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
I'm currently traveling 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190903/261aa29b/attachment.html>

From simonpj at microsoft.com  Wed Sep  4 07:30:50 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 4 Sep 2019 07:30:50 +0000
Subject: [ghc-steering-committee] Please review #258:
 TopLevelKindSignatures -> StandaloneKindSignatures , Shepherd: Chris
In-Reply-To: <CADRtjwYy9tCTjLbNofSgeQgHuvKfAkeWvwqmeUP4WnSZTw0wAg@mail.gmail.com>
References: <aecc8839c72dcb9b971e1aaefc879c779ad4b42c.camel@joachim-breitner.de>
 <CADRtjwYy9tCTjLbNofSgeQgHuvKfAkeWvwqmeUP4WnSZTw0wAg@mail.gmail.com>
Message-ID: <VI1PR83MB03196E24DBB907025F04EDD5ADB80@VI1PR83MB0319.EURPRD83.prod.outlook.com>

Yes I think that’s the right step here.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Sandy Maguire
Sent: 04 September 2019 07:00
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Please review #258: TopLevelKindSignatures -> StandaloneKindSignatures , Shepherd: Chris

Hi all,

It's been two weeks since this was given to the committee. We haven't heard anything from Chris, but it's a tiny change and everyone is already in support. Let's just merge it and save the bureaucracy for proposals with real consequences behind them.

Best,
Sandy

On Tue, Aug 20, 2019 at 7:43 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

this is your secretary speaking:

TopLevelKindSignatures -> StandaloneKindSignatures
has been proposed by Krzysztof Gogolewski
https://github.com/ghc-proposals/ghc-proposals/pull/258

I propose Chris 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 at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/

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


--
I'm currently traveling 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190904/ac830c45/attachment.html>

From simonpj at microsoft.com  Wed Sep  4 15:31:52 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 4 Sep 2019 15:31:52 +0000
Subject: [ghc-steering-committee] Proposals under review
Message-ID: <VI1PR83MB0319DF7CCB1C6C679AEA19DAADB80@VI1PR83MB0319.EURPRD83.prod.outlook.com>

Joachim
On our home page https://github.com/ghc-proposals/ghc-proposals
there is a list of "proposals under committee review": https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22
But alas the latter shows zero proposals -- but I know there are proposals under review.
What's up?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190904/c1b7da33/attachment.html>

From simonpj at microsoft.com  Wed Sep  4 16:41:38 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 4 Sep 2019 16:41:38 +0000
Subject: [ghc-steering-committee] Please review #233: Higher-order roles,
	Shepherd: Simon PJ
In-Reply-To: <c3f3fc1a8326f34e4956f07c95ce0bb8521c97dc.camel@joachim-breitner.de>
References: <c3f3fc1a8326f34e4956f07c95ce0bb8521c97dc.camel@joachim-breitner.de>
Message-ID: <DB7PR83MB031345A0657DA13D7BEB24A9ADB80@DB7PR83MB0313.EURPRD83.prod.outlook.com>

I discussed with Richard and put it back into discussion state.

Is there a label for "under discussion" or is that indicated by the /absence/ of a label?

S

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Joachim Breitner
|  Sent: 07 August 2019 22:03
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] Please review #233: Higher-order roles,
|  Shepherd: Simon PJ
|  
|  Dear Committee,
|  
|  this is your secretary speaking:
|  
|  Higher-order Roles
|  has been proposed by Richard
|  https://github.com/ghc-proposals/ghc-proposals/pull/233
|  https://github.com/goldfirere/ghc-proposals/blob/higher-
|  roles/proposals/0000-higher-roles.rst
|  
|  I propose Simon PJ as the shepherd, as he already has had a discussion
|  with Richard on this.
|  
|  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 at joachim-breitner.de
|    http://www.joachim-breitner.de/


From rae at richarde.dev  Wed Sep  4 17:15:26 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 4 Sep 2019 18:15:26 +0100
Subject: [ghc-steering-committee] Please review #258:
 TopLevelKindSignatures -> StandaloneKindSignatures , Shepherd: Chris
In-Reply-To: <VI1PR83MB03196E24DBB907025F04EDD5ADB80@VI1PR83MB0319.EURPRD83.prod.outlook.com>
References: <aecc8839c72dcb9b971e1aaefc879c779ad4b42c.camel@joachim-breitner.de>
 <CADRtjwYy9tCTjLbNofSgeQgHuvKfAkeWvwqmeUP4WnSZTw0wAg@mail.gmail.com>
 <VI1PR83MB03196E24DBB907025F04EDD5ADB80@VI1PR83MB0319.EURPRD83.prod.outlook.com>
Message-ID: <3D4DB888-1BE2-4B4E-B752-8AFB5B17B8C0@richarde.dev>

I agree as well.

> On Sep 4, 2019, at 8:30 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> Yes I think that’s the right step here.
>  
> Simon
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Sandy Maguire
> Sent: 04 September 2019 07:00
> To: Joachim Breitner <mail at joachim-breitner.de>
> Cc: ghc-steering-committee at haskell.org
> Subject: Re: [ghc-steering-committee] Please review #258: TopLevelKindSignatures -> StandaloneKindSignatures , Shepherd: Chris
>  
> Hi all,
> 
>  
> 
> It's been two weeks since this was given to the committee. We haven't heard anything from Chris, but it's a tiny change and everyone is already in support. Let's just merge it and save the bureaucracy for proposals with real consequences behind them.
> 
>  
> 
> Best,
> 
> Sandy
> 
>  
> 
> On Tue, Aug 20, 2019 at 7:43 AM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> 
> Dear Committee,
> 
> this is your secretary speaking:
> 
> TopLevelKindSignatures -> StandaloneKindSignatures  
> has been proposed by Krzysztof Gogolewski
> https://github.com/ghc-proposals/ghc-proposals/pull/258 <https://github.com/ghc-proposals/ghc-proposals/pull/258>
> 
> I propose Chris as the 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>
> 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 at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
>  
> 
> -- 
> 
> I'm currently traveling 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://isovector.github.io/erdos/>_______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190904/aba701b7/attachment-0001.html>

From eric at seidel.io  Wed Sep  4 18:07:14 2019
From: eric at seidel.io (Eric Seidel)
Date: Wed, 04 Sep 2019 14:07:14 -0400
Subject: [ghc-steering-committee] Proposals under review
In-Reply-To: <VI1PR83MB0319DF7CCB1C6C679AEA19DAADB80@VI1PR83MB0319.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0319DF7CCB1C6C679AEA19DAADB80@VI1PR83MB0319.EURPRD83.prod.outlook.com>
Message-ID: <18b33bdd-8b2e-484c-8f83-215dabd980c6@www.fastmail.com>

There's also the "pending shepherd recommendation" label which is part of the review process. That shows 3 proposals currently.

https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+shepherd+recommendation%22

And then there's also "needs revision", which should mean that the ball is not in our court at the moment. But I think some of those proposals have semi-active conversations about how to revise the proposal.

https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Needs+revision%22

On Wed, Sep 4, 2019, at 11:31, Simon Peyton Jones via ghc-steering-committee wrote:
>  
> Joachim
> 
> On our home page https://github.com/ghc-proposals/ghc-proposals
> 
> there is a list of “proposals under committee review”: 
> https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22
> 
> But alas the latter shows zero proposals -- but I know there are 
> proposals under review.
> 
> What’s up?
> 
> Simon
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From eric at seidel.io  Wed Sep  4 18:08:37 2019
From: eric at seidel.io (Eric Seidel)
Date: Wed, 04 Sep 2019 14:08:37 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Please_review_=23233=3A_Higher?=
 =?utf-8?q?-order_roles=2C=09Shepherd=3A_Simon_PJ?=
In-Reply-To: <DB7PR83MB031345A0657DA13D7BEB24A9ADB80@DB7PR83MB0313.EURPRD83.prod.outlook.com>
References: <c3f3fc1a8326f34e4956f07c95ce0bb8521c97dc.camel@joachim-breitner.de>
 <DB7PR83MB031345A0657DA13D7BEB24A9ADB80@DB7PR83MB0313.EURPRD83.prod.outlook.com>
Message-ID: <78dc26ff-298f-4356-9435-d7f251103a85@www.fastmail.com>

This seems like a good candidate for the "needs revision" label.

On Wed, Sep 4, 2019, at 12:41, Simon Peyton Jones via ghc-steering-committee wrote:
> I discussed with Richard and put it back into discussion state.
> 
> Is there a label for "under discussion" or is that indicated by the 
> /absence/ of a label?
> 
> S
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> |  On Behalf Of Joachim Breitner
> |  Sent: 07 August 2019 22:03
> |  To: ghc-steering-committee at haskell.org
> |  Subject: [ghc-steering-committee] Please review #233: Higher-order roles,
> |  Shepherd: Simon PJ
> |  
> |  Dear Committee,
> |  
> |  this is your secretary speaking:
> |  
> |  Higher-order Roles
> |  has been proposed by Richard
> |  https://github.com/ghc-proposals/ghc-proposals/pull/233
> |  https://github.com/goldfirere/ghc-proposals/blob/higher-
> |  roles/proposals/0000-higher-roles.rst
> |  
> |  I propose Simon PJ as the shepherd, as he already has had a discussion
> |  with Richard on this.
> |  
> |  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 at joachim-breitner.de
> |    http://www.joachim-breitner.de/
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From mail at joachim-breitner.de  Wed Sep  4 18:17:11 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 04 Sep 2019 20:17:11 +0200
Subject: [ghc-steering-committee] Please review #233: Higher-order roles,
	Shepherd: Simon PJ
In-Reply-To: <DB7PR83MB031345A0657DA13D7BEB24A9ADB80@DB7PR83MB0313.EURPRD83.prod.outlook.com>
References: <c3f3fc1a8326f34e4956f07c95ce0bb8521c97dc.camel@joachim-breitner.de>
 <DB7PR83MB031345A0657DA13D7BEB24A9ADB80@DB7PR83MB0313.EURPRD83.prod.outlook.com>
Message-ID: <ACBDF2F8-A242-4C05-AA15-4CAB6726E296@joachim-breitner.de>

There is a “needs review” label, but in general absence of labels is “under discussion”. (Why? Because non-members cannot set labels and we want new proposals to have that status)

Cheers,
Joachim

Am 4. September 2019 18:41:38 MESZ schrieb Simon Peyton Jones <simonpj at microsoft.com>:
>I discussed with Richard and put it back into discussion state.
>
>Is there a label for "under discussion" or is that indicated by the
>/absence/ of a label?
>
>S
>
>|  -----Original Message-----
>|  From: ghc-steering-committee
><ghc-steering-committee-bounces at haskell.org>
>|  On Behalf Of Joachim Breitner
>|  Sent: 07 August 2019 22:03
>|  To: ghc-steering-committee at haskell.org
>|  Subject: [ghc-steering-committee] Please review #233: Higher-order
>roles,
>|  Shepherd: Simon PJ
>|  
>|  Dear Committee,
>|  
>|  this is your secretary speaking:
>|  
>|  Higher-order Roles
>|  has been proposed by Richard
>|  https://github.com/ghc-proposals/ghc-proposals/pull/233
>|  https://github.com/goldfirere/ghc-proposals/blob/higher-
>|  roles/proposals/0000-higher-roles.rst
>|  
>|  I propose Simon PJ as the shepherd, as he already has had a
>discussion
>|  with Richard on this.
>|  
>|  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 at joachim-breitner.de
>|    http://www.joachim-breitner.de/

From mail at joachim-breitner.de  Thu Sep  5 08:35:51 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 05 Sep 2019 10:35:51 +0200
Subject: [ghc-steering-committee] Please review #258:
 TopLevelKindSignatures -> StandaloneKindSignatures , Shepherd: Chris
In-Reply-To: <CADRtjwYy9tCTjLbNofSgeQgHuvKfAkeWvwqmeUP4WnSZTw0wAg@mail.gmail.com>
References: <aecc8839c72dcb9b971e1aaefc879c779ad4b42c.camel@joachim-breitner.de>
 <CADRtjwYy9tCTjLbNofSgeQgHuvKfAkeWvwqmeUP4WnSZTw0wAg@mail.gmail.com>
Message-ID: <5ea7585cb727130c157573e43e8d39278d8f485c.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 03.09.2019, 22:59 -0700 schrieb Sandy Maguire:
> Let's just merge it and save the bureaucracy for proposals with real consequences behind them.

done. Should have realized that alrady when it was proposed, but wasn’t
paying close attention.

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From mail at joachim-breitner.de  Thu Sep  5 08:39:37 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 05 Sep 2019 10:39:37 +0200
Subject: [ghc-steering-committee] Proposals under review
In-Reply-To: <18b33bdd-8b2e-484c-8f83-215dabd980c6@www.fastmail.com>
References: <VI1PR83MB0319DF7CCB1C6C679AEA19DAADB80@VI1PR83MB0319.EURPRD83.prod.outlook.com>
 <18b33bdd-8b2e-484c-8f83-215dabd980c6@www.fastmail.com>
Message-ID: <ee447dd31a19dcc8d062ec0f9a61c9078291948e.camel@joachim-breitner.de>

Hi,

indeed, there is no proposal at the moment that is in that phase. At
the last status mail (Aug 18) there were 3, but we have accepted two of
them (#229 and #160) and returned one for revision (#231)

So unless you are one of the shepherds (Simon or Vitaly), there is
nothing to do right now! Wow…

If you are bored: Join the ongoing dscussions before they are
officially assigned to a shepherd:
https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no%3Alabel

Cheers,
Joachim-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From mail at joachim-breitner.de  Thu Sep  5 08:42:54 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 05 Sep 2019 10:42:54 +0200
Subject: [ghc-steering-committee] Please review #259: No kind signatures on
 associated types Shepherd: Simon PJ
Message-ID: <87300980d2b2ea5ee64639cf2bc2d8ebb7c3c2e7.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

No kind signatures on associated types
has been proposed by Richard
https://github.com/ghc-proposals/ghc-proposals/pull/259

I propose Simon PJ as the shepherd, this seems to be a smaller fix of
an existing proposal and Simon has already looked at it.

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 at joachim-breitner.de
  http://www.joachim-breitner.de/


From rae at richarde.dev  Thu Sep  5 11:26:47 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 5 Sep 2019 12:26:47 +0100
Subject: [ghc-steering-committee] Please review #233: Higher-order roles,
	Shepherd: Simon PJ
In-Reply-To: <78dc26ff-298f-4356-9435-d7f251103a85@www.fastmail.com>
References: <c3f3fc1a8326f34e4956f07c95ce0bb8521c97dc.camel@joachim-breitner.de>
 <DB7PR83MB031345A0657DA13D7BEB24A9ADB80@DB7PR83MB0313.EURPRD83.prod.outlook.com>
 <78dc26ff-298f-4356-9435-d7f251103a85@www.fastmail.com>
Message-ID: <64DEDC7E-BF4C-485F-869F-1F0B375CE3CE@richarde.dev>



> On Sep 4, 2019, at 7:08 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> This seems like a good candidate for the "needs revision" label.

Indeed. Applied.

> 
> On Wed, Sep 4, 2019, at 12:41, Simon Peyton Jones via ghc-steering-committee wrote:
>> I discussed with Richard and put it back into discussion state.
>> 
>> Is there a label for "under discussion" or is that indicated by the 
>> /absence/ of a label?
>> 
>> S
>> 
>> |  -----Original Message-----
>> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
>> |  On Behalf Of Joachim Breitner
>> |  Sent: 07 August 2019 22:03
>> |  To: ghc-steering-committee at haskell.org
>> |  Subject: [ghc-steering-committee] Please review #233: Higher-order roles,
>> |  Shepherd: Simon PJ
>> |  
>> |  Dear Committee,
>> |  
>> |  this is your secretary speaking:
>> |  
>> |  Higher-order Roles
>> |  has been proposed by Richard
>> |  https://github.com/ghc-proposals/ghc-proposals/pull/233
>> |  https://github.com/goldfirere/ghc-proposals/blob/higher-
>> |  roles/proposals/0000-higher-roles.rst
>> |  
>> |  I propose Simon PJ as the shepherd, as he already has had a discussion
>> |  with Richard on this.
>> |  
>> |  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 at joachim-breitner.de
>> |    http://www.joachim-breitner.de/
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From simonpj at microsoft.com  Fri Sep  6 16:42:36 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 6 Sep 2019 16:42:36 +0000
Subject: [ghc-steering-committee] Please review #259: No kind signatures
 on associated types Shepherd: Simon PJ
In-Reply-To: <87300980d2b2ea5ee64639cf2bc2d8ebb7c3c2e7.camel@joachim-breitner.de>
References: <87300980d2b2ea5ee64639cf2bc2d8ebb7c3c2e7.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB0319EC9179AF085E7293D070ADBA0@VI1PR83MB0319.EURPRD83.prod.outlook.com>

All,

I'm the shepherd for

|  No kind signatures on associated types
|  https://github.com/ghc-proposals/ghc-proposals/pull/259

I recommend acceptance.

The proposal takes the form of an amendment to an earlier accepted proposal
   Standalone kind signatures
   https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0054-kind-signatures.rst

by prohibiting a standalone kind signature for the associated type of a class.

The reason for this narrowing is well described in the "Associated types" subsection of the revised proposal.

The first link above lets you see the baseline proposal, the diff, and the new proposal.

I recommend acceptance because
- the need for standalone signatures on
  associated types is weaker (albeit not absent)
- allowing such a signature closes of one possible
  future direction

So making them illegal now keeps our options open for the future.

Since standalone kind signatures are not yet released, there will be no back-compat issues.

Please express your opinion.  I don't think this one is controversial.

Simon


|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Joachim Breitner
|  Sent: 05 September 2019 09:43
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] Please review #259: No kind signatures
|  on associated types Shepherd: Simon PJ
|  
|  Dear Committee,
|  
|  this is your secretary speaking:
|  
|  No kind signatures on associated types
|  has been proposed by Richard
|  https://github.com/ghc-proposals/ghc-proposals/pull/259
|  
|  I propose Simon PJ as the shepherd, this seems to be a smaller fix of an
|  existing proposal and Simon has already looked at it.
|  
|  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 at joachim-breitner.de
|    http://www.joachim-breitner.de/
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From mail at joachim-breitner.de  Fri Sep  6 21:41:44 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 06 Sep 2019 23:41:44 +0200
Subject: [ghc-steering-committee] Please review #259: No kind signatures
 on associated types Shepherd: Simon PJ
In-Reply-To: <VI1PR83MB0319EC9179AF085E7293D070ADBA0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
References: <87300980d2b2ea5ee64639cf2bc2d8ebb7c3c2e7.camel@joachim-breitner.de>
 <VI1PR83MB0319EC9179AF085E7293D070ADBA0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
Message-ID: <3975020081432123993a5a4d8921bb3e5cf84cb6.camel@joachim-breitner.de>

Hi,

Am Freitag, den 06.09.2019, 16:42 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> So making them illegal now keeps our options open for the future.

compelling argument, am in favor :-)

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From iavor.diatchki at gmail.com  Fri Sep  6 21:44:09 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 6 Sep 2019 14:44:09 -0700
Subject: [ghc-steering-committee] Please review #259: No kind signatures
 on associated types Shepherd: Simon PJ
In-Reply-To: <3975020081432123993a5a4d8921bb3e5cf84cb6.camel@joachim-breitner.de>
References: <87300980d2b2ea5ee64639cf2bc2d8ebb7c3c2e7.camel@joachim-breitner.de>
 <VI1PR83MB0319EC9179AF085E7293D070ADBA0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
 <3975020081432123993a5a4d8921bb3e5cf84cb6.camel@joachim-breitner.de>
Message-ID: <CAGK9nur4iYZ2daZsiA6DDmZ31jL7EXoOE065DggJe=kuCQM9SQ@mail.gmail.com>

Yeah, seems reasonable to me as well.

On Fri, Sep 6, 2019 at 2:41 PM Joachim Breitner
<mail at joachim-breitner.de> wrote:
>
> Hi,
>
> Am Freitag, den 06.09.2019, 16:42 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
> > So making them illegal now keeps our options open for the future.
>
> compelling argument, am in favor :-)
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From arnaud.spiwack at tweag.io  Mon Sep  9 06:49:23 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 9 Sep 2019 08:49:23 +0200
Subject: [ghc-steering-committee] Please review #259: No kind signatures
 on associated types Shepherd: Simon PJ
In-Reply-To: <CAGK9nur4iYZ2daZsiA6DDmZ31jL7EXoOE065DggJe=kuCQM9SQ@mail.gmail.com>
References: <87300980d2b2ea5ee64639cf2bc2d8ebb7c3c2e7.camel@joachim-breitner.de>
 <VI1PR83MB0319EC9179AF085E7293D070ADBA0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
 <3975020081432123993a5a4d8921bb3e5cf84cb6.camel@joachim-breitner.de>
 <CAGK9nur4iYZ2daZsiA6DDmZ31jL7EXoOE065DggJe=kuCQM9SQ@mail.gmail.com>
Message-ID: <CAH6fHQk5wYbDGNUSBFhxE_Ms1ZK8hpfjrP0bCk4_KEnXpu3FVw@mail.gmail.com>

In my eyes, one of the most important use of type-signatures-for-everything
(apart from a welcome uniformity), is the will to deprecate `*` in favour
of `Type`. That is because, in practice, I always use `*` in CUSKS (of
which I use a lot!), as with `Type`, they would become immensely crowded
and, to me at least, barely readable. In short: to me
type-signatures-for-everything is the one blocker for deprecating `*`.

So let's look at this proposal through the lens of this use-case:

- Associated type declaration are already kind of type signature
assignments.
- Except only partial, as some of the variables will be to the left of the
type families
- But these extra variables are already mentioned in the type class, where
their type can be specified. In particular by a kind signature!

So do I need to write `(Type -> Type) -> Type` near a type variable? No, I
don't.

I guess I'm in favour, then.

On Fri, Sep 6, 2019 at 11:44 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Yeah, seems reasonable to me as well.
>
> On Fri, Sep 6, 2019 at 2:41 PM Joachim Breitner
> <mail at joachim-breitner.de> wrote:
> >
> > Hi,
> >
> > Am Freitag, den 06.09.2019, 16:42 +0000 schrieb Simon Peyton Jones via
> > ghc-steering-committee:
> > > So making them illegal now keeps our options open for the future.
> >
> > compelling argument, am in favor :-)
> >
> > Cheers,
> > Joachim
> > --
> > Joachim Breitner
> >   mail at joachim-breitner.de
> >   http://www.joachim-breitner.de/
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190909/0f605907/attachment.html>

From rae at richarde.dev  Mon Sep  9 09:31:03 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 9 Sep 2019 10:31:03 +0100
Subject: [ghc-steering-committee] Please review #259: No kind signatures
 on associated types Shepherd: Simon PJ
In-Reply-To: <CAH6fHQk5wYbDGNUSBFhxE_Ms1ZK8hpfjrP0bCk4_KEnXpu3FVw@mail.gmail.com>
References: <87300980d2b2ea5ee64639cf2bc2d8ebb7c3c2e7.camel@joachim-breitner.de>
 <VI1PR83MB0319EC9179AF085E7293D070ADBA0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
 <3975020081432123993a5a4d8921bb3e5cf84cb6.camel@joachim-breitner.de>
 <CAGK9nur4iYZ2daZsiA6DDmZ31jL7EXoOE065DggJe=kuCQM9SQ@mail.gmail.com>
 <CAH6fHQk5wYbDGNUSBFhxE_Ms1ZK8hpfjrP0bCk4_KEnXpu3FVw@mail.gmail.com>
Message-ID: <69A78AC4-29F4-48AE-A167-C960A2F5BA65@richarde.dev>



> On Sep 9, 2019, at 7:49 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> - Associated type declaration are already kind of type signature assignments.
> - Except only partial, as some of the variables will be to the left of the type families
> - But these extra variables are already mentioned in the type class, where their type can be specified. In particular by a kind signature!
> 
> So do I need to write `(Type -> Type) -> Type` near a type variable? No, I don't.

Not that I wish to dampen your enthusiasm for the proposal, but I disagree here.

> class C a where
>   type F a (b :: Type -> Type -> Type)

So, while it's true that we don't need all the Type stuff on the class variables, other variables may be included in an associated type and they might need kind signatures.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190909/1e2fa71d/attachment.html>

From arnaud.spiwack at tweag.io  Mon Sep  9 17:02:25 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 9 Sep 2019 19:02:25 +0200
Subject: [ghc-steering-committee] Please review #259: No kind signatures
 on associated types Shepherd: Simon PJ
In-Reply-To: <69A78AC4-29F4-48AE-A167-C960A2F5BA65@richarde.dev>
References: <87300980d2b2ea5ee64639cf2bc2d8ebb7c3c2e7.camel@joachim-breitner.de>
 <VI1PR83MB0319EC9179AF085E7293D070ADBA0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
 <3975020081432123993a5a4d8921bb3e5cf84cb6.camel@joachim-breitner.de>
 <CAGK9nur4iYZ2daZsiA6DDmZ31jL7EXoOE065DggJe=kuCQM9SQ@mail.gmail.com>
 <CAH6fHQk5wYbDGNUSBFhxE_Ms1ZK8hpfjrP0bCk4_KEnXpu3FVw@mail.gmail.com>
 <69A78AC4-29F4-48AE-A167-C960A2F5BA65@richarde.dev>
Message-ID: <CAH6fHQ=kX-V9t6bmhb1GcEyqnk+3eCLHGnytJaEtUm1B82Y5QQ@mail.gmail.com>

I didn't know one could do that. Ah well. Still rare enough a use-case that
I won't complain about this limitation.

On Mon, 9 Sep 2019, 11:31 Richard Eisenberg, <rae at richarde.dev> wrote:

>
>
> On Sep 9, 2019, at 7:49 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> - Associated type declaration are already kind of type signature
> assignments.
> - Except only partial, as some of the variables will be to the left of the
> type families
> - But these extra variables are already mentioned in the type class, where
> their type can be specified. In particular by a kind signature!
>
> So do I need to write `(Type -> Type) -> Type` near a type variable? No, I
> don't.
>
>
> Not that I wish to dampen your enthusiasm for the proposal, but I disagree
> here.
>
> > class C a where
> >   type F a (b :: Type -> Type -> Type)
>
> So, while it's true that we don't need all the Type stuff on the class
> variables, other variables may be included in an associated type and they
> might need kind signatures.
>
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190909/9fd168dc/attachment.html>

From mail at joachim-breitner.de  Sat Sep 14 07:51:31 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 14 Sep 2019 09:51:31 +0200
Subject: [ghc-steering-committee] Early feedback wanted on #243: TH overhaul
 to make it Cross-compile-friendly
Message-ID: <00bc815b4d0e7d9e19dc492f334aa94c0f8a9b0c.camel@joachim-breitner.de>

Dear committee,

there is a rather large proposal sitting in #243. Its goal is to
address our somewhat embarrassing story around Template Haskell and
cross compilation, and as such deserves attention. But it is also a
very big, wide reaching change, even removing some existing features
until we figured out how to do them properly.

In his comment at
https://github.com/ghc-proposals/ghc-proposals/pull/243#issuecomment-531394109
the author (John Ericson) wondered if he could get preliminary feedback
on the proposal: Is this going into a direction that has a chance of
acceptance?

Who in the committee knows enough about TH and (maybe) also cross
compilation to give the proposal in its current form a good read and
give a first assessment?

Thanks,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From mail at joachim-breitner.de  Sat Sep 14 08:07:27 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 14 Sep 2019 10:07:27 +0200
Subject: [ghc-steering-committee] Status
Message-ID: <373165755cda50d0da53a9a0afaa5fbb8e09ee69.camel@joachim-breitner.de>

Dear committee,

nothing creative to say here this month, while I am sitting at
Richard’s breakfast table due to my intra-european jet lag (train
lag?).

Since the last status, we

 * had a partial committee meeting at ICFP, with some suggested
   changes. None of those not there have vetoed (or even commented) them,
   so I guess we should start implementing those that we haven't yet.

 * were asked to review these proposals:
   #160: NoToplevelFieldSelectors (Shepherd: Eric)
   #259: No kind signatures on associated types (Shepherd: Simon PJ)
   
 * have a recommendation form the shepherd about:
   #259: No kind signatures on associated types (rec: accept)
      
 * decided about the following proposals
   #231: #233: Higher-order roles (needs revision)
   #231: Record with syntax (needs revision)
   #160: NoFieldSelectors (accept)
   #229: Simplified parsing of (~) and (!) (accept)


We currently have to act on the following 3 proposals, 3 down
since last time. Good job committee!

No kind signatures on associated types
Shepherd: Simon PJ
Status: acceptance recommended, consensus seems to emerge
https://github.com/ghc-proposals/ghc-proposals/pull/259

Qualified Imports
Shepherd: Simon M.
Status: Waiting for Simon to officially make a recommendation.
https://github.com/ghc-proposals/ghc-proposals/pull/220

Updated partial type signatures
Shepherd: Vitaly
Status: Waiting for Vitaly to make a recommendation.
https://github.com/ghc-proposals/ghc-proposals/pull/194


Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190914/aba4dc68/attachment.sig>

From simonpj at microsoft.com  Sat Sep 14 12:13:54 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sat, 14 Sep 2019 12:13:54 +0000
Subject: [ghc-steering-committee] Please review #259: No kind signatures
 on associated types Shepherd: Simon PJ
In-Reply-To: <VI1PR83MB0319EC9179AF085E7293D070ADBA0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
References: <87300980d2b2ea5ee64639cf2bc2d8ebb7c3c2e7.camel@joachim-breitner.de>
 <VI1PR83MB0319EC9179AF085E7293D070ADBA0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
Message-ID: <VI1PR83MB0319862D773AAEB76B75259EADB20@VI1PR83MB0319.EURPRD83.prod.outlook.com>

Friends

Last call on this one:

| |  No kind signatures on associated types
| |  https://github.com/ghc-proposals/ghc-proposals/pull/259

I have only heard from
	Joachim
	Iavor
	Arnaud
I would love to hear from more of you.

But this particular proposal is a small delta, and if I don't hear any objections I'll declare it accepted on Weds 18 Dept.

Simon

| -----Original Message-----
| From: Simon Peyton Jones
| Sent: 06 September 2019 17:43
| To: Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-
| committee at haskell.org
| Subject: RE: [ghc-steering-committee] Please review #259: No kind
| signatures on associated types Shepherd: Simon PJ
| 
| All,
| 
| I'm the shepherd for
| 
| |  No kind signatures on associated types
| |  https://github.com/ghc-proposals/ghc-proposals/pull/259
| 
| I recommend acceptance.
| 
| The proposal takes the form of an amendment to an earlier accepted
| proposal
|    Standalone kind signatures
|    https://github.com/ghc-proposals/ghc-
| proposals/blob/master/proposals/0054-kind-signatures.rst
| 
| by prohibiting a standalone kind signature for the associated type of a
| class.
| 
| The reason for this narrowing is well described in the "Associated types"
| subsection of the revised proposal.
| 
| The first link above lets you see the baseline proposal, the diff, and the
| new proposal.
| 
| I recommend acceptance because
| - the need for standalone signatures on
|   associated types is weaker (albeit not absent)
| - allowing such a signature closes of one possible
|   future direction
| 
| So making them illegal now keeps our options open for the future.
| 
| Since standalone kind signatures are not yet released, there will be no
| back-compat issues.
| 
| Please express your opinion.  I don't think this one is controversial.
| 
| Simon
| 
| 
| |  -----Original Message-----
| |  From: ghc-steering-committee
| | <ghc-steering-committee-bounces at haskell.org>
| |  On Behalf Of Joachim Breitner
| |  Sent: 05 September 2019 09:43
| |  To: ghc-steering-committee at haskell.org
| |  Subject: [ghc-steering-committee] Please review #259: No kind
| | signatures  on associated types Shepherd: Simon PJ
| |
| |  Dear Committee,
| |
| |  this is your secretary speaking:
| |
| |  No kind signatures on associated types  has been proposed by Richard
| |  https://github.com/ghc-proposals/ghc-proposals/pull/259
| |
| |  I propose Simon PJ as the shepherd, this seems to be a smaller fix of
| | an  existing proposal and Simon has already looked at it.
| |
| |  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 at joachim-breitner.de
| |    http://www.joachim-breitner.de/
| |
| |  _______________________________________________
| |  ghc-steering-committee mailing list
| |  ghc-steering-committee at haskell.org
| |
| | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ
| | ee

From marlowsd at gmail.com  Mon Sep 16 07:23:20 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 16 Sep 2019 08:23:20 +0100
Subject: [ghc-steering-committee] Please review #220: QualifiedImports,
 Shepherd: Simon M
In-Reply-To: <CANsrgPKUULLOmFCwvXG=U2Yf+NV-0uLjn6n1ZHY=TfvE6KwXSw@mail.gmail.com>
References: <ada52b5e529a8d52e6f5f1f070e8aa2dfa2a5a62.camel@joachim-breitner.de>
 <CANsrgPKUULLOmFCwvXG=U2Yf+NV-0uLjn6n1ZHY=TfvE6KwXSw@mail.gmail.com>
Message-ID: <CANsrgP+3JaOnTqRVbKL2FuAwjcAXc0ipHE_0uUpRcFXJ=GFAhw@mail.gmail.com>

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-531666589

Any further comments before we close it?

Thanks
Simon

On Fri, 5 Jul 2019 at 08:19, Simon Marlow <marlowsd at 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-508414602
>
> 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 <mail at 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-default-qualified-import.rst
>>
>> 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 at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190916/d4638591/attachment.html>

From sandy at sandymaguire.me  Mon Sep 16 12:04:22 2019
From: sandy at sandymaguire.me (Sandy Maguire)
Date: Mon, 16 Sep 2019 14:04:22 +0200
Subject: [ghc-steering-committee] Please review #220: QualifiedImports,
 Shepherd: Simon M
In-Reply-To: <CANsrgP+3JaOnTqRVbKL2FuAwjcAXc0ipHE_0uUpRcFXJ=GFAhw@mail.gmail.com>
References: <ada52b5e529a8d52e6f5f1f070e8aa2dfa2a5a62.camel@joachim-breitner.de>
 <CANsrgPKUULLOmFCwvXG=U2Yf+NV-0uLjn6n1ZHY=TfvE6KwXSw@mail.gmail.com>
 <CANsrgP+3JaOnTqRVbKL2FuAwjcAXc0ipHE_0uUpRcFXJ=GFAhw@mail.gmail.com>
Message-ID: <CADRtjwaxVGXD_JeZzGEQ5L1=TnGONTQ3UC3rrh=XCbfxRUKc4Q@mail.gmail.com>

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 <marlowsd at 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-531666589
>
> Any further comments before we close it?
>
> Thanks
> Simon
>
> On Fri, 5 Jul 2019 at 08:19, Simon Marlow <marlowsd at 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-508414602
>>
>> 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 <mail at 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-default-qualified-import.rst
>>>
>>> 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 at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190916/9c6ada37/attachment.html>

From arnaud.spiwack at tweag.io  Tue Sep 17 06:52:24 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 17 Sep 2019 08:52:24 +0200
Subject: [ghc-steering-committee] Please review #220: QualifiedImports,
 Shepherd: Simon M
In-Reply-To: <CADRtjwaxVGXD_JeZzGEQ5L1=TnGONTQ3UC3rrh=XCbfxRUKc4Q@mail.gmail.com>
References: <ada52b5e529a8d52e6f5f1f070e8aa2dfa2a5a62.camel@joachim-breitner.de>
 <CANsrgPKUULLOmFCwvXG=U2Yf+NV-0uLjn6n1ZHY=TfvE6KwXSw@mail.gmail.com>
 <CANsrgP+3JaOnTqRVbKL2FuAwjcAXc0ipHE_0uUpRcFXJ=GFAhw@mail.gmail.com>
 <CADRtjwaxVGXD_JeZzGEQ5L1=TnGONTQ3UC3rrh=XCbfxRUKc4Q@mail.gmail.com>
Message-ID: <CAH6fHQ=XYFuaq+xTYUWdUB067jAhZXxja_prKUuWOOYFwJFzGQ@mail.gmail.com>

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 <sandy at 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 <marlowsd at 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-531666589
>>
>> Any further comments before we close it?
>>
>> Thanks
>> Simon
>>
>> On Fri, 5 Jul 2019 at 08:19, Simon Marlow <marlowsd at 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-508414602
>>>
>>> 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 <mail at 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-default-qualified-import.rst
>>>>
>>>> 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 at joachim-breitner.de
>>>>   http://www.joachim-breitner.de/
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190917/762495c1/attachment.html>

From marlowsd at gmail.com  Tue Sep 17 08:06:53 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 17 Sep 2019 09:06:53 +0100
Subject: [ghc-steering-committee] Please review #220: QualifiedImports,
 Shepherd: Simon M
In-Reply-To: <CAH6fHQ=XYFuaq+xTYUWdUB067jAhZXxja_prKUuWOOYFwJFzGQ@mail.gmail.com>
References: <ada52b5e529a8d52e6f5f1f070e8aa2dfa2a5a62.camel@joachim-breitner.de>
 <CANsrgPKUULLOmFCwvXG=U2Yf+NV-0uLjn6n1ZHY=TfvE6KwXSw@mail.gmail.com>
 <CANsrgP+3JaOnTqRVbKL2FuAwjcAXc0ipHE_0uUpRcFXJ=GFAhw@mail.gmail.com>
 <CADRtjwaxVGXD_JeZzGEQ5L1=TnGONTQ3UC3rrh=XCbfxRUKc4Q@mail.gmail.com>
 <CAH6fHQ=XYFuaq+xTYUWdUB067jAhZXxja_prKUuWOOYFwJFzGQ@mail.gmail.com>
Message-ID: <CANsrgPKxFTrz22-WZwdib=sHf1LpyhuHO=WD7V_A0Ndv1peWhg@mail.gmail.com>

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 <arnaud.spiwack at 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 <sandy at 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 <marlowsd at 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-531666589
>>>
>>> Any further comments before we close it?
>>>
>>> Thanks
>>> Simon
>>>
>>> On Fri, 5 Jul 2019 at 08:19, Simon Marlow <marlowsd at 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-508414602
>>>>
>>>> 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 <mail at 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-default-qualified-import.rst
>>>>>
>>>>> 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 at joachim-breitner.de
>>>>>   http://www.joachim-breitner.de/
>>>>>
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at 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 at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190917/011524ea/attachment-0001.html>

From rae at richarde.dev  Tue Sep 17 21:03:49 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 17 Sep 2019 22:03:49 +0100
Subject: [ghc-steering-committee] Please review #220: QualifiedImports,
 Shepherd: Simon M
In-Reply-To: <CAH6fHQ=XYFuaq+xTYUWdUB067jAhZXxja_prKUuWOOYFwJFzGQ@mail.gmail.com>
References: <ada52b5e529a8d52e6f5f1f070e8aa2dfa2a5a62.camel@joachim-breitner.de>
 <CANsrgPKUULLOmFCwvXG=U2Yf+NV-0uLjn6n1ZHY=TfvE6KwXSw@mail.gmail.com>
 <CANsrgP+3JaOnTqRVbKL2FuAwjcAXc0ipHE_0uUpRcFXJ=GFAhw@mail.gmail.com>
 <CADRtjwaxVGXD_JeZzGEQ5L1=TnGONTQ3UC3rrh=XCbfxRUKc4Q@mail.gmail.com>
 <CAH6fHQ=XYFuaq+xTYUWdUB067jAhZXxja_prKUuWOOYFwJFzGQ@mail.gmail.com>
Message-ID: <44ACEFDD-068B-4D4F-A6BB-308C9688ADC2@richarde.dev>

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 <arnaud.spiwack at 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 <sandy at sandymaguire.me <mailto:sandy at 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 <marlowsd at gmail.com <mailto:marlowsd at 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-531666589 <https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-531666589>
> 
> Any further comments before we close it?
> 
> Thanks
> Simon
> 
> On Fri, 5 Jul 2019 at 08:19, Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at 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-508414602 <https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-508414602>
> 
> 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 <mail at joachim-breitner.de <mailto:mail at 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/ghc-proposals/ghc-proposals/pull/220>
> https://github.com/tweag/ghc-proposals/blob/qualified-import/proposals/0000-default-qualified-import.rst <https://github.com/tweag/ghc-proposals/blob/qualified-import/proposals/0000-default-qualified-import.rst>
> 
> I propose Simon M as the 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>
> 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 at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/ <https://isovector.github.io/erdos/>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190917/e5c7521e/attachment.html>

From simonpj at microsoft.com  Tue Sep 17 22:56:22 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 17 Sep 2019 22:56:22 +0000
Subject: [ghc-steering-committee] Please review #220: QualifiedImports,
 Shepherd: Simon M
In-Reply-To: <44ACEFDD-068B-4D4F-A6BB-308C9688ADC2@richarde.dev>
References: <ada52b5e529a8d52e6f5f1f070e8aa2dfa2a5a62.camel@joachim-breitner.de>
 <CANsrgPKUULLOmFCwvXG=U2Yf+NV-0uLjn6n1ZHY=TfvE6KwXSw@mail.gmail.com>
 <CANsrgP+3JaOnTqRVbKL2FuAwjcAXc0ipHE_0uUpRcFXJ=GFAhw@mail.gmail.com>
 <CADRtjwaxVGXD_JeZzGEQ5L1=TnGONTQ3UC3rrh=XCbfxRUKc4Q@mail.gmail.com>
 <CAH6fHQ=XYFuaq+xTYUWdUB067jAhZXxja_prKUuWOOYFwJFzGQ@mail.gmail.com>
 <44ACEFDD-068B-4D4F-A6BB-308C9688ADC2@richarde.dev>
Message-ID: <VI1PR83MB03198048C217A58E4D240C8EAD8F0@VI1PR83MB0319.EURPRD83.prod.outlook.com>

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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 17 September 2019 22:04
To: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>; Sandy Maguire <sandy at sandymaguire.me>
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 <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at 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 <sandy at sandymaguire.me<mailto:sandy at 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 <marlowsd at gmail.com<mailto:marlowsd at 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-531666589

Any further comments before we close it?

Thanks
Simon

On Fri, 5 Jul 2019 at 08:19, Simon Marlow <marlowsd at gmail.com<mailto:marlowsd at 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-508414602

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 <mail at joachim-breitner.de<mailto:mail at 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-default-qualified-import.rst

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 at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190917/24186ea4/attachment-0001.html>

From marlowsd at gmail.com  Thu Sep 19 18:02:55 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 19 Sep 2019 19:02:55 +0100
Subject: [ghc-steering-committee] Please review #220: QualifiedImports,
 Shepherd: Simon M
In-Reply-To: <VI1PR83MB03198048C217A58E4D240C8EAD8F0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
References: <ada52b5e529a8d52e6f5f1f070e8aa2dfa2a5a62.camel@joachim-breitner.de>
 <CANsrgPKUULLOmFCwvXG=U2Yf+NV-0uLjn6n1ZHY=TfvE6KwXSw@mail.gmail.com>
 <CANsrgP+3JaOnTqRVbKL2FuAwjcAXc0ipHE_0uUpRcFXJ=GFAhw@mail.gmail.com>
 <CADRtjwaxVGXD_JeZzGEQ5L1=TnGONTQ3UC3rrh=XCbfxRUKc4Q@mail.gmail.com>
 <CAH6fHQ=XYFuaq+xTYUWdUB067jAhZXxja_prKUuWOOYFwJFzGQ@mail.gmail.com>
 <44ACEFDD-068B-4D4F-A6BB-308C9688ADC2@richarde.dev>
 <VI1PR83MB03198048C217A58E4D240C8EAD8F0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgPK58xLWdoBtakDkhO1HfxH+YjTFNQ_-P7_W-ud-e1uaOw@mail.gmail.com>

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
<ghc-steering-committee at haskell.org> 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 <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Richard Eisenberg
> *Sent:* 17 September 2019 22:04
> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>; Sandy Maguire <sandy at sandymaguire.me>
> *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 <arnaud.spiwack at 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 <sandy at 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 <marlowsd at 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-531666589
>
>
>
> Any further comments before we close it?
>
>
>
> Thanks
>
> Simon
>
>
>
> On Fri, 5 Jul 2019 at 08:19, Simon Marlow <marlowsd at 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-508414602
>
>
>
> 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 <mail at 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-default-qualified-import.rst
>
> 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190919/8d9f7fca/attachment.html>

From iavor.diatchki at gmail.com  Thu Sep 19 18:28:39 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 19 Sep 2019 11:28:39 -0700
Subject: [ghc-steering-committee] Please review #220: QualifiedImports,
 Shepherd: Simon M
In-Reply-To: <CANsrgPK58xLWdoBtakDkhO1HfxH+YjTFNQ_-P7_W-ud-e1uaOw@mail.gmail.com>
References: <ada52b5e529a8d52e6f5f1f070e8aa2dfa2a5a62.camel@joachim-breitner.de>
 <CANsrgPKUULLOmFCwvXG=U2Yf+NV-0uLjn6n1ZHY=TfvE6KwXSw@mail.gmail.com>
 <CANsrgP+3JaOnTqRVbKL2FuAwjcAXc0ipHE_0uUpRcFXJ=GFAhw@mail.gmail.com>
 <CADRtjwaxVGXD_JeZzGEQ5L1=TnGONTQ3UC3rrh=XCbfxRUKc4Q@mail.gmail.com>
 <CAH6fHQ=XYFuaq+xTYUWdUB067jAhZXxja_prKUuWOOYFwJFzGQ@mail.gmail.com>
 <44ACEFDD-068B-4D4F-A6BB-308C9688ADC2@richarde.dev>
 <VI1PR83MB03198048C217A58E4D240C8EAD8F0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
 <CANsrgPK58xLWdoBtakDkhO1HfxH+YjTFNQ_-P7_W-ud-e1uaOw@mail.gmail.com>
Message-ID: <CAGK9nuoNv1KmpcKbDW1aS6vPAkdgERYihRG7eoEbvJ5srM5pBg@mail.gmail.com>

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 <marlowsd at gmail.com> 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 <ghc-steering-committee at haskell.org> 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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
>> Sent: 17 September 2019 22:04
>> To: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>; Sandy Maguire <sandy at sandymaguire.me>
>> 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 <arnaud.spiwack at 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 <sandy at 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 <marlowsd at 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-531666589
>>
>>
>>
>> Any further comments before we close it?
>>
>>
>>
>> Thanks
>>
>> Simon
>>
>>
>>
>> On Fri, 5 Jul 2019 at 08:19, Simon Marlow <marlowsd at 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-508414602
>>
>>
>>
>> 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 <mail at 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-default-qualified-import.rst
>>
>> 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 at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at 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 at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From simonpj at microsoft.com  Thu Sep 19 21:02:17 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 19 Sep 2019 21:02:17 +0000
Subject: [ghc-steering-committee] Please review #220: QualifiedImports,
 Shepherd: Simon M
In-Reply-To: <CANsrgPK58xLWdoBtakDkhO1HfxH+YjTFNQ_-P7_W-ud-e1uaOw@mail.gmail.com>
References: <ada52b5e529a8d52e6f5f1f070e8aa2dfa2a5a62.camel@joachim-breitner.de>
 <CANsrgPKUULLOmFCwvXG=U2Yf+NV-0uLjn6n1ZHY=TfvE6KwXSw@mail.gmail.com>
 <CANsrgP+3JaOnTqRVbKL2FuAwjcAXc0ipHE_0uUpRcFXJ=GFAhw@mail.gmail.com>
 <CADRtjwaxVGXD_JeZzGEQ5L1=TnGONTQ3UC3rrh=XCbfxRUKc4Q@mail.gmail.com>
 <CAH6fHQ=XYFuaq+xTYUWdUB067jAhZXxja_prKUuWOOYFwJFzGQ@mail.gmail.com>
 <44ACEFDD-068B-4D4F-A6BB-308C9688ADC2@richarde.dev>
 <VI1PR83MB03198048C217A58E4D240C8EAD8F0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
 <CANsrgPK58xLWdoBtakDkhO1HfxH+YjTFNQ_-P7_W-ud-e1uaOw@mail.gmail.com>
Message-ID: <VI1PR83MB0319D45C197A6D7296A5B6B0AD890@VI1PR83MB0319.EURPRD83.prod.outlook.com>

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.

Simon

From: Simon Marlow <marlowsd at gmail.com>
Sent: 19 September 2019 19:03
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Richard Eisenberg <rae at richarde.dev>; Spiwack, Arnaud <arnaud.spiwack at tweag.io>; ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>; Sandy Maguire <sandy at sandymaguire.me>
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 <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> 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 <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Richard Eisenberg
Sent: 17 September 2019 22:04
To: Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>; Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>; Sandy Maguire <sandy at sandymaguire.me<mailto:sandy at sandymaguire.me>>
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 <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at 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 <sandy at sandymaguire.me<mailto:sandy at 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 <marlowsd at gmail.com<mailto:marlowsd at 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-531666589<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 <marlowsd at gmail.com<mailto:marlowsd at 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-508414602<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 <mail at joachim-breitner.de<mailto:mail at 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://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-default-qualified-import.rst<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 at joachim-breitner.de<mailto:mail at 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 at haskell.org<mailto:ghc-steering-committee at 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 at haskell.org<mailto:ghc-steering-committee at 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 at haskell.org<mailto:ghc-steering-committee at 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 at haskell.org<mailto:ghc-steering-committee at 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 at haskell.org<mailto:ghc-steering-committee at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190919/35226ab1/attachment-0001.html>

From mail at joachim-breitner.de  Fri Sep 20 13:43:50 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 20 Sep 2019 15:43:50 +0200
Subject: [ghc-steering-committee] Please review #274: Quick Look
	Impredicativity Shepherd: Arnaud
Message-ID: <c1db6bd819302338df08cfa6b6db34dfb7ad7d99.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Quick Look Impredicativity
has been proposed by Alejandro Serrano
https://github.com/ghc-proposals/ghc-proposals/pull/274

I propose Arnaud as the shepherd, as he whined about not having
anything to shepherd when I met him on Wednesday ;-)

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 at joachim-breitner.de
  http://www.joachim-breitner.de/


From mail at joachim-breitner.de  Fri Sep 20 14:01:18 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 20 Sep 2019 16:01:18 +0200
Subject: [ghc-steering-committee] Please review #277: winapi calling
 convention Shepherd: Sandy
Message-ID: <198a01e3f516cfc1cc0a7fb5ed382bf72ce7b69d.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

winapi pseudo calling convention
has been proposed by Tamar Christina
https://github.com/ghc-proposals/ghc-proposals/pull/277

I propose Sandy Maguire as the shepherd. (I had a hard time guessing
who of the current idle members have expertise about FFI, so this is
rather arbitrary.)

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 at joachim-breitner.de
  http://www.joachim-breitner.de/


From sandy at sandymaguire.me  Sun Sep 22 06:44:19 2019
From: sandy at sandymaguire.me (Sandy Maguire)
Date: Sun, 22 Sep 2019 08:44:19 +0200
Subject: [ghc-steering-committee] Winapi pseudo calling conv (#277) ---
	recommendation: accept
Message-ID: <CADRtjwYOQuAW06xzUw=97dcMD7Z67rxSkvthNgFD1=9EPRNDCw@mail.gmail.com>

Hi all,

Proposal 277 is on the topic of a psuedo calling convention for windows,
where on x86 you need to use `stdcall`, but on x86_64 it should be `ccall`.
The base and Win32 packages both use extensive amounts of CPP to work
around this.

This proposal is to add a `winapi` calling convention that does the right
thing regardless of the platform architecture.

With the caveat that I am not well versed in FFI or Windows, *my
recommendation is to accept. *This is a very small proposal that can
immediately be used to clean up over 650 CPP invocations throughout the
ecosystem. It's clearly a problem that people are running into, and we
should focus on easy quality of life improvements.

As usual, silence will be considered assent!

Best,
Sandy

-- 
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190922/a247704b/attachment.html>

From sandy at sandymaguire.me  Sun Sep 22 06:44:53 2019
From: sandy at sandymaguire.me (Sandy Maguire)
Date: Sun, 22 Sep 2019 08:44:53 +0200
Subject: [ghc-steering-committee] Winapi pseudo calling conv (#277) ---
	recommendation: accept
In-Reply-To: <CADRtjwYOQuAW06xzUw=97dcMD7Z67rxSkvthNgFD1=9EPRNDCw@mail.gmail.com>
References: <CADRtjwYOQuAW06xzUw=97dcMD7Z67rxSkvthNgFD1=9EPRNDCw@mail.gmail.com>
Message-ID: <CADRtjwa=pZrrmni1Z=qQUWu7kdMYD7ujBy4GKvv41e+iWCJwsg@mail.gmail.com>

Link to the proposal:
https://github.com/ghc-proposals/ghc-proposals/pull/277

On Sun, Sep 22, 2019 at 8:44 AM Sandy Maguire <sandy at sandymaguire.me> wrote:

> Hi all,
>
> Proposal 277 is on the topic of a psuedo calling convention for windows,
> where on x86 you need to use `stdcall`, but on x86_64 it should be `ccall`.
> The base and Win32 packages both use extensive amounts of CPP to work
> around this.
>
> This proposal is to add a `winapi` calling convention that does the right
> thing regardless of the platform architecture.
>
> With the caveat that I am not well versed in FFI or Windows, *my
> recommendation is to accept. *This is a very small proposal that can
> immediately be used to clean up over 650 CPP invocations throughout the
> ecosystem. It's clearly a problem that people are running into, and we
> should focus on easy quality of life improvements.
>
> As usual, silence will be considered assent!
>
> Best,
> Sandy
>
> --
> 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/
>


-- 
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190922/5f01868f/attachment.html>

From marlowsd at gmail.com  Mon Sep 23 07:05:48 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 23 Sep 2019 08:05:48 +0100
Subject: [ghc-steering-committee] Winapi pseudo calling conv (#277) ---
 recommendation: accept
In-Reply-To: <CADRtjwYOQuAW06xzUw=97dcMD7Z67rxSkvthNgFD1=9EPRNDCw@mail.gmail.com>
References: <CADRtjwYOQuAW06xzUw=97dcMD7Z67rxSkvthNgFD1=9EPRNDCw@mail.gmail.com>
Message-ID: <CANsrgPKv3adtnRTrwbiTBmfXULz7ev_dxwDjSyCqo_VPYPzg+Q@mail.gmail.com>

Sounds good to me.

Cheers
Simon

On Sun, 22 Sep 2019 at 07:44, Sandy Maguire <sandy at sandymaguire.me> wrote:

> Hi all,
>
> Proposal 277 is on the topic of a psuedo calling convention for windows,
> where on x86 you need to use `stdcall`, but on x86_64 it should be `ccall`.
> The base and Win32 packages both use extensive amounts of CPP to work
> around this.
>
> This proposal is to add a `winapi` calling convention that does the right
> thing regardless of the platform architecture.
>
> With the caveat that I am not well versed in FFI or Windows, *my
> recommendation is to accept. *This is a very small proposal that can
> immediately be used to clean up over 650 CPP invocations throughout the
> ecosystem. It's clearly a problem that people are running into, and we
> should focus on easy quality of life improvements.
>
> As usual, silence will be considered assent!
>
> Best,
> Sandy
>
> --
> 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190923/a97ed86d/attachment.html>

From marlowsd at gmail.com  Fri Sep 20 09:06:48 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 20 Sep 2019 10:06:48 +0100
Subject: [ghc-steering-committee] Please review #220: QualifiedImports,
 Shepherd: Simon M
In-Reply-To: <VI1PR83MB0319D45C197A6D7296A5B6B0AD890@VI1PR83MB0319.EURPRD83.prod.outlook.com>
References: <ada52b5e529a8d52e6f5f1f070e8aa2dfa2a5a62.camel@joachim-breitner.de>
 <CANsrgPKUULLOmFCwvXG=U2Yf+NV-0uLjn6n1ZHY=TfvE6KwXSw@mail.gmail.com>
 <CANsrgP+3JaOnTqRVbKL2FuAwjcAXc0ipHE_0uUpRcFXJ=GFAhw@mail.gmail.com>
 <CADRtjwaxVGXD_JeZzGEQ5L1=TnGONTQ3UC3rrh=XCbfxRUKc4Q@mail.gmail.com>
 <CAH6fHQ=XYFuaq+xTYUWdUB067jAhZXxja_prKUuWOOYFwJFzGQ@mail.gmail.com>
 <44ACEFDD-068B-4D4F-A6BB-308C9688ADC2@richarde.dev>
 <VI1PR83MB03198048C217A58E4D240C8EAD8F0@VI1PR83MB0319.EURPRD83.prod.outlook.com>
 <CANsrgPK58xLWdoBtakDkhO1HfxH+YjTFNQ_-P7_W-ud-e1uaOw@mail.gmail.com>
 <VI1PR83MB0319D45C197A6D7296A5B6B0AD890@VI1PR83MB0319.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgPLVd58bdjW8OTznTKvw9eKoCQNzt1181=RwzZeOPcDyZQ@mail.gmail.com>

On Thu, 19 Sep 2019 at 22:02, Simon Peyton Jones <simonpj at microsoft.com>
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 <marlowsd at gmail.com>
> *Sent:* 19 September 2019 19:03
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Richard Eisenberg <rae at richarde.dev>; Spiwack, Arnaud <
> arnaud.spiwack at tweag.io>; ghc-steering-committee at haskell.org; Joachim
> Breitner <mail at joachim-breitner.de>; Sandy Maguire <sandy at sandymaguire.me>
> *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 <ghc-steering-committee at haskell.org> 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 <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Richard Eisenberg
> *Sent:* 17 September 2019 22:04
> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>; Sandy Maguire <sandy at sandymaguire.me>
> *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 <arnaud.spiwack at 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 <sandy at 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 <marlowsd at 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-531666589
> <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 <marlowsd at 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-508414602
> <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 <mail at 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://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-default-qualified-import.rst
> <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 at 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 at 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 at 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 at 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 at 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 at 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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190920/6e1d94a1/attachment-0001.html>

From mail at joachim-breitner.de  Wed Sep 25 14:56:36 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 25 Sep 2019 16:56:36 +0200
Subject: [ghc-steering-committee] Please review #270: Add Unified Namespace
 Shepherd: Iavor
Message-ID: <6d028229e63fa8891f20c97e186dfe895613eeb7.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Add Unified Namespace
has been proposed by Artyom Kuznetsov  
https://github.com/ghc-proposals/ghc-proposals/pull/270
https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-unified-namespace.md

I propose Iavor as the shepherd. (I was tempted to pick Richard, as
this has presumably positive interactions with Dependent Haskell, but
in a way it is a competitor to Richards’ #214.)

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 at joachim-breitner.de
  http://www.joachim-breitner.de/