From sandy at sandymaguire.me  Wed Oct  2 14:57:38 2019
From: sandy at sandymaguire.me (Sandy Maguire)
Date: Wed, 2 Oct 2019 16:57:38 +0200
Subject: [ghc-steering-committee] Winapi pseudo calling conv (#277) ---
 recommendation: accept
In-Reply-To: <CANsrgPKv3adtnRTrwbiTBmfXULz7ev_dxwDjSyCqo_VPYPzg+Q@mail.gmail.com>
References: <CADRtjwYOQuAW06xzUw=97dcMD7Z67rxSkvthNgFD1=9EPRNDCw@mail.gmail.com>
 <CANsrgPKv3adtnRTrwbiTBmfXULz7ev_dxwDjSyCqo_VPYPzg+Q@mail.gmail.com>
Message-ID: <CADRtjwZEsNBBure+nCr=e2UN70OsSTq1cxU0eHv-HXZa_LyMGQ@mail.gmail.com>

We've now marked this as accepted. Thanks all!

On Mon, Sep 23, 2019 at 9:06 AM Simon Marlow <marlowsd at gmail.com> wrote:

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

-- 
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/20191002/b3a0431c/attachment.html>

From arnaud.spiwack at tweag.io  Mon Oct 14 06:53:34 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 14 Oct 2019 08:53:34 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Quick_look_impredicativity_=28?=
	=?utf-8?q?=23274=29_=E2=80=94_recommendation=3A_accept?=
Message-ID: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>

Dear all,

As the title implies: I'm hereby recommending accepting the Quick look
impredicativity proposal.

Summary:

The proposal modifies the `-XImpredicativeTypes` extension with a well
defined semantics which consists in considering n-ary applications, rather
than binary. And look, in such an application, for arguments which
absolutely require impredicative instantiation (either universally
quantified type applications, or arguments where a universal type is
guarded by an invariant type constructor).

In order to have the expected behaviour for `($)` and `(.)`, the proposal
also makes the left-hand argument of the arrow invariant with respect to
instantiation (currently: contravariant). The proposal is to make this
change effective, even if `-XRankNTypes` is turned on, but not
`-XImpredicativeTypes`. The proposal also introduces an extension
`-XContravariantFunctions` to restore the old behaviour, for compatibility.

Rational:

`-XImpredicativeTypes` is a useful extension which is currently in a rather
sad state. I'm happy to see it stabilise to a clear semantics. The
semantics in the proposal covers a ton of use cases. It strikes a very good
balance between usefulness and predictability.

The use of n-ary application in the type system also has good theoretical
roots: sequent calculi have n-ary applications. (in manyrespects,
bidirectional type systems are also about n-ary application). So I don't
consider it a wart at all.

The propsal's semantics, including the absence of contravariant functions,
goes in the direction of _guessing less things_. This is a direction that
many GHC features have taken lately. I think it's a very very good
direction! Guessing can be damaging for predictability, but. more
importantly, guessing has a tendency to compose badly with other typing
features. (it is to be noted, too, that the implementation of contravariant
functions. in GHC, eta-expands the function, which can casually change its
semantics, if the function was bottom).

So, everything in this proposal does look good to me, except that, I think,
I would like a deprecation route for the `-XContravariantFunctions`
extension. Otherwise, we will be stuck with legacy code forever.

Best,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191014/7ca62e31/attachment.html>

From mail at joachim-breitner.de  Mon Oct 14 07:34:51 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 14 Oct 2019 09:34:51 +0200
Subject: [ghc-steering-committee] Please review #254: Scale back "Function
 Result Type Signatures" Shepherd: SPJ
Message-ID: <26334dda17346630ad592c9ebc185bd1ab992fd8.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Scale back "Function Result Type Signatures" to keep pattern sigs as-is
has been proposed by John Ericson
https://github.com/ghc-proposals/ghc-proposals/pull/254


This proposal amends #228, so I propose Simon PJ as the shepherd,
because he also shepherded #228.

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  Mon Oct 14 09:42:45 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 14 Oct 2019 10:42:45 +0100
Subject: [ghc-steering-committee]
 =?utf-8?q?Quick_look_impredicativity_=28?=
 =?utf-8?q?=23274=29_=E2=80=94_recommendation=3A_accept?=
In-Reply-To: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
References: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
Message-ID: <BD006B61-272D-4FD4-807D-F754A3020018@richarde.dev>

I'm in support.

Thanks for the nice summary.

Richard

> On Oct 14, 2019, at 7:53 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> Dear all,
> 
> As the title implies: I'm hereby recommending accepting the Quick look impredicativity proposal.
> 
> Summary:
> 
> The proposal modifies the `-XImpredicativeTypes` extension with a well defined semantics which consists in considering n-ary applications, rather than binary. And look, in such an application, for arguments which absolutely require impredicative instantiation (either universally quantified type applications, or arguments where a universal type is guarded by an invariant type constructor).
> 
> In order to have the expected behaviour for `($)` and `(.)`, the proposal also makes the left-hand argument of the arrow invariant with respect to instantiation (currently: contravariant). The proposal is to make this change effective, even if `-XRankNTypes` is turned on, but not `-XImpredicativeTypes`. The proposal also introduces an extension `-XContravariantFunctions` to restore the old behaviour, for compatibility.
> 
> Rational:
> 
> `-XImpredicativeTypes` is a useful extension which is currently in a rather sad state. I'm happy to see it stabilise to a clear semantics. The semantics in the proposal covers a ton of use cases. It strikes a very good balance between usefulness and predictability.
> 
> The use of n-ary application in the type system also has good theoretical roots: sequent calculi have n-ary applications. (in manyrespects, bidirectional type systems are also about n-ary application). So I don't consider it a wart at all.
> 
> The propsal's semantics, including the absence of contravariant functions, goes in the direction of _guessing less things_. This is a direction that many GHC features have taken lately. I think it's a very very good direction! Guessing can be damaging for predictability, but. more importantly, guessing has a tendency to compose badly with other typing features. (it is to be noted, too, that the implementation of contravariant functions. in GHC, eta-expands the function, which can casually change its semantics, if the function was bottom).
> 
> So, everything in this proposal does look good to me, except that, I think, I would like a deprecation route for the `-XContravariantFunctions` extension. Otherwise, we will be stuck with legacy code forever.
> 
> Best,
> Arnaud
> _______________________________________________
> 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  Mon Oct 14 11:37:52 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Oct 2019 11:37:52 +0000
Subject: [ghc-steering-committee]
 =?utf-8?q?Quick_look_impredicativity_=28?=
 =?utf-8?q?=23274=29_=E2=80=94_recommendation=3A_accept?=
In-Reply-To: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
References: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
Message-ID: <AM6PR83MB02793DAC19792DB852782621AD900@AM6PR83MB0279.EURPRD83.prod.outlook.com>

I strongly support acceptance.   I think is a genuine step forward, specifically because it has such a nice, small, modular, and (critically) non-invasive implementation.  And we already have that implementation, so it’s not just an aspirational claim.

Moreover, precisely because the implementation is so simple, the explanation to the user can be correspondingly simple.

I’ve been trying to get here for well over a decade, and now I feel that we have finally landed.   Hooray.

Declaration of interest: I’m part of the team that developed the idea.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
Sent: 14 October 2019 07:54
To: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: [ghc-steering-committee] Quick look impredicativity (#274) — recommendation: accept

Dear all,

As the title implies: I'm hereby recommending accepting the Quick look impredicativity proposal.

Summary:

The proposal modifies the `-XImpredicativeTypes` extension with a well defined semantics which consists in considering n-ary applications, rather than binary. And look, in such an application, for arguments which absolutely require impredicative instantiation (either universally quantified type applications, or arguments where a universal type is guarded by an invariant type constructor).

In order to have the expected behaviour for `($)` and `(.)`, the proposal also makes the left-hand argument of the arrow invariant with respect to instantiation (currently: contravariant). The proposal is to make this change effective, even if `-XRankNTypes` is turned on, but not `-XImpredicativeTypes`. The proposal also introduces an extension `-XContravariantFunctions` to restore the old behaviour, for compatibility.

Rational:

`-XImpredicativeTypes` is a useful extension which is currently in a rather sad state. I'm happy to see it stabilise to a clear semantics. The semantics in the proposal covers a ton of use cases. It strikes a very good balance between usefulness and predictability.

The use of n-ary application in the type system also has good theoretical roots: sequent calculi have n-ary applications. (in manyrespects, bidirectional type systems are also about n-ary application). So I don't consider it a wart at all.

The propsal's semantics, including the absence of contravariant functions, goes in the direction of _guessing less things_. This is a direction that many GHC features have taken lately. I think it's a very very good direction! Guessing can be damaging for predictability, but. more importantly, guessing has a tendency to compose badly with other typing features. (it is to be noted, too, that the implementation of contravariant functions. in GHC, eta-expands the function, which can casually change its semantics, if the function was bottom).

So, everything in this proposal does look good to me, except that, I think, I would like a deprecation route for the `-XContravariantFunctions` extension. Otherwise, we will be stuck with legacy code forever.

Best,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191014/fc2aeabd/attachment-0001.html>

From eric at seidel.io  Tue Oct 15 00:51:46 2019
From: eric at seidel.io (Eric Seidel)
Date: Mon, 14 Oct 2019 20:51:46 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Quick_look_impredicativity_=28?=
 =?utf-8?q?=23274=29_=E2=80=94_recommendation=3A_accept?=
In-Reply-To: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
References: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
Message-ID: <68e54ee1-df78-4860-948a-f069aebd3293@www.fastmail.com>

I support acceptance too, modulo a few small comments that I left on the GH discussion.

On Mon, Oct 14, 2019, at 02:53, Spiwack, Arnaud wrote:
> Dear all,
> 
> As the title implies: I'm hereby recommending accepting the Quick look 
> impredicativity proposal.
> 
> Summary:
> 
> The proposal modifies the `-XImpredicativeTypes` extension with a well 
> defined semantics which consists in considering n-ary applications, 
> rather than binary. And look, in such an application, for arguments 
> which absolutely require impredicative instantiation (either 
> universally quantified type applications, or arguments where a 
> universal type is guarded by an invariant type constructor).
> 
> In order to have the expected behaviour for `($)` and `(.)`, the 
> proposal also makes the left-hand argument of the arrow invariant with 
> respect to instantiation (currently: contravariant). The proposal is to 
> make this change effective, even if `-XRankNTypes` is turned on, but 
> not `-XImpredicativeTypes`. The proposal also introduces an extension 
> `-XContravariantFunctions` to restore the old behaviour, for 
> compatibility.
> 
> Rational:
> 
> `-XImpredicativeTypes` is a useful extension which is currently in a 
> rather sad state. I'm happy to see it stabilise to a clear semantics. 
> The semantics in the proposal covers a ton of use cases. It strikes a 
> very good balance between usefulness and predictability.
> 
> The use of n-ary application in the type system also has good 
> theoretical roots: sequent calculi have n-ary applications. (in 
> manyrespects, bidirectional type systems are also about n-ary 
> application). So I don't consider it a wart at all.
> 
> The propsal's semantics, including the absence of contravariant 
> functions, goes in the direction of _guessing less things_. This is a 
> direction that many GHC features have taken lately. I think it's a very 
> very good direction! Guessing can be damaging for predictability, but. 
> more importantly, guessing has a tendency to compose badly with other 
> typing features. (it is to be noted, too, that the implementation of 
> contravariant functions. in GHC, eta-expands the function, which can 
> casually change its semantics, if the function was bottom).
> 
> So, everything in this proposal does look good to me, except that, I 
> think, I would like a deprecation route for the 
> `-XContravariantFunctions` extension. Otherwise, we will be stuck with 
> legacy code forever.
> 
> Best,
> Arnaud
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From iavor.diatchki at gmail.com  Tue Oct 15 18:37:16 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 15 Oct 2019 11:37:16 -0700
Subject: [ghc-steering-committee] Question about "Add Unified Namespace"
	(#270)
Message-ID: <CAGK9nuoDSCCDYoJwJU_FpO6kw-741jQ2oyty+x7dXTPEw67snA@mail.gmail.com>

Hello,

I am the shepherd for #270, "Add Unified Namesapce", which was
submitted for us to review around September 25.   I read the proposal
when it was submitted, but pretty much since then there has been
continuing discussion with various new ideas being fleshed out.

So, I've been waiting for things to stabilize a bit, before I re-read
it, and ask for feedback from the committee.   Given that it has been
about 3 weeks, and there are still more comments and suggestions, I
was wondering if it would be appropriate to move it back to the
"discussion" phase,
or if we should leave things as they are and keep waiting.

Thoughts?

-Iavor

From rae at richarde.dev  Tue Oct 15 21:07:49 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 15 Oct 2019 22:07:49 +0100
Subject: [ghc-steering-committee] Question about "Add Unified Namespace"
 (#270)
In-Reply-To: <CAGK9nuoDSCCDYoJwJU_FpO6kw-741jQ2oyty+x7dXTPEw67snA@mail.gmail.com>
References: <CAGK9nuoDSCCDYoJwJU_FpO6kw-741jQ2oyty+x7dXTPEw67snA@mail.gmail.com>
Message-ID: <98E0230A-37E6-44E1-803A-9C7885E66526@richarde.dev>

My interpretation is that as soon as discussion (that might change the content of the proposal) picks up, the proposal should go back into the discussion state. It's not good for us to have "pending recommendation" for a long time.

Richard

> On Oct 15, 2019, at 7:37 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hello,
> 
> I am the shepherd for #270, "Add Unified Namesapce", which was
> submitted for us to review around September 25.   I read the proposal
> when it was submitted, but pretty much since then there has been
> continuing discussion with various new ideas being fleshed out.
> 
> So, I've been waiting for things to stabilize a bit, before I re-read
> it, and ask for feedback from the committee.   Given that it has been
> about 3 weeks, and there are still more comments and suggestions, I
> was wondering if it would be appropriate to move it back to the
> "discussion" phase,
> or if we should leave things as they are and keep waiting.
> 
> Thoughts?
> 
> -Iavor
> _______________________________________________
> 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  Wed Oct 16 09:36:41 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 16 Oct 2019 09:36:41 +0000
Subject: [ghc-steering-committee] Question about "Add Unified Namespace"
 (#270)
In-Reply-To: <98E0230A-37E6-44E1-803A-9C7885E66526@richarde.dev>
References: <CAGK9nuoDSCCDYoJwJU_FpO6kw-741jQ2oyty+x7dXTPEw67snA@mail.gmail.com>
 <98E0230A-37E6-44E1-803A-9C7885E66526@richarde.dev>
Message-ID: <AM6PR83MB02791B8946A76A8922B7A225AD920@AM6PR83MB0279.EURPRD83.prod.outlook.com>

This is covered in my still-pending PR
https://github.com/ghc-proposals/ghc-proposals/pull/271
in exactly the way Richard describes.

Can we commit it?  It's been pending for ages.  But NB: it's not just typography and presentation: it has actual content.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Richard Eisenberg
|  Sent: 15 October 2019 22:08
|  To: Iavor Diatchki <iavor.diatchki at gmail.com>
|  Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
|  Subject: Re: [ghc-steering-committee] Question about "Add Unified
|  Namespace" (#270)
|  
|  My interpretation is that as soon as discussion (that might change the
|  content of the proposal) picks up, the proposal should go back into the
|  discussion state. It's not good for us to have "pending recommendation"
|  for a long time.
|  
|  Richard
|  
|  > On Oct 15, 2019, at 7:37 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
|  wrote:
|  >
|  > Hello,
|  >
|  > I am the shepherd for #270, "Add Unified Namesapce", which was
|  > submitted for us to review around September 25.   I read the proposal
|  > when it was submitted, but pretty much since then there has been
|  > continuing discussion with various new ideas being fleshed out.
|  >
|  > So, I've been waiting for things to stabilize a bit, before I re-read
|  > it, and ask for feedback from the committee.   Given that it has been
|  > about 3 weeks, and there are still more comments and suggestions, I
|  > was wondering if it would be appropriate to move it back to the
|  > "discussion" phase,
|  > or if we should leave things as they are and keep waiting.
|  >
|  > Thoughts?
|  >
|  > -Iavor
|  > _______________________________________________
|  > 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 rae at richarde.dev  Wed Oct 16 09:47:05 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 16 Oct 2019 10:47:05 +0100
Subject: [ghc-steering-committee] Question about "Add Unified Namespace"
 (#270)
In-Reply-To: <AM6PR83MB02791B8946A76A8922B7A225AD920@AM6PR83MB0279.EURPRD83.prod.outlook.com>
References: <CAGK9nuoDSCCDYoJwJU_FpO6kw-741jQ2oyty+x7dXTPEw67snA@mail.gmail.com>
 <98E0230A-37E6-44E1-803A-9C7885E66526@richarde.dev>
 <AM6PR83MB02791B8946A76A8922B7A225AD920@AM6PR83MB0279.EURPRD83.prod.outlook.com>
Message-ID: <E79DB306-53AF-4A31-9617-96616BC62BBF@richarde.dev>

Support seems quite positive on that. I think we can commit. (There's not really a shepherd here because it's all internal.)

> On Oct 16, 2019, at 10:36 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> This is covered in my still-pending PR
> https://github.com/ghc-proposals/ghc-proposals/pull/271
> in exactly the way Richard describes.
> 
> Can we commit it?  It's been pending for ages.  But NB: it's not just typography and presentation: it has actual content.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> |  On Behalf Of Richard Eisenberg
> |  Sent: 15 October 2019 22:08
> |  To: Iavor Diatchki <iavor.diatchki at gmail.com>
> |  Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  Subject: Re: [ghc-steering-committee] Question about "Add Unified
> |  Namespace" (#270)
> |  
> |  My interpretation is that as soon as discussion (that might change the
> |  content of the proposal) picks up, the proposal should go back into the
> |  discussion state. It's not good for us to have "pending recommendation"
> |  for a long time.
> |  
> |  Richard
> |  
> |  > On Oct 15, 2019, at 7:37 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> |  wrote:
> |  >
> |  > Hello,
> |  >
> |  > I am the shepherd for #270, "Add Unified Namesapce", which was
> |  > submitted for us to review around September 25.   I read the proposal
> |  > when it was submitted, but pretty much since then there has been
> |  > continuing discussion with various new ideas being fleshed out.
> |  >
> |  > So, I've been waiting for things to stabilize a bit, before I re-read
> |  > it, and ask for feedback from the committee.   Given that it has been
> |  > about 3 weeks, and there are still more comments and suggestions, I
> |  > was wondering if it would be appropriate to move it back to the
> |  > "discussion" phase,
> |  > or if we should leave things as they are and keep waiting.
> |  >
> |  > Thoughts?
> |  >
> |  > -Iavor
> |  > _______________________________________________
> |  > 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  Wed Oct 16 10:51:28 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 16 Oct 2019 10:51:28 +0000
Subject: [ghc-steering-committee] Please review #254: Scale back
 "Function Result Type Signatures" Shepherd: SPJ
In-Reply-To: <26334dda17346630ad592c9ebc185bd1ab992fd8.camel@joachim-breitner.de>
References: <26334dda17346630ad592c9ebc185bd1ab992fd8.camel@joachim-breitner.de>
Message-ID: <AM6PR83MB02791B1D8707A991E275A5CCAD920@AM6PR83MB0279.EURPRD83.prod.outlook.com>

Colleagues

I recommend acceptance.  I have given my reasoning here:
https://github.com/ghc-proposals/ghc-proposals/pull/254#issuecomment-542643788

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Joachim Breitner
|  Sent: 14 October 2019 08:35
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] Please review #254: Scale back "Function
|  Result Type Signatures" Shepherd: SPJ
|  
|  Dear Committee,
|  
|  this is your secretary speaking:
|  
|  Scale back "Function Result Type Signatures" to keep pattern sigs as-is
|  has been proposed by John Ericson
|  https://github.com/ghc-proposals/ghc-proposals/pull/254
|  
|  
|  This proposal amends #228, so I propose Simon PJ as the shepherd,
|  because he also shepherded #228.
|  
|  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 eric at seidel.io  Wed Oct 16 13:17:51 2019
From: eric at seidel.io (Eric Seidel)
Date: Wed, 16 Oct 2019 09:17:51 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Question_about_=22Add_Unified_?=
 =?utf-8?b?TmFtZXNwYWNlIiAoIzI3MCk=?=
In-Reply-To: <E79DB306-53AF-4A31-9617-96616BC62BBF@richarde.dev>
References: <CAGK9nuoDSCCDYoJwJU_FpO6kw-741jQ2oyty+x7dXTPEw67snA@mail.gmail.com>
 <98E0230A-37E6-44E1-803A-9C7885E66526@richarde.dev>
 <AM6PR83MB02791B8946A76A8922B7A225AD920@AM6PR83MB0279.EURPRD83.prod.outlook.com>
 <E79DB306-53AF-4A31-9617-96616BC62BBF@richarde.dev>
Message-ID: <c707d71c-c43c-4da0-b003-4b96e24370fa@www.fastmail.com>

Agreed, I think we can commit it at this point.

On Wed, Oct 16, 2019, at 05:47, Richard Eisenberg wrote:
> Support seems quite positive on that. I think we can commit. (There's 
> not really a shepherd here because it's all internal.)
> 
> > On Oct 16, 2019, at 10:36 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > 
> > This is covered in my still-pending PR
> > https://github.com/ghc-proposals/ghc-proposals/pull/271
> > in exactly the way Richard describes.
> > 
> > Can we commit it?  It's been pending for ages.  But NB: it's not just typography and presentation: it has actual content.
> > 
> > Simon
> > 
> > |  -----Original Message-----
> > |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> > |  On Behalf Of Richard Eisenberg
> > |  Sent: 15 October 2019 22:08
> > |  To: Iavor Diatchki <iavor.diatchki at gmail.com>
> > |  Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > |  Subject: Re: [ghc-steering-committee] Question about "Add Unified
> > |  Namespace" (#270)
> > |  
> > |  My interpretation is that as soon as discussion (that might change the
> > |  content of the proposal) picks up, the proposal should go back into the
> > |  discussion state. It's not good for us to have "pending recommendation"
> > |  for a long time.
> > |  
> > |  Richard
> > |  
> > |  > On Oct 15, 2019, at 7:37 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> > |  wrote:
> > |  >
> > |  > Hello,
> > |  >
> > |  > I am the shepherd for #270, "Add Unified Namesapce", which was
> > |  > submitted for us to review around September 25.   I read the proposal
> > |  > when it was submitted, but pretty much since then there has been
> > |  > continuing discussion with various new ideas being fleshed out.
> > |  >
> > |  > So, I've been waiting for things to stabilize a bit, before I re-read
> > |  > it, and ask for feedback from the committee.   Given that it has been
> > |  > about 3 weeks, and there are still more comments and suggestions, I
> > |  > was wondering if it would be appropriate to move it back to the
> > |  > "discussion" phase,
> > |  > or if we should leave things as they are and keep waiting.
> > |  >
> > |  > Thoughts?
> > |  >
> > |  > -Iavor
> > |  > _______________________________________________
> > |  > 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 iavor.diatchki at gmail.com  Wed Oct 16 17:45:16 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 16 Oct 2019 10:45:16 -0700
Subject: [ghc-steering-committee]
	=?utf-8?q?Quick_look_impredicativity_=28?=
	=?utf-8?q?=23274=29_=E2=80=94_recommendation=3A_accept?=
In-Reply-To: <68e54ee1-df78-4860-948a-f069aebd3293@www.fastmail.com>
References: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
 <68e54ee1-df78-4860-948a-f069aebd3293@www.fastmail.com>
Message-ID: <CAGK9nupdmGKHasFjoRf_gj1RqJoj+H9xmL9c0dXgE6OJ_cxWpw@mail.gmail.com>

I haven't had time to read through this proposal, but I am comfortable
accepting it based on the recommendations of others.

On Mon, Oct 14, 2019 at 5:52 PM Eric Seidel <eric at seidel.io> wrote:
>
> I support acceptance too, modulo a few small comments that I left on the GH discussion.
>
> On Mon, Oct 14, 2019, at 02:53, Spiwack, Arnaud wrote:
> > Dear all,
> >
> > As the title implies: I'm hereby recommending accepting the Quick look
> > impredicativity proposal.
> >
> > Summary:
> >
> > The proposal modifies the `-XImpredicativeTypes` extension with a well
> > defined semantics which consists in considering n-ary applications,
> > rather than binary. And look, in such an application, for arguments
> > which absolutely require impredicative instantiation (either
> > universally quantified type applications, or arguments where a
> > universal type is guarded by an invariant type constructor).
> >
> > In order to have the expected behaviour for `($)` and `(.)`, the
> > proposal also makes the left-hand argument of the arrow invariant with
> > respect to instantiation (currently: contravariant). The proposal is to
> > make this change effective, even if `-XRankNTypes` is turned on, but
> > not `-XImpredicativeTypes`. The proposal also introduces an extension
> > `-XContravariantFunctions` to restore the old behaviour, for
> > compatibility.
> >
> > Rational:
> >
> > `-XImpredicativeTypes` is a useful extension which is currently in a
> > rather sad state. I'm happy to see it stabilise to a clear semantics.
> > The semantics in the proposal covers a ton of use cases. It strikes a
> > very good balance between usefulness and predictability.
> >
> > The use of n-ary application in the type system also has good
> > theoretical roots: sequent calculi have n-ary applications. (in
> > manyrespects, bidirectional type systems are also about n-ary
> > application). So I don't consider it a wart at all.
> >
> > The propsal's semantics, including the absence of contravariant
> > functions, goes in the direction of _guessing less things_. This is a
> > direction that many GHC features have taken lately. I think it's a very
> > very good direction! Guessing can be damaging for predictability, but.
> > more importantly, guessing has a tendency to compose badly with other
> > typing features. (it is to be noted, too, that the implementation of
> > contravariant functions. in GHC, eta-expands the function, which can
> > casually change its semantics, if the function was bottom).
> >
> > So, everything in this proposal does look good to me, except that, I
> > think, I would like a deprecation route for the
> > `-XContravariantFunctions` extension. Otherwise, we will be stuck with
> > legacy code forever.
> >
> > Best,
> > Arnaud
> > _______________________________________________
> > 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 iavor.diatchki at gmail.com  Wed Oct 16 18:01:18 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 16 Oct 2019 11:01:18 -0700
Subject: [ghc-steering-committee] Question about "Add Unified Namespace"
	(#270)
In-Reply-To: <c707d71c-c43c-4da0-b003-4b96e24370fa@www.fastmail.com>
References: <CAGK9nuoDSCCDYoJwJU_FpO6kw-741jQ2oyty+x7dXTPEw67snA@mail.gmail.com>
 <98E0230A-37E6-44E1-803A-9C7885E66526@richarde.dev>
 <AM6PR83MB02791B8946A76A8922B7A225AD920@AM6PR83MB0279.EURPRD83.prod.outlook.com>
 <E79DB306-53AF-4A31-9617-96616BC62BBF@richarde.dev>
 <c707d71c-c43c-4da0-b003-4b96e24370fa@www.fastmail.com>
Message-ID: <CAGK9nupxtUHWo2ZZ=dxNgB6BGMGy1ANEG2OZNXur5fxDuaADjQ@mail.gmail.com>

I am fine with committing Simon's changes to the process, although
having read through them I am unclear on what action should I take.
Here are some idea:

   1. should I remove the label "Pending Shepherd Recommendation" and
un-assign myself as a shepherd? or
   2. remove the label, but stay as a shepherd, or
   3. change the label to "Needs revision", or
   4. do nothing, and stay in the current state until the discussion
settles down?

-Iavor




On Wed, Oct 16, 2019 at 6:18 AM Eric Seidel <eric at seidel.io> wrote:
>
> Agreed, I think we can commit it at this point.
>
> On Wed, Oct 16, 2019, at 05:47, Richard Eisenberg wrote:
> > Support seems quite positive on that. I think we can commit. (There's
> > not really a shepherd here because it's all internal.)
> >
> > > On Oct 16, 2019, at 10:36 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > >
> > > This is covered in my still-pending PR
> > > https://github.com/ghc-proposals/ghc-proposals/pull/271
> > > in exactly the way Richard describes.
> > >
> > > Can we commit it?  It's been pending for ages.  But NB: it's not just typography and presentation: it has actual content.
> > >
> > > Simon
> > >
> > > |  -----Original Message-----
> > > |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> > > |  On Behalf Of Richard Eisenberg
> > > |  Sent: 15 October 2019 22:08
> > > |  To: Iavor Diatchki <iavor.diatchki at gmail.com>
> > > |  Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > > |  Subject: Re: [ghc-steering-committee] Question about "Add Unified
> > > |  Namespace" (#270)
> > > |
> > > |  My interpretation is that as soon as discussion (that might change the
> > > |  content of the proposal) picks up, the proposal should go back into the
> > > |  discussion state. It's not good for us to have "pending recommendation"
> > > |  for a long time.
> > > |
> > > |  Richard
> > > |
> > > |  > On Oct 15, 2019, at 7:37 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> > > |  wrote:
> > > |  >
> > > |  > Hello,
> > > |  >
> > > |  > I am the shepherd for #270, "Add Unified Namesapce", which was
> > > |  > submitted for us to review around September 25.   I read the proposal
> > > |  > when it was submitted, but pretty much since then there has been
> > > |  > continuing discussion with various new ideas being fleshed out.
> > > |  >
> > > |  > So, I've been waiting for things to stabilize a bit, before I re-read
> > > |  > it, and ask for feedback from the committee.   Given that it has been
> > > |  > about 3 weeks, and there are still more comments and suggestions, I
> > > |  > was wondering if it would be appropriate to move it back to the
> > > |  > "discussion" phase,
> > > |  > or if we should leave things as they are and keep waiting.
> > > |  >
> > > |  > Thoughts?
> > > |  >
> > > |  > -Iavor
> > > |  > _______________________________________________
> > > |  > 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 eric at seidel.io  Wed Oct 16 22:02:16 2019
From: eric at seidel.io (Eric Seidel)
Date: Wed, 16 Oct 2019 18:02:16 -0400
Subject: [ghc-steering-committee] Question about "Add Unified Namespace"
	(#270)
In-Reply-To: <CAGK9nupxtUHWo2ZZ=dxNgB6BGMGy1ANEG2OZNXur5fxDuaADjQ@mail.gmail.com>
References: <CAGK9nupxtUHWo2ZZ=dxNgB6BGMGy1ANEG2OZNXur5fxDuaADjQ@mail.gmail.com>
Message-ID: <9142D297-DE2F-4BE7-9317-F5341A79FC33@seidel.io>

Presumably you’ll remain the shepherd once the proposal is ready for another review, so I don’t think it makes sense to unassign yourself.

According to Simon’s PR, you should also flip the label to “Needs revision” (see step 6 of the lifecycle). We may not have explicitly requested a revision this time, but that seems close enough for tracking purposes. 

Sent from my iPhone

> On Oct 16, 2019, at 14:01, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> I am fine with committing Simon's changes to the process, although
> having read through them I am unclear on what action should I take.
> Here are some idea:
> 
>  1. should I remove the label "Pending Shepherd Recommendation" and
> un-assign myself as a shepherd? or
>  2. remove the label, but stay as a shepherd, or
>  3. change the label to "Needs revision", or
>  4. do nothing, and stay in the current state until the discussion
> settles down?
> 
> -Iavor
> 
> 
> 
> 
>>> On Wed, Oct 16, 2019 at 6:18 AM Eric Seidel <eric at seidel.io> wrote:
>> Agreed, I think we can commit it at this point.
>>> On Wed, Oct 16, 2019, at 05:47, Richard Eisenberg wrote:
>>> Support seems quite positive on that. I think we can commit. (There's
>>> not really a shepherd here because it's all internal.)
>>>> On Oct 16, 2019, at 10:36 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>>>> This is covered in my still-pending PR
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/271
>>>> in exactly the way Richard describes.
>>>> Can we commit it?  It's been pending for ages.  But NB: it's not just typography and presentation: it has actual content.
>>>> Simon
>>>> |  -----Original Message-----
>>>> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
>>>> |  On Behalf Of Richard Eisenberg
>>>> |  Sent: 15 October 2019 22:08
>>>> |  To: Iavor Diatchki <iavor.diatchki at gmail.com>
>>>> |  Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
>>>> |  Subject: Re: [ghc-steering-committee] Question about "Add Unified
>>>> |  Namespace" (#270)
>>>> |
>>>> |  My interpretation is that as soon as discussion (that might change the
>>>> |  content of the proposal) picks up, the proposal should go back into the
>>>> |  discussion state. It's not good for us to have "pending recommendation"
>>>> |  for a long time.
>>>> |
>>>> |  Richard
>>>> |
>>>> |  > On Oct 15, 2019, at 7:37 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>>>> |  wrote:
>>>> |  >
>>>> |  > Hello,
>>>> |  >
>>>> |  > I am the shepherd for #270, "Add Unified Namesapce", which was
>>>> |  > submitted for us to review around September 25.   I read the proposal
>>>> |  > when it was submitted, but pretty much since then there has been
>>>> |  > continuing discussion with various new ideas being fleshed out.
>>>> |  >
>>>> |  > So, I've been waiting for things to stabilize a bit, before I re-read
>>>> |  > it, and ask for feedback from the committee.   Given that it has been
>>>> |  > about 3 weeks, and there are still more comments and suggestions, I
>>>> |  > was wondering if it would be appropriate to move it back to the
>>>> |  > "discussion" phase,
>>>> |  > or if we should leave things as they are and keep waiting.
>>>> |  >
>>>> |  > Thoughts?
>>>> |  >
>>>> |  > -Iavor
>>>> |  > _______________________________________________
>>>> |  > 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 arnaud.spiwack at tweag.io  Thu Oct 17 07:04:34 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 17 Oct 2019 09:04:34 +0200
Subject: [ghc-steering-committee]
	=?utf-8?q?Quick_look_impredicativity_=28?=
	=?utf-8?q?=23274=29_=E2=80=94_recommendation=3A_accept?=
In-Reply-To: <CAGK9nupdmGKHasFjoRf_gj1RqJoj+H9xmL9c0dXgE6OJ_cxWpw@mail.gmail.com>
References: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
 <68e54ee1-df78-4860-948a-f069aebd3293@www.fastmail.com>
 <CAGK9nupdmGKHasFjoRf_gj1RqJoj+H9xmL9c0dXgE6OJ_cxWpw@mail.gmail.com>
Message-ID: <CAH6fHQnZ5z49La-psJ6zD1+KxKCJwVig5KZJqUREwHaPaZkCNQ@mail.gmail.com>

Support seems unanimous so far. Unless someones voices a second opinion by
then, I'll accept the proposal early next week.

Any other opinion on deprecation of `-XContravariantFunctions`? I'd like
this to be planned and to have a schedule. Maybe, as Simon suggested in the
Github thread, this should be another discussion, though?

On Wed, Oct 16, 2019 at 7:45 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> I haven't had time to read through this proposal, but I am comfortable
> accepting it based on the recommendations of others.
>
> On Mon, Oct 14, 2019 at 5:52 PM Eric Seidel <eric at seidel.io> wrote:
> >
> > I support acceptance too, modulo a few small comments that I left on the
> GH discussion.
> >
> > On Mon, Oct 14, 2019, at 02:53, Spiwack, Arnaud wrote:
> > > Dear all,
> > >
> > > As the title implies: I'm hereby recommending accepting the Quick look
> > > impredicativity proposal.
> > >
> > > Summary:
> > >
> > > The proposal modifies the `-XImpredicativeTypes` extension with a well
> > > defined semantics which consists in considering n-ary applications,
> > > rather than binary. And look, in such an application, for arguments
> > > which absolutely require impredicative instantiation (either
> > > universally quantified type applications, or arguments where a
> > > universal type is guarded by an invariant type constructor).
> > >
> > > In order to have the expected behaviour for `($)` and `(.)`, the
> > > proposal also makes the left-hand argument of the arrow invariant with
> > > respect to instantiation (currently: contravariant). The proposal is to
> > > make this change effective, even if `-XRankNTypes` is turned on, but
> > > not `-XImpredicativeTypes`. The proposal also introduces an extension
> > > `-XContravariantFunctions` to restore the old behaviour, for
> > > compatibility.
> > >
> > > Rational:
> > >
> > > `-XImpredicativeTypes` is a useful extension which is currently in a
> > > rather sad state. I'm happy to see it stabilise to a clear semantics.
> > > The semantics in the proposal covers a ton of use cases. It strikes a
> > > very good balance between usefulness and predictability.
> > >
> > > The use of n-ary application in the type system also has good
> > > theoretical roots: sequent calculi have n-ary applications. (in
> > > manyrespects, bidirectional type systems are also about n-ary
> > > application). So I don't consider it a wart at all.
> > >
> > > The propsal's semantics, including the absence of contravariant
> > > functions, goes in the direction of _guessing less things_. This is a
> > > direction that many GHC features have taken lately. I think it's a very
> > > very good direction! Guessing can be damaging for predictability, but.
> > > more importantly, guessing has a tendency to compose badly with other
> > > typing features. (it is to be noted, too, that the implementation of
> > > contravariant functions. in GHC, eta-expands the function, which can
> > > casually change its semantics, if the function was bottom).
> > >
> > > So, everything in this proposal does look good to me, except that, I
> > > think, I would like a deprecation route for the
> > > `-XContravariantFunctions` extension. Otherwise, we will be stuck with
> > > legacy code forever.
> > >
> > > Best,
> > > Arnaud
> > > _______________________________________________
> > > 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/20191017/3270e847/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Oct 17 07:10:08 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 17 Oct 2019 09:10:08 +0200
Subject: [ghc-steering-committee] Please review #254: Scale back
 "Function Result Type Signatures" Shepherd: SPJ
In-Reply-To: <AM6PR83MB02791B1D8707A991E275A5CCAD920@AM6PR83MB0279.EURPRD83.prod.outlook.com>
References: <26334dda17346630ad592c9ebc185bd1ab992fd8.camel@joachim-breitner.de>
 <AM6PR83MB02791B1D8707A991E275A5CCAD920@AM6PR83MB0279.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQn2SNmYvxz8y0DOtuiqdCnOvhMPFBQtexQgMEJVUtU9eQ@mail.gmail.com>

I'm convinced.

On Wed, Oct 16, 2019 at 12:51 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Colleagues
>
> I recommend acceptance.  I have given my reasoning here:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/254#issuecomment-542643788
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org>
> |  On Behalf Of Joachim Breitner
> |  Sent: 14 October 2019 08:35
> |  To: ghc-steering-committee at haskell.org
> |  Subject: [ghc-steering-committee] Please review #254: Scale back
> "Function
> |  Result Type Signatures" Shepherd: SPJ
> |
> |  Dear Committee,
> |
> |  this is your secretary speaking:
> |
> |  Scale back "Function Result Type Signatures" to keep pattern sigs as-is
> |  has been proposed by John Ericson
> |  https://github.com/ghc-proposals/ghc-proposals/pull/254
> |
> |
> |  This proposal amends #228, so I propose Simon PJ as the shepherd,
> |  because he also shepherded #228.
> |
> |  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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191017/5874373b/attachment.html>

From mail at joachim-breitner.de  Thu Oct 17 10:32:43 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 17 Oct 2019 12:32:43 +0200
Subject: [ghc-steering-committee] Question about "Add Unified Namespace"
 (#270)
In-Reply-To: <CAGK9nupxtUHWo2ZZ=dxNgB6BGMGy1ANEG2OZNXur5fxDuaADjQ@mail.gmail.com>
References: <CAGK9nuoDSCCDYoJwJU_FpO6kw-741jQ2oyty+x7dXTPEw67snA@mail.gmail.com>
 <98E0230A-37E6-44E1-803A-9C7885E66526@richarde.dev>
 <AM6PR83MB02791B8946A76A8922B7A225AD920@AM6PR83MB0279.EURPRD83.prod.outlook.com>
 <E79DB306-53AF-4A31-9617-96616BC62BBF@richarde.dev>
 <c707d71c-c43c-4da0-b003-4b96e24370fa@www.fastmail.com>
 <CAGK9nupxtUHWo2ZZ=dxNgB6BGMGy1ANEG2OZNXur5fxDuaADjQ@mail.gmail.com>
Message-ID: <45ee3f98f723877e47e2cbd783d61a387087ff17.camel@joachim-breitner.de>

Hi,

if you want to move it back to discussion, I think you should

* remove the current label
* add label "Needs revision"
* maybe stay assigned (you’re the default shepherd when it comes back)
* explain what it means to the authors, and that they should ping 
  me when it is ready for review again.

Cheers,
Joachim

Am Mittwoch, den 16.10.2019, 11:01 -0700 schrieb Iavor Diatchki:
> I am fine with committing Simon's changes to the process, although
> having read through them I am unclear on what action should I take.
> Here are some idea:
> 
>    1. should I remove the label "Pending Shepherd Recommendation" and
> un-assign myself as a shepherd? or
>    2. remove the label, but stay as a shepherd, or
>    3. change the label to "Needs revision", or
>    4. do nothing, and stay in the current state until the discussion
> settles down?
> 
> -Iavor
> 
> 
> 
> 
> On Wed, Oct 16, 2019 at 6:18 AM Eric Seidel <eric at seidel.io> wrote:
> > Agreed, I think we can commit it at this point.
> > 
> > On Wed, Oct 16, 2019, at 05:47, Richard Eisenberg wrote:
> > > Support seems quite positive on that. I think we can commit. (There's
> > > not really a shepherd here because it's all internal.)
> > > 
> > > > On Oct 16, 2019, at 10:36 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > > > 
> > > > This is covered in my still-pending PR
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/271
> > > > in exactly the way Richard describes.
> > > > 
> > > > Can we commit it?  It's been pending for ages.  But NB: it's not just typography and presentation: it has actual content.
> > > > 
> > > > Simon
> > > > 
> > > > >  -----Original Message-----
> > > > >  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> > > > >  On Behalf Of Richard Eisenberg
> > > > >  Sent: 15 October 2019 22:08
> > > > >  To: Iavor Diatchki <iavor.diatchki at gmail.com>
> > > > >  Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > > > >  Subject: Re: [ghc-steering-committee] Question about "Add Unified
> > > > >  Namespace" (#270)
> > > > > 
> > > > >  My interpretation is that as soon as discussion (that might change the
> > > > >  content of the proposal) picks up, the proposal should go back into the
> > > > >  discussion state. It's not good for us to have "pending recommendation"
> > > > >  for a long time.
> > > > > 
> > > > >  Richard
> > > > > 
> > > > >  > On Oct 15, 2019, at 7:37 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> > > > >  wrote:
> > > > >  >
> > > > >  > Hello,
> > > > >  >
> > > > >  > I am the shepherd for #270, "Add Unified Namesapce", which was
> > > > >  > submitted for us to review around September 25.   I read the proposal
> > > > >  > when it was submitted, but pretty much since then there has been
> > > > >  > continuing discussion with various new ideas being fleshed out.
> > > > >  >
> > > > >  > So, I've been waiting for things to stabilize a bit, before I re-read
> > > > >  > it, and ask for feedback from the committee.   Given that it has been
> > > > >  > about 3 weeks, and there are still more comments and suggestions, I
> > > > >  > was wondering if it would be appropriate to move it back to the
> > > > >  > "discussion" phase,
> > > > >  > or if we should leave things as they are and keep waiting.
> > > > >  >
> > > > >  > Thoughts?
> > > > >  >
> > > > >  > -Iavor
> > > > >  > _______________________________________________
> > > > >  > 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From simonpj at microsoft.com  Thu Oct 17 11:24:40 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Oct 2019 11:24:40 +0000
Subject: [ghc-steering-committee]
 =?utf-8?q?Quick_look_impredicativity_=28?=
 =?utf-8?q?=23274=29_=E2=80=94_recommendation=3A_accept?=
In-Reply-To: <CAH6fHQnZ5z49La-psJ6zD1+KxKCJwVig5KZJqUREwHaPaZkCNQ@mail.gmail.com>
References: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
 <68e54ee1-df78-4860-948a-f069aebd3293@www.fastmail.com>
 <CAGK9nupdmGKHasFjoRf_gj1RqJoj+H9xmL9c0dXgE6OJ_cxWpw@mail.gmail.com>
 <CAH6fHQnZ5z49La-psJ6zD1+KxKCJwVig5KZJqUREwHaPaZkCNQ@mail.gmail.com>
Message-ID: <AM6PR83MB0279F58FA4A6A4A07E0B8579AD6D0@AM6PR83MB0279.EURPRD83.prod.outlook.com>

Any other opinion on deprecation of `-XContravariantFunctions`? I'd like this to be planned and to have a schedule. Maybe, as Simon suggested in the Github thread, this should be another discussion, though?

I have produced a GHC Proposal
https://github.com/ghc-proposals/ghc-proposals/pull/287

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
Sent: 17 October 2019 08:05
To: Iavor Diatchki <iavor.diatchki at gmail.com>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Quick look impredicativity (#274) — recommendation: accept

Support seems unanimous so far. Unless someones voices a second opinion by then, I'll accept the proposal early next week.

Any other opinion on deprecation of `-XContravariantFunctions`? I'd like this to be planned and to have a schedule. Maybe, as Simon suggested in the Github thread, this should be another discussion, though?

On Wed, Oct 16, 2019 at 7:45 PM Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:
I haven't had time to read through this proposal, but I am comfortable
accepting it based on the recommendations of others.

On Mon, Oct 14, 2019 at 5:52 PM Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
>
> I support acceptance too, modulo a few small comments that I left on the GH discussion.
>
> On Mon, Oct 14, 2019, at 02:53, Spiwack, Arnaud wrote:
> > Dear all,
> >
> > As the title implies: I'm hereby recommending accepting the Quick look
> > impredicativity proposal.
> >
> > Summary:
> >
> > The proposal modifies the `-XImpredicativeTypes` extension with a well
> > defined semantics which consists in considering n-ary applications,
> > rather than binary. And look, in such an application, for arguments
> > which absolutely require impredicative instantiation (either
> > universally quantified type applications, or arguments where a
> > universal type is guarded by an invariant type constructor).
> >
> > In order to have the expected behaviour for `($)` and `(.)`, the
> > proposal also makes the left-hand argument of the arrow invariant with
> > respect to instantiation (currently: contravariant). The proposal is to
> > make this change effective, even if `-XRankNTypes` is turned on, but
> > not `-XImpredicativeTypes`. The proposal also introduces an extension
> > `-XContravariantFunctions` to restore the old behaviour, for
> > compatibility.
> >
> > Rational:
> >
> > `-XImpredicativeTypes` is a useful extension which is currently in a
> > rather sad state. I'm happy to see it stabilise to a clear semantics.
> > The semantics in the proposal covers a ton of use cases. It strikes a
> > very good balance between usefulness and predictability.
> >
> > The use of n-ary application in the type system also has good
> > theoretical roots: sequent calculi have n-ary applications. (in
> > manyrespects, bidirectional type systems are also about n-ary
> > application). So I don't consider it a wart at all.
> >
> > The propsal's semantics, including the absence of contravariant
> > functions, goes in the direction of _guessing less things_. This is a
> > direction that many GHC features have taken lately. I think it's a very
> > very good direction! Guessing can be damaging for predictability, but.
> > more importantly, guessing has a tendency to compose badly with other
> > typing features. (it is to be noted, too, that the implementation of
> > contravariant functions. in GHC, eta-expands the function, which can
> > casually change its semantics, if the function was bottom).
> >
> > So, everything in this proposal does look good to me, except that, I
> > think, I would like a deprecation route for the
> > `-XContravariantFunctions` extension. Otherwise, we will be stuck with
> > legacy code forever.
> >
> > Best,
> > Arnaud
> > _______________________________________________
> > 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
_______________________________________________
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/20191017/5aa9994b/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Oct 17 11:27:39 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 17 Oct 2019 13:27:39 +0200
Subject: [ghc-steering-committee]
	=?utf-8?q?Quick_look_impredicativity_=28?=
	=?utf-8?q?=23274=29_=E2=80=94_recommendation=3A_accept?=
In-Reply-To: <AM6PR83MB0279F58FA4A6A4A07E0B8579AD6D0@AM6PR83MB0279.EURPRD83.prod.outlook.com>
References: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
 <68e54ee1-df78-4860-948a-f069aebd3293@www.fastmail.com>
 <CAGK9nupdmGKHasFjoRf_gj1RqJoj+H9xmL9c0dXgE6OJ_cxWpw@mail.gmail.com>
 <CAH6fHQnZ5z49La-psJ6zD1+KxKCJwVig5KZJqUREwHaPaZkCNQ@mail.gmail.com>
 <AM6PR83MB0279F58FA4A6A4A07E0B8579AD6D0@AM6PR83MB0279.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQkiVPzvtuYejT+QgkSN9LxiL=MWTTKR0FA7rEeEz9eN3A@mail.gmail.com>

Sweet!

Should we, therefore, consider removing the contravariance discussion from
the quick look impredicativity proposal?

On Thu, Oct 17, 2019 at 1:24 PM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Any other opinion on deprecation of `-XContravariantFunctions`? I'd like
> this to be planned and to have a schedule. Maybe, as Simon suggested in the
> Github thread, this should be another discussion, though?
>
>
>
> I have produced a GHC Proposal
>
> https://github.com/ghc-proposals/ghc-proposals/pull/287
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Spiwack, Arnaud
> *Sent:* 17 October 2019 08:05
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Quick look impredicativity (#274)
> — recommendation: accept
>
>
>
> Support seems unanimous so far. Unless someones voices a second opinion by
> then, I'll accept the proposal early next week.
>
>
>
> Any other opinion on deprecation of `-XContravariantFunctions`? I'd like
> this to be planned and to have a schedule. Maybe, as Simon suggested in the
> Github thread, this should be another discussion, though?
>
>
>
> On Wed, Oct 16, 2019 at 7:45 PM Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> I haven't had time to read through this proposal, but I am comfortable
> accepting it based on the recommendations of others.
>
> On Mon, Oct 14, 2019 at 5:52 PM Eric Seidel <eric at seidel.io> wrote:
> >
> > I support acceptance too, modulo a few small comments that I left on the
> GH discussion.
> >
> > On Mon, Oct 14, 2019, at 02:53, Spiwack, Arnaud wrote:
> > > Dear all,
> > >
> > > As the title implies: I'm hereby recommending accepting the Quick look
> > > impredicativity proposal.
> > >
> > > Summary:
> > >
> > > The proposal modifies the `-XImpredicativeTypes` extension with a well
> > > defined semantics which consists in considering n-ary applications,
> > > rather than binary. And look, in such an application, for arguments
> > > which absolutely require impredicative instantiation (either
> > > universally quantified type applications, or arguments where a
> > > universal type is guarded by an invariant type constructor).
> > >
> > > In order to have the expected behaviour for `($)` and `(.)`, the
> > > proposal also makes the left-hand argument of the arrow invariant with
> > > respect to instantiation (currently: contravariant). The proposal is to
> > > make this change effective, even if `-XRankNTypes` is turned on, but
> > > not `-XImpredicativeTypes`. The proposal also introduces an extension
> > > `-XContravariantFunctions` to restore the old behaviour, for
> > > compatibility.
> > >
> > > Rational:
> > >
> > > `-XImpredicativeTypes` is a useful extension which is currently in a
> > > rather sad state. I'm happy to see it stabilise to a clear semantics.
> > > The semantics in the proposal covers a ton of use cases. It strikes a
> > > very good balance between usefulness and predictability.
> > >
> > > The use of n-ary application in the type system also has good
> > > theoretical roots: sequent calculi have n-ary applications. (in
> > > manyrespects, bidirectional type systems are also about n-ary
> > > application). So I don't consider it a wart at all.
> > >
> > > The propsal's semantics, including the absence of contravariant
> > > functions, goes in the direction of _guessing less things_. This is a
> > > direction that many GHC features have taken lately. I think it's a very
> > > very good direction! Guessing can be damaging for predictability, but.
> > > more importantly, guessing has a tendency to compose badly with other
> > > typing features. (it is to be noted, too, that the implementation of
> > > contravariant functions. in GHC, eta-expands the function, which can
> > > casually change its semantics, if the function was bottom).
> > >
> > > So, everything in this proposal does look good to me, except that, I
> > > think, I would like a deprecation route for the
> > > `-XContravariantFunctions` extension. Otherwise, we will be stuck with
> > > legacy code forever.
> > >
> > > Best,
> > > Arnaud
> > > _______________________________________________
> > > 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/20191017/ebec24af/attachment.html>

From eric at seidel.io  Thu Oct 17 13:00:54 2019
From: eric at seidel.io (Eric Seidel)
Date: Thu, 17 Oct 2019 09:00:54 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Quick_look_impredicativity_=28?=
 =?utf-8?q?=23274=29_=E2=80=94_recommendation=3A_accept?=
In-Reply-To: <CAH6fHQkiVPzvtuYejT+QgkSN9LxiL=MWTTKR0FA7rEeEz9eN3A@mail.gmail.com>
References: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
 <68e54ee1-df78-4860-948a-f069aebd3293@www.fastmail.com>
 <CAGK9nupdmGKHasFjoRf_gj1RqJoj+H9xmL9c0dXgE6OJ_cxWpw@mail.gmail.com>
 <CAH6fHQnZ5z49La-psJ6zD1+KxKCJwVig5KZJqUREwHaPaZkCNQ@mail.gmail.com>
 <AM6PR83MB0279F58FA4A6A4A07E0B8579AD6D0@AM6PR83MB0279.EURPRD83.prod.outlook.com>
 <CAH6fHQkiVPzvtuYejT+QgkSN9LxiL=MWTTKR0FA7rEeEz9eN3A@mail.gmail.com>
Message-ID: <3ec8918d-e986-4810-a80b-61d4ea21215d@www.fastmail.com>

We can't remove the discussion entirely, right? Removing contravariance is necessary for QuickLook to work for the most common case of impredicative instantiation.

I would, however, support returning the proposal to its previous recommendation to

1. introduce `-X[No]ContravariantFunctions`
2. enable `-XContravariantFunctions` by default`
3. make `-XImpredicativeTypes` imply `-XNoContravariantFunctions`

and move discussion of deprecating contravariance (and any other excesses in the type system) to a follow-on proposal.

It seems to me that the above steps are the minimum for the QuickLook proposal to be acceptable on its own.

On Thu, Oct 17, 2019, at 07:27, Spiwack, Arnaud wrote:
> Sweet!
> 
> Should we, therefore, consider removing the contravariance discussion 
> from the quick look impredicativity proposal?
> 
> On Thu, Oct 17, 2019 at 1:24 PM Simon Peyton Jones 
> <simonpj at microsoft.com> wrote:
> >  Any other opinion on deprecation of `-XContravariantFunctions`? I'd like this to be planned and to have a schedule. Maybe, as Simon suggested in the Github thread, this should be another discussion, though?____
> 
> > __ __
> 
> > I have produced a GHC Proposal____
> 
> > https://github.com/ghc-proposals/ghc-proposals/pull/287____
> 
> > __ __
> 
> > Simon____
> 
> > __ __
> 
> > *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
> > *Sent:* 17 October 2019 08:05
> > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > *Subject:* Re: [ghc-steering-committee] Quick look impredicativity (#274) — recommendation: accept____
> 
> > __ __
> 
> >  Support seems unanimous so far. Unless someones voices a second opinion by then, I'll accept the proposal early next week.____
> 
> > __ __
> 
> >  Any other opinion on deprecation of `-XContravariantFunctions`? I'd like this to be planned and to have a schedule. Maybe, as Simon suggested in the Github thread, this should be another discussion, though?____
> 
> > __ __
> 
> >  On Wed, Oct 16, 2019 at 7:45 PM Iavor Diatchki <iavor.diatchki at gmail.com> wrote:____
> 
> >>  I haven't had time to read through this proposal, but I am comfortable
> >>  accepting it based on the recommendations of others.
> >> 
> >>  On Mon, Oct 14, 2019 at 5:52 PM Eric Seidel <eric at seidel.io> wrote:
> >>  >
> >>  > I support acceptance too, modulo a few small comments that I left on the GH discussion.
> >>  >
> >>  > On Mon, Oct 14, 2019, at 02:53, Spiwack, Arnaud wrote:
> >>  > > Dear all,
> >>  > >
> >>  > > As the title implies: I'm hereby recommending accepting the Quick look
> >>  > > impredicativity proposal.
> >>  > >
> >>  > > Summary:
> >>  > >
> >>  > > The proposal modifies the `-XImpredicativeTypes` extension with a well
> >>  > > defined semantics which consists in considering n-ary applications,
> >>  > > rather than binary. And look, in such an application, for arguments
> >>  > > which absolutely require impredicative instantiation (either
> >>  > > universally quantified type applications, or arguments where a
> >>  > > universal type is guarded by an invariant type constructor).
> >>  > >
> >>  > > In order to have the expected behaviour for `($)` and `(.)`, the
> >>  > > proposal also makes the left-hand argument of the arrow invariant with
> >>  > > respect to instantiation (currently: contravariant). The proposal is to
> >>  > > make this change effective, even if `-XRankNTypes` is turned on, but
> >>  > > not `-XImpredicativeTypes`. The proposal also introduces an extension
> >>  > > `-XContravariantFunctions` to restore the old behaviour, for
> >>  > > compatibility.
> >>  > >
> >>  > > Rational:
> >>  > >
> >>  > > `-XImpredicativeTypes` is a useful extension which is currently in a
> >>  > > rather sad state. I'm happy to see it stabilise to a clear semantics.
> >>  > > The semantics in the proposal covers a ton of use cases. It strikes a
> >>  > > very good balance between usefulness and predictability.
> >>  > >
> >>  > > The use of n-ary application in the type system also has good
> >>  > > theoretical roots: sequent calculi have n-ary applications. (in
> >>  > > manyrespects, bidirectional type systems are also about n-ary
> >>  > > application). So I don't consider it a wart at all.
> >>  > >
> >>  > > The propsal's semantics, including the absence of contravariant
> >>  > > functions, goes in the direction of _guessing less things_. This is a
> >>  > > direction that many GHC features have taken lately. I think it's a very
> >>  > > very good direction! Guessing can be damaging for predictability, but.
> >>  > > more importantly, guessing has a tendency to compose badly with other
> >>  > > typing features. (it is to be noted, too, that the implementation of
> >>  > > contravariant functions. in GHC, eta-expands the function, which can
> >>  > > casually change its semantics, if the function was bottom).
> >>  > >
> >>  > > So, everything in this proposal does look good to me, except that, I
> >>  > > think, I would like a deprecation route for the
> >>  > > `-XContravariantFunctions` extension. Otherwise, we will be stuck with
> >>  > > legacy code forever.
> >>  > >
> >>  > > Best,
> >>  > > Arnaud
> >>  > > _______________________________________________
> >>  > > 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 Oct 17 13:09:05 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Oct 2019 13:09:05 +0000
Subject: [ghc-steering-committee]
 =?utf-8?q?Quick_look_impredicativity_=28?=
 =?utf-8?q?=23274=29_=E2=80=94_recommendation=3A_accept?=
In-Reply-To: <3ec8918d-e986-4810-a80b-61d4ea21215d@www.fastmail.com>
References: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
 <68e54ee1-df78-4860-948a-f069aebd3293@www.fastmail.com>
 <CAGK9nupdmGKHasFjoRf_gj1RqJoj+H9xmL9c0dXgE6OJ_cxWpw@mail.gmail.com>
 <CAH6fHQnZ5z49La-psJ6zD1+KxKCJwVig5KZJqUREwHaPaZkCNQ@mail.gmail.com>
 <AM6PR83MB0279F58FA4A6A4A07E0B8579AD6D0@AM6PR83MB0279.EURPRD83.prod.outlook.com>
 <CAH6fHQkiVPzvtuYejT+QgkSN9LxiL=MWTTKR0FA7rEeEz9eN3A@mail.gmail.com>
 <3ec8918d-e986-4810-a80b-61d4ea21215d@www.fastmail.com>
Message-ID: <AM6PR83MB02793FAC953FBBA5D873DA0BAD6D0@AM6PR83MB0279.EURPRD83.prod.outlook.com>

|  We can't remove the discussion entirely, right? Removing contravariance is
|  necessary for QuickLook to work for the most common case of impredicative
|  instantiation.

I don't think so -- it just weakens it so that it works in fewer cases.

Best to ask Alejandro -- by putting this technical discussion on the thread rather than on the committee list.

S

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Eric Seidel
|  Sent: 17 October 2019 14:01
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Quick look impredicativity (#274) —
|  recommendation: accept
|  
|  We can't remove the discussion entirely, right? Removing contravariance is
|  necessary for QuickLook to work for the most common case of impredicative
|  instantiation.
|  
|  I would, however, support returning the proposal to its previous
|  recommendation to
|  
|  1. introduce `-X[No]ContravariantFunctions`
|  2. enable `-XContravariantFunctions` by default`
|  3. make `-XImpredicativeTypes` imply `-XNoContravariantFunctions`
|  
|  and move discussion of deprecating contravariance (and any other excesses
|  in the type system) to a follow-on proposal.
|  
|  It seems to me that the above steps are the minimum for the QuickLook
|  proposal to be acceptable on its own.
|  
|  On Thu, Oct 17, 2019, at 07:27, Spiwack, Arnaud wrote:
|  > Sweet!
|  >
|  > Should we, therefore, consider removing the contravariance discussion
|  > from the quick look impredicativity proposal?
|  >
|  > On Thu, Oct 17, 2019 at 1:24 PM Simon Peyton Jones
|  > <simonpj at microsoft.com> wrote:
|  > >  Any other opinion on deprecation of `-XContravariantFunctions`? I'd
|  like this to be planned and to have a schedule. Maybe, as Simon suggested
|  in the Github thread, this should be another discussion, though?____
|  >
|  > > __ __
|  >
|  > > I have produced a GHC Proposal____
|  >
|  > > https://github.com/ghc-proposals/ghc-proposals/pull/287____
|  >
|  > > __ __
|  >
|  > > Simon____
|  >
|  > > __ __
|  >
|  > > *From:* ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
|  > > *Sent:* 17 October 2019 08:05
|  > > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
|  > > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
|  > > *Subject:* Re: [ghc-steering-committee] Quick look impredicativity
|  (#274) — recommendation: accept____
|  >
|  > > __ __
|  >
|  > >  Support seems unanimous so far. Unless someones voices a second
|  opinion by then, I'll accept the proposal early next week.____
|  >
|  > > __ __
|  >
|  > >  Any other opinion on deprecation of `-XContravariantFunctions`? I'd
|  like this to be planned and to have a schedule. Maybe, as Simon suggested
|  in the Github thread, this should be another discussion, though?____
|  >
|  > > __ __
|  >
|  > >  On Wed, Oct 16, 2019 at 7:45 PM Iavor Diatchki
|  <iavor.diatchki at gmail.com> wrote:____
|  >
|  > >>  I haven't had time to read through this proposal, but I am
|  comfortable
|  > >>  accepting it based on the recommendations of others.
|  > >>
|  > >>  On Mon, Oct 14, 2019 at 5:52 PM Eric Seidel <eric at seidel.io> wrote:
|  > >>  >
|  > >>  > I support acceptance too, modulo a few small comments that I left
|  on the GH discussion.
|  > >>  >
|  > >>  > On Mon, Oct 14, 2019, at 02:53, Spiwack, Arnaud wrote:
|  > >>  > > Dear all,
|  > >>  > >
|  > >>  > > As the title implies: I'm hereby recommending accepting the
|  Quick look
|  > >>  > > impredicativity proposal.
|  > >>  > >
|  > >>  > > Summary:
|  > >>  > >
|  > >>  > > The proposal modifies the `-XImpredicativeTypes` extension with
|  a well
|  > >>  > > defined semantics which consists in considering n-ary
|  applications,
|  > >>  > > rather than binary. And look, in such an application, for
|  arguments
|  > >>  > > which absolutely require impredicative instantiation (either
|  > >>  > > universally quantified type applications, or arguments where a
|  > >>  > > universal type is guarded by an invariant type constructor).
|  > >>  > >
|  > >>  > > In order to have the expected behaviour for `($)` and `(.)`, the
|  > >>  > > proposal also makes the left-hand argument of the arrow
|  invariant with
|  > >>  > > respect to instantiation (currently: contravariant). The
|  proposal is to
|  > >>  > > make this change effective, even if `-XRankNTypes` is turned on,
|  but
|  > >>  > > not `-XImpredicativeTypes`. The proposal also introduces an
|  extension
|  > >>  > > `-XContravariantFunctions` to restore the old behaviour, for
|  > >>  > > compatibility.
|  > >>  > >
|  > >>  > > Rational:
|  > >>  > >
|  > >>  > > `-XImpredicativeTypes` is a useful extension which is currently
|  in a
|  > >>  > > rather sad state. I'm happy to see it stabilise to a clear
|  semantics.
|  > >>  > > The semantics in the proposal covers a ton of use cases. It
|  strikes a
|  > >>  > > very good balance between usefulness and predictability.
|  > >>  > >
|  > >>  > > The use of n-ary application in the type system also has good
|  > >>  > > theoretical roots: sequent calculi have n-ary applications. (in
|  > >>  > > manyrespects, bidirectional type systems are also about n-ary
|  > >>  > > application). So I don't consider it a wart at all.
|  > >>  > >
|  > >>  > > The propsal's semantics, including the absence of contravariant
|  > >>  > > functions, goes in the direction of _guessing less things_. This
|  is a
|  > >>  > > direction that many GHC features have taken lately. I think it's
|  a very
|  > >>  > > very good direction! Guessing can be damaging for
|  predictability, but.
|  > >>  > > more importantly, guessing has a tendency to compose badly with
|  other
|  > >>  > > typing features. (it is to be noted, too, that the
|  implementation of
|  > >>  > > contravariant functions. in GHC, eta-expands the function, which
|  can
|  > >>  > > casually change its semantics, if the function was bottom).
|  > >>  > >
|  > >>  > > So, everything in this proposal does look good to me, except
|  that, I
|  > >>  > > think, I would like a deprecation route for the
|  > >>  > > `-XContravariantFunctions` extension. Otherwise, we will be
|  stuck with
|  > >>  > > legacy code forever.
|  > >>  > >
|  > >>  > > Best,
|  > >>  > > Arnaud
|  > >>  > > _______________________________________________
|  > >>  > > 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
|  >
|  _______________________________________________
|  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  Thu Oct 17 13:58:39 2019
From: eric at seidel.io (Eric Seidel)
Date: Thu, 17 Oct 2019 09:58:39 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Quick_look_impredicativity_=28?=
 =?utf-8?q?=23274=29_=E2=80=94_recommendation=3A_accept?=
In-Reply-To: <AM6PR83MB02793FAC953FBBA5D873DA0BAD6D0@AM6PR83MB0279.EURPRD83.prod.outlook.com>
References: <CAH6fHQkVVAKHynY3vu7mMLtuM0u5ZiKY28+ZuKLqrU=_V4qqGA@mail.gmail.com>
 <68e54ee1-df78-4860-948a-f069aebd3293@www.fastmail.com>
 <CAGK9nupdmGKHasFjoRf_gj1RqJoj+H9xmL9c0dXgE6OJ_cxWpw@mail.gmail.com>
 <CAH6fHQnZ5z49La-psJ6zD1+KxKCJwVig5KZJqUREwHaPaZkCNQ@mail.gmail.com>
 <AM6PR83MB0279F58FA4A6A4A07E0B8579AD6D0@AM6PR83MB0279.EURPRD83.prod.outlook.com>
 <CAH6fHQkiVPzvtuYejT+QgkSN9LxiL=MWTTKR0FA7rEeEz9eN3A@mail.gmail.com>
 <3ec8918d-e986-4810-a80b-61d4ea21215d@www.fastmail.com>
 <AM6PR83MB02793FAC953FBBA5D873DA0BAD6D0@AM6PR83MB0279.EURPRD83.prod.outlook.com>
Message-ID: <ba2d8ef8-d69e-462d-a83e-1c42b9f52fb9@www.fastmail.com>

On Thu, Oct 17, 2019, at 09:09, Simon Peyton Jones wrote:
> |  We can't remove the discussion entirely, right? Removing contravariance is
> |  necessary for QuickLook to work for the most common case of impredicative
> |  instantiation.
> 
> I don't think so -- it just weakens it so that it works in fewer cases.

True, I was thinking primarily of ($), which will retain its special rule in the type-checker (for now) regardless.

From iavor.diatchki at gmail.com  Fri Oct 18 18:17:44 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 18 Oct 2019 11:17:44 -0700
Subject: [ghc-steering-committee] Please review #254: Scale back
 "Function Result Type Signatures" Shepherd: SPJ
In-Reply-To: <CAH6fHQn2SNmYvxz8y0DOtuiqdCnOvhMPFBQtexQgMEJVUtU9eQ@mail.gmail.com>
References: <26334dda17346630ad592c9ebc185bd1ab992fd8.camel@joachim-breitner.de>
 <AM6PR83MB02791B1D8707A991E275A5CCAD920@AM6PR83MB0279.EURPRD83.prod.outlook.com>
 <CAH6fHQn2SNmYvxz8y0DOtuiqdCnOvhMPFBQtexQgMEJVUtU9eQ@mail.gmail.com>
Message-ID: <CAGK9nup1aHL0P11LbidP+mEmUWU0mxHpmNvAS5vuWEGWhAC3bg@mail.gmail.com>

The scaling back seems reasonable to me.

Similar to Simon's comment
(https://github.com/ghc-proposals/ghc-proposals/pull/254#issuecomment-542644791)
I am also quite unclear of what a return type annotations like `Num a
=> a -> a` is supposed to mean.  After all, `a` is not universally
quantified here, it is just a name for a type that occurs in the
result, so the definition of the function could already impose
whatever constraints it wants on it...

-Iavor



On Thu, Oct 17, 2019 at 12:11 AM Spiwack, Arnaud
<arnaud.spiwack at tweag.io> wrote:
>
> I'm convinced.
>
> On Wed, Oct 16, 2019 at 12:51 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>
>> Colleagues
>>
>> I recommend acceptance.  I have given my reasoning here:
>> https://github.com/ghc-proposals/ghc-proposals/pull/254#issuecomment-542643788
>>
>> Simon
>>
>> |  -----Original Message-----
>> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
>> |  On Behalf Of Joachim Breitner
>> |  Sent: 14 October 2019 08:35
>> |  To: ghc-steering-committee at haskell.org
>> |  Subject: [ghc-steering-committee] Please review #254: Scale back "Function
>> |  Result Type Signatures" Shepherd: SPJ
>> |
>> |  Dear Committee,
>> |
>> |  this is your secretary speaking:
>> |
>> |  Scale back "Function Result Type Signatures" to keep pattern sigs as-is
>> |  has been proposed by John Ericson
>> |  https://github.com/ghc-proposals/ghc-proposals/pull/254
>> |
>> |
>> |  This proposal amends #228, so I propose Simon PJ as the shepherd,
>> |  because he also shepherded #228.
>> |
>> |  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
>
> _______________________________________________
> 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  Sun Oct 20 10:08:11 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 20 Oct 2019 12:08:11 +0200
Subject: [ghc-steering-committee] Please review #195: newtype Q (TExp a),
	Shepherd: Iavor
Message-ID: <1a67f036fefad9565f0d99f813b7dfcc6c745db1.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Make Q (TExp a) into a newtype
has been updated by Matthew Pickering
https://github.com/ghc-proposals/ghc-proposals/pull/195
https://github.com/mpickering/ghc-proposals/blob/code-texp/proposals/0000-code-texp.rst

I propose Iavor as the shepherd, as he indicated support.

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

Thanks,
Joachim
-- 
Joachim Breitner
  mail 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/20191020/677d0bd4/attachment.sig>