From iavor.diatchki at gmail.com  Mon Apr  1 15:37:17 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 1 Apr 2019 08:37:17 -0700
Subject: [ghc-steering-committee] Please review #177: Simple constrained
 type families, Shepherd: Vitaly
In-Reply-To: <6f575250c72e2c1a21f52ce944c0e84da866be5b.camel@joachim-breitner.de>
References: <6f575250c72e2c1a21f52ce944c0e84da866be5b.camel@joachim-breitner.de>
Message-ID: <CAGK9nurh01C=3_ySCub-Ho6A002Z0NeJTx4Uh-MyOZrUAAFuEA@mail.gmail.com>

There is a typo in the URL to the proposal, here is the pull request for
177:

https://github.com/ghc-proposals/ghc-proposals/pull/177

On Fri, Mar 29, 2019 at 4:23 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Simple constrained type families
> has been proposed by Alex Williams
> https://github.com/ghc-proposals/ghc-proposals/pull/117
>
> https://github.com/typedrat/ghc-proposals/blob/constrained-type-families/proposals/0000-simple-constrained-type-families.rst
>
> I propose Vitaly as the Shepherd.
>
> Please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> I suggest you make a recommendation, in a new e-mail thread with the
> proposal number in the subject, about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
>
> Thanks,
> Joachim
> --
> Joachim Breitner
>   mail 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/20190401/f772d35c/attachment.html>

From iavor.diatchki at gmail.com  Wed Apr  3 16:45:48 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 3 Apr 2019 09:45:48 -0700
Subject: [ghc-steering-committee] Discussion on #155 Type Variable in
	Labmdas
In-Reply-To: <5b7eb5a6-d961-43b2-a93d-96d23798413a@www.fastmail.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <CAGK9nurqdZA3Zr3UXSVz9bdeThxH96RgsXu=-mDzukOLmdY6JQ@mail.gmail.com>
 <5b7eb5a6-d961-43b2-a93d-96d23798413a@www.fastmail.com>
Message-ID: <CAGK9nup0=1PtizTFb-As+cmuUi-nO31kj5RrJaRWqNhjtfRO4A@mail.gmail.com>

Hello,

perhaps it is time to come up with some sort of decision here.  Based on
the replies to this thread we seem to have the following opinions:
  1. Eric and Richard seem to be quite keen on the feature
  2. Simon is on the fence, but likes it because it introduces System F
vocabulary to Haskell
  3. I am skeptical of the proposal as is, as I think it adds additional
complexity to the language (more non-orthogonal features) without
significant payoff.

Does anyone else have anything else to add?

-Iavor



On Tue, Mar 26, 2019 at 6:48 PM Eric Seidel <eric at seidel.io> wrote:

> On Tue, Mar 26, 2019, at 13:17, Iavor Diatchki wrote:
> > My concern is that the notation certainly suggests that you are binding
> > types with the @ syntax, but in really it is still the type signature
> > that guides the binding of the variables and the @ parameters just
> > duplicate the information from the type signature.
>
> But you are binding types with the @ syntax. The proposal gives a number
> of examples where the @-bound type variable is bound by a different name
> (or not at all) in the type signature. Many are contrived, to demonstrate
> where the binders are allowed, but the higher-rank and proxy-eliding
> examples look compelling to me.
>
> We also already allow repeated value binders in Haskell. When I write a
> function in equational style, I have to rebind each argument in each
> alternate equation. Sometimes this is noisy and I'll prefer a single
> equation with an explicit `case`. But for functions where the body is
> sizable, I find the repeated binders to be quite helpful because the scopes
> are smaller. I can easily see the same benefit applying to type binders.
> Ultimately, I think this comes down to a matter of style, and I favor
> letting Haskell programmers pick the style that works best for them.
>
> Eric
> _______________________________________________
> 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/20190403/3d6abc87/attachment.html>

From simonpj at microsoft.com  Thu Apr  4 10:10:24 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 4 Apr 2019 10:10:24 +0000
Subject: [ghc-steering-committee] Discussion on #155 Type Variable
	in	Labmdas
In-Reply-To: <CAGK9nup0=1PtizTFb-As+cmuUi-nO31kj5RrJaRWqNhjtfRO4A@mail.gmail.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <CAGK9nurqdZA3Zr3UXSVz9bdeThxH96RgsXu=-mDzukOLmdY6JQ@mail.gmail.com>
 <5b7eb5a6-d961-43b2-a93d-96d23798413a@www.fastmail.com>
 <CAGK9nup0=1PtizTFb-As+cmuUi-nO31kj5RrJaRWqNhjtfRO4A@mail.gmail.com>
Message-ID: <DB7PR83MB0298F8FDED14784C9D60871FAD500@DB7PR83MB0298.EURPRD83.prod.outlook.com>

I really am on the fence.   Good things:


  *   Richard’s first motivating example, where we still need Proxy, is quite convincing.



  *   It fills out an obvious gap, with the right sort of intro/elim duality with visible type application.



  *   And I like that it gives us a language in which to talk about System F elaboration of the program, if and when we want to.  E.g. we can say: if you write



f x = Just x



it is as if you had written



f :: forall a. a -> Maybe a

f = \@a \(x::a). Just x


Less good:

  *   It’s still incomplete concerning (B) because we can’t talk about dictionary bindings.
  *   It adds more complexity.
  *   We are not under real pressure to do this now.

I’d like to hear from a broader range of opinion.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 03 April 2019 17:46
To: Eric Seidel <eric at seidel.io>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas

Hello,

perhaps it is time to come up with some sort of decision here.  Based on the replies to this thread we seem to have the following opinions:
  1. Eric and Richard seem to be quite keen on the feature
  2. Simon is on the fence, but likes it because it introduces System F vocabulary to Haskell
  3. I am skeptical of the proposal as is, as I think it adds additional complexity to the language (more non-orthogonal features) without significant payoff.

Does anyone else have anything else to add?

-Iavor



On Tue, Mar 26, 2019 at 6:48 PM Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
On Tue, Mar 26, 2019, at 13:17, Iavor Diatchki wrote:
> My concern is that the notation certainly suggests that you are binding
> types with the @ syntax, but in really it is still the type signature
> that guides the binding of the variables and the @ parameters just
> duplicate the information from the type signature.

But you are binding types with the @ syntax. The proposal gives a number of examples where the @-bound type variable is bound by a different name (or not at all) in the type signature. Many are contrived, to demonstrate where the binders are allowed, but the higher-rank and proxy-eliding examples look compelling to me.

We also already allow repeated value binders in Haskell. When I write a function in equational style, I have to rebind each argument in each alternate equation. Sometimes this is noisy and I'll prefer a single equation with an explicit `case`. But for functions where the body is sizable, I find the repeated binders to be quite helpful because the scopes are smaller. I can easily see the same benefit applying to type binders. Ultimately, I think this comes down to a matter of style, and I favor letting Haskell programmers pick the style that works best for them.

Eric
_______________________________________________
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%7C8371ed497872442e7ba708d6b853dea8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636899067690452644&sdata=uPf6eWyl9bxDxwsVqC%2FxB%2FqtVXwCEz2WP5LAHsURB3I%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190404/6ff6ca1d/attachment-0001.html>

From mail at joachim-breitner.de  Wed Apr 17 06:51:45 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 08:51:45 +0200
Subject: [ghc-steering-committee] #207: Type variables in TH	quotes
 (recommendation: reject)
In-Reply-To: <7F193E16-0CB9-40DA-A5FD-A641ECB0D767@justtesting.org>
References: <597EFB29-EFF6-4150-AEF3-920096A5BB47@cs.brynmawr.edu>
 <AM0PR83MB0289761200029510A4CF37C8AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <7F193E16-0CB9-40DA-A5FD-A641ECB0D767@justtesting.org>
Message-ID: <e82659783ff257b780e28813c7f2443222491d74.camel@joachim-breitner.de>

Hi,

Am Freitag, den 08.03.2019, 11:14 +0100 schrieb Manuel M T Chakravarty:
> > Am 08.03.2019 um 10:56 schrieb Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>:
> > 
> > There’s a simple bug-fix for now: just reject the program.  If we get lots of people yelling that they really want such programs, we can tackle it then.
> 
> Sounds like the right approach to me, too.


that looks like consensus to me, will mark as rejected.

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/20190417/7e4b0c2b/attachment.sig>

From mail at joachim-breitner.de  Wed Apr 17 06:54:16 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 08:54:16 +0200
Subject: [ghc-steering-committee] GHC proposal #203: PtrRep.
 Recommendation: accept
In-Reply-To: <0A91B676-E13F-4A1B-BB4F-415FDC1851C1@richarde.dev>
References: <DB7PR83MB0298D50C104F06DB43A5973CAD400@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <727BB5E0-841F-41DE-8AB0-1C44C8312D5D@cs.brynmawr.edu>
 <DB7PR83MB0298017BBBE331016937C870AD400@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <0A91B676-E13F-4A1B-BB4F-415FDC1851C1@richarde.dev>
Message-ID: <e669f858941d4227334f09ac0d1f673f119bda45.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 19.03.2019, 23:22 -0400 schrieb Richard Eisenberg:
> OK -- yes, that all makes sense. I support acceptance.

so be it.

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/20190417/6b4d70b4/attachment.sig>

From mail at joachim-breitner.de  Wed Apr 17 07:00:33 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 09:00:33 +0200
Subject: [ghc-steering-committee] #190: Module qualified syntax,
 recommendation: accept
In-Reply-To: <2A4CEC6F-5A55-43D8-9714-F507AE1A8CBC@cs.brynmawr.edu>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
 <CALpVSmP+s2L0cWZ6WqJnoX-v7xmn8ofit3ekawMPacAjnJdp9w@mail.gmail.com>
 <CAGK9nuqaow5pdoebwcQTD8Af2ygpUvmjtW9ACATpZ9c2vEiT3A@mail.gmail.com>
 <2A4CEC6F-5A55-43D8-9714-F507AE1A8CBC@cs.brynmawr.edu>
Message-ID: <7e2210851b53e68fb08f81da78ad22039816f517.camel@joachim-breitner.de>

Hi,

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

 * FlexibleImports
 * QualifiedLast
 * QualifiedImportsPostpositive
 * ImportQualifiedPost

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

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/20190417/77ff3e3c/attachment.sig>

From mail at joachim-breitner.de  Wed Apr 17 07:01:58 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 09:01:58 +0200
Subject: [ghc-steering-committee] #179: Tweak the printing of foralls,
 recommendation: accept
In-Reply-To: <5DEA3DD0-273F-4951-8803-6775231A52CC@richarde.dev>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <baf92eee08c3d851f3145295db267f121b21beec.camel@joachim-breitner.de>
 <CAGK9nuqVMje8Z+HKgz6OD8HpW4c3zZmWRjgKX5J2YbcKKj57tQ@mail.gmail.com>
 <08E3F317-362B-414A-A705-11C60A6AF679@richarde.dev>
 <DB7PR83MB0298F6833FA9735938F13F9BAD440@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAGK9nuojLMuO6QxN0-JpBXjbJVwrrCqO1Qjy-2uD3Bmf7g1iBw@mail.gmail.com>
 <5DEA3DD0-273F-4951-8803-6775231A52CC@richarde.dev>
Message-ID: <6d87b2cb0b18dd22820ddeb5a0b36290cfe7e188.camel@joachim-breitner.de>

Hi Iavor,

have these explanations helped your understanding here? Do they address
your concerns?

Cheers,
Joachim

Am Freitag, den 15.03.2019, 14:03 -0400 schrieb Richard Eisenberg:
> On Mar 15, 2019, at 1:04 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> > 
> > This is a bit orthogonal, but what would you expect to see in this case:
> > 
> > type T b = Bool
> > bar :: (a ~ Int) => a -> T b -> a
> > 
> > :t bar
> 
> Without -fprint-explicit-foralls: (a ~ Int) => a -> T b -> a
> With -fprint-explicit-foralls: forall a b. (a ~ Int) => a -> T b -> a
> 
> > :t bar @Bool
> 
> Without -fprint-explicit-foralls: (Bool ~ Int) => Bool -> T b -> Bool
> With -fprint-explicit-foralls: forall b. (Bool ~ Int) => Bool -> T b -> Bool
> 
> > I guess the answer to these depends on if `b` is quantified or not.
> 
> b *is* quantified -- the quantification happens on the type as the user writes it.
> 
> Richard
> 
> > 
> > 
> > 
> > 
> > On Fri, Mar 15, 2019 at 1:26 AM Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > > This looks particularly confusing without the explicit `forall`, although it seems questionable either way.
> > >  
> > > Why?  GHC often suppresses foralls when printing types; and had -fprint-explicit-foralls to stop doing that.
> > >  
> > > Simon
> > >  
> > > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
> > > Sent: 14 March 2019 23:46
> > > To: Iavor Diatchki <iavor.diatchki at gmail.com>
> > > Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
> > > Subject: Re: [ghc-steering-committee] #179: Tweak the printing of foralls, recommendation: accept
> > >  
> > >  
> > > > On Mar 14, 2019, at 6:18 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> > > >  
> > > > bar :: forall a b. (a ~ Int) => a -> b -> a
> > > >  
> > > > Is it the case that `:t bar @Bool` will print
> > > >  
> > > > bar :: (Bool ~ Int) => Bool -> b -> Bool
> > > >  
> > > > This looks particularly confusing without the explicit `forall`, although it seems questionable either way.
> > > 
> > >  
> > > Yes, you understand correctly. `:t bar @Bool` will print that unfortunate type. I agree this is questionable. But I don't know how to do better. The current state of affairs is awkward in a different way, in that `:t bar @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int -> b -> Int`, even though a further visible type application is possible. Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even though the next variable to be instantiated is `a`. This is why we have `:type +v`.
> > >  
> > > The direction in the proposal came about in wondering if it's possible to improve the mechanics of `:t` (without the `+v`). After we thought of doing maximal instantiation of inferred arguments (but no generalization), then we realized we could drop `:type +v` as redundant. I agree it's something of an uneasy compromise here, but I think any choice is going to have unfortunate behavior in some scenarios.
> > >  
> > > Richard
> > > 
> > > 
> > > >  
> > > > -Iavor
> > > >  
> > > >  
> > > >  
> > > > On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner <mail at joachim-breitner.de> wrote:
> > > > > Dear Committee,
> > > > > 
> > > > > Richard, in collarboration with Simon PJ, proposes some tweaks to how
> > > > > foralls are printed by GHC.
> > > > > 
> > > > > In particular, whenever a type variable is printed with an forall, it
> > > > > is printed with {a} unless it is a specified variable. And there are
> > > > > tweaks to what :type does with its argument that makes it more useful,
> > > > > and obviates the need for a separate :type +v.
> > > > > https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst
> > > > > 
> > > > > I like that it actually simplifies the UI (by removing :type +v), so I
> > > > > recommend acceptance.
> > > > > 
> > > > > Cheers,
> > > > > Joachim
> > > > > -- 
> > > > > Joachim Breitner
> > > > >   mail at joachim-breitner.de
> > > > >   http://www.joachim-breitner.de/
> > > > > 
> > > > > -----BEGIN PGP SIGNATURE-----
> > > > > 
> > > > > iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7
> > > > > 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN
> > > > > R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM
> > > > > DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+
> > > > > cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA
> > > > > hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr
> > > > > mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M
> > > > > 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE
> > > > > r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt
> > > > > fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H
> > > > > c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05
> > > > > rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg=
> > > > > =1qbg
> > > > > -----END PGP SIGNATURE-----
> > > > > _______________________________________________
> > > > > 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/

-------------- 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/20190417/7aa4e92f/attachment.sig>

From mail at joachim-breitner.de  Wed Apr 17 07:05:30 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 09:05:30 +0200
Subject: [ghc-steering-committee] #176: SCC Parsing,
 recommendation: accept
In-Reply-To: <CANsrgP+JE4m310kcSC4yT=mN-ONtXGTefi_xtFhioD8rXNgTVg@mail.gmail.com>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <CANsrgP+JE4m310kcSC4yT=mN-ONtXGTefi_xtFhioD8rXNgTVg@mail.gmail.com>
Message-ID: <58bb642632f487af91779321dca755210dea8d4b.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 06.02.2019, 08:35 +0000 schrieb marlowsd at gmail.com:
> So, I propose we accept this.

accepted.

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/20190417/918331dc/attachment.sig>

From mail at joachim-breitner.de  Wed Apr 17 07:15:49 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 09:15:49 +0200
Subject: [ghc-steering-committee] Discussion on #155 Type Variable
	in	Labmdas
In-Reply-To: <DB7PR83MB0298F8FDED14784C9D60871FAD500@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <CAGK9nurqdZA3Zr3UXSVz9bdeThxH96RgsXu=-mDzukOLmdY6JQ@mail.gmail.com>
 <5b7eb5a6-d961-43b2-a93d-96d23798413a@www.fastmail.com>
 <CAGK9nup0=1PtizTFb-As+cmuUi-nO31kj5RrJaRWqNhjtfRO4A@mail.gmail.com>
 <DB7PR83MB0298F8FDED14784C9D60871FAD500@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <7f2af94c1df8d825ea414cd354e77c247f482c91.camel@joachim-breitner.de>

Hi,

there is lots of fence-sitting here (and I am also on that particular
fence). But to make shake the fence: Let’s do it! I think people will
find good and surprising uses for this feature.

Iavor, your original message did not carry a concrete recommendation.
Did the discussion help you to form an opinion?

Cheers,
Joachim


Am Donnerstag, den 04.04.2019, 10:10 +0000 schrieb Simon Peyton Jones
via ghc-steering-committee:
> I really am on the fence.   Good things:
>  
> Richard’s first motivating example, where we still need Proxy, is quite convincing.
>  
> It fills out an obvious gap, with the right sort of intro/elim duality with visible type application.
>  
> And I like that it gives us a language in which to talk about System F elaboration of the program, if and when we want to.  E.g. we can say: if you write
>  
> f x = Just x
>  
> it is as if you had written
>  
> f :: forall a. a -> Maybe a
> f = \@a \(x::a). Just x
>  
> Less good:
> It’s still incomplete concerning (B) because we can’t talk about dictionary bindings.
> It adds more complexity.
> We are not under real pressure to do this now.
>  
> I’d like to hear from a broader range of opinion.
>  
> Simon
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
> Sent: 03 April 2019 17:46
> To: Eric Seidel <eric at seidel.io>
> Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas
>  
> Hello,
>  
> perhaps it is time to come up with some sort of decision here.  Based on the replies to this thread we seem to have the following opinions:
>   1. Eric and Richard seem to be quite keen on the feature
>   2. Simon is on the fence, but likes it because it introduces System F vocabulary to Haskell
>   3. I am skeptical of the proposal as is, as I think it adds additional complexity to the language (more non-orthogonal features) without significant payoff.
>  
> Does anyone else have anything else to add?
>  
> -Iavor
>  
>  
>  
> On Tue, Mar 26, 2019 at 6:48 PM Eric Seidel <eric at seidel.io> wrote:
> > On Tue, Mar 26, 2019, at 13:17, Iavor Diatchki wrote:
> > > My concern is that the notation certainly suggests that you are binding 
> > > types with the @ syntax, but in really it is still the type signature 
> > > that guides the binding of the variables and the @ parameters just 
> > > duplicate the information from the type signature.
> > 
> > But you are binding types with the @ syntax. The proposal gives a number of examples where the @-bound type variable is bound by a different name (or not at all) in the type signature. Many are contrived, to demonstrate where the binders are allowed, but the higher-rank and proxy-eliding examples look compelling to me.
> > 
> > We also already allow repeated value binders in Haskell. When I write a function in equational style, I have to rebind each argument in each alternate equation. Sometimes this is noisy and I'll prefer a single equation with an explicit `case`. But for functions where the body is sizable, I find the repeated binders to be quite helpful because the scopes are smaller. I can easily see the same benefit applying to type binders. Ultimately, I think this comes down to a matter of style, and I favor letting Haskell programmers pick the style that works best for them.
> > 
> > Eric
> > _______________________________________________
> > 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/

-------------- 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/20190417/8c70fb98/attachment-0001.sig>

From mail at joachim-breitner.de  Wed Apr 17 09:43:09 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 11:43:09 +0200
Subject: [ghc-steering-committee] Status
Message-ID: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>

Dear committee,

has it really been three months since the last status?
Time flies like an arrow (and fruit flies like banana).

Some proposals are stalled on individual members of the committee who
have become much less active recently (Manuel, Ben, partly Chris). I
encourage you (and everyone else of course) to realistically assess
your commitment, and – if you think that that’s in the best interest of
all involved – indicate if we should start to find new members with
fresh engery.

Anyways, quite a few things have happened:

 * were asked to review these proposals:
   #167 Deprecated Entities (shepherd: Vitaly)
   #203 PtrRep (shepherd: SPJ)
   #176 SCC Parsing (shepherd: Simon M)
   #193 forall keyword (shepherd: Eric)
   #155 Type Vars in Lambdas (shepherd: Iavor)
   #209 Levity polymorphic lift (shepherd: Eric)
   #210 -Wredundand-minimal-methods (shepherd: me)
   #190 module qualified syntax (shepherd: Simon M)
   #207 type variables in quotations (shepherd: Richard)
   #195 newtype Q (shepherd: Vitaly)
   #204 nested brackets (shepherd: Iavor)
   #179 Printing of foralls (shepherd: me)
   #177 constrained type families (shepherd: Vitaly)

 * got a recommendation from shepherds about:
   #193 forall keyword (rec: acccept)
   #176 SCC Parsing (rec: accept)
   #210 -Wredundand-minimal-methods (rec: accept)
   #209 Levity polymorphic lift (rec: accept)
   #207 type variables in quotations (rec: reject)
   #167 Deprecated Entities (rec: accept)
   #195 newtype Q (rec: accept)
   #190 module qualified syntax (rec: accept)
   #204 nested brackets (rec: shelve)
   #179 Printing of foralls (rec: acccept)
   #203 PtrRep (rec: accept)

 * decided about the following proposals
   #158 Add setField to HasField (accept)
   #28 Bundling patterns with type synonyms (reject)
   #167 Deprecated Entities (reject)
   #193 forall keyword (acccept)
   #207 type variables in quotations (reject)
   #195 newtype Q (needs revision)
   #210 -Wredundand-minimal-methods (accept)
   #203 PtrRep (accept)
   #176 SCC Parsing (accept)

We currently have to act on the following 8 proposals, up two since the
last status:

Levity polymorphic lift
https://github.com/ghc-proposals/ghc-proposals/pull/209
Shepherd: Eric
Status: To be accepted after minor tweaks by the authors

Module qualified syntax
https://github.com/ghc-proposals/ghc-proposals/pull/190
Shepherd: Simon M
Status: To be accepted after we decide on the pragma name

Tweak printing of foralls
https://github.com/ghc-proposals/ghc-proposals/pull/179
Shepherd: me
Status: Ongoing discussion (Iavor had questions)

Simple constrained type families
https://github.com/ghc-proposals/ghc-proposals/pull/177
Shepherd: Vitaly
Status: Waiting for Vitaly to make a recommendation

Binding type variables in lambda expressions
https://github.com/ghc-proposals/ghc-proposals/pull/155
Shepherd: Iavor
Status: Discussion ongoing, Iavor did not make an official recommendation

Type annotated quoters
https://github.com/ghc-proposals/ghc-proposals/pull/125
Shepherd: Manuel
Status: Still waiting for recommendation. Manuel?

Provenance-Qualified Package Imports
https://github.com/ghc-proposals/ghc-proposals/pull/115
Shepherd: Ben
Status: Still waiting for recommendation. This is pretty old!

ExtraCommas
https://github.com/ghc-proposals/ghc-proposals/pull/87
Shepherd: Chris
Recommendation: accept
Status: Met with some reservation. Chris, please pick this up again.


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/20190417/8cd3a73a/attachment.sig>

From mail at joachim-breitner.de  Wed Apr 17 10:30:02 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 12:30:02 +0200
Subject: [ghc-steering-committee] Unhappy proposers
Message-ID: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>

Dear Committee,

I have received an email from one of our most productive proposal
writers, Matthew, who we have left quite unhappy with the process, and
I hope we can take the time to see what went wrong, and what we can do
differently to not be wasteful with the motivation of the Matthews out
there.

Matthew asked me to paraphrase his complaints, just to get this started
on a productive tone. So I’ll play annoyance tone firewall.

The PR in question is #207 (Fix the treatment of type variables in
quotations), and he has three main reasons why he is unsatsified:


1. Delay
========

There was a long delay between consensus on the mailing list (March 7)
and the official announcement on GitHub.


This is clearly true, and is purely on me, and I am sorry for that.

I try to do a monthly sweep of the committee activities, including
closing or accepting proposals where I did not do it directly, but
well, the last month turned out to be 90 days or so … I will try to be
better here, but also appreciate nudges.

Also, shepherds, if you detect consensus, feel encouraged to respond to
the list with “Looks like we can accept/reject this, Joachim, can you
do it?” Then I am likely to do the bureaucratic acts directly.


2. Lack of understanding
========================

Matthew has the impression that the itch he was trying to scratch, the
overall needs of Typed Template Haskell (a still rarely used feature,
but dear to his hard) and his solutions are not well understood.


I am not in a position (and this is maybe not the right thread) to
judge who is wrong and who is right. And maybe that is partly the
point: Not the whole committee is in a position to understand the
implications of a change to, say, Typed Template Haskell. Do we need to
adjust our process to that somehow? How do we deal with that?

Also, I think we can recognize that we should not underestimate the
motivation and the actual needs of the people who sit down and write
proposals, and assume good faith. Matthew says that the bug he tries to
fix here does affect his actual work, and in particular that our
solution (forbid type variables in splices) does not actually solve his
problem.


3. Lack of communication
========================

Finally, Matthew points out that some of the reasons that led to the
rejection were not properly discussed with him as the author first.


I agree that this is a problematic pattern, and one that I have
observed a few times too: A proposal gets proposed, the shepherd
recommends rejection (or the discussion veers in that direction), we
discuss the pros and cons, and then just reject it. I understand how a
proposer might feel helpless in that situation.

Worse, they see that proposals by committee members have an easier
time, because then the committee member happens to be on the list and
can defend and explain their proposal better. (This point was not
raised by Matthew, but added by me).


Luckily, I think this problem can be solved in a procedural way. 

   Procedural proposal A:

   When a shepherd intents to proposal rejecting a proposal, he first
   writes his rationale on the Github discussion thread and waits for
   the author’s rebuttal. This can (and is encouraged) to lead to a
   discussion between shepherd and authors (and any further interesting
   party or committee member) with one of these outcomes:
    * the shepherd is swayed and proposes acceptance,
    * the proposal is improved and the shepherd can propose to accept  
      it,
    * the authors withdraw the proposal,
    * no agreement can be reached, and the discussion comes to an end.
      Now the shepherd may propose rejecting to the committee.


I think this process would give the authors a bigger say and role, more
insight and warning into a possible rejection, and thus hopefully
better satisfaction in the end.


A simpler variant of that with a similar result would be something we
have discussed earlier:

   Procedural proposal B:

   The committee discusses proposals on Github; the mailing list is
   only used for announcement (new proposal and shepherd assignment,
   shepherd’s recommendation, decision, status messages,
   metadiscussions like this one.)


What are you opinions here?

Matthew, would any of these procedures have given you a better
experience and/or outcome?


I hope we can turn Matthew’s bad experience into something with a
productive outcome!

(Note that I have not included all technical details of Matthew’s email
here, to keep this focused on the procedural problems he points out.
Matthew, maybe you can raise the good technical points on Github
separately?)


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/20190417/acd96a72/attachment.sig>

From simonpj at microsoft.com  Wed Apr 17 11:01:47 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 17 Apr 2019 11:01:47 +0000
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
Message-ID: <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>

Thanks Joachim - and thank you Matthew for taking the trouble to write.

Some brief responses

* I don't see any reason to conduct a conversation on the steering
  committee email list, rather than on the Github converation.  In
  fact doing it by email is *less* good because the discussion is in
  two places.  The only reason to do so would be to have a private
  conversation -- but the email list is by design public.  So yes
  to Github; and let's explicitly invite the author to participate
  in the conversation if they wish.

* Delay.  This is a challenge because everyone is a volunteer and
  everyone is busy.  Should I spend the next 30 mins reviewing a
  GHC proposal or a patch that fixes a bug?  That delay is hard on 
  the author, but I see no way to fully solve that tension.

* Cost and benefit.  The biggest tension I feel is that every incremental
  change to the language makes it more complicated, makes the compiler
  more complicated, and imposes a new maintenance burden on the
  implementors, forever.  There are many features I value (e.g. partial
  type signatures, or pattern synonyms) whose authors have long since
  moved on, and I am the de-facto maintainer.

  It's not wrong to move on. It's a huge service for someone to propose,
  design, and implement something.  But is genuinely difficult to balance
  the immediate benefits (esp to the author) against the long-term costs.

* Audience.  Sometimes the population that genuinely wants a feature is
  pretty small.  That does not make it a bad proposal -- sometimes people
  don't know they want something till it's there.  But it does make it
  harder to generate the time and energy to dig into the technical details.

It may be that we could articulate some of these tensions on our wiki pages.
Doing so won't solve them but might help people to feel less badly treated.
And THAT is a very important goal.

Matthew: you are a major contributor to GHC -- thank you!

Simon
 

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Joachim Breitner
|  Sent: 17 April 2019 11:30
|  To: ghc-steering-committee at haskell.org
|  Cc: Matthew Pickering <matthewtpickering at gmail.com>
|  Subject: [ghc-steering-committee] Unhappy proposers
|  
|  Dear Committee,
|  
|  I have received an email from one of our most productive proposal writers,
|  Matthew, who we have left quite unhappy with the process, and I hope we
|  can take the time to see what went wrong, and what we can do differently
|  to not be wasteful with the motivation of the Matthews out there.
|  
|  Matthew asked me to paraphrase his complaints, just to get this started on
|  a productive tone. So I’ll play annoyance tone firewall.
|  
|  The PR in question is #207 (Fix the treatment of type variables in
|  quotations), and he has three main reasons why he is unsatsified:
|  
|  
|  1. Delay
|  ========
|  
|  There was a long delay between consensus on the mailing list (March 7) and
|  the official announcement on GitHub.
|  
|  
|  This is clearly true, and is purely on me, and I am sorry for that.
|  
|  I try to do a monthly sweep of the committee activities, including closing
|  or accepting proposals where I did not do it directly, but well, the last
|  month turned out to be 90 days or so … I will try to be better here, but
|  also appreciate nudges.
|  
|  Also, shepherds, if you detect consensus, feel encouraged to respond to
|  the list with “Looks like we can accept/reject this, Joachim, can you do
|  it?” Then I am likely to do the bureaucratic acts directly.
|  
|  
|  2. Lack of understanding
|  ========================
|  
|  Matthew has the impression that the itch he was trying to scratch, the
|  overall needs of Typed Template Haskell (a still rarely used feature, but
|  dear to his hard) and his solutions are not well understood.
|  
|  
|  I am not in a position (and this is maybe not the right thread) to judge
|  who is wrong and who is right. And maybe that is partly the
|  point: Not the whole committee is in a position to understand the
|  implications of a change to, say, Typed Template Haskell. Do we need to
|  adjust our process to that somehow? How do we deal with that?
|  
|  Also, I think we can recognize that we should not underestimate the
|  motivation and the actual needs of the people who sit down and write
|  proposals, and assume good faith. Matthew says that the bug he tries to
|  fix here does affect his actual work, and in particular that our solution
|  (forbid type variables in splices) does not actually solve his problem.
|  
|  
|  3. Lack of communication
|  ========================
|  
|  Finally, Matthew points out that some of the reasons that led to the
|  rejection were not properly discussed with him as the author first.
|  
|  
|  I agree that this is a problematic pattern, and one that I have observed a
|  few times too: A proposal gets proposed, the shepherd recommends rejection
|  (or the discussion veers in that direction), we discuss the pros and cons,
|  and then just reject it. I understand how a proposer might feel helpless
|  in that situation.
|  
|  Worse, they see that proposals by committee members have an easier time,
|  because then the committee member happens to be on the list and can defend
|  and explain their proposal better. (This point was not raised by Matthew,
|  but added by me).
|  
|  
|  Luckily, I think this problem can be solved in a procedural way.
|  
|     Procedural proposal A:
|  
|     When a shepherd intents to proposal rejecting a proposal, he first
|     writes his rationale on the Github discussion thread and waits for
|     the author’s rebuttal. This can (and is encouraged) to lead to a
|     discussion between shepherd and authors (and any further interesting
|     party or committee member) with one of these outcomes:
|      * the shepherd is swayed and proposes acceptance,
|      * the proposal is improved and the shepherd can propose to accept
|        it,
|      * the authors withdraw the proposal,
|      * no agreement can be reached, and the discussion comes to an end.
|        Now the shepherd may propose rejecting to the committee.
|  
|  
|  I think this process would give the authors a bigger say and role, more
|  insight and warning into a possible rejection, and thus hopefully better
|  satisfaction in the end.
|  
|  
|  A simpler variant of that with a similar result would be something we have
|  discussed earlier:
|  
|     Procedural proposal B:
|  
|     The committee discusses proposals on Github; the mailing list is
|     only used for announcement (new proposal and shepherd assignment,
|     shepherd’s recommendation, decision, status messages,
|     metadiscussions like this one.)
|  
|  
|  What are you opinions here?
|  
|  Matthew, would any of these procedures have given you a better experience
|  and/or outcome?
|  
|  
|  I hope we can turn Matthew’s bad experience into something with a
|  productive outcome!
|  
|  (Note that I have not included all technical details of Matthew’s email
|  here, to keep this focused on the procedural problems he points out.
|  Matthew, maybe you can raise the good technical points on Github
|  separately?)
|  
|  
|  Cheers,
|  Joachim
|  
|  
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|    http://www.joachim-breitner.de/


From eric at seidel.io  Wed Apr 17 15:16:06 2019
From: eric at seidel.io (Eric Seidel)
Date: Wed, 17 Apr 2019 11:16:06 -0400
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
 <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>

The cost/benefit and audience points are important issues that we have to consider when evaluating a proposal, but I'm not sure that they are that relevant to this particular situation.

It seems like the big issue apart from the delay (which I think we can all agree is a problem) was a failure of communication. We were under the impression that rejecting the programs would also solve Matthew's problem, but it seems we were mistaken. I think that alone points to the need for a more flexible process than an up-or-down decision.

I like Joachim's first suggestion for point 3, that we deliberate on the list, present an initial response, and invite a rebuttal from the author before making a final decision. I think that keeping our initial deliberations on the list makes sense because it provides a more focussed forum for us to discuss the proposal. But I don't feel too strongly about deliberating on the list vs github.

Thank you for sharing your frustrations with us, Matthew. We all appreciate the work you do.

Eric

On Wed, Apr 17, 2019, at 07:02, Simon Peyton Jones via ghc-steering-committee wrote:
> Thanks Joachim - and thank you Matthew for taking the trouble to write.
> 
> Some brief responses
> 
> * I don't see any reason to conduct a conversation on the steering
>   committee email list, rather than on the Github converation.  In
>   fact doing it by email is *less* good because the discussion is in
>   two places.  The only reason to do so would be to have a private
>   conversation -- but the email list is by design public.  So yes
>   to Github; and let's explicitly invite the author to participate
>   in the conversation if they wish.
> 
> * Delay.  This is a challenge because everyone is a volunteer and
>   everyone is busy.  Should I spend the next 30 mins reviewing a
>   GHC proposal or a patch that fixes a bug?  That delay is hard on 
>   the author, but I see no way to fully solve that tension.
> 
> * Cost and benefit.  The biggest tension I feel is that every incremental
>   change to the language makes it more complicated, makes the compiler
>   more complicated, and imposes a new maintenance burden on the
>   implementors, forever.  There are many features I value (e.g. partial
>   type signatures, or pattern synonyms) whose authors have long since
>   moved on, and I am the de-facto maintainer.
> 
>   It's not wrong to move on. It's a huge service for someone to propose,
>   design, and implement something.  But is genuinely difficult to balance
>   the immediate benefits (esp to the author) against the long-term costs.
> 
> * Audience.  Sometimes the population that genuinely wants a feature is
>   pretty small.  That does not make it a bad proposal -- sometimes people
>   don't know they want something till it's there.  But it does make it
>   harder to generate the time and energy to dig into the technical details.
> 
> It may be that we could articulate some of these tensions on our wiki pages.
> Doing so won't solve them but might help people to feel less badly treated.
> And THAT is a very important goal.
> 
> Matthew: you are a major contributor to GHC -- thank you!
> 
> Simon
>  
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> |  On Behalf Of Joachim Breitner
> |  Sent: 17 April 2019 11:30
> |  To: ghc-steering-committee at haskell.org
> |  Cc: Matthew Pickering <matthewtpickering at gmail.com>
> |  Subject: [ghc-steering-committee] Unhappy proposers
> |  
> |  Dear Committee,
> |  
> |  I have received an email from one of our most productive proposal writers,
> |  Matthew, who we have left quite unhappy with the process, and I hope we
> |  can take the time to see what went wrong, and what we can do differently
> |  to not be wasteful with the motivation of the Matthews out there.
> |  
> |  Matthew asked me to paraphrase his complaints, just to get this started on
> |  a productive tone. So I’ll play annoyance tone firewall.
> |  
> |  The PR in question is #207 (Fix the treatment of type variables in
> |  quotations), and he has three main reasons why he is unsatsified:
> |  
> |  
> |  1. Delay
> |  ========
> |  
> |  There was a long delay between consensus on the mailing list (March 7) and
> |  the official announcement on GitHub.
> |  
> |  
> |  This is clearly true, and is purely on me, and I am sorry for that.
> |  
> |  I try to do a monthly sweep of the committee activities, including closing
> |  or accepting proposals where I did not do it directly, but well, the last
> |  month turned out to be 90 days or so … I will try to be better here, but
> |  also appreciate nudges.
> |  
> |  Also, shepherds, if you detect consensus, feel encouraged to respond to
> |  the list with “Looks like we can accept/reject this, Joachim, can you do
> |  it?” Then I am likely to do the bureaucratic acts directly.
> |  
> |  
> |  2. Lack of understanding
> |  ========================
> |  
> |  Matthew has the impression that the itch he was trying to scratch, the
> |  overall needs of Typed Template Haskell (a still rarely used feature, but
> |  dear to his hard) and his solutions are not well understood.
> |  
> |  
> |  I am not in a position (and this is maybe not the right thread) to judge
> |  who is wrong and who is right. And maybe that is partly the
> |  point: Not the whole committee is in a position to understand the
> |  implications of a change to, say, Typed Template Haskell. Do we need to
> |  adjust our process to that somehow? How do we deal with that?
> |  
> |  Also, I think we can recognize that we should not underestimate the
> |  motivation and the actual needs of the people who sit down and write
> |  proposals, and assume good faith. Matthew says that the bug he tries to
> |  fix here does affect his actual work, and in particular that our solution
> |  (forbid type variables in splices) does not actually solve his problem.
> |  
> |  
> |  3. Lack of communication
> |  ========================
> |  
> |  Finally, Matthew points out that some of the reasons that led to the
> |  rejection were not properly discussed with him as the author first.
> |  
> |  
> |  I agree that this is a problematic pattern, and one that I have observed a
> |  few times too: A proposal gets proposed, the shepherd recommends rejection
> |  (or the discussion veers in that direction), we discuss the pros and cons,
> |  and then just reject it. I understand how a proposer might feel helpless
> |  in that situation.
> |  
> |  Worse, they see that proposals by committee members have an easier time,
> |  because then the committee member happens to be on the list and can defend
> |  and explain their proposal better. (This point was not raised by Matthew,
> |  but added by me).
> |  
> |  
> |  Luckily, I think this problem can be solved in a procedural way.
> |  
> |     Procedural proposal A:
> |  
> |     When a shepherd intents to proposal rejecting a proposal, he first
> |     writes his rationale on the Github discussion thread and waits for
> |     the author’s rebuttal. This can (and is encouraged) to lead to a
> |     discussion between shepherd and authors (and any further interesting
> |     party or committee member) with one of these outcomes:
> |      * the shepherd is swayed and proposes acceptance,
> |      * the proposal is improved and the shepherd can propose to accept
> |        it,
> |      * the authors withdraw the proposal,
> |      * no agreement can be reached, and the discussion comes to an end.
> |        Now the shepherd may propose rejecting to the committee.
> |  
> |  
> |  I think this process would give the authors a bigger say and role, more
> |  insight and warning into a possible rejection, and thus hopefully better
> |  satisfaction in the end.
> |  
> |  
> |  A simpler variant of that with a similar result would be something we have
> |  discussed earlier:
> |  
> |     Procedural proposal B:
> |  
> |     The committee discusses proposals on Github; the mailing list is
> |     only used for announcement (new proposal and shepherd assignment,
> |     shepherd’s recommendation, decision, status messages,
> |     metadiscussions like this one.)
> |  
> |  
> |  What are you opinions here?
> |  
> |  Matthew, would any of these procedures have given you a better experience
> |  and/or outcome?
> |  
> |  
> |  I hope we can turn Matthew’s bad experience into something with a
> |  productive outcome!
> |  
> |  (Note that I have not included all technical details of Matthew’s email
> |  here, to keep this focused on the procedural problems he points out.
> |  Matthew, maybe you can raise the good technical points on Github
> |  separately?)
> |  
> |  
> |  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 mail at joachim-breitner.de  Wed Apr 17 16:59:24 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 18:59:24 +0200
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <a4160553-3c61-4327-937a-2c86ff4c8cfe@www.fastmail.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
 <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
 <DB7PR83MB029819400A9669497730E074AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <7d0c15f7-06ec-4a0a-bbb8-faa1907f661d@www.fastmail.com>
 <DB7PR83MB0298EE7DFE19DEB0961B343BAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAGK9nupp7A5nJ=q3arxCCUSTQgMM+W33XcpSGgtSzso93VDO=Q@mail.gmail.com>
 <C0491A7D-5451-4E19-B270-A97659AE0074@cs.brynmawr.edu>
 <bff01274-4e9b-4c34-bd39-680cb9053916@www.fastmail.com>
 <8A88C4A9-3077-44E6-A9E9-D4C7CF0313F5@richarde.dev>
 <a4160553-3c61-4327-937a-2c86ff4c8cfe@www.fastmail.com>
Message-ID: <61842bc30a691f021e9b7a6bdfc7fbeebda268c4.camel@joachim-breitner.de>

HI,

Am Samstag, den 16.03.2019, 10:40 -0400 schrieb Eric Seidel:
> Too bad. It sounds like we agree then that removing the default
> implementation is the best option we have. I've proposed that on
> GitHub and will approve the modified proposal assuming there aren't
> any last objections.

modified and approved.

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/20190417/bb1fe2a3/attachment.sig>

From iavor.diatchki at gmail.com  Wed Apr 17 17:15:07 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 17 Apr 2019 10:15:07 -0700
Subject: [ghc-steering-committee] #179: Tweak the printing of foralls,
 recommendation: accept
In-Reply-To: <6d87b2cb0b18dd22820ddeb5a0b36290cfe7e188.camel@joachim-breitner.de>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <baf92eee08c3d851f3145295db267f121b21beec.camel@joachim-breitner.de>
 <CAGK9nuqVMje8Z+HKgz6OD8HpW4c3zZmWRjgKX5J2YbcKKj57tQ@mail.gmail.com>
 <08E3F317-362B-414A-A705-11C60A6AF679@richarde.dev>
 <DB7PR83MB0298F6833FA9735938F13F9BAD440@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAGK9nuojLMuO6QxN0-JpBXjbJVwrrCqO1Qjy-2uD3Bmf7g1iBw@mail.gmail.com>
 <5DEA3DD0-273F-4951-8803-6775231A52CC@richarde.dev>
 <6d87b2cb0b18dd22820ddeb5a0b36290cfe7e188.camel@joachim-breitner.de>
Message-ID: <CAGK9nuqBv4H4XotR+hwuwv2RF6fJMg61HAzKr-imDZN1PHKB_g@mail.gmail.com>

I am fine with the change.

Something that I've realized from the last few discussions we've had is
that the underlying feature I find questionable is the bit where GHC infers
a variable ordering from the written signatures (left to write, but kinds
before types, and synonyms matter).



On Wed, Apr 17, 2019 at 12:02 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi Iavor,
>
> have these explanations helped your understanding here? Do they address
> your concerns?
>
> Cheers,
> Joachim
>
> Am Freitag, den 15.03.2019, 14:03 -0400 schrieb Richard Eisenberg:
> > On Mar 15, 2019, at 1:04 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
> > >
> > > This is a bit orthogonal, but what would you expect to see in this
> case:
> > >
> > > type T b = Bool
> > > bar :: (a ~ Int) => a -> T b -> a
> > >
> > > :t bar
> >
> > Without -fprint-explicit-foralls: (a ~ Int) => a -> T b -> a
> > With -fprint-explicit-foralls: forall a b. (a ~ Int) => a -> T b -> a
> >
> > > :t bar @Bool
> >
> > Without -fprint-explicit-foralls: (Bool ~ Int) => Bool -> T b -> Bool
> > With -fprint-explicit-foralls: forall b. (Bool ~ Int) => Bool -> T b ->
> Bool
> >
> > > I guess the answer to these depends on if `b` is quantified or not.
> >
> > b *is* quantified -- the quantification happens on the type as the user
> writes it.
> >
> > Richard
> >
> > >
> > >
> > >
> > >
> > > On Fri, Mar 15, 2019 at 1:26 AM Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
> > > > This looks particularly confusing without the explicit `forall`,
> although it seems questionable either way.
> > > >
> > > > Why?  GHC often suppresses foralls when printing types; and had
> -fprint-explicit-foralls to stop doing that.
> > > >
> > > > Simon
> > > >
> > > > From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
> > > > Sent: 14 March 2019 23:46
> > > > To: Iavor Diatchki <iavor.diatchki at gmail.com>
> > > > Cc: ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
> > > > Subject: Re: [ghc-steering-committee] #179: Tweak the printing of
> foralls, recommendation: accept
> > > >
> > > >
> > > > > On Mar 14, 2019, at 6:18 PM, Iavor Diatchki <
> iavor.diatchki at gmail.com> wrote:
> > > > >
> > > > > bar :: forall a b. (a ~ Int) => a -> b -> a
> > > > >
> > > > > Is it the case that `:t bar @Bool` will print
> > > > >
> > > > > bar :: (Bool ~ Int) => Bool -> b -> Bool
> > > > >
> > > > > This looks particularly confusing without the explicit `forall`,
> although it seems questionable either way.
> > > >
> > > >
> > > > Yes, you understand correctly. `:t bar @Bool` will print that
> unfortunate type. I agree this is questionable. But I don't know how to do
> better. The current state of affairs is awkward in a different way, in that
> `:t bar @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int
> -> b -> Int`, even though a further visible type application is possible.
> Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even
> though the next variable to be instantiated is `a`. This is why we have
> `:type +v`.
> > > >
> > > > The direction in the proposal came about in wondering if it's
> possible to improve the mechanics of `:t` (without the `+v`). After we
> thought of doing maximal instantiation of inferred arguments (but no
> generalization), then we realized we could drop `:type +v` as redundant. I
> agree it's something of an uneasy compromise here, but I think any choice
> is going to have unfortunate behavior in some scenarios.
> > > >
> > > > Richard
> > > >
> > > >
> > > > >
> > > > > -Iavor
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner <
> mail at joachim-breitner.de> wrote:
> > > > > > Dear Committee,
> > > > > >
> > > > > > Richard, in collarboration with Simon PJ, proposes some tweaks
> to how
> > > > > > foralls are printed by GHC.
> > > > > >
> > > > > > In particular, whenever a type variable is printed with an
> forall, it
> > > > > > is printed with {a} unless it is a specified variable. And there
> are
> > > > > > tweaks to what :type does with its argument that makes it more
> useful,
> > > > > > and obviates the need for a separate :type +v.
> > > > > >
> https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst
> > > > > >
> > > > > > I like that it actually simplifies the UI (by removing :type
> +v), so I
> > > > > > recommend acceptance.
> > > > > >
> > > > > > Cheers,
> > > > > > Joachim
> > > > > > --
> > > > > > Joachim Breitner
> > > > > >   mail at joachim-breitner.de
> > > > > >   http://www.joachim-breitner.de/
> > > > > >
> > > > > > -----BEGIN PGP SIGNATURE-----
> > > > > >
> > > > > > iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7
> > > > > > 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN
> > > > > > R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM
> > > > > > DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+
> > > > > > cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA
> > > > > > hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr
> > > > > > mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M
> > > > > > 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE
> > > > > > r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt
> > > > > > fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H
> > > > > > c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05
> > > > > > rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg=
> > > > > > =1qbg
> > > > > > -----END PGP SIGNATURE-----
> > > > > > _______________________________________________
> > > > > > 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/
>
> _______________________________________________
> 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/20190417/c8b3c594/attachment-0001.html>

From mail at joachim-breitner.de  Wed Apr 17 17:27:53 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 19:27:53 +0200
Subject: [ghc-steering-committee] #179: Tweak the printing of foralls,
 recommendation: accept
In-Reply-To: <CAGK9nuqBv4H4XotR+hwuwv2RF6fJMg61HAzKr-imDZN1PHKB_g@mail.gmail.com>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <baf92eee08c3d851f3145295db267f121b21beec.camel@joachim-breitner.de>
 <CAGK9nuqVMje8Z+HKgz6OD8HpW4c3zZmWRjgKX5J2YbcKKj57tQ@mail.gmail.com>
 <08E3F317-362B-414A-A705-11C60A6AF679@richarde.dev>
 <DB7PR83MB0298F6833FA9735938F13F9BAD440@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAGK9nuojLMuO6QxN0-JpBXjbJVwrrCqO1Qjy-2uD3Bmf7g1iBw@mail.gmail.com>
 <5DEA3DD0-273F-4951-8803-6775231A52CC@richarde.dev>
 <6d87b2cb0b18dd22820ddeb5a0b36290cfe7e188.camel@joachim-breitner.de>
 <CAGK9nuqBv4H4XotR+hwuwv2RF6fJMg61HAzKr-imDZN1PHKB_g@mail.gmail.com>
Message-ID: <b59e3701f3a2c8c53d3de78cf0ddb412aa53f55d.camel@joachim-breitner.de>

Hi,

ok, that means we have consensus.

accepted.

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/20190417/c8edb183/attachment.sig>

From iavor.diatchki at gmail.com  Wed Apr 17 17:43:16 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 17 Apr 2019 10:43:16 -0700
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
 <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>
Message-ID: <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>

I also think it's better to have all the discussion in one place.  However,
I think it would be beneficial to preserve the following two features of
the current process:

   1. Proposals are still submitted to the committee for review (and we get
an e-mail about it).  This is useful for me, as while I sometimes read
through proposals if I have some free time, I certainly don't track all of
them all the time.  But I do go and read them once Joachim sends the e-mail
that we should be discussing them.

   2. I think it would be good to try to keep the committee discussion on
Github more or less restricted to the committee and the proposal author.  I
think this would help keep steer discussions towards termination (which is
sometimes difficult even when we are restricted to just the committee :-)

Finally, I'd say that if we are going to discuss things on Github, then we
should probably make the mailing list private, since it won't really
contain any information of interest to the community.  And, it would make
it possible to have a private discussion, if we need to (of course, we
could do that anyway by e-mailing everyone explicitly, but that's a bit of
a pain).

On the topic of delay: to me it feels that a lot of the time when we have a
long delay, is when there isn't a clear consensus in the committee about
what to do---I am not sure what we can do about it.  My personal preference
is that in such cases we should reject "new features" and accept
"incomplete fixes", but of course we just have to deal with it on a case by
case basis.

-Iavor








On Wed, Apr 17, 2019 at 8:16 AM Eric Seidel <eric at seidel.io> wrote:

> The cost/benefit and audience points are important issues that we have to
> consider when evaluating a proposal, but I'm not sure that they are that
> relevant to this particular situation.
>
> It seems like the big issue apart from the delay (which I think we can all
> agree is a problem) was a failure of communication. We were under the
> impression that rejecting the programs would also solve Matthew's problem,
> but it seems we were mistaken. I think that alone points to the need for a
> more flexible process than an up-or-down decision.
>
> I like Joachim's first suggestion for point 3, that we deliberate on the
> list, present an initial response, and invite a rebuttal from the author
> before making a final decision. I think that keeping our initial
> deliberations on the list makes sense because it provides a more focussed
> forum for us to discuss the proposal. But I don't feel too strongly about
> deliberating on the list vs github.
>
> Thank you for sharing your frustrations with us, Matthew. We all
> appreciate the work you do.
>
> Eric
>
> On Wed, Apr 17, 2019, at 07:02, Simon Peyton Jones via
> ghc-steering-committee wrote:
> > Thanks Joachim - and thank you Matthew for taking the trouble to write.
> >
> > Some brief responses
> >
> > * I don't see any reason to conduct a conversation on the steering
> >   committee email list, rather than on the Github converation.  In
> >   fact doing it by email is *less* good because the discussion is in
> >   two places.  The only reason to do so would be to have a private
> >   conversation -- but the email list is by design public.  So yes
> >   to Github; and let's explicitly invite the author to participate
> >   in the conversation if they wish.
> >
> > * Delay.  This is a challenge because everyone is a volunteer and
> >   everyone is busy.  Should I spend the next 30 mins reviewing a
> >   GHC proposal or a patch that fixes a bug?  That delay is hard on
> >   the author, but I see no way to fully solve that tension.
> >
> > * Cost and benefit.  The biggest tension I feel is that every incremental
> >   change to the language makes it more complicated, makes the compiler
> >   more complicated, and imposes a new maintenance burden on the
> >   implementors, forever.  There are many features I value (e.g. partial
> >   type signatures, or pattern synonyms) whose authors have long since
> >   moved on, and I am the de-facto maintainer.
> >
> >   It's not wrong to move on. It's a huge service for someone to propose,
> >   design, and implement something.  But is genuinely difficult to balance
> >   the immediate benefits (esp to the author) against the long-term costs.
> >
> > * Audience.  Sometimes the population that genuinely wants a feature is
> >   pretty small.  That does not make it a bad proposal -- sometimes people
> >   don't know they want something till it's there.  But it does make it
> >   harder to generate the time and energy to dig into the technical
> details.
> >
> > It may be that we could articulate some of these tensions on our wiki
> pages.
> > Doing so won't solve them but might help people to feel less badly
> treated.
> > And THAT is a very important goal.
> >
> > Matthew: you are a major contributor to GHC -- thank you!
> >
> > Simon
> >
> >
> > |  -----Original Message-----
> > |  From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org>
> > |  On Behalf Of Joachim Breitner
> > |  Sent: 17 April 2019 11:30
> > |  To: ghc-steering-committee at haskell.org
> > |  Cc: Matthew Pickering <matthewtpickering at gmail.com>
> > |  Subject: [ghc-steering-committee] Unhappy proposers
> > |
> > |  Dear Committee,
> > |
> > |  I have received an email from one of our most productive proposal
> writers,
> > |  Matthew, who we have left quite unhappy with the process, and I hope
> we
> > |  can take the time to see what went wrong, and what we can do
> differently
> > |  to not be wasteful with the motivation of the Matthews out there.
> > |
> > |  Matthew asked me to paraphrase his complaints, just to get this
> started on
> > |  a productive tone. So I’ll play annoyance tone firewall.
> > |
> > |  The PR in question is #207 (Fix the treatment of type variables in
> > |  quotations), and he has three main reasons why he is unsatsified:
> > |
> > |
> > |  1. Delay
> > |  ========
> > |
> > |  There was a long delay between consensus on the mailing list (March
> 7) and
> > |  the official announcement on GitHub.
> > |
> > |
> > |  This is clearly true, and is purely on me, and I am sorry for that.
> > |
> > |  I try to do a monthly sweep of the committee activities, including
> closing
> > |  or accepting proposals where I did not do it directly, but well, the
> last
> > |  month turned out to be 90 days or so … I will try to be better here,
> but
> > |  also appreciate nudges.
> > |
> > |  Also, shepherds, if you detect consensus, feel encouraged to respond
> to
> > |  the list with “Looks like we can accept/reject this, Joachim, can you
> do
> > |  it?” Then I am likely to do the bureaucratic acts directly.
> > |
> > |
> > |  2. Lack of understanding
> > |  ========================
> > |
> > |  Matthew has the impression that the itch he was trying to scratch, the
> > |  overall needs of Typed Template Haskell (a still rarely used feature,
> but
> > |  dear to his hard) and his solutions are not well understood.
> > |
> > |
> > |  I am not in a position (and this is maybe not the right thread) to
> judge
> > |  who is wrong and who is right. And maybe that is partly the
> > |  point: Not the whole committee is in a position to understand the
> > |  implications of a change to, say, Typed Template Haskell. Do we need
> to
> > |  adjust our process to that somehow? How do we deal with that?
> > |
> > |  Also, I think we can recognize that we should not underestimate the
> > |  motivation and the actual needs of the people who sit down and write
> > |  proposals, and assume good faith. Matthew says that the bug he tries
> to
> > |  fix here does affect his actual work, and in particular that our
> solution
> > |  (forbid type variables in splices) does not actually solve his
> problem.
> > |
> > |
> > |  3. Lack of communication
> > |  ========================
> > |
> > |  Finally, Matthew points out that some of the reasons that led to the
> > |  rejection were not properly discussed with him as the author first.
> > |
> > |
> > |  I agree that this is a problematic pattern, and one that I have
> observed a
> > |  few times too: A proposal gets proposed, the shepherd recommends
> rejection
> > |  (or the discussion veers in that direction), we discuss the pros and
> cons,
> > |  and then just reject it. I understand how a proposer might feel
> helpless
> > |  in that situation.
> > |
> > |  Worse, they see that proposals by committee members have an easier
> time,
> > |  because then the committee member happens to be on the list and can
> defend
> > |  and explain their proposal better. (This point was not raised by
> Matthew,
> > |  but added by me).
> > |
> > |
> > |  Luckily, I think this problem can be solved in a procedural way.
> > |
> > |     Procedural proposal A:
> > |
> > |     When a shepherd intents to proposal rejecting a proposal, he first
> > |     writes his rationale on the Github discussion thread and waits for
> > |     the author’s rebuttal. This can (and is encouraged) to lead to a
> > |     discussion between shepherd and authors (and any further
> interesting
> > |     party or committee member) with one of these outcomes:
> > |      * the shepherd is swayed and proposes acceptance,
> > |      * the proposal is improved and the shepherd can propose to accept
> > |        it,
> > |      * the authors withdraw the proposal,
> > |      * no agreement can be reached, and the discussion comes to an end.
> > |        Now the shepherd may propose rejecting to the committee.
> > |
> > |
> > |  I think this process would give the authors a bigger say and role,
> more
> > |  insight and warning into a possible rejection, and thus hopefully
> better
> > |  satisfaction in the end.
> > |
> > |
> > |  A simpler variant of that with a similar result would be something we
> have
> > |  discussed earlier:
> > |
> > |     Procedural proposal B:
> > |
> > |     The committee discusses proposals on Github; the mailing list is
> > |     only used for announcement (new proposal and shepherd assignment,
> > |     shepherd’s recommendation, decision, status messages,
> > |     metadiscussions like this one.)
> > |
> > |
> > |  What are you opinions here?
> > |
> > |  Matthew, would any of these procedures have given you a better
> experience
> > |  and/or outcome?
> > |
> > |
> > |  I hope we can turn Matthew’s bad experience into something with a
> > |  productive outcome!
> > |
> > |  (Note that I have not included all technical details of Matthew’s
> email
> > |  here, to keep this focused on the procedural problems he points out.
> > |  Matthew, maybe you can raise the good technical points on Github
> > |  separately?)
> > |
> > |
> > |  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/20190417/ee83b085/attachment-0001.html>

From eric at seidel.io  Wed Apr 17 17:44:46 2019
From: eric at seidel.io (Eric Seidel)
Date: Wed, 17 Apr 2019 13:44:46 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?=23179=3A_Tweak_the_printing_o?=
 =?utf-8?q?f_foralls=2C_recommendation=3A_accept?=
In-Reply-To: <CAGK9nuqBv4H4XotR+hwuwv2RF6fJMg61HAzKr-imDZN1PHKB_g@mail.gmail.com>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <baf92eee08c3d851f3145295db267f121b21beec.camel@joachim-breitner.de>
 <CAGK9nuqVMje8Z+HKgz6OD8HpW4c3zZmWRjgKX5J2YbcKKj57tQ@mail.gmail.com>
 <08E3F317-362B-414A-A705-11C60A6AF679@richarde.dev>
 <DB7PR83MB0298F6833FA9735938F13F9BAD440@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAGK9nuojLMuO6QxN0-JpBXjbJVwrrCqO1Qjy-2uD3Bmf7g1iBw@mail.gmail.com>
 <5DEA3DD0-273F-4951-8803-6775231A52CC@richarde.dev>
 <6d87b2cb0b18dd22820ddeb5a0b36290cfe7e188.camel@joachim-breitner.de>
 <CAGK9nuqBv4H4XotR+hwuwv2RF6fJMg61HAzKr-imDZN1PHKB_g@mail.gmail.com>
Message-ID: <59a92f63-2f49-4dfb-8ab8-20ef97a0d512@www.fastmail.com>

On Wed, Apr 17, 2019, at 13:15, Iavor Diatchki wrote:
> Something that I've realized from the last few discussions we've had is 
> that the underlying feature I find questionable is the bit where GHC 
> infers a variable ordering from the written signatures (left to write, 
> but kinds before types, and synonyms matter). 

I'm not super happy about that either, but I think it's the only way that TypeApplications could have been made useful without requiring a vast refactoring of haskell code to e.g. add explicit foralls. And TypeApplications is incredibly useful.

From eric at seidel.io  Wed Apr 17 18:00:34 2019
From: eric at seidel.io (Eric Seidel)
Date: Wed, 17 Apr 2019 14:00:34 -0400
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
 <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>
 <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>
Message-ID: <fbd93ba3-e2a7-4e1a-97cd-10b1ce856563@www.fastmail.com>

On Wed, Apr 17, 2019, at 13:43, Iavor Diatchki wrote:
> On the topic of delay: to me it feels that a lot of the time when we 
> have a long delay, is when there isn't a clear consensus in the 
> committee about what to do---I am not sure what we can do about it.

Good point. I've noticed that as well. We get to a point where everyone has made their position fairly clear, but there's no consensus. And then things linger..

I've tried a couple times to restart the discussion with a summary of the current positions and disagreements, but that doesn't really do much to resolve the disagreements themselves.

I'm not really sure what to do in this case either. Perhaps a default response would make sense. Another option would be that when we reach an impasse, we reach out to the author and invite them to address the concerns directly.

From mail at joachim-breitner.de  Wed Apr 17 18:01:16 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 20:01:16 +0200
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
 <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>
 <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>
Message-ID: <4bd51c16b93116a05017c13ea88ed542e3a75fae.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 17.04.2019, 10:43 -0700 schrieb Iavor Diatchki:
> I also think it's better to have all the discussion in one place. 
> However, I think it would be beneficial to preserve the following two
> features of the current process:
> 
>    1. Proposals are still submitted to the committee for review (and
> we get an e-mail about it).  This is useful for me, as while I
> sometimes read through proposals if I have some free time, I
> certainly don't track all of them all the time.  But I do go and read
> them once Joachim sends the e-mail that we should be discussing them.

Yes, I agree that the overall process would stay the same, and all
status messages (submitted, recommendation, result) still go to this
list.

>    2. I think it would be good to try to keep the committee
> discussion on Github more or less restricted to the committee and the
> proposal author.  I think this would help keep steer discussions
> towards termination (which is sometimes difficult even when we are
> restricted to just the committee :-)

Likely not possible from a technical point of view, but without
enforcement not possible from a social point of view. I think if we
move the discussion to Github, we have to face (and maybe benefit!)
from a larger group of participants.

(You can lock conversations, but that would also lock out the original
author, see https://help.github.com/en/articles/locking-conversations)

> Finally, I'd say that if we are going to discuss things on Github,
> then we should probably make the mailing list private, since it won't
> really contain any information of interest to the community.  And, it
> would make it possible to have a private discussion, if we need to
> (of course, we could do that anyway by e-mailing everyone explicitly,
> but that's a bit of a pain).

I dislike private mailing lists, but I see the merit, e.g. discussing
possible rotations of committee members.

I wonder how many non-member are actively following this list.

> On the topic of delay: to me it feels that a lot of the time when we
> have a long delay, is when there isn't a clear consensus in the
> committee about what to do---I am not sure what we can do about it.  

In general, you are right; but in this particular case, there was
consensus, it just slipped my attention, and then my regular sweep
(which would have found it) was late. 

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/20190417/394b778b/attachment.sig>

From mail at joachim-breitner.de  Wed Apr 17 18:04:00 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Apr 2019 20:04:00 +0200
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <fbd93ba3-e2a7-4e1a-97cd-10b1ce856563@www.fastmail.com>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
 <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>
 <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>
 <fbd93ba3-e2a7-4e1a-97cd-10b1ce856563@www.fastmail.com>
Message-ID: <bd6ba7f6e1efbdbdf3f753f24a168bdca966c30c.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 17.04.2019, 14:00 -0400 schrieb Eric Seidel:
> Good point. I've noticed that as well. We get to a point where everyone has made their position fairly clear, but there's no consensus. And then things linger..

if there is really disagreement, then we vote. At least that the
process. It is a fallback (and I think we never needed it), but there
is a way forward. It would be up to the shepherd to determine that it
is time to vote.

> I'm not really sure what to do in this case either. Perhaps a default
> response would make sense. Another option would be that when we reach
> an impasse, we reach out to the author and invite them to address the
> concerns directly.

Well, we now want to involve the author during the discussion anyways,
so hopefully this will not be needed.

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/20190417/0ff1d244/attachment.sig>

From iavor.diatchki at gmail.com  Wed Apr 17 18:22:46 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 17 Apr 2019 11:22:46 -0700
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <4bd51c16b93116a05017c13ea88ed542e3a75fae.camel@joachim-breitner.de>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
 <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>
 <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>
 <4bd51c16b93116a05017c13ea88ed542e3a75fae.camel@joachim-breitner.de>
Message-ID: <CAGK9nuowqJ5gXJM4iZgCZ7PvDescX0K5-aK6t-haOUrfBT6WEQ@mail.gmail.com>

On Wed, Apr 17, 2019 at 11:01 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

>
> >    2. I think it would be good to try to keep the committee
> > discussion on Github more or less restricted to the committee and the
> > proposal author.  I think this would help keep steer discussions
> > towards termination (which is sometimes difficult even when we are
> > restricted to just the committee :-)
>
> Likely not possible from a technical point of view, but without
> enforcement not possible from a social point of view. I think if we
> move the discussion to Github, we have to face (and maybe benefit!)
> from a larger group of participants.
>
> (You can lock conversations, but that would also lock out the original
> author, see https://help.github.com/en/articles/locking-conversations)
>
>
Yeah, I didn't mean that we should do anything technical, just have this be
the specified process and hope that people more or less follow it.
Obviously, if someone has something productive to say during the committee
discussion, they can mention it and we can try to address it.

However, I think there is a benefit to encourage the community to give
their feedback before the committee discussion has begun,
as I think this 1) helps improve proposals, and 2) enables us (the
committee) to read through the discussion to see what the current opinions
are---
I find this quite helpful, as it gives me an idea of what people
like/dislike, and sometime points out issue I hadn't thought about.

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

From cma at bitemyapp.com  Wed Apr 17 18:38:51 2019
From: cma at bitemyapp.com (Christopher Allen)
Date: Wed, 17 Apr 2019 13:38:51 -0500
Subject: [ghc-steering-committee] Status
In-Reply-To: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
Message-ID: <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>

I'm happy to let someone else take my slot.

I gave my recommendation for ExtraCommas, acceptance of the original
proposal as written. I talk with the proposer almost every day so I
know where he stands. He still thinks it's worth doing and would like
to see it accepted. I think ExtraCommas merits acceptance. If we can't
achieve consensus on it then it should be rejected so it gets cleared
off the slate. I'm not inclined to argue a syntactic extension like
this, but I will say this:

The proposal captures a nice design element that we've seen work very
well ergonomically in Rust. We're never going to make the same
decisions with the same tradeoffs as a totally different language but
any time there is a relatively isolated "good idea" like this, I'd
like to see us try to take advantage of that and see if it works for
us.

Cheers,
Chris Allen

On Wed, Apr 17, 2019 at 4:43 AM Joachim Breitner
<mail at joachim-breitner.de> wrote:
>
> Dear committee,
>
> has it really been three months since the last status?
> Time flies like an arrow (and fruit flies like banana).
>
> Some proposals are stalled on individual members of the committee who
> have become much less active recently (Manuel, Ben, partly Chris). I
> encourage you (and everyone else of course) to realistically assess
> your commitment, and – if you think that that’s in the best interest of
> all involved – indicate if we should start to find new members with
> fresh engery.
>
> Anyways, quite a few things have happened:
>
>  * were asked to review these proposals:
>    #167 Deprecated Entities (shepherd: Vitaly)
>    #203 PtrRep (shepherd: SPJ)
>    #176 SCC Parsing (shepherd: Simon M)
>    #193 forall keyword (shepherd: Eric)
>    #155 Type Vars in Lambdas (shepherd: Iavor)
>    #209 Levity polymorphic lift (shepherd: Eric)
>    #210 -Wredundand-minimal-methods (shepherd: me)
>    #190 module qualified syntax (shepherd: Simon M)
>    #207 type variables in quotations (shepherd: Richard)
>    #195 newtype Q (shepherd: Vitaly)
>    #204 nested brackets (shepherd: Iavor)
>    #179 Printing of foralls (shepherd: me)
>    #177 constrained type families (shepherd: Vitaly)
>
>  * got a recommendation from shepherds about:
>    #193 forall keyword (rec: acccept)
>    #176 SCC Parsing (rec: accept)
>    #210 -Wredundand-minimal-methods (rec: accept)
>    #209 Levity polymorphic lift (rec: accept)
>    #207 type variables in quotations (rec: reject)
>    #167 Deprecated Entities (rec: accept)
>    #195 newtype Q (rec: accept)
>    #190 module qualified syntax (rec: accept)
>    #204 nested brackets (rec: shelve)
>    #179 Printing of foralls (rec: acccept)
>    #203 PtrRep (rec: accept)
>
>  * decided about the following proposals
>    #158 Add setField to HasField (accept)
>    #28 Bundling patterns with type synonyms (reject)
>    #167 Deprecated Entities (reject)
>    #193 forall keyword (acccept)
>    #207 type variables in quotations (reject)
>    #195 newtype Q (needs revision)
>    #210 -Wredundand-minimal-methods (accept)
>    #203 PtrRep (accept)
>    #176 SCC Parsing (accept)
>
> We currently have to act on the following 8 proposals, up two since the
> last status:
>
> Levity polymorphic lift
> https://github.com/ghc-proposals/ghc-proposals/pull/209
> Shepherd: Eric
> Status: To be accepted after minor tweaks by the authors
>
> Module qualified syntax
> https://github.com/ghc-proposals/ghc-proposals/pull/190
> Shepherd: Simon M
> Status: To be accepted after we decide on the pragma name
>
> Tweak printing of foralls
> https://github.com/ghc-proposals/ghc-proposals/pull/179
> Shepherd: me
> Status: Ongoing discussion (Iavor had questions)
>
> Simple constrained type families
> https://github.com/ghc-proposals/ghc-proposals/pull/177
> Shepherd: Vitaly
> Status: Waiting for Vitaly to make a recommendation
>
> Binding type variables in lambda expressions
> https://github.com/ghc-proposals/ghc-proposals/pull/155
> Shepherd: Iavor
> Status: Discussion ongoing, Iavor did not make an official recommendation
>
> Type annotated quoters
> https://github.com/ghc-proposals/ghc-proposals/pull/125
> Shepherd: Manuel
> Status: Still waiting for recommendation. Manuel?
>
> Provenance-Qualified Package Imports
> https://github.com/ghc-proposals/ghc-proposals/pull/115
> Shepherd: Ben
> Status: Still waiting for recommendation. This is pretty old!
>
> ExtraCommas
> https://github.com/ghc-proposals/ghc-proposals/pull/87
> Shepherd: Chris
> Recommendation: accept
> Status: Met with some reservation. Chris, please pick this up again.
>
>
> 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



-- 
Chris Allen
Currently working on http://haskellbook.com

From eric at seidel.io  Wed Apr 17 21:43:07 2019
From: eric at seidel.io (Eric Seidel)
Date: Wed, 17 Apr 2019 17:43:07 -0400
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <CAGK9nuowqJ5gXJM4iZgCZ7PvDescX0K5-aK6t-haOUrfBT6WEQ@mail.gmail.com>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
 <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>
 <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>
 <4bd51c16b93116a05017c13ea88ed542e3a75fae.camel@joachim-breitner.de>
 <CAGK9nuowqJ5gXJM4iZgCZ7PvDescX0K5-aK6t-haOUrfBT6WEQ@mail.gmail.com>
Message-ID: <55681059-73b1-4f67-b8dd-ac5c334b7bc0@www.fastmail.com>

Iavor's point about keeping the committee discussion restricted to the committee is basically my only reason for preferring to keep the discussion on the mailing list. 

It seems useful to have a separate place for us to deliberate and formulate a response to the proposal, not for any notion of privacy or secrecy (our discussions are already public, as they should be). Rather, it's just easier to keep the discussion focused  when we have a smaller group of participants.

If there's a feeling that our discussions are not visible enough, perhaps we could deliberate proposals on a separate, locked issue? That might satisfy both desires, though it also feels a bit laborious..



On Wed, Apr 17, 2019, at 14:23, Iavor Diatchki wrote:
> 
> 
> On Wed, Apr 17, 2019 at 11:01 AM Joachim Breitner 
> <mail at joachim-breitner.de> wrote:
> > 
> >  > 2. I think it would be good to try to keep the committee
> >  > discussion on Github more or less restricted to the committee and the
> >  > proposal author. I think this would help keep steer discussions
> >  > towards termination (which is sometimes difficult even when we are
> >  > restricted to just the committee :-)
> > 
> >  Likely not possible from a technical point of view, but without
> >  enforcement not possible from a social point of view. I think if we
> >  move the discussion to Github, we have to face (and maybe benefit!)
> >  from a larger group of participants.
> > 
> >  (You can lock conversations, but that would also lock out the original
> >  author, see https://help.github.com/en/articles/locking-conversations)
> > 
> 
> Yeah, I didn't mean that we should do anything technical, just have 
> this be the specified process and hope that people more or less follow 
> it.
> Obviously, if someone has something productive to say during the 
> committee discussion, they can mention it and we can try to address it.
> 
> However, I think there is a benefit to encourage the community to give 
> their feedback before the committee discussion has begun,
> as I think this 1) helps improve proposals, and 2) enables us (the 
> committee) to read through the discussion to see what the current 
> opinions are---
> I find this quite helpful, as it gives me an idea of what people 
> like/dislike, and sometime points out issue I hadn't thought about.
> 
> -Iavor
> 
> _______________________________________________
> 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 Apr 17 22:31:16 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 18 Apr 2019 00:31:16 +0200
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
Message-ID: <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher Allen:
> I gave my recommendation for ExtraCommas, acceptance of the original
> proposal as written. I talk with the proposer almost every day so I
> know where he stands. He still thinks it's worth doing and would like
> to see it accepted. I think ExtraCommas merits acceptance. If we can't
> achieve consensus on it then it should be rejected so it gets cleared
> off the slate. I'm not inclined to argue a syntactic extension like
> this, but I will say this:
> 
> The proposal captures a nice design element that we've seen work very
> well ergonomically in Rust. We're never going to make the same
> decisions with the same tradeoffs as a totally different language but
> any time there is a relatively isolated "good idea" like this, I'd
> like to see us try to take advantage of that and see if it works for
> us.

thanks for picking this up. 

The most contentious point, besides whether its worth the bother at
all, was the interaction with TupleSections. Which gives us three
options, I think: 
 * reject
 * accept, covering tuples (and making it conflict with TupleSections)
 * accept, not covering tuples.

No decision is absolutely wrong, none is obviously right.

Maybe we should simply do a vote, to get it decided? Simons (as
Chairs), what do you think?

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/20190418/c5278830/attachment.sig>

From cma at bitemyapp.com  Thu Apr 18 00:34:22 2019
From: cma at bitemyapp.com (Christopher Allen)
Date: Wed, 17 Apr 2019 19:34:22 -0500
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
Message-ID: <CADnndOojBexHEitDW+SpwstkHHQrDEMsttYtkikxa=NvaQncow@mail.gmail.com>

I'm inclined to option #2. I'll report back if I hear from Matt on
what he would prefer.


On Wed, Apr 17, 2019 at 5:31 PM Joachim Breitner
<mail at joachim-breitner.de> wrote:
>
> Hi,
>
> Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher Allen:
> > I gave my recommendation for ExtraCommas, acceptance of the original
> > proposal as written. I talk with the proposer almost every day so I
> > know where he stands. He still thinks it's worth doing and would like
> > to see it accepted. I think ExtraCommas merits acceptance. If we can't
> > achieve consensus on it then it should be rejected so it gets cleared
> > off the slate. I'm not inclined to argue a syntactic extension like
> > this, but I will say this:
> >
> > The proposal captures a nice design element that we've seen work very
> > well ergonomically in Rust. We're never going to make the same
> > decisions with the same tradeoffs as a totally different language but
> > any time there is a relatively isolated "good idea" like this, I'd
> > like to see us try to take advantage of that and see if it works for
> > us.
>
> thanks for picking this up.
>
> The most contentious point, besides whether its worth the bother at
> all, was the interaction with TupleSections. Which gives us three
> options, I think:
>  * reject
>  * accept, covering tuples (and making it conflict with TupleSections)
>  * accept, not covering tuples.
>
> No decision is absolutely wrong, none is obviously right.
>
> Maybe we should simply do a vote, to get it decided? Simons (as
> Chairs), what do you think?
>
> 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



--
Chris Allen
Currently working on http://haskellbook.com

From eric at seidel.io  Thu Apr 18 01:15:26 2019
From: eric at seidel.io (Eric Seidel)
Date: Wed, 17 Apr 2019 21:15:26 -0400
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
Message-ID: <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>

I favor accepting the proposal, with or without tuples. I've been writing a bit of Rust recently, and agree with Chris about the ergonomics of trailing commas.

On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
> Hi,
> 
> Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher Allen:
> > I gave my recommendation for ExtraCommas, acceptance of the original
> > proposal as written. I talk with the proposer almost every day so I
> > know where he stands. He still thinks it's worth doing and would like
> > to see it accepted. I think ExtraCommas merits acceptance. If we can't
> > achieve consensus on it then it should be rejected so it gets cleared
> > off the slate. I'm not inclined to argue a syntactic extension like
> > this, but I will say this:
> > 
> > The proposal captures a nice design element that we've seen work very
> > well ergonomically in Rust. We're never going to make the same
> > decisions with the same tradeoffs as a totally different language but
> > any time there is a relatively isolated "good idea" like this, I'd
> > like to see us try to take advantage of that and see if it works for
> > us.
> 
> thanks for picking this up. 
> 
> The most contentious point, besides whether its worth the bother at
> all, was the interaction with TupleSections. Which gives us three
> options, I think: 
>  * reject
>  * accept, covering tuples (and making it conflict with TupleSections)
>  * accept, not covering tuples.
> 
> No decision is absolutely wrong, none is obviously right.
> 
> Maybe we should simply do a vote, to get it decided? Simons (as
> Chairs), what do you think?
> 
> 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
> 
> Attachments:
> * signature.asc

From rae at richarde.dev  Thu Apr 18 03:16:07 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 17 Apr 2019 23:16:07 -0400
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <55681059-73b1-4f67-b8dd-ac5c334b7bc0@www.fastmail.com>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
 <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>
 <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>
 <4bd51c16b93116a05017c13ea88ed542e3a75fae.camel@joachim-breitner.de>
 <CAGK9nuowqJ5gXJM4iZgCZ7PvDescX0K5-aK6t-haOUrfBT6WEQ@mail.gmail.com>
 <55681059-73b1-4f67-b8dd-ac5c334b7bc0@www.fastmail.com>
Message-ID: <4483DE1D-94B1-4EB1-9C1D-C7A46E855799@richarde.dev>

Thanks, Joachim, for writing the initial post and suggesting concrete directions. And, thanks, Matthew (who, at some point, got dropped off this conversation -- no doubt unintentionally), for speaking up about your dissatisfaction instead of just stewing.

I agree that we should make it a policy not to make a "reject" recommendation without writing on the GitHub issue first, in order to invite a rebuttal.

However, I'd prefer to keep discussions on this list, for the reasons others have mentioned. Primarily, I'm worried that GitHub can be a noisy place, and if we have our deliberations there, our status as a decision-making committee is somewhat compromised. On the other hand, an easy practice that could increase discoverability and transparency is to have the shepherd post a link to the on-list conversation on the GitHub trail at the end of deliberations. Our thoughts are then preserved nicely.

Richard

> On Apr 17, 2019, at 5:43 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> Iavor's point about keeping the committee discussion restricted to the committee is basically my only reason for preferring to keep the discussion on the mailing list. 
> 
> It seems useful to have a separate place for us to deliberate and formulate a response to the proposal, not for any notion of privacy or secrecy (our discussions are already public, as they should be). Rather, it's just easier to keep the discussion focused  when we have a smaller group of participants.
> 
> If there's a feeling that our discussions are not visible enough, perhaps we could deliberate proposals on a separate, locked issue? That might satisfy both desires, though it also feels a bit laborious..
> 
> 
> 
> On Wed, Apr 17, 2019, at 14:23, Iavor Diatchki wrote:
>> 
>> 
>> On Wed, Apr 17, 2019 at 11:01 AM Joachim Breitner 
>> <mail at joachim-breitner.de> wrote:
>>> 
>>>> 2. I think it would be good to try to keep the committee
>>>> discussion on Github more or less restricted to the committee and the
>>>> proposal author. I think this would help keep steer discussions
>>>> towards termination (which is sometimes difficult even when we are
>>>> restricted to just the committee :-)
>>> 
>>> Likely not possible from a technical point of view, but without
>>> enforcement not possible from a social point of view. I think if we
>>> move the discussion to Github, we have to face (and maybe benefit!)
>>> from a larger group of participants.
>>> 
>>> (You can lock conversations, but that would also lock out the original
>>> author, see https://help.github.com/en/articles/locking-conversations)
>>> 
>> 
>> Yeah, I didn't mean that we should do anything technical, just have 
>> this be the specified process and hope that people more or less follow 
>> it.
>> Obviously, if someone has something productive to say during the 
>> committee discussion, they can mention it and we can try to address it.
>> 
>> However, I think there is a benefit to encourage the community to give 
>> their feedback before the committee discussion has begun,
>> as I think this 1) helps improve proposals, and 2) enables us (the 
>> committee) to read through the discussion to see what the current 
>> opinions are---
>> I find this quite helpful, as it gives me an idea of what people 
>> like/dislike, and sometime points out issue I hadn't thought about.
>> 
>> -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 cma at bitemyapp.com  Thu Apr 18 03:18:44 2019
From: cma at bitemyapp.com (Christopher Allen)
Date: Wed, 17 Apr 2019 22:18:44 -0500
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
Message-ID: <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>

I spoke with Matt, he's fine either way with or without tuples.

I'd prefer "with tuples" for consistency. I use tuples sometimes, but
don't care about sectioning.

On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel <eric at seidel.io> wrote:
>
> I favor accepting the proposal, with or without tuples. I've been writing a bit of Rust recently, and agree with Chris about the ergonomics of trailing commas.
>
> On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
> > Hi,
> >
> > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher Allen:
> > > I gave my recommendation for ExtraCommas, acceptance of the original
> > > proposal as written. I talk with the proposer almost every day so I
> > > know where he stands. He still thinks it's worth doing and would like
> > > to see it accepted. I think ExtraCommas merits acceptance. If we can't
> > > achieve consensus on it then it should be rejected so it gets cleared
> > > off the slate. I'm not inclined to argue a syntactic extension like
> > > this, but I will say this:
> > >
> > > The proposal captures a nice design element that we've seen work very
> > > well ergonomically in Rust. We're never going to make the same
> > > decisions with the same tradeoffs as a totally different language but
> > > any time there is a relatively isolated "good idea" like this, I'd
> > > like to see us try to take advantage of that and see if it works for
> > > us.
> >
> > thanks for picking this up.
> >
> > The most contentious point, besides whether its worth the bother at
> > all, was the interaction with TupleSections. Which gives us three
> > options, I think:
> >  * reject
> >  * accept, covering tuples (and making it conflict with TupleSections)
> >  * accept, not covering tuples.
> >
> > No decision is absolutely wrong, none is obviously right.
> >
> > Maybe we should simply do a vote, to get it decided? Simons (as
> > Chairs), what do you think?
> >
> > 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
> >
> > Attachments:
> > * signature.asc
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee



-- 
Chris Allen
Currently working on http://haskellbook.com

From simonpj at microsoft.com  Thu Apr 18 07:11:06 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 18 Apr 2019 07:11:06 +0000
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
Message-ID: <DB7PR83MB02987CB2DDA1DA0EBFA6FC47AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>

Just to remind everyone, here's the proposal
https://github.com/parsonsmatt/ghc-proposals/blob/trailing-leading-commas/proposals/0000-trailing-leading-commas-subexports.rst

I think the TupleSections conflict means that the proposal does *not* plan to allow leading or trailing commas in tuples.  That's an exception, but has no other technical difficulty.

I wonder if, for uniformity, the same exception should be made for constraint tuples, disallowing
	f :: (Monad m,) => blah
because constraint tuples *are* really just tuples, and perhaps (Monad m,) :: Constraint -> Constraint.

The proposal has a "maybe" for pattern guards, so we don't have a clear recommendation from the author there.

But aside from these points I see not great difficulty.  It's a superficial syntactic change (like putting 'qualified' in a different place; some people like it, and no harm is done to people who don't want it.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Joachim Breitner
|  Sent: 17 April 2019 23:31
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Extra Commas
|  
|  Hi,
|  
|  Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher Allen:
|  > I gave my recommendation for ExtraCommas, acceptance of the original
|  > proposal as written. I talk with the proposer almost every day so I
|  > know where he stands. He still thinks it's worth doing and would like
|  > to see it accepted. I think ExtraCommas merits acceptance. If we can't
|  > achieve consensus on it then it should be rejected so it gets cleared
|  > off the slate. I'm not inclined to argue a syntactic extension like
|  > this, but I will say this:
|  >
|  > The proposal captures a nice design element that we've seen work very
|  > well ergonomically in Rust. We're never going to make the same
|  > decisions with the same tradeoffs as a totally different language but
|  > any time there is a relatively isolated "good idea" like this, I'd
|  > like to see us try to take advantage of that and see if it works for
|  > us.
|  
|  thanks for picking this up.
|  
|  The most contentious point, besides whether its worth the bother at all,
|  was the interaction with TupleSections. Which gives us three options, I
|  think:
|   * reject
|   * accept, covering tuples (and making it conflict with TupleSections)
|   * accept, not covering tuples.
|  
|  No decision is absolutely wrong, none is obviously right.
|  
|  Maybe we should simply do a vote, to get it decided? Simons (as Chairs),
|  what do you think?
|  
|  Cheers,
|  Joachim
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|    http://www.joachim-breitner.de/


From simonpj at microsoft.com  Thu Apr 18 07:16:56 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 18 Apr 2019 07:16:56 +0000
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
Message-ID: <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>

But it's actually *incompatible* with TupleSections, so how shoule
	(True,)
be interpreted if both are on?

S

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Christopher Allen
|  Sent: 18 April 2019 04:19
|  To: Eric Seidel <eric at seidel.io>
|  Cc: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Extra Commas
|  
|  I spoke with Matt, he's fine either way with or without tuples.
|  
|  I'd prefer "with tuples" for consistency. I use tuples sometimes, but
|  don't care about sectioning.
|  
|  On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel <eric at seidel.io> wrote:
|  >
|  > I favor accepting the proposal, with or without tuples. I've been
|  writing a bit of Rust recently, and agree with Chris about the ergonomics
|  of trailing commas.
|  >
|  > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
|  > > Hi,
|  > >
|  > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher Allen:
|  > > > I gave my recommendation for ExtraCommas, acceptance of the
|  > > > original proposal as written. I talk with the proposer almost
|  > > > every day so I know where he stands. He still thinks it's worth
|  > > > doing and would like to see it accepted. I think ExtraCommas
|  > > > merits acceptance. If we can't achieve consensus on it then it
|  > > > should be rejected so it gets cleared off the slate. I'm not
|  > > > inclined to argue a syntactic extension like this, but I will say
|  this:
|  > > >
|  > > > The proposal captures a nice design element that we've seen work
|  > > > very well ergonomically in Rust. We're never going to make the
|  > > > same decisions with the same tradeoffs as a totally different
|  > > > language but any time there is a relatively isolated "good idea"
|  > > > like this, I'd like to see us try to take advantage of that and
|  > > > see if it works for us.
|  > >
|  > > thanks for picking this up.
|  > >
|  > > The most contentious point, besides whether its worth the bother at
|  > > all, was the interaction with TupleSections. Which gives us three
|  > > options, I think:
|  > >  * reject
|  > >  * accept, covering tuples (and making it conflict with
|  > > TupleSections)
|  > >  * accept, not covering tuples.
|  > >
|  > > No decision is absolutely wrong, none is obviously right.
|  > >
|  > > Maybe we should simply do a vote, to get it decided? Simons (as
|  > > Chairs), what do you think?
|  > >
|  > > 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-commi
|  > > ttee
|  > >
|  > > Attachments:
|  > > * signature.asc
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ
|  > ee
|  
|  
|  
|  --
|  Chris Allen
|  Currently working on http://haskellbook.com
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From cma at bitemyapp.com  Thu Apr 18 09:07:50 2019
From: cma at bitemyapp.com (Christopher Allen)
Date: Thu, 18 Apr 2019 04:07:50 -0500
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>

My understanding of previous discussions was that:

"tuples included" means "incompatible with tuple sections" means "they
are mutually exclusive to a module."

On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones
<simonpj at microsoft.com> wrote:
>
> But it's actually *incompatible* with TupleSections, so how shoule
>         (True,)
> be interpreted if both are on?
>
> S
>
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> |  On Behalf Of Christopher Allen
> |  Sent: 18 April 2019 04:19
> |  To: Eric Seidel <eric at seidel.io>
> |  Cc: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] Extra Commas
> |
> |  I spoke with Matt, he's fine either way with or without tuples.
> |
> |  I'd prefer "with tuples" for consistency. I use tuples sometimes, but
> |  don't care about sectioning.
> |
> |  On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel <eric at seidel.io> wrote:
> |  >
> |  > I favor accepting the proposal, with or without tuples. I've been
> |  writing a bit of Rust recently, and agree with Chris about the ergonomics
> |  of trailing commas.
> |  >
> |  > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
> |  > > Hi,
> |  > >
> |  > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher Allen:
> |  > > > I gave my recommendation for ExtraCommas, acceptance of the
> |  > > > original proposal as written. I talk with the proposer almost
> |  > > > every day so I know where he stands. He still thinks it's worth
> |  > > > doing and would like to see it accepted. I think ExtraCommas
> |  > > > merits acceptance. If we can't achieve consensus on it then it
> |  > > > should be rejected so it gets cleared off the slate. I'm not
> |  > > > inclined to argue a syntactic extension like this, but I will say
> |  this:
> |  > > >
> |  > > > The proposal captures a nice design element that we've seen work
> |  > > > very well ergonomically in Rust. We're never going to make the
> |  > > > same decisions with the same tradeoffs as a totally different
> |  > > > language but any time there is a relatively isolated "good idea"
> |  > > > like this, I'd like to see us try to take advantage of that and
> |  > > > see if it works for us.
> |  > >
> |  > > thanks for picking this up.
> |  > >
> |  > > The most contentious point, besides whether its worth the bother at
> |  > > all, was the interaction with TupleSections. Which gives us three
> |  > > options, I think:
> |  > >  * reject
> |  > >  * accept, covering tuples (and making it conflict with
> |  > > TupleSections)
> |  > >  * accept, not covering tuples.
> |  > >
> |  > > No decision is absolutely wrong, none is obviously right.
> |  > >
> |  > > Maybe we should simply do a vote, to get it decided? Simons (as
> |  > > Chairs), what do you think?
> |  > >
> |  > > 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-commi
> |  > > ttee
> |  > >
> |  > > Attachments:
> |  > > * signature.asc
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at haskell.org
> |  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ
> |  > ee
> |
> |
> |
> |  --
> |  Chris Allen
> |  Currently working on http://haskellbook.com
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee



-- 
Chris Allen
Currently working on http://haskellbook.com

From simonpj at microsoft.com  Thu Apr 18 14:52:37 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 18 Apr 2019 14:52:37 +0000
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
Message-ID: <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>

|  "tuples included" means "incompatible with tuple sections" means "they are
|  mutually exclusive to a module."

You mean, some kind of new error message that says "these two extension are mutually incompatible".  I can't say I love this.  Let's just leave out tuples from ExtraCommas.

(Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day.  Maybe we omit list literals too?  Or would that break the key use-cases?

Simon

|  -----Original Message-----
|  From: Christopher Allen <cma at bitemyapp.com>
|  Sent: 18 April 2019 10:08
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Eric Seidel <eric at seidel.io>; ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Extra Commas
|  
|  My understanding of previous discussions was that:
|  
|  
|  On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones <simonpj at microsoft.com>
|  wrote:
|  >
|  > But it's actually *incompatible* with TupleSections, so how shoule
|  >         (True,)
|  > be interpreted if both are on?
|  >
|  > S
|  >
|  > |  -----Original Message-----
|  > |  From: ghc-steering-committee
|  > | <ghc-steering-committee-bounces at haskell.org>
|  > |  On Behalf Of Christopher Allen
|  > |  Sent: 18 April 2019 04:19
|  > |  To: Eric Seidel <eric at seidel.io>
|  > |  Cc: ghc-steering-committee at haskell.org
|  > |  Subject: Re: [ghc-steering-committee] Extra Commas
|  > |
|  > |  I spoke with Matt, he's fine either way with or without tuples.
|  > |
|  > |  I'd prefer "with tuples" for consistency. I use tuples sometimes,
|  > | but  don't care about sectioning.
|  > |
|  > |  On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel <eric at seidel.io> wrote:
|  > |  >
|  > |  > I favor accepting the proposal, with or without tuples. I've been
|  > | writing a bit of Rust recently, and agree with Chris about the
|  > | ergonomics  of trailing commas.
|  > |  >
|  > |  > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
|  > |  > > Hi,
|  > |  > >
|  > |  > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher
|  Allen:
|  > |  > > > I gave my recommendation for ExtraCommas, acceptance of the
|  > | > > > original proposal as written. I talk with the proposer almost
|  > | > > > every day so I know where he stands. He still thinks it's
|  > | worth  > > > doing and would like to see it accepted. I think
|  > | ExtraCommas  > > > merits acceptance. If we can't achieve consensus
|  > | on it then it  > > > should be rejected so it gets cleared off the
|  > | slate. I'm not  > > > inclined to argue a syntactic extension like
|  > | this, but I will say
|  > |  this:
|  > |  > > >
|  > |  > > > The proposal captures a nice design element that we've seen
|  > | work  > > > very well ergonomically in Rust. We're never going to
|  > | make the  > > > same decisions with the same tradeoffs as a totally
|  > | different  > > > language but any time there is a relatively isolated
|  "good idea"
|  > |  > > > like this, I'd like to see us try to take advantage of that
|  > | and  > > > see if it works for us.
|  > |  > >
|  > |  > > thanks for picking this up.
|  > |  > >
|  > |  > > The most contentious point, besides whether its worth the
|  > | bother at  > > all, was the interaction with TupleSections. Which
|  > | gives us three  > > options, I think:
|  > |  > >  * reject
|  > |  > >  * accept, covering tuples (and making it conflict with  > >
|  > | TupleSections)  > >  * accept, not covering tuples.
|  > |  > >
|  > |  > > No decision is absolutely wrong, none is obviously right.
|  > |  > >
|  > |  > > Maybe we should simply do a vote, to get it decided? Simons (as
|  > | > > Chairs), what do you think?
|  > |  > >
|  > |  > > Cheers,
|  > |  > > Joachim
|  > |  > >
|  > |  > > --
|  > |  > > Joachim Breitner
|  > |  > >  mail at joachim-breitner.de
|  > |  > >
|  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
|  > | .joachim-breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7
|  > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47
|  > | %7C1%7C0%7C636911752855987147&amp;sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u
|  > | 9fb%2BRkQMqGibDlM%3D&amp;reserved=0
|  > |  > >
|  > |  > >
|  > |  > > _______________________________________________
|  > |  > > ghc-steering-committee mailing list  > >
|  > | ghc-steering-committee at haskell.org
|  > |  > >
|  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
|  > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a
|  > | mp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408d6
|  > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598
|  > | 7147&amp;sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&amp;re
|  > | served=0
|  > |  > > ttee
|  > |  > >
|  > |  > > Attachments:
|  > |  > > * signature.asc
|  > |  > _______________________________________________
|  > |  > ghc-steering-committee mailing list  >
|  > | ghc-steering-committee at haskell.org
|  > |  >
|  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
|  > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
|  > | &amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408
|  > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855
|  > | 987147&amp;sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D&
|  > | amp;reserved=0
|  > |  > ee
|  > |
|  > |
|  > |
|  > |  --
|  > |  Chris Allen
|  > |  Currently working on
|  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas
|  > | kellbook.com&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836
|  > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
|  > | 636911752855987147&amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK
|  > | 8IyjBI%3D&amp;reserved=0
|  > | _______________________________________________
|  > |  ghc-steering-committee mailing list
|  > | ghc-steering-committee at haskell.org
|  > |
|  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
|  > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
|  > | ee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a294
|  > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528
|  > | 55987147&amp;sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D&
|  > | amp;reserved=0
|  
|  
|  
|  --
|  Chris Allen
|  Currently working on
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo
|  ok.com&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408
|  d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147
|  &amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&amp;reserved=0

From rae at richarde.dev  Thu Apr 18 15:06:10 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 18 Apr 2019 11:06:10 -0400
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
 <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>

I strongly dislike the idea of mutually-incompatible extensions.

We could say that ExtraCommas allows extra commas everywhere, including in tuples and lists. We could also say that TupleSections overrides this behavior in tuples and gives it new meaning. We could further imagine ListSections that would override the behavior in lists. To me, this is preferable than mutual incompatibility.

Does this make for a nice user experience? I'm not sure. Happily, the reinterpretation from TupleSections or ListSections would change types, so you'd get errors up front. These errors might even be clever enough to notice that both ExtraCommas and TupleSections are in effect and gently remind the user that this combination can be confusing. Actually, this might be a nice "have your cake and eat it too" moment: let's just do all the things!

Richard

> On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> |  "tuples included" means "incompatible with tuple sections" means "they are
> |  mutually exclusive to a module."
> 
> You mean, some kind of new error message that says "these two extension are mutually incompatible".  I can't say I love this.  Let's just leave out tuples from ExtraCommas.
> 
> (Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day.  Maybe we omit list literals too?  Or would that break the key use-cases?
> 
> Simon
> 
> |  -----Original Message-----
> |  From: Christopher Allen <cma at bitemyapp.com>
> |  Sent: 18 April 2019 10:08
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
> |  Cc: Eric Seidel <eric at seidel.io>; ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] Extra Commas
> |  
> |  My understanding of previous discussions was that:
> |  
> |  
> |  On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones <simonpj at microsoft.com>
> |  wrote:
> |  >
> |  > But it's actually *incompatible* with TupleSections, so how shoule
> |  >         (True,)
> |  > be interpreted if both are on?
> |  >
> |  > S
> |  >
> |  > |  -----Original Message-----
> |  > |  From: ghc-steering-committee
> |  > | <ghc-steering-committee-bounces at haskell.org>
> |  > |  On Behalf Of Christopher Allen
> |  > |  Sent: 18 April 2019 04:19
> |  > |  To: Eric Seidel <eric at seidel.io>
> |  > |  Cc: ghc-steering-committee at haskell.org
> |  > |  Subject: Re: [ghc-steering-committee] Extra Commas
> |  > |
> |  > |  I spoke with Matt, he's fine either way with or without tuples.
> |  > |
> |  > |  I'd prefer "with tuples" for consistency. I use tuples sometimes,
> |  > | but  don't care about sectioning.
> |  > |
> |  > |  On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel <eric at seidel.io> wrote:
> |  > |  >
> |  > |  > I favor accepting the proposal, with or without tuples. I've been
> |  > | writing a bit of Rust recently, and agree with Chris about the
> |  > | ergonomics  of trailing commas.
> |  > |  >
> |  > |  > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
> |  > |  > > Hi,
> |  > |  > >
> |  > |  > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher
> |  Allen:
> |  > |  > > > I gave my recommendation for ExtraCommas, acceptance of the
> |  > | > > > original proposal as written. I talk with the proposer almost
> |  > | > > > every day so I know where he stands. He still thinks it's
> |  > | worth  > > > doing and would like to see it accepted. I think
> |  > | ExtraCommas  > > > merits acceptance. If we can't achieve consensus
> |  > | on it then it  > > > should be rejected so it gets cleared off the
> |  > | slate. I'm not  > > > inclined to argue a syntactic extension like
> |  > | this, but I will say
> |  > |  this:
> |  > |  > > >
> |  > |  > > > The proposal captures a nice design element that we've seen
> |  > | work  > > > very well ergonomically in Rust. We're never going to
> |  > | make the  > > > same decisions with the same tradeoffs as a totally
> |  > | different  > > > language but any time there is a relatively isolated
> |  "good idea"
> |  > |  > > > like this, I'd like to see us try to take advantage of that
> |  > | and  > > > see if it works for us.
> |  > |  > >
> |  > |  > > thanks for picking this up.
> |  > |  > >
> |  > |  > > The most contentious point, besides whether its worth the
> |  > | bother at  > > all, was the interaction with TupleSections. Which
> |  > | gives us three  > > options, I think:
> |  > |  > >  * reject
> |  > |  > >  * accept, covering tuples (and making it conflict with  > >
> |  > | TupleSections)  > >  * accept, not covering tuples.
> |  > |  > >
> |  > |  > > No decision is absolutely wrong, none is obviously right.
> |  > |  > >
> |  > |  > > Maybe we should simply do a vote, to get it decided? Simons (as
> |  > | > > Chairs), what do you think?
> |  > |  > >
> |  > |  > > Cheers,
> |  > |  > > Joachim
> |  > |  > >
> |  > |  > > --
> |  > |  > > Joachim Breitner
> |  > |  > >  mail at joachim-breitner.de
> |  > |  > >
> |  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> |  > | .joachim-breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7
> |  > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47
> |  > | %7C1%7C0%7C636911752855987147&amp;sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u
> |  > | 9fb%2BRkQMqGibDlM%3D&amp;reserved=0
> |  > |  > >
> |  > |  > >
> |  > |  > > _______________________________________________
> |  > |  > > ghc-steering-committee mailing list  > >
> |  > | ghc-steering-committee at haskell.org
> |  > |  > >
> |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> |  > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a
> |  > | mp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408d6
> |  > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598
> |  > | 7147&amp;sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&amp;re
> |  > | served=0
> |  > |  > > ttee
> |  > |  > >
> |  > |  > > Attachments:
> |  > |  > > * signature.asc
> |  > |  > _______________________________________________
> |  > |  > ghc-steering-committee mailing list  >
> |  > | ghc-steering-committee at haskell.org
> |  > |  >
> |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> |  > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> |  > | &amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408
> |  > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855
> |  > | 987147&amp;sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D&
> |  > | amp;reserved=0
> |  > |  > ee
> |  > |
> |  > |
> |  > |
> |  > |  --
> |  > |  Chris Allen
> |  > |  Currently working on
> |  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas
> |  > | kellbook.com&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836
> |  > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> |  > | 636911752855987147&amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK
> |  > | 8IyjBI%3D&amp;reserved=0
> |  > | _______________________________________________
> |  > |  ghc-steering-committee mailing list
> |  > | ghc-steering-committee at haskell.org
> |  > |
> |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> |  > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> |  > | ee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a294
> |  > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528
> |  > | 55987147&amp;sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D&
> |  > | amp;reserved=0
> |  
> |  
> |  
> |  --
> |  Chris Allen
> |  Currently working on
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo
> |  ok.com&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408
> |  d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147
> |  &amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&amp;reserved=0
> _______________________________________________
> 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  Thu Apr 18 15:22:45 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 18 Apr 2019 17:22:45 +0200
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
 <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>
Message-ID: <1f1081b7d1b17ef1a55a15d357b387a20433c76e.camel@joachim-breitner.de>

I approve of this Salomonic proposal.


Am Donnerstag, den 18.04.2019, 11:06 -0400 schrieb Richard Eisenberg:
> I strongly dislike the idea of mutually-incompatible extensions.
> 
> We could say that ExtraCommas allows extra commas everywhere, including in tuples and lists. We could also say that TupleSections overrides this behavior in tuples and gives it new meaning. We could further imagine ListSections that would override the behavior in lists. To me, this is preferable than mutual incompatibility.
> 
> Does this make for a nice user experience? I'm not sure. Happily, the reinterpretation from TupleSections or ListSections would change types, so you'd get errors up front. These errors might even be clever enough to notice that both ExtraCommas and TupleSections are in effect and gently remind the user that this combination can be confusing. Actually, this might be a nice "have your cake and eat it too" moment: let's just do all the things!
> 
> Richard
> 
> > On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> > 
> > >  "tuples included" means "incompatible with tuple sections" means "they are
> > >  mutually exclusive to a module."
> > 
> > You mean, some kind of new error message that says "these two extension are mutually incompatible".  I can't say I love this.  Let's just leave out tuples from ExtraCommas.
> > 
> > (Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day.  Maybe we omit list literals too?  Or would that break the key use-cases?
> > 
> > Simon
> > 
> > >  -----Original Message-----
> > >  From: Christopher Allen <cma at bitemyapp.com>
> > >  Sent: 18 April 2019 10:08
> > >  To: Simon Peyton Jones <simonpj at microsoft.com>
> > >  Cc: Eric Seidel <eric at seidel.io>; ghc-steering-committee at haskell.org
> > >  Subject: Re: [ghc-steering-committee] Extra Commas
> > >  
> > >  My understanding of previous discussions was that:
> > >  
> > >  
> > >  On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones <simonpj at microsoft.com>
> > >  wrote:
> > >  >
> > >  > But it's actually *incompatible* with TupleSections, so how shoule
> > >  >         (True,)
> > >  > be interpreted if both are on?
> > >  >
> > >  > S
> > >  >
> > >  > |  -----Original Message-----
> > >  > |  From: ghc-steering-committee
> > >  > | <ghc-steering-committee-bounces at haskell.org>
> > >  > |  On Behalf Of Christopher Allen
> > >  > |  Sent: 18 April 2019 04:19
> > >  > |  To: Eric Seidel <eric at seidel.io>
> > >  > |  Cc: ghc-steering-committee at haskell.org
> > >  > |  Subject: Re: [ghc-steering-committee] Extra Commas
> > >  > |
> > >  > |  I spoke with Matt, he's fine either way with or without tuples.
> > >  > |
> > >  > |  I'd prefer "with tuples" for consistency. I use tuples sometimes,
> > >  > | but  don't care about sectioning.
> > >  > |
> > >  > |  On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel <eric at seidel.io> wrote:
> > >  > |  >
> > >  > |  > I favor accepting the proposal, with or without tuples. I've been
> > >  > | writing a bit of Rust recently, and agree with Chris about the
> > >  > | ergonomics  of trailing commas.
> > >  > |  >
> > >  > |  > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
> > >  > |  > > Hi,
> > >  > |  > >
> > >  > |  > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher
> > >  Allen:
> > >  > |  > > > I gave my recommendation for ExtraCommas, acceptance of the
> > >  > | > > > original proposal as written. I talk with the proposer almost
> > >  > | > > > every day so I know where he stands. He still thinks it's
> > >  > | worth  > > > doing and would like to see it accepted. I think
> > >  > | ExtraCommas  > > > merits acceptance. If we can't achieve consensus
> > >  > | on it then it  > > > should be rejected so it gets cleared off the
> > >  > | slate. I'm not  > > > inclined to argue a syntactic extension like
> > >  > | this, but I will say
> > >  > |  this:
> > >  > |  > > >
> > >  > |  > > > The proposal captures a nice design element that we've seen
> > >  > | work  > > > very well ergonomically in Rust. We're never going to
> > >  > | make the  > > > same decisions with the same tradeoffs as a totally
> > >  > | different  > > > language but any time there is a relatively isolated
> > >  "good idea"
> > >  > |  > > > like this, I'd like to see us try to take advantage of that
> > >  > | and  > > > see if it works for us.
> > >  > |  > >
> > >  > |  > > thanks for picking this up.
> > >  > |  > >
> > >  > |  > > The most contentious point, besides whether its worth the
> > >  > | bother at  > > all, was the interaction with TupleSections. Which
> > >  > | gives us three  > > options, I think:
> > >  > |  > >  * reject
> > >  > |  > >  * accept, covering tuples (and making it conflict with  > >
> > >  > | TupleSections)  > >  * accept, not covering tuples.
> > >  > |  > >
> > >  > |  > > No decision is absolutely wrong, none is obviously right.
> > >  > |  > >
> > >  > |  > > Maybe we should simply do a vote, to get it decided? Simons (as
> > >  > | > > Chairs), what do you think?
> > >  > |  > >
> > >  > |  > > Cheers,
> > >  > |  > > Joachim
> > >  > |  > >
> > >  > |  > > --
> > >  > |  > > Joachim Breitner
> > >  > |  > >  mail at joachim-breitner.de
> > >  > |  > >
> > >  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> > >  > | .joachim-breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7
> > >  > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47
> > >  > | %7C1%7C0%7C636911752855987147&amp;sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u
> > >  > | 9fb%2BRkQMqGibDlM%3D&amp;reserved=0
> > >  > |  > >
> > >  > |  > >
> > >  > |  > > _______________________________________________
> > >  > |  > > ghc-steering-committee mailing list  > >
> > >  > | ghc-steering-committee at haskell.org
> > >  > |  > >
> > >  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > >  > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a
> > >  > | mp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408d6
> > >  > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598
> > >  > | 7147&amp;sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&amp;re
> > >  > | served=0
> > >  > |  > > ttee
> > >  > |  > >
> > >  > |  > > Attachments:
> > >  > |  > > * signature.asc
> > >  > |  > _______________________________________________
> > >  > |  > ghc-steering-committee mailing list  >
> > >  > | ghc-steering-committee at haskell.org
> > >  > |  >
> > >  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > >  > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> > >  > | &amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408
> > >  > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855
> > >  > | 987147&amp;sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D&
> > >  > | amp;reserved=0
> > >  > |  > ee
> > >  > |
> > >  > |
> > >  > |
> > >  > |  --
> > >  > |  Chris Allen
> > >  > |  Currently working on
> > >  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas
> > >  > | kellbook.com&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836
> > >  > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> > >  > | 636911752855987147&amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK
> > >  > | 8IyjBI%3D&amp;reserved=0
> > >  > | _______________________________________________
> > >  > |  ghc-steering-committee mailing list
> > >  > | ghc-steering-committee at haskell.org
> > >  > |
> > >  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > >  > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> > >  > | ee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a294
> > >  > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528
> > >  > | 55987147&amp;sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D&
> > >  > | amp;reserved=0
> > >  
> > >  
> > >  
> > >  --
> > >  Chris Allen
> > >  Currently working on
> > >  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo
> > >  ok.com&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408
> > >  d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147
> > >  &amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&amp;reserved=0
> > _______________________________________________
> > 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/

-------------- 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/20190418/051ae54f/attachment-0001.sig>

From mail at joachim-breitner.de  Thu Apr 18 16:02:56 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 18 Apr 2019 18:02:56 +0200
Subject: [ghc-steering-committee] Please review #213: Namespace specifiers,
	Shepherd: Iavor
Message-ID: <3077d026d7a217d39f9b977e877a9ba29b73b4fc.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Namespace specifiers
have been proposed by Richard
https://github.com/ghc-proposals/ghc-proposals/pull/213
https://github.com/goldfirere/ghc-proposals/blob/namespaces/proposals/0000-namespaces.rst

I propose Iavor as the Shepherd.

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

Thanks,
Joachim
-- 
Joachim Breitner
  mail 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/20190418/c0c2664b/attachment.sig>

From mail at joachim-breitner.de  Thu Apr 18 16:21:43 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 18 Apr 2019 18:21:43 +0200
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <4483DE1D-94B1-4EB1-9C1D-C7A46E855799@richarde.dev>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
 <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>
 <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>
 <4bd51c16b93116a05017c13ea88ed542e3a75fae.camel@joachim-breitner.de>
 <CAGK9nuowqJ5gXJM4iZgCZ7PvDescX0K5-aK6t-haOUrfBT6WEQ@mail.gmail.com>
 <55681059-73b1-4f67-b8dd-ac5c334b7bc0@www.fastmail.com>
 <4483DE1D-94B1-4EB1-9C1D-C7A46E855799@richarde.dev>
Message-ID: <4e4027efe82f5420df5408cbf6685bf6dd150437.camel@joachim-breitner.de>

Hi,

based on this discussion I am making a concrete proposal here:

https://github.com/ghc-proposals/ghc-proposals/pull/221

The main idea is that if the shepherd intends to reject the proposal,
they have to first discuss this with the authors, to give the authors a
chance to respond, tweak, or point out misunderstandings in the
shepherd’s perception.

So the process of accepting proposals is unchanged, and still on the
list, rejecting a proposal is now a two step process: the shepherd
discusses it with the authors on GitHub (and anyone else interested, of
course), and then there is a shorter discussion on the mailinglist,
with hopefully all facts clarified.

This does not move all discussion to Github yet, so it is the smaller
change, in a way. But of course committee members are encouraged to
join GitHub discussions early, especially if they are unhappy with a
proposal.


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/20190418/5c978f2e/attachment.sig>

From chak at justtesting.org  Mon Apr 22 19:44:21 2019
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Mon, 22 Apr 2019 21:44:21 +0200
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <4e4027efe82f5420df5408cbf6685bf6dd150437.camel@joachim-breitner.de>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
 <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>
 <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>
 <4bd51c16b93116a05017c13ea88ed542e3a75fae.camel@joachim-breitner.de>
 <CAGK9nuowqJ5gXJM4iZgCZ7PvDescX0K5-aK6t-haOUrfBT6WEQ@mail.gmail.com>
 <55681059-73b1-4f67-b8dd-ac5c334b7bc0@www.fastmail.com>
 <4483DE1D-94B1-4EB1-9C1D-C7A46E855799@richarde.dev>
 <4e4027efe82f5420df5408cbf6685bf6dd150437.camel@joachim-breitner.de>
Message-ID: <9F145602-0251-40FE-A521-1F61DB44C8FA@justtesting.org>

Yes, I think, this is an improvement.

Cheers,
Manuel

> Am 18.04.2019 um 18:21 schrieb Joachim Breitner <mail at joachim-breitner.de>:
> 
> Hi,
> 
> based on this discussion I am making a concrete proposal here:
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/221
> 
> The main idea is that if the shepherd intends to reject the proposal,
> they have to first discuss this with the authors, to give the authors a
> chance to respond, tweak, or point out misunderstandings in the
> shepherd’s perception.
> 
> So the process of accepting proposals is unchanged, and still on the
> list, rejecting a proposal is now a two step process: the shepherd
> discusses it with the authors on GitHub (and anyone else interested, of
> course), and then there is a shorter discussion on the mailinglist,
> with hopefully all facts clarified.
> 
> This does not move all discussion to Github yet, so it is the smaller
> change, in a way. But of course committee members are encouraged to
> join GitHub discussions early, especially if they are unhappy with a
> proposal.
> 
> 
> 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 marlowsd at gmail.com  Mon Apr 22 21:15:52 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 22 Apr 2019 22:15:52 +0100
Subject: [ghc-steering-committee] #190: Module qualified syntax,
 recommendation: accept
In-Reply-To: <7e2210851b53e68fb08f81da78ad22039816f517.camel@joachim-breitner.de>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
 <CALpVSmP+s2L0cWZ6WqJnoX-v7xmn8ofit3ekawMPacAjnJdp9w@mail.gmail.com>
 <CAGK9nuqaow5pdoebwcQTD8Af2ygpUvmjtW9ACATpZ9c2vEiT3A@mail.gmail.com>
 <2A4CEC6F-5A55-43D8-9714-F507AE1A8CBC@cs.brynmawr.edu>
 <7e2210851b53e68fb08f81da78ad22039816f517.camel@joachim-breitner.de>
Message-ID: <CANsrgP+svBvqj2dPO471EmEhDYdH9sxdVdVGk3XKLKzQXJrHQQ@mail.gmail.com>

On Wed, 17 Apr 2019 at 08:00, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> it looks like we agree on accepting this with a pragma, but need to
> decide upon the pragma. We had these options:
>
>  * FlexibleImports
>  * QualifiedLast
>  * QualifiedImportsPostpositive
>  * ImportQualifiedPost
>
> Simon M, as the shepherd, care to make a final recommendation about the
> pragma and/or ask the authors to come up with one (and amend the
> proposal)?
>

Sometimes I just want someone else to choose the actual syntax while I
scowl slightly and accept it :-)

Ok, would anyone be vigorously against ImportQualifiedPost?

(on "FlexibleImports" I'm not very keen on adding an extension flag that we
explicitly intend to mean different things in the future. That's just a way
of getting around the extension flag policy. Either we think it's a good
idea to have flags for every extension, or we don't. Yes I know we've
discussed this in the past and there are grey areas, and we do already
change the meaning of extensions sometimes. But pre-allocating a bucket for
an unknown set of future extensions seems like a step too far to me.)

Cheers
Simon



>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail 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/20190422/b3874551/attachment.html>

From simonpj at microsoft.com  Tue Apr 23 11:52:17 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 23 Apr 2019 11:52:17 +0000
Subject: [ghc-steering-committee] #190: Module qualified syntax,
 recommendation: accept
In-Reply-To: <CANsrgP+svBvqj2dPO471EmEhDYdH9sxdVdVGk3XKLKzQXJrHQQ@mail.gmail.com>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
 <CALpVSmP+s2L0cWZ6WqJnoX-v7xmn8ofit3ekawMPacAjnJdp9w@mail.gmail.com>
 <CAGK9nuqaow5pdoebwcQTD8Af2ygpUvmjtW9ACATpZ9c2vEiT3A@mail.gmail.com>
 <2A4CEC6F-5A55-43D8-9714-F507AE1A8CBC@cs.brynmawr.edu>
 <7e2210851b53e68fb08f81da78ad22039816f517.camel@joachim-breitner.de>
 <CANsrgP+svBvqj2dPO471EmEhDYdH9sxdVdVGk3XKLKzQXJrHQQ@mail.gmail.com>
Message-ID: <DB7PR83MB02988376D3D84CE664A6367CAD230@DB7PR83MB0298.EURPRD83.prod.outlook.com>

I’m ok with ImportQualifiedPost.

S

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 22 April 2019 22:16
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] #190: Module qualified syntax, recommendation: accept

On Wed, 17 Apr 2019 at 08:00, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,

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

 * FlexibleImports
 * QualifiedLast
 * QualifiedImportsPostpositive
 * ImportQualifiedPost

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

Sometimes I just want someone else to choose the actual syntax while I scowl slightly and accept it :-)

Ok, would anyone be vigorously against ImportQualifiedPost?

(on "FlexibleImports" I'm not very keen on adding an extension flag that we explicitly intend to mean different things in the future. That's just a way of getting around the extension flag policy. Either we think it's a good idea to have flags for every extension, or we don't. Yes I know we've discussed this in the past and there are grey areas, and we do already change the meaning of extensions sometimes. But pre-allocating a bucket for an unknown set of future extensions seems like a step too far to me.)

Cheers
Simon



Cheers,
Joachim
--
Joachim Breitner
  mail 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%7Ccdbd32d99299486f83b008d6c767c2a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636915645804232180&sdata=ccjFM9bAa14utV%2BDeGft5bDjjj7c5gZfl6CpC%2FdFDXc%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%7Ccdbd32d99299486f83b008d6c767c2a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636915645804232180&sdata=FDR5Eaq8RcdCRnIHHD9FyssFY1FIvCvojg5cqCK3%2B5k%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190423/74a3ab42/attachment-0001.html>

From iavor.diatchki at gmail.com  Tue Apr 23 16:55:49 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 23 Apr 2019 09:55:49 -0700
Subject: [ghc-steering-committee] Discussion on #155 Type Variable in
	Labmdas
In-Reply-To: <7f2af94c1df8d825ea414cd354e77c247f482c91.camel@joachim-breitner.de>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <CAGK9nurqdZA3Zr3UXSVz9bdeThxH96RgsXu=-mDzukOLmdY6JQ@mail.gmail.com>
 <5b7eb5a6-d961-43b2-a93d-96d23798413a@www.fastmail.com>
 <CAGK9nup0=1PtizTFb-As+cmuUi-nO31kj5RrJaRWqNhjtfRO4A@mail.gmail.com>
 <DB7PR83MB0298F8FDED14784C9D60871FAD500@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <7f2af94c1df8d825ea414cd354e77c247f482c91.camel@joachim-breitner.de>
Message-ID: <CAGK9nur9fBnigiCTQ+YNsHa2AO2NfDbMe+bTSAOR5kaw-OsDYw@mail.gmail.com>

Well there wasn't really any discussion after my message, to summarize:
   * Simon said that he is still on the fence, and would like more input
from the rest of the committee,
   * An you (Joachim) said that you are on the fence, but you think that we
should do it because people may use the feature in surprising ways.

So I am still unconvinced, especially if we don't have a good motivation
beyond expecting to be surprised by the users :-)

As far as I see, the main benefit is the ability to name the type when
passing in polymorphic parameters, where the type variable
does not appear in any of the arguments of to the parameter.

To me this seems as a rather niche case to warrant a new language construct
to make it more convenient.  In addition,
the notation certainly looks like "big lambda" and I bet there will be some
confusion about why it doesn't work as one would expect (yet?).

So my recommendation would be to shelve this for the moment, and spend some
effort to make it behave more like "big lambda",
which I think would be a potentially useful feature.

-Iavor
















On Wed, Apr 17, 2019 at 12:16 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> there is lots of fence-sitting here (and I am also on that particular
> fence). But to make shake the fence: Let’s do it! I think people will
> find good and surprising uses for this feature.
>
> Iavor, your original message did not carry a concrete recommendation.
> Did the discussion help you to form an opinion?
>
> Cheers,
> Joachim
>
>
> Am Donnerstag, den 04.04.2019, 10:10 +0000 schrieb Simon Peyton Jones
> via ghc-steering-committee:
> > I really am on the fence.   Good things:
> >
> > Richard’s first motivating example, where we still need Proxy, is quite
> convincing.
> >
> > It fills out an obvious gap, with the right sort of intro/elim duality
> with visible type application.
> >
> > And I like that it gives us a language in which to talk about System F
> elaboration of the program, if and when we want to.  E.g. we can say: if
> you write
> >
> > f x = Just x
> >
> > it is as if you had written
> >
> > f :: forall a. a -> Maybe a
> > f = \@a \(x::a). Just x
> >
> > Less good:
> > It’s still incomplete concerning (B) because we can’t talk about
> dictionary bindings.
> > It adds more complexity.
> > We are not under real pressure to do this now.
> >
> > I’d like to hear from a broader range of opinion.
> >
> > Simon
> >
> > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> On Behalf Of Iavor Diatchki
> > Sent: 03 April 2019 17:46
> > To: Eric Seidel <eric at seidel.io>
> > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable
> in Labmdas
> >
> > Hello,
> >
> > perhaps it is time to come up with some sort of decision here.  Based on
> the replies to this thread we seem to have the following opinions:
> >   1. Eric and Richard seem to be quite keen on the feature
> >   2. Simon is on the fence, but likes it because it introduces System F
> vocabulary to Haskell
> >   3. I am skeptical of the proposal as is, as I think it adds additional
> complexity to the language (more non-orthogonal features) without
> significant payoff.
> >
> > Does anyone else have anything else to add?
> >
> > -Iavor
> >
> >
> >
> > On Tue, Mar 26, 2019 at 6:48 PM Eric Seidel <eric at seidel.io> wrote:
> > > On Tue, Mar 26, 2019, at 13:17, Iavor Diatchki wrote:
> > > > My concern is that the notation certainly suggests that you are
> binding
> > > > types with the @ syntax, but in really it is still the type
> signature
> > > > that guides the binding of the variables and the @ parameters just
> > > > duplicate the information from the type signature.
> > >
> > > But you are binding types with the @ syntax. The proposal gives a
> number of examples where the @-bound type variable is bound by a different
> name (or not at all) in the type signature. Many are contrived, to
> demonstrate where the binders are allowed, but the higher-rank and
> proxy-eliding examples look compelling to me.
> > >
> > > We also already allow repeated value binders in Haskell. When I write
> a function in equational style, I have to rebind each argument in each
> alternate equation. Sometimes this is noisy and I'll prefer a single
> equation with an explicit `case`. But for functions where the body is
> sizable, I find the repeated binders to be quite helpful because the scopes
> are smaller. I can easily see the same benefit applying to type binders.
> Ultimately, I think this comes down to a matter of style, and I favor
> letting Haskell programmers pick the style that works best for them.
> > >
> > > Eric
> > > _______________________________________________
> > > 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/
>
> _______________________________________________
> 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/20190423/1fcbcf74/attachment.html>

From simonpj at microsoft.com  Tue Apr 23 22:46:16 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 23 Apr 2019 22:46:16 +0000
Subject: [ghc-steering-committee] Discussion on #155 Type Variable
	in	Labmdas
In-Reply-To: <CAGK9nur9fBnigiCTQ+YNsHa2AO2NfDbMe+bTSAOR5kaw-OsDYw@mail.gmail.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <CAGK9nurqdZA3Zr3UXSVz9bdeThxH96RgsXu=-mDzukOLmdY6JQ@mail.gmail.com>
 <5b7eb5a6-d961-43b2-a93d-96d23798413a@www.fastmail.com>
 <CAGK9nup0=1PtizTFb-As+cmuUi-nO31kj5RrJaRWqNhjtfRO4A@mail.gmail.com>
 <DB7PR83MB0298F8FDED14784C9D60871FAD500@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <7f2af94c1df8d825ea414cd354e77c247f482c91.camel@joachim-breitner.de>
 <CAGK9nur9fBnigiCTQ+YNsHa2AO2NfDbMe+bTSAOR5kaw-OsDYw@mail.gmail.com>
Message-ID: <AM0PR83MB0289A7B216F445337F8687CCAD230@AM0PR83MB0289.EURPRD83.prod.outlook.com>

I’m puzzled why other members of the committee have not expressed a view.  Would you consider doing so?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 23 April 2019 17:56
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas

Well there wasn't really any discussion after my message, to summarize:
   * Simon said that he is still on the fence, and would like more input from the rest of the committee,
   * An you (Joachim) said that you are on the fence, but you think that we should do it because people may use the feature in surprising ways.

So I am still unconvinced, especially if we don't have a good motivation beyond expecting to be surprised by the users :-)

As far as I see, the main benefit is the ability to name the type when passing in polymorphic parameters, where the type variable
does not appear in any of the arguments of to the parameter.

To me this seems as a rather niche case to warrant a new language construct to make it more convenient.  In addition,
the notation certainly looks like "big lambda" and I bet there will be some confusion about why it doesn't work as one would expect (yet?).

So my recommendation would be to shelve this for the moment, and spend some effort to make it behave more like "big lambda",
which I think would be a potentially useful feature.

-Iavor
















On Wed, Apr 17, 2019 at 12:16 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,

there is lots of fence-sitting here (and I am also on that particular
fence). But to make shake the fence: Let’s do it! I think people will
find good and surprising uses for this feature.

Iavor, your original message did not carry a concrete recommendation.
Did the discussion help you to form an opinion?

Cheers,
Joachim


Am Donnerstag, den 04.04.2019, 10:10 +0000 schrieb Simon Peyton Jones
via ghc-steering-committee:
> I really am on the fence.   Good things:
>
> Richard’s first motivating example, where we still need Proxy, is quite convincing.
>
> It fills out an obvious gap, with the right sort of intro/elim duality with visible type application.
>
> And I like that it gives us a language in which to talk about System F elaboration of the program, if and when we want to.  E.g. we can say: if you write
>
> f x = Just x
>
> it is as if you had written
>
> f :: forall a. a -> Maybe a
> f = \@a \(x::a). Just x
>
> Less good:
> It’s still incomplete concerning (B) because we can’t talk about dictionary bindings.
> It adds more complexity.
> We are not under real pressure to do this now.
>
> I’d like to hear from a broader range of opinion.
>
> Simon
>
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Iavor Diatchki
> Sent: 03 April 2019 17:46
> To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>
> Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
> Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas
>
> Hello,
>
> perhaps it is time to come up with some sort of decision here.  Based on the replies to this thread we seem to have the following opinions:
>   1. Eric and Richard seem to be quite keen on the feature
>   2. Simon is on the fence, but likes it because it introduces System F vocabulary to Haskell
>   3. I am skeptical of the proposal as is, as I think it adds additional complexity to the language (more non-orthogonal features) without significant payoff.
>
> Does anyone else have anything else to add?
>
> -Iavor
>
>
>
> On Tue, Mar 26, 2019 at 6:48 PM Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
> > On Tue, Mar 26, 2019, at 13:17, Iavor Diatchki wrote:
> > > My concern is that the notation certainly suggests that you are binding
> > > types with the @ syntax, but in really it is still the type signature
> > > that guides the binding of the variables and the @ parameters just
> > > duplicate the information from the type signature.
> >
> > But you are binding types with the @ syntax. The proposal gives a number of examples where the @-bound type variable is bound by a different name (or not at all) in the type signature. Many are contrived, to demonstrate where the binders are allowed, but the higher-rank and proxy-eliding examples look compelling to me.
> >
> > We also already allow repeated value binders in Haskell. When I write a function in equational style, I have to rebind each argument in each alternate equation. Sometimes this is noisy and I'll prefer a single equation with an explicit `case`. But for functions where the body is sizable, I find the repeated binders to be quite helpful because the scopes are smaller. I can easily see the same benefit applying to type binders. Ultimately, I think this comes down to a matter of style, and I favor letting Haskell programmers pick the style that works best for them.
> >
> > Eric
> > _______________________________________________
> > 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%7Cb01f469f49274bc3980108d6c80c9851%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636916353760006580&sdata=0bUACqXPM5OmzQnMNq7A%2Bqx7YCd9e1CS44thT%2B44R9g%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%7Cb01f469f49274bc3980108d6c80c9851%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636916353760016579&sdata=isitcg1QKSBFqIhhkqazqSujvX4s4lbYC4HiHhQSxdg%3D&reserved=0>
--
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%7Cb01f469f49274bc3980108d6c80c9851%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636916353760016579&sdata=N2iYGZyHh%2BgieMXW7I4D9odfi6HjqazEfWYpN7nK54g%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%7Cb01f469f49274bc3980108d6c80c9851%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636916353760026570&sdata=MP24WmWJS7qksc0%2FQ0PY8WYSBqeMeAogL9b%2BucV%2FBBU%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190423/6473d375/attachment-0001.html>

From marlowsd at gmail.com  Wed Apr 24 07:30:00 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 24 Apr 2019 08:30:00 +0100
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
 <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>
Message-ID: <CANsrgPJkoC7q10Um7F6+ToL=-aqD_AUKdb_1cBu=jpbRUfixxg@mail.gmail.com>

I'm also strongly against mutually incompatible extensions.

I'm not sure about allowing the combination of TupleSections and
ExtraCommas. It would mean that (x,) has a different meaning depending on
what extensions are in force. This is a pretty strange direction to take
the language in, and raises questions about whether we should think of GHC
as a testing ground for language extensions of which only some will
eventually make it into a language standard, or whether we should take a
position on which extensions are sensible when there are conflicts.
Personally I'm in favour of the committee taking some editorial decisions
here - not just assessing which extensions make sense in isolation, but
considering whether an extension makes sense in the context of the other
extensions we already have.

But back to the current proposal, I would vote for allowing the parts of
the proposal that don't conflict with TupleSections.

Cheers
Simon

On Thu, 18 Apr 2019 at 16:06, Richard Eisenberg <rae at richarde.dev> wrote:

> I strongly dislike the idea of mutually-incompatible extensions.
>
> We could say that ExtraCommas allows extra commas everywhere, including in
> tuples and lists. We could also say that TupleSections overrides this
> behavior in tuples and gives it new meaning. We could further imagine
> ListSections that would override the behavior in lists. To me, this is
> preferable than mutual incompatibility.
>
> Does this make for a nice user experience? I'm not sure. Happily, the
> reinterpretation from TupleSections or ListSections would change types, so
> you'd get errors up front. These errors might even be clever enough to
> notice that both ExtraCommas and TupleSections are in effect and gently
> remind the user that this combination can be confusing. Actually, this
> might be a nice "have your cake and eat it too" moment: let's just do all
> the things!
>
> Richard
>
> > On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> >
> > |  "tuples included" means "incompatible with tuple sections" means
> "they are
> > |  mutually exclusive to a module."
> >
> > You mean, some kind of new error message that says "these two extension
> are mutually incompatible".  I can't say I love this.  Let's just leave out
> tuples from ExtraCommas.
> >
> > (Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day.
> Maybe we omit list literals too?  Or would that break the key use-cases?
> >
> > Simon
> >
> > |  -----Original Message-----
> > |  From: Christopher Allen <cma at bitemyapp.com>
> > |  Sent: 18 April 2019 10:08
> > |  To: Simon Peyton Jones <simonpj at microsoft.com>
> > |  Cc: Eric Seidel <eric at seidel.io>; ghc-steering-committee at haskell.org
> > |  Subject: Re: [ghc-steering-committee] Extra Commas
> > |
> > |  My understanding of previous discussions was that:
> > |
> > |
> > |  On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones <
> simonpj at microsoft.com>
> > |  wrote:
> > |  >
> > |  > But it's actually *incompatible* with TupleSections, so how shoule
> > |  >         (True,)
> > |  > be interpreted if both are on?
> > |  >
> > |  > S
> > |  >
> > |  > |  -----Original Message-----
> > |  > |  From: ghc-steering-committee
> > |  > | <ghc-steering-committee-bounces at haskell.org>
> > |  > |  On Behalf Of Christopher Allen
> > |  > |  Sent: 18 April 2019 04:19
> > |  > |  To: Eric Seidel <eric at seidel.io>
> > |  > |  Cc: ghc-steering-committee at haskell.org
> > |  > |  Subject: Re: [ghc-steering-committee] Extra Commas
> > |  > |
> > |  > |  I spoke with Matt, he's fine either way with or without tuples.
> > |  > |
> > |  > |  I'd prefer "with tuples" for consistency. I use tuples sometimes,
> > |  > | but  don't care about sectioning.
> > |  > |
> > |  > |  On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel <eric at seidel.io>
> wrote:
> > |  > |  >
> > |  > |  > I favor accepting the proposal, with or without tuples. I've
> been
> > |  > | writing a bit of Rust recently, and agree with Chris about the
> > |  > | ergonomics  of trailing commas.
> > |  > |  >
> > |  > |  > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
> > |  > |  > > Hi,
> > |  > |  > >
> > |  > |  > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher
> > |  Allen:
> > |  > |  > > > I gave my recommendation for ExtraCommas, acceptance of the
> > |  > | > > > original proposal as written. I talk with the proposer
> almost
> > |  > | > > > every day so I know where he stands. He still thinks it's
> > |  > | worth  > > > doing and would like to see it accepted. I think
> > |  > | ExtraCommas  > > > merits acceptance. If we can't achieve
> consensus
> > |  > | on it then it  > > > should be rejected so it gets cleared off the
> > |  > | slate. I'm not  > > > inclined to argue a syntactic extension like
> > |  > | this, but I will say
> > |  > |  this:
> > |  > |  > > >
> > |  > |  > > > The proposal captures a nice design element that we've seen
> > |  > | work  > > > very well ergonomically in Rust. We're never going to
> > |  > | make the  > > > same decisions with the same tradeoffs as a
> totally
> > |  > | different  > > > language but any time there is a relatively
> isolated
> > |  "good idea"
> > |  > |  > > > like this, I'd like to see us try to take advantage of that
> > |  > | and  > > > see if it works for us.
> > |  > |  > >
> > |  > |  > > thanks for picking this up.
> > |  > |  > >
> > |  > |  > > The most contentious point, besides whether its worth the
> > |  > | bother at  > > all, was the interaction with TupleSections. Which
> > |  > | gives us three  > > options, I think:
> > |  > |  > >  * reject
> > |  > |  > >  * accept, covering tuples (and making it conflict with  > >
> > |  > | TupleSections)  > >  * accept, not covering tuples.
> > |  > |  > >
> > |  > |  > > No decision is absolutely wrong, none is obviously right.
> > |  > |  > >
> > |  > |  > > Maybe we should simply do a vote, to get it decided? Simons
> (as
> > |  > | > > Chairs), what do you think?
> > |  > |  > >
> > |  > |  > > Cheers,
> > |  > |  > > Joachim
> > |  > |  > >
> > |  > |  > > --
> > |  > |  > > Joachim Breitner
> > |  > |  > >  mail at joachim-breitner.de
> > |  > |  > >
> > |  > |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> > |  > | .joachim-breitner.de%2F&amp;data=02%7C01%7Csimonpj%
> 40microsoft.com%7
> > |  > |
> C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47
> > |  > |
> %7C1%7C0%7C636911752855987147&amp;sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u
> > |  > | 9fb%2BRkQMqGibDlM%3D&amp;reserved=0
> > |  > |  > >
> > |  > |  > >
> > |  > |  > > _______________________________________________
> > |  > |  > > ghc-steering-committee mailing list  > >
> > |  > | ghc-steering-committee at haskell.org
> > |  > |  > >
> > |  > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > |  > | il.haskell.org
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a
> > |  > | mp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C670f986836834427a29408d6
> > |  > |
> c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598
> > |  > |
> 7147&amp;sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&amp;re
> > |  > | served=0
> > |  > |  > > ttee
> > |  > |  > >
> > |  > |  > > Attachments:
> > |  > |  > > * signature.asc
> > |  > |  > _______________________________________________
> > |  > |  > ghc-steering-committee mailing list  >
> > |  > | ghc-steering-committee at haskell.org
> > |  > |  >
> > |  > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > |  > | il.haskell.org
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> > |  > | &amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C670f986836834427a29408
> > |  > |
> d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855
> > |  > |
> 987147&amp;sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D&
> > |  > | amp;reserved=0
> > |  > |  > ee
> > |  > |
> > |  > |
> > |  > |
> > |  > |  --
> > |  > |  Chris Allen
> > |  > |  Currently working on
> > |  > |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas
> > |  > | kellbook.com&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C670f986836
> > |  > |
> 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> > |  > |
> 636911752855987147&amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK
> > |  > | 8IyjBI%3D&amp;reserved=0
> > |  > | _______________________________________________
> > |  > |  ghc-steering-committee mailing list
> > |  > | ghc-steering-committee at haskell.org
> > |  > |
> > |  > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > |  > | il.haskell.org
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> > |  > | ee&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C670f986836834427a294
> > |  > |
> 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528
> > |  > |
> 55987147&amp;sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D&
> > |  > | amp;reserved=0
> > |
> > |
> > |
> > |  --
> > |  Chris Allen
> > |  Currently working on
> > |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo
> > |  ok.com&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C670f986836834427a29408
> > |
> d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147
> > |
> &amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&amp;reserved=0
> > _______________________________________________
> > 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/20190424/177eeea8/attachment.html>

From bravit111 at gmail.com  Wed Apr 24 11:59:26 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Wed, 24 Apr 2019 14:59:26 +0300
Subject: [ghc-steering-committee] Discussion on #155 Type Variable in
	Labmdas
In-Reply-To: <AM0PR83MB0289A7B216F445337F8687CCAD230@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <CAGK9nurqdZA3Zr3UXSVz9bdeThxH96RgsXu=-mDzukOLmdY6JQ@mail.gmail.com>
 <5b7eb5a6-d961-43b2-a93d-96d23798413a@www.fastmail.com>
 <CAGK9nup0=1PtizTFb-As+cmuUi-nO31kj5RrJaRWqNhjtfRO4A@mail.gmail.com>
 <DB7PR83MB0298F8FDED14784C9D60871FAD500@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <7f2af94c1df8d825ea414cd354e77c247f482c91.camel@joachim-breitner.de>
 <CAGK9nur9fBnigiCTQ+YNsHa2AO2NfDbMe+bTSAOR5kaw-OsDYw@mail.gmail.com>
 <AM0PR83MB0289A7B216F445337F8687CCAD230@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <CALpVSmMm7V8wrKXx87a1t=w3UoeR15R=5zznRgNDMDC38rMeaA@mail.gmail.com>

Hello,

I actually like this proposal. I see it as a relatively simple (limited,
but that's ok) way to express some of System F features in Haskell. By the
way, it makes it easier to teach about Haskell to Core translation (I did
that several times): we could present it step by step without leaving
Haskell while being able to use GHC for checking code. Getting rid of Proxy
and providing an alternative to the less-intuitive ScopedTypeVariables
extension is a big plus either.

Regards,
Vitaly

ср, 24 апр. 2019 г. в 01:46, Simon Peyton Jones via ghc-steering-committee <
ghc-steering-committee at haskell.org>:

> I’m puzzled why other members of the committee have not expressed a view.
> Would you consider doing so?
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Iavor Diatchki
> *Sent:* 23 April 2019 17:56
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Discussion on #155 Type Variable
> in Labmdas
>
>
>
> Well there wasn't really any discussion after my message, to summarize:
>
>    * Simon said that he is still on the fence, and would like more input
> from the rest of the committee,
>
>    * An you (Joachim) said that you are on the fence, but you think that
> we should do it because people may use the feature in surprising ways.
>
>
>
> So I am still unconvinced, especially if we don't have a good motivation
> beyond expecting to be surprised by the users :-)
>
>
>
> As far as I see, the main benefit is the ability to name the type when
> passing in polymorphic parameters, where the type variable
>
> does not appear in any of the arguments of to the parameter.
>
>
>
> To me this seems as a rather niche case to warrant a new language
> construct to make it more convenient.  In addition,
>
> the notation certainly looks like "big lambda" and I bet there will be
> some confusion about why it doesn't work as one would expect (yet?).
>
>
>
> So my recommendation would be to shelve this for the moment, and spend
> some effort to make it behave more like "big lambda",
>
> which I think would be a potentially useful feature.
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Apr 17, 2019 at 12:16 AM Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
> Hi,
>
> there is lots of fence-sitting here (and I am also on that particular
> fence). But to make shake the fence: Let’s do it! I think people will
> find good and surprising uses for this feature.
>
> Iavor, your original message did not carry a concrete recommendation.
> Did the discussion help you to form an opinion?
>
> Cheers,
> Joachim
>
>
> Am Donnerstag, den 04.04.2019, 10:10 +0000 schrieb Simon Peyton Jones
> via ghc-steering-committee:
> > I really am on the fence.   Good things:
> >
> > Richard’s first motivating example, where we still need Proxy, is quite
> convincing.
> >
> > It fills out an obvious gap, with the right sort of intro/elim duality
> with visible type application.
> >
> > And I like that it gives us a language in which to talk about System F
> elaboration of the program, if and when we want to.  E.g. we can say: if
> you write
> >
> > f x = Just x
> >
> > it is as if you had written
> >
> > f :: forall a. a -> Maybe a
> > f = \@a \(x::a). Just x
> >
> > Less good:
> > It’s still incomplete concerning (B) because we can’t talk about
> dictionary bindings.
> > It adds more complexity.
> > We are not under real pressure to do this now.
> >
> > I’d like to hear from a broader range of opinion.
> >
> > Simon
> >
> > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> On Behalf Of Iavor Diatchki
> > Sent: 03 April 2019 17:46
> > To: Eric Seidel <eric at seidel.io>
> > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable
> in Labmdas
> >
> > Hello,
> >
> > perhaps it is time to come up with some sort of decision here.  Based on
> the replies to this thread we seem to have the following opinions:
> >   1. Eric and Richard seem to be quite keen on the feature
> >   2. Simon is on the fence, but likes it because it introduces System F
> vocabulary to Haskell
> >   3. I am skeptical of the proposal as is, as I think it adds additional
> complexity to the language (more non-orthogonal features) without
> significant payoff.
> >
> > Does anyone else have anything else to add?
> >
> > -Iavor
> >
> >
> >
> > On Tue, Mar 26, 2019 at 6:48 PM Eric Seidel <eric at seidel.io> wrote:
> > > On Tue, Mar 26, 2019, at 13:17, Iavor Diatchki wrote:
> > > > My concern is that the notation certainly suggests that you are
> binding
> > > > types with the @ syntax, but in really it is still the type
> signature
> > > > that guides the binding of the variables and the @ parameters just
> > > > duplicate the information from the type signature.
> > >
> > > But you are binding types with the @ syntax. The proposal gives a
> number of examples where the @-bound type variable is bound by a different
> name (or not at all) in the type signature. Many are contrived, to
> demonstrate where the binders are allowed, but the higher-rank and
> proxy-eliding examples look compelling to me.
> > >
> > > We also already allow repeated value binders in Haskell. When I write
> a function in equational style, I have to rebind each argument in each
> alternate equation. Sometimes this is noisy and I'll prefer a single
> equation with an explicit `case`. But for functions where the body is
> sizable, I find the repeated binders to be quite helpful because the scopes
> are smaller. I can easily see the same benefit applying to type binders.
> Ultimately, I think this comes down to a matter of style, and I favor
> letting Haskell programmers pick the style that works best for them.
> > >
> > > Eric
> > > _______________________________________________
> > > 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%7Cb01f469f49274bc3980108d6c80c9851%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636916353760006580&sdata=0bUACqXPM5OmzQnMNq7A%2Bqx7YCd9e1CS44thT%2B44R9g%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%7Cb01f469f49274bc3980108d6c80c9851%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636916353760016579&sdata=isitcg1QKSBFqIhhkqazqSujvX4s4lbYC4HiHhQSxdg%3D&reserved=0>
> --
> 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%7Cb01f469f49274bc3980108d6c80c9851%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636916353760016579&sdata=N2iYGZyHh%2BgieMXW7I4D9odfi6HjqazEfWYpN7nK54g%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%7Cb01f469f49274bc3980108d6c80c9851%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636916353760026570&sdata=MP24WmWJS7qksc0%2FQ0PY8WYSBqeMeAogL9b%2BucV%2FBBU%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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190424/6aae949a/attachment-0001.html>

From chak at justtesting.org  Wed Apr 24 16:16:43 2019
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 24 Apr 2019 18:16:43 +0200
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <CANsrgPJkoC7q10Um7F6+ToL=-aqD_AUKdb_1cBu=jpbRUfixxg@mail.gmail.com>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
 <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>
 <CANsrgPJkoC7q10Um7F6+ToL=-aqD_AUKdb_1cBu=jpbRUfixxg@mail.gmail.com>
Message-ID: <F73F718C-C121-4E49-8ADE-5DDEA04C2E7A@justtesting.org>

As I have said previously, I strongly agree with Simon on that we need to make some editorial decisions.

Concerning the general proposal, I think, the convenience of trailing commas is a consequence of insufficient editor support and IMHO it’d be better to improve that support rather than applying band-aids to the language. However, I can live with the extensions as long as their is no conflict with TupleSections.

Cheers,
Manuel

> Am 24.04.2019 um 09:30 schrieb Simon Marlow <marlowsd at gmail.com>:
> 
> I'm also strongly against mutually incompatible extensions. 
> 
> I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force. This is a pretty strange direction to take the language in, and raises questions about whether we should think of GHC as a testing ground for language extensions of which only some will eventually make it into a language standard, or whether we should take a position on which extensions are sensible when there are conflicts. Personally I'm in favour of the committee taking some editorial decisions here - not just assessing which extensions make sense in isolation, but considering whether an extension makes sense in the context of the other extensions we already have.
> 
> But back to the current proposal, I would vote for allowing the parts of the proposal that don't conflict with TupleSections.
> 
> Cheers
> Simon
> 
> On Thu, 18 Apr 2019 at 16:06, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> I strongly dislike the idea of mutually-incompatible extensions.
> 
> We could say that ExtraCommas allows extra commas everywhere, including in tuples and lists. We could also say that TupleSections overrides this behavior in tuples and gives it new meaning. We could further imagine ListSections that would override the behavior in lists. To me, this is preferable than mutual incompatibility.
> 
> Does this make for a nice user experience? I'm not sure. Happily, the reinterpretation from TupleSections or ListSections would change types, so you'd get errors up front. These errors might even be clever enough to notice that both ExtraCommas and TupleSections are in effect and gently remind the user that this combination can be confusing. Actually, this might be a nice "have your cake and eat it too" moment: let's just do all the things!
> 
> Richard
> 
> > On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
> > 
> > |  "tuples included" means "incompatible with tuple sections" means "they are
> > |  mutually exclusive to a module."
> > 
> > You mean, some kind of new error message that says "these two extension are mutually incompatible".  I can't say I love this.  Let's just leave out tuples from ExtraCommas.
> > 
> > (Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day.  Maybe we omit list literals too?  Or would that break the key use-cases?
> > 
> > Simon
> > 
> > |  -----Original Message-----
> > |  From: Christopher Allen <cma at bitemyapp.com <mailto:cma at bitemyapp.com>>
> > |  Sent: 18 April 2019 10:08
> > |  To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> > |  Cc: Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>>; ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> > |  Subject: Re: [ghc-steering-committee] Extra Commas
> > |  
> > |  My understanding of previous discussions was that:
> > |  
> > |  
> > |  On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> > |  wrote:
> > |  >
> > |  > But it's actually *incompatible* with TupleSections, so how shoule
> > |  >         (True,)
> > |  > be interpreted if both are on?
> > |  >
> > |  > S
> > |  >
> > |  > |  -----Original Message-----
> > |  > |  From: ghc-steering-committee
> > |  > | <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>>
> > |  > |  On Behalf Of Christopher Allen
> > |  > |  Sent: 18 April 2019 04:19
> > |  > |  To: Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>>
> > |  > |  Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> > |  > |  Subject: Re: [ghc-steering-committee] Extra Commas
> > |  > |
> > |  > |  I spoke with Matt, he's fine either way with or without tuples.
> > |  > |
> > |  > |  I'd prefer "with tuples" for consistency. I use tuples sometimes,
> > |  > | but  don't care about sectioning.
> > |  > |
> > |  > |  On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
> > |  > |  >
> > |  > |  > I favor accepting the proposal, with or without tuples. I've been
> > |  > | writing a bit of Rust recently, and agree with Chris about the
> > |  > | ergonomics  of trailing commas.
> > |  > |  >
> > |  > |  > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
> > |  > |  > > Hi,
> > |  > |  > >
> > |  > |  > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher
> > |  Allen:
> > |  > |  > > > I gave my recommendation for ExtraCommas, acceptance of the
> > |  > | > > > original proposal as written. I talk with the proposer almost
> > |  > | > > > every day so I know where he stands. He still thinks it's
> > |  > | worth  > > > doing and would like to see it accepted. I think
> > |  > | ExtraCommas  > > > merits acceptance. If we can't achieve consensus
> > |  > | on it then it  > > > should be rejected so it gets cleared off the
> > |  > | slate. I'm not  > > > inclined to argue a syntactic extension like
> > |  > | this, but I will say
> > |  > |  this:
> > |  > |  > > >
> > |  > |  > > > The proposal captures a nice design element that we've seen
> > |  > | work  > > > very well ergonomically in Rust. We're never going to
> > |  > | make the  > > > same decisions with the same tradeoffs as a totally
> > |  > | different  > > > language but any time there is a relatively isolated
> > |  "good idea"
> > |  > |  > > > like this, I'd like to see us try to take advantage of that
> > |  > | and  > > > see if it works for us.
> > |  > |  > >
> > |  > |  > > thanks for picking this up.
> > |  > |  > >
> > |  > |  > > The most contentious point, besides whether its worth the
> > |  > | bother at  > > all, was the interaction with TupleSections. Which
> > |  > | gives us three  > > options, I think:
> > |  > |  > >  * reject
> > |  > |  > >  * accept, covering tuples (and making it conflict with  > >
> > |  > | TupleSections)  > >  * accept, not covering tuples.
> > |  > |  > >
> > |  > |  > > No decision is absolutely wrong, none is obviously right.
> > |  > |  > >
> > |  > |  > > Maybe we should simply do a vote, to get it decided? Simons (as
> > |  > | > > Chairs), what do you think?
> > |  > |  > >
> > |  > |  > > Cheers,
> > |  > |  > > Joachim
> > |  > |  > >
> > |  > |  > > --
> > |  > |  > > Joachim Breitner
> > |  > |  > >  mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
> > |  > |  > >
> > |  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww>
> > |  > | .joachim-breitner.de <http://joachim-breitner.de/>%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7
> > |  > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47
> > |  > | %7C1%7C0%7C636911752855987147&amp;sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u
> > |  > | 9fb%2BRkQMqGibDlM%3D&amp;reserved=0
> > |  > |  > >
> > |  > |  > >
> > |  > |  > > _______________________________________________
> > |  > |  > > ghc-steering-committee mailing list  > >
> > |  > | ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> > |  > |  > >
> > |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma>
> > |  > | il.haskell.org <http://il.haskell.org/>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a
> > |  > | mp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C670f986836834427a29408d6
> > |  > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598
> > |  > | 7147&amp;sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&amp;re
> > |  > | served=0
> > |  > |  > > ttee
> > |  > |  > >
> > |  > |  > > Attachments:
> > |  > |  > > * signature.asc
> > |  > |  > _______________________________________________
> > |  > |  > ghc-steering-committee mailing list  >
> > |  > | ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> > |  > |  >
> > |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma>
> > |  > | il.haskell.org <http://il.haskell.org/>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> > |  > | &amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C670f986836834427a29408
> > |  > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855
> > |  > | 987147&amp;sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D&
> > |  > | amp;reserved=0
> > |  > |  > ee
> > |  > |
> > |  > |
> > |  > |
> > |  > |  --
> > |  > |  Chris Allen
> > |  > |  Currently working on
> > |  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas>
> > |  > | kellbook.com <http://kellbook.com/>&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C670f986836
> > |  > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> > |  > | 636911752855987147&amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK
> > |  > | 8IyjBI%3D&amp;reserved=0
> > |  > | _______________________________________________
> > |  > |  ghc-steering-committee mailing list
> > |  > | ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> > |  > |
> > |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma>
> > |  > | il.haskell.org <http://il.haskell.org/>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> > |  > | ee&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C670f986836834427a294
> > |  > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528
> > |  > | 55987147&amp;sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D&
> > |  > | amp;reserved=0
> > |  
> > |  
> > |  
> > |  --
> > |  Chris Allen
> > |  Currently working on
> > |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo>
> > |  ok.com <http://ok.com/>&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C670f986836834427a29408
> > |  d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147
> > |  &amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&amp;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://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>
> _______________________________________________
> 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/20190424/7fc4eab7/attachment-0001.html>

From bravit111 at gmail.com  Wed Apr 24 19:20:12 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Wed, 24 Apr 2019 22:20:12 +0300
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <F73F718C-C121-4E49-8ADE-5DDEA04C2E7A@justtesting.org>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
 <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>
 <CANsrgPJkoC7q10Um7F6+ToL=-aqD_AUKdb_1cBu=jpbRUfixxg@mail.gmail.com>
 <F73F718C-C121-4E49-8ADE-5DDEA04C2E7A@justtesting.org>
Message-ID: <CALpVSmOFZf7umm=paNHDPqMubj_N9a4kMUL_j0EMizqTiC-WHg@mail.gmail.com>

I am next voting to accept this proposal, not covering tuples.

Vitaly

ср, 24 апр. 2019 г. в 19:17, Manuel M T Chakravarty <chak at justtesting.org>:

> As I have said previously, I strongly agree with Simon on that we need to
> make some editorial decisions.
>
> Concerning the general proposal, I think, the convenience of trailing
> commas is a consequence of insufficient editor support and IMHO it’d be
> better to improve that support rather than applying band-aids to the
> language. However, I can live with the extensions as long as their is no
> conflict with TupleSections.
>
> Cheers,
> Manuel
>
> Am 24.04.2019 um 09:30 schrieb Simon Marlow <marlowsd at gmail.com>:
>
> I'm also strongly against mutually incompatible extensions.
>
> I'm not sure about allowing the combination of TupleSections and
> ExtraCommas. It would mean that (x,) has a different meaning depending on
> what extensions are in force. This is a pretty strange direction to take
> the language in, and raises questions about whether we should think of GHC
> as a testing ground for language extensions of which only some will
> eventually make it into a language standard, or whether we should take a
> position on which extensions are sensible when there are conflicts.
> Personally I'm in favour of the committee taking some editorial decisions
> here - not just assessing which extensions make sense in isolation, but
> considering whether an extension makes sense in the context of the other
> extensions we already have.
>
> But back to the current proposal, I would vote for allowing the parts of
> the proposal that don't conflict with TupleSections.
>
> Cheers
> Simon
>
> On Thu, 18 Apr 2019 at 16:06, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> I strongly dislike the idea of mutually-incompatible extensions.
>>
>> We could say that ExtraCommas allows extra commas everywhere, including
>> in tuples and lists. We could also say that TupleSections overrides this
>> behavior in tuples and gives it new meaning. We could further imagine
>> ListSections that would override the behavior in lists. To me, this is
>> preferable than mutual incompatibility.
>>
>> Does this make for a nice user experience? I'm not sure. Happily, the
>> reinterpretation from TupleSections or ListSections would change types, so
>> you'd get errors up front. These errors might even be clever enough to
>> notice that both ExtraCommas and TupleSections are in effect and gently
>> remind the user that this combination can be confusing. Actually, this
>> might be a nice "have your cake and eat it too" moment: let's just do all
>> the things!
>>
>> Richard
>>
>> > On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via
>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>> >
>> > |  "tuples included" means "incompatible with tuple sections" means
>> "they are
>> > |  mutually exclusive to a module."
>> >
>> > You mean, some kind of new error message that says "these two extension
>> are mutually incompatible".  I can't say I love this.  Let's just leave out
>> tuples from ExtraCommas.
>> >
>> > (Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day.
>> Maybe we omit list literals too?  Or would that break the key use-cases?
>> >
>> > Simon
>> >
>> > |  -----Original Message-----
>> > |  From: Christopher Allen <cma at bitemyapp.com>
>> > |  Sent: 18 April 2019 10:08
>> > |  To: Simon Peyton Jones <simonpj at microsoft.com>
>> > |  Cc: Eric Seidel <eric at seidel.io>; ghc-steering-committee at haskell.org
>> > |  Subject: Re: [ghc-steering-committee] Extra Commas
>> > |
>> > |  My understanding of previous discussions was that:
>> > |
>> > |
>> > |  On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones <
>> simonpj at microsoft.com>
>> > |  wrote:
>> > |  >
>> > |  > But it's actually *incompatible* with TupleSections, so how shoule
>> > |  >         (True,)
>> > |  > be interpreted if both are on?
>> > |  >
>> > |  > S
>> > |  >
>> > |  > |  -----Original Message-----
>> > |  > |  From: ghc-steering-committee
>> > |  > | <ghc-steering-committee-bounces at haskell.org>
>> > |  > |  On Behalf Of Christopher Allen
>> > |  > |  Sent: 18 April 2019 04:19
>> > |  > |  To: Eric Seidel <eric at seidel.io>
>> > |  > |  Cc: ghc-steering-committee at haskell.org
>> > |  > |  Subject: Re: [ghc-steering-committee] Extra Commas
>> > |  > |
>> > |  > |  I spoke with Matt, he's fine either way with or without tuples.
>> > |  > |
>> > |  > |  I'd prefer "with tuples" for consistency. I use tuples
>> sometimes,
>> > |  > | but  don't care about sectioning.
>> > |  > |
>> > |  > |  On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel <eric at seidel.io>
>> wrote:
>> > |  > |  >
>> > |  > |  > I favor accepting the proposal, with or without tuples. I've
>> been
>> > |  > | writing a bit of Rust recently, and agree with Chris about the
>> > |  > | ergonomics  of trailing commas.
>> > |  > |  >
>> > |  > |  > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
>> > |  > |  > > Hi,
>> > |  > |  > >
>> > |  > |  > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher
>> > |  Allen:
>> > |  > |  > > > I gave my recommendation for ExtraCommas, acceptance of
>> the
>> > |  > | > > > original proposal as written. I talk with the proposer
>> almost
>> > |  > | > > > every day so I know where he stands. He still thinks it's
>> > |  > | worth  > > > doing and would like to see it accepted. I think
>> > |  > | ExtraCommas  > > > merits acceptance. If we can't achieve
>> consensus
>> > |  > | on it then it  > > > should be rejected so it gets cleared off
>> the
>> > |  > | slate. I'm not  > > > inclined to argue a syntactic extension
>> like
>> > |  > | this, but I will say
>> > |  > |  this:
>> > |  > |  > > >
>> > |  > |  > > > The proposal captures a nice design element that we've
>> seen
>> > |  > | work  > > > very well ergonomically in Rust. We're never going to
>> > |  > | make the  > > > same decisions with the same tradeoffs as a
>> totally
>> > |  > | different  > > > language but any time there is a relatively
>> isolated
>> > |  "good idea"
>> > |  > |  > > > like this, I'd like to see us try to take advantage of
>> that
>> > |  > | and  > > > see if it works for us.
>> > |  > |  > >
>> > |  > |  > > thanks for picking this up.
>> > |  > |  > >
>> > |  > |  > > The most contentious point, besides whether its worth the
>> > |  > | bother at  > > all, was the interaction with TupleSections. Which
>> > |  > | gives us three  > > options, I think:
>> > |  > |  > >  * reject
>> > |  > |  > >  * accept, covering tuples (and making it conflict with  > >
>> > |  > | TupleSections)  > >  * accept, not covering tuples.
>> > |  > |  > >
>> > |  > |  > > No decision is absolutely wrong, none is obviously right.
>> > |  > |  > >
>> > |  > |  > > Maybe we should simply do a vote, to get it decided? Simons
>> (as
>> > |  > | > > Chairs), what do you think?
>> > |  > |  > >
>> > |  > |  > > Cheers,
>> > |  > |  > > Joachim
>> > |  > |  > >
>> > |  > |  > > --
>> > |  > |  > > Joachim Breitner
>> > |  > |  > >  mail at joachim-breitner.de
>> > |  > |  > >
>> > |  > |
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
>> > |  > | .joachim-breitner.de%2F&amp;data=02%7C01%7Csimonpj%
>> 40microsoft.com%7
>> > |  > |
>> C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47
>> > |  > |
>> %7C1%7C0%7C636911752855987147&amp;sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u
>> > |  > | 9fb%2BRkQMqGibDlM%3D&amp;reserved=0
>> > |  > |  > >
>> > |  > |  > >
>> > |  > |  > > _______________________________________________
>> > |  > |  > > ghc-steering-committee mailing list  > >
>> > |  > | ghc-steering-committee at haskell.org
>> > |  > |  > >
>> > |  > |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
>> > |  > | il.haskell.org
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a
>> > |  > | mp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7C670f986836834427a29408d6
>> > |  > |
>> c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598
>> > |  > |
>> 7147&amp;sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&amp;re
>> > |  > | served=0
>> > |  > |  > > ttee
>> > |  > |  > >
>> > |  > |  > > Attachments:
>> > |  > |  > > * signature.asc
>> > |  > |  > _______________________________________________
>> > |  > |  > ghc-steering-committee mailing list  >
>> > |  > | ghc-steering-committee at haskell.org
>> > |  > |  >
>> > |  > |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
>> > |  > | il.haskell.org
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
>> > |  > | &amp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7C670f986836834427a29408
>> > |  > |
>> d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855
>> > |  > |
>> 987147&amp;sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D&
>> > |  > | amp;reserved=0
>> > |  > |  > ee
>> > |  > |
>> > |  > |
>> > |  > |
>> > |  > |  --
>> > |  > |  Chris Allen
>> > |  > |  Currently working on
>> > |  > |
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas
>> > |  > | kellbook.com&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7C670f986836
>> > |  > |
>> 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
>> > |  > |
>> 636911752855987147&amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK
>> > |  > | 8IyjBI%3D&amp;reserved=0
>> > |  > | _______________________________________________
>> > |  > |  ghc-steering-committee mailing list
>> > |  > | ghc-steering-committee at haskell.org
>> > |  > |
>> > |  > |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
>> > |  > | il.haskell.org
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
>> > |  > | ee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7C670f986836834427a294
>> > |  > |
>> 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528
>> > |  > |
>> 55987147&amp;sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D&
>> > |  > | amp;reserved=0
>> > |
>> > |
>> > |
>> > |  --
>> > |  Chris Allen
>> > |  Currently working on
>> > |
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo
>> > |  ok.com&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7C670f986836834427a29408
>> > |
>> d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147
>> > |
>> &amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&amp;reserved=0
>> > _______________________________________________
>> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190424/c7f80f2d/attachment-0001.html>

From rae at richarde.dev  Thu Apr 25 16:19:06 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 25 Apr 2019 12:19:06 -0400
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <CANsrgPJkoC7q10Um7F6+ToL=-aqD_AUKdb_1cBu=jpbRUfixxg@mail.gmail.com>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
 <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>
 <CANsrgPJkoC7q10Um7F6+ToL=-aqD_AUKdb_1cBu=jpbRUfixxg@mail.gmail.com>
Message-ID: <A6FA802C-D051-4942-BB94-F7DD39C9EA0D@richarde.dev>



> On Apr 24, 2019, at 3:30 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force.

While I agree that this situation is suboptimal, it already exists in multiple ways. For example `f $x` has different meanings depending on whether -XTemplateHaskell is enabled -- and sometimes, both would type-check but mean different things. `data T a = MkT` has a different meaning depending on whether -XPolyKinds is enabled, and this change is not strictly conservative due to the potential for ambiguity when generalizing. At top-level, `pattern Nothing = Just ()` has a different meaning depending on whether -XPatternSynonyms is enabled; both meanings are error-free. My point here is that this argument doesn't hold much sway, for me -- the cows have already left the pasture. (I do agree that letting yet another calf out isn't great, but it's not, to me, a self-standing argument for rejection.)

What allowed me to consider the possibility of combining both extensions is that the change in interpretation would almost always lead to a type error, so that an author meaning one interpretation but getting another can simply twiddle extensions. If the change in interpretation would manifest only at runtime, say, or only in downstream modules, I'd be much less sanguine.

So my vote is to have both, but do not interpret this as a vote against "everything but tuples", which seems to be gaining momentum.

Richard

PS: I agree that this is a matter of editor support, and I'm not a fan of extra commas. But I hear a chorus of voices asking for this feature, and so I'm inclined to go with the wisdom of the crowd here.

From iavor.diatchki at gmail.com  Thu Apr 25 17:43:28 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 25 Apr 2019 10:43:28 -0700
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <A6FA802C-D051-4942-BB94-F7DD39C9EA0D@richarde.dev>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
 <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>
 <CANsrgPJkoC7q10Um7F6+ToL=-aqD_AUKdb_1cBu=jpbRUfixxg@mail.gmail.com>
 <A6FA802C-D051-4942-BB94-F7DD39C9EA0D@richarde.dev>
Message-ID: <CAGK9nuqnssdNdKpbj3kfRnYcgmwY+picSiJ_902zXqWutugjRQ@mail.gmail.com>

On Thu, Apr 25, 2019 at 9:19 AM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> > On Apr 24, 2019, at 3:30 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> >
> > I'm not sure about allowing the combination of TupleSections and
> ExtraCommas. It would mean that (x,) has a different meaning depending on
> what extensions are in force.
>
> While I agree that this situation is suboptimal, it already exists in
> multiple ways. For example `f $x` has different meanings depending on
> whether -XTemplateHaskell is enabled -- and sometimes, both would
> type-check but mean different things. `data T a = MkT` has a different
> meaning depending on whether -XPolyKinds is enabled, and this change is not
> strictly conservative due to the potential for ambiguity when generalizing.
> At top-level, `pattern Nothing = Just ()` has a different meaning depending
> on whether -XPatternSynonyms is enabled; both meanings are error-free. My
> point here is that this argument doesn't hold much sway, for me -- the cows
> have already left the pasture. (I do agree that letting yet another calf
> out isn't great, but it's not, to me, a self-standing argument for
> rejection.)
>

It seems that these are examples of things working differently depending on
if an extension is on or not, which is not a problem because, well, this is
the whole point of turning on the extension.   I don't think we have many
examples where different extensions conflict with each other, so we'd
probably want to write some code to report an error if both extensions are
on, as clearly someone made a mistake.   Unfortunately, this does not work
if you write all extensions in the cabal file, rather then enumerating them
in each separate module, so maybe in that case we don't report an error.
Or we just arbitrarily order the extensions so that one takes precedence
over the other...



> So my vote is to have both, but do not interpret this as a vote against
> "everything but tuples", which seems to be gaining momentum.
>
> What we seem to be discussing is a specification that would read something
like this: 1) "(a,)" is an error, unless (2) "tuple sections" are one, in
which case it is a function, unless (3) "extra commas" is on, in which case
it just means "a", or maybe with (2) and (3) swapped.   Ugh.    And,
presumably having "extra commas" work on tuples, would be useful if one had
some really big tuples, and didn't want to delete the extra comma at the
end.   Having really big tuples does not make programs easier to read and
manipulate, so I question what sort of programs are we trying to make
easier to write.

PS: I agree that this is a matter of editor support, and I'm not a fan of
> extra commas. But I hear a chorus of voices asking for this feature, and so
> I'm inclined to go with the wisdom of the crowd here.
>
> Well, I remain completely unconvinced by the wisdom of the crowd in this
case, at least for "extra commas" in the expression language.  The main
reasoning I've see in the discussion are:

   1. Improved "ergonomics", but I am not sure what that means,

   2. Cleaner "diffs"---I find this completely unconvincing because
        1) there are plenty of tools for working with diffs and an extra
modified line when someone edits a list really make no difference,
        2) the use case we are optimizing for are: programs with lots of
large list/tuple literals, where most of the edits are to
add/remove/reorder the elements in those literals; how common are those,
really?

   3. Easier support for CPP---also unconvincing as it is easy to work
around by naming the parts of the list that may change; not only is this
easy to do, but it likely makes the code more readable.  Note that the CPP
use case likely does not apply to tuples, as if you comment out some of the
fields, the whole type would change, and now you'd have to CPP all uses of
the tuples as well.

So I still think accepting this is a mistake, but if everyone else finds it
useful, obviously, it is not something that will interfere with my use of
Haskell in significant ways.

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

From simonpj at microsoft.com  Thu Apr 25 22:16:41 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 25 Apr 2019 22:16:41 +0000
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <CAGK9nuqnssdNdKpbj3kfRnYcgmwY+picSiJ_902zXqWutugjRQ@mail.gmail.com>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
 <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>
 <CANsrgPJkoC7q10Um7F6+ToL=-aqD_AUKdb_1cBu=jpbRUfixxg@mail.gmail.com>
 <A6FA802C-D051-4942-BB94-F7DD39C9EA0D@richarde.dev>
 <CAGK9nuqnssdNdKpbj3kfRnYcgmwY+picSiJ_902zXqWutugjRQ@mail.gmail.com>
Message-ID: <DB7PR83MB029846062B0F891B2A46E52DAD3D0@DB7PR83MB0298.EURPRD83.prod.outlook.com>

So I still think accepting this is a mistake, but if everyone else finds it useful, obviously, it is not something that will interfere with my use of Haskell in significant ways.
If it were just me I wouldn’t do it either.  But it seems important to some people, and it doesn’t harm anyone (provided we can avoid it interacting badly with tuple sections).  So I’m not going to stand in the way.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 25 April 2019 18:43
To: Richard Eisenberg <rae at richarde.dev>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Extra Commas



On Thu, Apr 25, 2019 at 9:19 AM Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:


> On Apr 24, 2019, at 3:30 AM, Simon Marlow <marlowsd at gmail.com<mailto:marlowsd at gmail.com>> wrote:
>
> I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force.

While I agree that this situation is suboptimal, it already exists in multiple ways. For example `f $x` has different meanings depending on whether -XTemplateHaskell is enabled -- and sometimes, both would type-check but mean different things. `data T a = MkT` has a different meaning depending on whether -XPolyKinds is enabled, and this change is not strictly conservative due to the potential for ambiguity when generalizing. At top-level, `pattern Nothing = Just ()` has a different meaning depending on whether -XPatternSynonyms is enabled; both meanings are error-free. My point here is that this argument doesn't hold much sway, for me -- the cows have already left the pasture. (I do agree that letting yet another calf out isn't great, but it's not, to me, a self-standing argument for rejection.)

It seems that these are examples of things working differently depending on if an extension is on or not, which is not a problem because, well, this is the whole point of turning on the extension.   I don't think we have many examples where different extensions conflict with each other, so we'd probably want to write some code to report an error if both extensions are on, as clearly someone made a mistake.   Unfortunately, this does not work if you write all extensions in the cabal file, rather then enumerating them in each separate module, so maybe in that case we don't report an error.  Or we just arbitrarily order the extensions so that one takes precedence over the other...


So my vote is to have both, but do not interpret this as a vote against "everything but tuples", which seems to be gaining momentum.
What we seem to be discussing is a specification that would read something like this: 1) "(a,)" is an error, unless (2) "tuple sections" are one, in which case it is a function, unless (3) "extra commas" is on, in which case it just means "a", or maybe with (2) and (3) swapped.   Ugh.    And, presumably having "extra commas" work on tuples, would be useful if one had some really big tuples, and didn't want to delete the extra comma at the end.   Having really big tuples does not make programs easier to read and manipulate, so I question what sort of programs are we trying to make easier to write.

PS: I agree that this is a matter of editor support, and I'm not a fan of extra commas. But I hear a chorus of voices asking for this feature, and so I'm inclined to go with the wisdom of the crowd here.
Well, I remain completely unconvinced by the wisdom of the crowd in this case, at least for "extra commas" in the expression language.  The main reasoning I've see in the discussion are:

   1. Improved "ergonomics", but I am not sure what that means,

   2. Cleaner "diffs"---I find this completely unconvincing because
        1) there are plenty of tools for working with diffs and an extra modified line when someone edits a list really make no difference,
        2) the use case we are optimizing for are: programs with lots of large list/tuple literals, where most of the edits are to add/remove/reorder the elements in those literals; how common are those, really?

   3. Easier support for CPP---also unconvincing as it is easy to work around by naming the parts of the list that may change; not only is this easy to do, but it likely makes the code more readable.  Note that the CPP use case likely does not apply to tuples, as if you comment out some of the fields, the whole type would change, and now you'd have to CPP all uses of the tuples as well.

So I still think accepting this is a mistake, but if everyone else finds it useful, obviously, it is not something that will interfere with my use of Haskell in significant ways.

-Iavor







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

From eric at seidel.io  Fri Apr 26 02:02:48 2019
From: eric at seidel.io (Eric Seidel)
Date: Thu, 25 Apr 2019 22:02:48 -0400
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <CAGK9nuqnssdNdKpbj3kfRnYcgmwY+picSiJ_902zXqWutugjRQ@mail.gmail.com>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
 <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>
 <CANsrgPJkoC7q10Um7F6+ToL=-aqD_AUKdb_1cBu=jpbRUfixxg@mail.gmail.com>
 <A6FA802C-D051-4942-BB94-F7DD39C9EA0D@richarde.dev>
 <CAGK9nuqnssdNdKpbj3kfRnYcgmwY+picSiJ_902zXqWutugjRQ@mail.gmail.com>
Message-ID: <2a240f96-1705-4b54-890c-a004d0744e88@www.fastmail.com>

On Thu, Apr 25, 2019, at 13:43, Iavor Diatchki wrote:
> On Thu, Apr 25, 2019 at 9:19 AM Richard Eisenberg <rae at richarde.dev> wrote:
> >  So my vote is to have both, but do not interpret this as a vote against "everything but tuples", which seems to be gaining momentum.
> > 
> What we seem to be discussing is a specification that would read 
> something like this: 1) "(a,)" is an error, unless (2) "tuple sections" 
> are one, in which case it is a function, unless (3) "extra commas" is 
> on, in which case it just means "a", or maybe with (2) and (3) swapped. 
> Ugh. And, presumably having "extra commas" work on tuples, would be 
> useful if one had some really big tuples, and didn't want to delete the 
> extra comma at the end. Having really big tuples does not make programs 
> easier to read and manipulate, so I question what sort of programs are 
> we trying to make easier to write.

Indeed, big tuples are suspicious, and I think the least compelling use-case for ExtraCommas. Which is why I would not be bothered if we left tuples out of the extension.

> >  PS: I agree that this is a matter of editor support, and I'm not a fan of extra commas. But I hear a chorus of voices asking for this feature, and so I'm inclined to go with the wisdom of the crowd here.
> > 
> Well, I remain completely unconvinced by the wisdom of the crowd in 
> this case, at least for "extra commas" in the expression language. The 
> main reasoning I've see in the discussion are:
> 
>  1. Improved "ergonomics", but I am not sure what that means,

I believe I'm one of the people who mentioned ergonomics, so let me try to elaborate.

A number of people have commented that it feels like the problem ExtraCommas is trying to address would be better solved by better editors. I don't really disagree with this, but we don't have better editors. People have been working on structured editors for decades, but they haven't really panned out. I think the most successful example of a structured editor might emacs' paredit (and the newer smartparens), and they work well precisely because of the minimal syntax of lisp.

The editors that we have today are by and large line-oriented, which makes operations on entire lines very easy. For example, if I have a large list or record

  foo = [
    1,
    2,
    3,
    4
  ]

it usually takes only a few keystrokes to add/delete/reorder elements. This is very convenient, but it starts to break down if I have to interact with the last element, 4. I cannot delete 4, or swap it with another element using the standard line-oriented commands, because the result will be syntactically invalid. So, what should be a very routine (and boring) part of my job as a programmer becomes just a bit more tedious. If we allow trailing commas, this issue goes away entirely.

It is a small issue, granted, but it's one that you run into regularly, at least I do. And it wears on you over time. This is why I claim ExtraCommas improves the ergonomics of Haskell's syntax.

Eric

From mail at joachim-breitner.de  Fri Apr 26 07:34:12 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 26 Apr 2019 09:34:12 +0200
Subject: [ghc-steering-committee] Process tweak: GitHub centric way
Message-ID: <96d45a8086d1bf586183aa6195ce7fc862dd24d5.camel@joachim-breitner.de>

Hi,

after even Richard, who earlier said

> Primarily, I'm worried that GitHub can be a noisy place, and if we
> have our deliberations there, our status as a decision-making
> committee is somewhat compromised

is now willing to try a github-based process, I wrote up a concrete
process teak, now at

https://github.com/ghc-proposals/ghc-proposals/pull/225
(see “Files changed” for the changes).

Tweaks and comments welcome, ideally on GitHub (if only to see how that
goes).

In a little while, unless there is clear consensus, I’ll likely do a
vote on the various process variants (using ranked voting, of course,
so that we put variants on the ballot).

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/20190426/46e66834/attachment.sig>

From marlowsd at gmail.com  Mon Apr 29 07:39:21 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 29 Apr 2019 08:39:21 +0100
Subject: [ghc-steering-committee] Unhappy proposers
In-Reply-To: <4e4027efe82f5420df5408cbf6685bf6dd150437.camel@joachim-breitner.de>
References: <50f443db7576c0d74c18dd0198a600d24581a49d.camel@joachim-breitner.de>
 <DB7PR83MB02982E04A308301383FCA7D0AD250@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <237cfdd2-a510-43ac-b47d-85d4626fb675@www.fastmail.com>
 <CAGK9nur9Sz8Fou8GkAF-jAbsT5DZm0kQmWwRrvLh1OygATrk+A@mail.gmail.com>
 <4bd51c16b93116a05017c13ea88ed542e3a75fae.camel@joachim-breitner.de>
 <CAGK9nuowqJ5gXJM4iZgCZ7PvDescX0K5-aK6t-haOUrfBT6WEQ@mail.gmail.com>
 <55681059-73b1-4f67-b8dd-ac5c334b7bc0@www.fastmail.com>
 <4483DE1D-94B1-4EB1-9C1D-C7A46E855799@richarde.dev>
 <4e4027efe82f5420df5408cbf6685bf6dd150437.camel@joachim-breitner.de>
Message-ID: <CANsrgPKK8OsEHcYmX=O49ZJHj6VzmW-WXWe8YmuPG8GpV6fobg@mail.gmail.com>

Sounds good to me. It would be really helpful if the secretary could add a
reminder about this policy when sending out the email assigning a shepherd,
to ensure we don't forget.

Cheers
Simon

On Thu, 18 Apr 2019 at 17:21, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> based on this discussion I am making a concrete proposal here:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/221
>
> The main idea is that if the shepherd intends to reject the proposal,
> they have to first discuss this with the authors, to give the authors a
> chance to respond, tweak, or point out misunderstandings in the
> shepherd’s perception.
>
> So the process of accepting proposals is unchanged, and still on the
> list, rejecting a proposal is now a two step process: the shepherd
> discusses it with the authors on GitHub (and anyone else interested, of
> course), and then there is a shorter discussion on the mailinglist,
> with hopefully all facts clarified.
>
> This does not move all discussion to Github yet, so it is the smaller
> change, in a way. But of course committee members are encouraged to
> join GitHub discussions early, especially if they are unhappy with a
> proposal.
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190429/c1d0b47c/attachment.html>

From simonpj at microsoft.com  Thu Apr 25 08:49:50 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 25 Apr 2019 08:49:50 -0000
Subject: [ghc-steering-committee] Extra Commas
In-Reply-To: <CALpVSmOFZf7umm=paNHDPqMubj_N9a4kMUL_j0EMizqTiC-WHg@mail.gmail.com>
References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de>
 <CADnndOp_bi4QC+urxnhNhV6qw=haKpB=jfSdhU8e+b_fU6DxfA@mail.gmail.com>
 <ed2f3a4417237bb591bd48962fd75cad9babb9e2.camel@joachim-breitner.de>
 <f10529c6-e7b8-4d04-84bb-0a69b7813432@www.fastmail.com>
 <CADnndOok2C3jij=z_gTPPfnUkdZAEHTWF-KviUJ_b1PE+Vex+w@mail.gmail.com>
 <DB7PR83MB02982A6873913D20AAB99180AD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADnndOpZ7ZRNeg+WBfj83FvLEi1y1kSO6VjWMrp7ZSSxHDP69A@mail.gmail.com>
 <DB7PR83MB0298A1000C35E070EF0BF13CAD260@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <BB407C9B-F1CC-4DF0-B383-8649E23F40CF@richarde.dev>
 <CANsrgPJkoC7q10Um7F6+ToL=-aqD_AUKdb_1cBu=jpbRUfixxg@mail.gmail.com>
 <F73F718C-C121-4E49-8ADE-5DDEA04C2E7A@justtesting.org>
 <CALpVSmOFZf7umm=paNHDPqMubj_N9a4kMUL_j0EMizqTiC-WHg@mail.gmail.com>
Message-ID: <DB7PR83MB0298061D12168883434A0970AD3D0@DB7PR83MB0298.EURPRD83.prod.outlook.com>

I’m ok with accepting, but excluding tuples, including constraint tuples.

I’m be ok with excluding list literals too.

We should ask the author if s/he feels that these exclusions would unacceptably eviscerate the proposal i.e. make it not worth doing.

The upside is that it’s clearly a superficial, syntax-only issue.  Nothing deep is at stake here.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Vitaly Bragilevsky
Sent: 24 April 2019 20:20
To: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Extra Commas

I am next voting to accept this proposal, not covering tuples.

Vitaly

ср, 24 апр. 2019 г. в 19:17, Manuel M T Chakravarty <chak at justtesting.org<mailto:chak at justtesting.org>>:
As I have said previously, I strongly agree with Simon on that we need to make some editorial decisions.

Concerning the general proposal, I think, the convenience of trailing commas is a consequence of insufficient editor support and IMHO it’d be better to improve that support rather than applying band-aids to the language. However, I can live with the extensions as long as their is no conflict with TupleSections.

Cheers,
Manuel


Am 24.04.2019 um 09:30 schrieb Simon Marlow <marlowsd at gmail.com<mailto:marlowsd at gmail.com>>:

I'm also strongly against mutually incompatible extensions.

I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force. This is a pretty strange direction to take the language in, and raises questions about whether we should think of GHC as a testing ground for language extensions of which only some will eventually make it into a language standard, or whether we should take a position on which extensions are sensible when there are conflicts. Personally I'm in favour of the committee taking some editorial decisions here - not just assessing which extensions make sense in isolation, but considering whether an extension makes sense in the context of the other extensions we already have.

But back to the current proposal, I would vote for allowing the parts of the proposal that don't conflict with TupleSections.

Cheers
Simon

On Thu, 18 Apr 2019 at 16:06, Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:
I strongly dislike the idea of mutually-incompatible extensions.

We could say that ExtraCommas allows extra commas everywhere, including in tuples and lists. We could also say that TupleSections overrides this behavior in tuples and gives it new meaning. We could further imagine ListSections that would override the behavior in lists. To me, this is preferable than mutual incompatibility.

Does this make for a nice user experience? I'm not sure. Happily, the reinterpretation from TupleSections or ListSections would change types, so you'd get errors up front. These errors might even be clever enough to notice that both ExtraCommas and TupleSections are in effect and gently remind the user that this combination can be confusing. Actually, this might be a nice "have your cake and eat it too" moment: let's just do all the things!

Richard

> On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
>
> |  "tuples included" means "incompatible with tuple sections" means "they are
> |  mutually exclusive to a module."
>
> You mean, some kind of new error message that says "these two extension are mutually incompatible".  I can't say I love this.  Let's just leave out tuples from ExtraCommas.
>
> (Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day.  Maybe we omit list literals too?  Or would that break the key use-cases?
>
> Simon
>
> |  -----Original Message-----
> |  From: Christopher Allen <cma at bitemyapp.com<mailto:cma at bitemyapp.com>>
> |  Sent: 18 April 2019 10:08
> |  To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> |  Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>; ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> |  Subject: Re: [ghc-steering-committee] Extra Commas
> |
> |  My understanding of previous discussions was that:
> |
> |
> |  On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> |  wrote:
> |  >
> |  > But it's actually *incompatible* with TupleSections, so how shoule
> |  >         (True,)
> |  > be interpreted if both are on?
> |  >
> |  > S
> |  >
> |  > |  -----Original Message-----
> |  > |  From: ghc-steering-committee
> |  > | <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>>
> |  > |  On Behalf Of Christopher Allen
> |  > |  Sent: 18 April 2019 04:19
> |  > |  To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>
> |  > |  Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> |  > |  Subject: Re: [ghc-steering-committee] Extra Commas
> |  > |
> |  > |  I spoke with Matt, he's fine either way with or without tuples.
> |  > |
> |  > |  I'd prefer "with tuples" for consistency. I use tuples sometimes,
> |  > | but  don't care about sectioning.
> |  > |
> |  > |  On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
> |  > |  >
> |  > |  > I favor accepting the proposal, with or without tuples. I've been
> |  > | writing a bit of Rust recently, and agree with Chris about the
> |  > | ergonomics  of trailing commas.
> |  > |  >
> |  > |  > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
> |  > |  > > Hi,
> |  > |  > >
> |  > |  > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher
> |  Allen:
> |  > |  > > > I gave my recommendation for ExtraCommas, acceptance of the
> |  > | > > > original proposal as written. I talk with the proposer almost
> |  > | > > > every day so I know where he stands. He still thinks it's
> |  > | worth  > > > doing and would like to see it accepted. I think
> |  > | ExtraCommas  > > > merits acceptance. If we can't achieve consensus
> |  > | on it then it  > > > should be rejected so it gets cleared off the
> |  > | slate. I'm not  > > > inclined to argue a syntactic extension like
> |  > | this, but I will say
> |  > |  this:
> |  > |  > > >
> |  > |  > > > The proposal captures a nice design element that we've seen
> |  > | work  > > > very well ergonomically in Rust. We're never going to
> |  > | make the  > > > same decisions with the same tradeoffs as a totally
> |  > | different  > > > language but any time there is a relatively isolated
> |  "good idea"
> |  > |  > > > like this, I'd like to see us try to take advantage of that
> |  > | and  > > > see if it works for us.
> |  > |  > >
> |  > |  > > thanks for picking this up.
> |  > |  > >
> |  > |  > > The most contentious point, besides whether its worth the
> |  > | bother at  > > all, was the interaction with TupleSections. Which
> |  > | gives us three  > > options, I think:
> |  > |  > >  * reject
> |  > |  > >  * accept, covering tuples (and making it conflict with  > >
> |  > | TupleSections)  > >  * accept, not covering tuples.
> |  > |  > >
> |  > |  > > No decision is absolutely wrong, none is obviously right.
> |  > |  > >
> |  > |  > > Maybe we should simply do a vote, to get it decided? Simons (as
> |  > | > > Chairs), what do you think?
> |  > |  > >
> |  > |  > > Cheers,
> |  > |  > > Joachim
> |  > |  > >
> |  > |  > > --
> |  > |  > > Joachim Breitner
> |  > |  > >  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
> |  > |  > >
> |  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> |  > | .joachim-breitner.de<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjoachim-breitner.de%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=lR2NQIVgxszL9PfjVDhzaQ%2Ba38gdzT3MtLR5CWq1E5o%3D&reserved=0>%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0>%7
> |  > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47
> |  > | %7C1%7C0%7C636911752855987147&amp;sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u
> |  > | 9fb%2BRkQMqGibDlM%3D&amp;reserved=0
> |  > |  > >
> |  > |  > >
> |  > |  > > _______________________________________________
> |  > |  > > ghc-steering-committee mailing list  > >
> |  > | ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> |  > |  > >
> |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> |  > | il.haskell.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fil.haskell.org%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=VuEBvcSJl8AXHj6DluWHV02IWb2t4IJoDVR0t8lM2Ec%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a
> |  > | mp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0>%7C670f986836834427a29408d6
> |  > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598
> |  > | 7147&amp;sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&amp;re
> |  > | served=0
> |  > |  > > ttee
> |  > |  > >
> |  > |  > > Attachments:
> |  > |  > > * signature.asc
> |  > |  > _______________________________________________
> |  > |  > ghc-steering-committee mailing list  >
> |  > | ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> |  > |  >
> |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> |  > | il.haskell.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fil.haskell.org%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=VuEBvcSJl8AXHj6DluWHV02IWb2t4IJoDVR0t8lM2Ec%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> |  > | &amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0>%7C670f986836834427a29408
> |  > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855
> |  > | 987147&amp;sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D&
> |  > | amp;reserved=0
> |  > |  > ee
> |  > |
> |  > |
> |  > |
> |  > |  --
> |  > |  Chris Allen
> |  > |  Currently working on
> |  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas
> |  > | kellbook.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkellbook.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=bPi0phmrOo4ANN016iNxh7TbcxKmKeLi%2B7%2FWQbDF4X4%3D&reserved=0>&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0>%7C670f986836
> |  > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> |  > | 636911752855987147&amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK
> |  > | 8IyjBI%3D&amp;reserved=0
> |  > | _______________________________________________
> |  > |  ghc-steering-committee mailing list
> |  > | ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> |  > |
> |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> |  > | il.haskell.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fil.haskell.org%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=VuEBvcSJl8AXHj6DluWHV02IWb2t4IJoDVR0t8lM2Ec%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> |  > | ee&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0>%7C670f986836834427a294
> |  > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528
> |  > | 55987147&amp;sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D&
> |  > | amp;reserved=0
> |
> |
> |
> |  --
> |  Chris Allen
> |  Currently working on
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo
> |  ok.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fok.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=4S14KSnrnmz05CBO%2FEapo5NMBEYlFAdt6c8lN6F19%2B0%3D&reserved=0>&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0>%7C670f986836834427a29408
> |  d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147
> |  &amp;sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&amp;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=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=BbCdHXiCFrLq9VnYXeWp5ypKqGDI4bO8AVXzLxV3clw%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=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=BbCdHXiCFrLq9VnYXeWp5ypKqGDI4bO8AVXzLxV3clw%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=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=BbCdHXiCFrLq9VnYXeWp5ypKqGDI4bO8AVXzLxV3clw%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=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=BbCdHXiCFrLq9VnYXeWp5ypKqGDI4bO8AVXzLxV3clw%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190425/bf27e089/attachment-0001.html>