From marlowsd at gmail.com  Mon Dec  2 10:06:15 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 2 Dec 2019 10:06:15 +0000
Subject: [ghc-steering-committee] #265: Unlifted Datatypes,
	recommendation: accept
In-Reply-To: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
References: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
Message-ID: <CANsrgP+2N4_VtvWT+k-3TtstWUm8LF3oZk3KyVx4Sj2uf7xDJw@mail.gmail.com>

I recommend that we *accept* proposal #265 (Unlifted Datatypes)

https://github.com/ghc-proposals/ghc-proposals/pull/265
https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst

It's a fairly conservative extension: the kind TYPE 'UnliftedRep already
exists with the required functionality, the only addition here is to allow
user-defined types to be declared with that kind. The semantics are clear,
and there already exists a prototype patch to implement it.

There are considerable performance benefits to be had for
performance-critical code, for instance the containers package.

A couple of minor issues remain:

   - Without special support, the type data unlifted Strict a = Force !a
   comes with an associated box, so this type isn't as useful as it could be.
   - It isn't possible to define values of kind TYPE 'UnlifedRep at the top
   level, which might be a surprising restriction to the programmer. (However,
   there's a reasonable workaround). Relatedly, GHC cannot lift expressions of
   kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead
   to surprising performance behaviour. See
   https://gitlab.haskell.org/ghc/ghc/issues/17521

Nevertheless, we shouldn't let the perfect be the enemy of the good, and
Unlifted Datatypes is a clearly useful addition in my view.

Cheers
Simon


On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Unlifed Datatypes
> has been proposed by Sebastian Graf
> https://github.com/ghc-proposals/ghc-proposals/pull/265
>
> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst
>
> I propose Simon Marlow as the shepherd, as the expert on low-level stuff.
>
> 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/20191202/c05207cb/attachment.html>

From marlowsd at gmail.com  Mon Dec  2 10:12:31 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 2 Dec 2019 10:12:31 +0000
Subject: [ghc-steering-committee] Please review #265: Unlifted Datatypes,
 Shepherd: Simon Marlow
In-Reply-To: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
References: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
Message-ID: <CANsrgPLdP3ZEhHD1DofYFvD7ekA44E2Up9B242J_6sTzcTJkQQ@mail.gmail.com>

On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Unlifed Datatypes
> has been proposed by Sebastian Graf
> https://github.com/ghc-proposals/ghc-proposals/pull/265
>
> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst
>
> I propose Simon Marlow as the shepherd, as the expert on low-level stuff.
>
> 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.
>

BTW, I just checked the proposal process documentation, and it says:

-

* Now the shepherd proposes to accept or reject the proposal. To do so, they

   - post their recommendation, with a rationale, on the GitHub discussion
   thread,
   - label the pull request as Pending committee review,
   - re-title the proposal pull request, appending (under review) at the
   end. (This enables easy email filtering.)
   - drop a short mail to the mailing list informing the committee that
   discussion has started.

which isn't exactly in line with the paragraph above. Shouldn't the first
line be something like "post their recommendation, with a rationale, to the
committee mailing list", and remove the final bullet?

Cheers
Simon



>
> 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/20191202/a07cd2c3/attachment.html>

From simonpj at microsoft.com  Mon Dec  2 10:51:05 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 2 Dec 2019 10:51:05 +0000
Subject: [ghc-steering-committee] [EXTERNAL] Re: Please review #265:
 Unlifted Datatypes, Shepherd: Simon Marlow
In-Reply-To: <CANsrgPLdP3ZEhHD1DofYFvD7ekA44E2Up9B242J_6sTzcTJkQQ@mail.gmail.com>
References: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
 <CANsrgPLdP3ZEhHD1DofYFvD7ekA44E2Up9B242J_6sTzcTJkQQ@mail.gmail.com>
Message-ID: <VI1PR83MB0288D04CAC6D10BC21F4CDA9AD430@VI1PR83MB0288.EURPRD83.prod.outlook.com>

Personally I think it’s helpful to have the proposal and rationale in the public discussion thread, because that gives non-committee members a chance to contribute.  E.g. by supporting the recommendation or explaining why they think the recommendation is wrong.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 02 December 2019 10:13
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: [EXTERNAL] Re: [ghc-steering-committee] Please review #265: Unlifted Datatypes, Shepherd: Simon Marlow

On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

this is your secretary speaking:

Unlifed Datatypes
has been proposed by Sebastian Graf
https://github.com/ghc-proposals/ghc-proposals/pull/265<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cea3e37d7fc99474f2b3208d77710332f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108783771075544&sdata=CTn29iF7iqGfn%2FwdIJRGz%2Baqim2rQk53sCKBPrSny8Q%3D&reserved=0>
https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cea3e37d7fc99474f2b3208d77710332f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108783771085539&sdata=4ytC%2BHNl38mGCLWUrssLwvH71DbBVrEOhC8TLhoS1jY%3D&reserved=0>

I propose Simon Marlow as the shepherd, as the expert on low-level stuff.

Please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Cea3e37d7fc99474f2b3208d77710332f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108783771085539&sdata=uRwxWiNwdquNYPfsHl4AESwX8pvrGhl6tAsFQb9WFR8%3D&reserved=0>
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.

BTW, I just checked the proposal process documentation, and it says:


•  * Now the shepherd proposes to accept or reject the proposal. To do so, they

  *   post their recommendation, with a rationale, on the GitHub discussion thread,
  *   label the pull request as Pending committee review,
  *   re-title the proposal pull request, appending (under review) at the end. (This enables easy email filtering.)
  *   drop a short mail to the mailing list informing the committee that discussion has started.
which isn't exactly in line with the paragraph above. Shouldn't the first line be something like "post their recommendation, with a rationale, to the committee mailing list", and remove the final bullet?

Cheers
Simon



Thanks,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cea3e37d7fc99474f2b3208d77710332f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108783771085539&sdata=NmVivDrYTY9W2P0cFMpSeAimgtwxViLKuZXp1iilw4E%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%7Cea3e37d7fc99474f2b3208d77710332f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108783771095532&sdata=hiXqsn8OTheQgjrd3vW%2BIhgITtVIOR7lpucgP3MoCuE%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191202/9bac68f9/attachment-0001.html>

From rae at richarde.dev  Mon Dec  2 12:54:38 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 2 Dec 2019 12:54:38 +0000
Subject: [ghc-steering-committee] #265: Unlifted Datatypes,
 recommendation: accept
In-Reply-To: <CANsrgP+2N4_VtvWT+k-3TtstWUm8LF3oZk3KyVx4Sj2uf7xDJw@mail.gmail.com>
References: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
 <CANsrgP+2N4_VtvWT+k-3TtstWUm8LF3oZk3KyVx4Sj2uf7xDJw@mail.gmail.com>
Message-ID: <1BA87FB4-CC81-493E-95EA-D54900ED217E@richarde.dev>

I’m generally in support of this idea, but I’ve suggested a few tweaks on the GitHub thread.

> On Dec 2, 2019, at 10:06 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> I recommend that we accept proposal #265 (Unlifted Datatypes)
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/265 <https://github.com/ghc-proposals/ghc-proposals/pull/265>
> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst <https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst>
> 
> It's a fairly conservative extension: the kind TYPE 'UnliftedRep already exists with the required functionality, the only addition here is to allow user-defined types to be declared with that kind. The semantics are clear, and there already exists a prototype patch to implement it.
> 
> There are considerable performance benefits to be had for performance-critical code, for instance the containers package.
> 
> A couple of minor issues remain:
> Without special support, the type data unlifted Strict a = Force !a comes with an associated box, so this type isn't as useful as it could be.
> It isn't possible to define values of kind TYPE 'UnlifedRep at the top level, which might be a surprising restriction to the programmer. (However, there's a reasonable workaround). Relatedly, GHC cannot lift expressions of kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead to surprising performance behaviour. See https://gitlab.haskell.org/ghc/ghc/issues/17521 <https://gitlab.haskell.org/ghc/ghc/issues/17521>
> Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view.
> 
> Cheers
> Simon
> 
> 
> On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Unlifed Datatypes
> has been proposed by Sebastian Graf
> https://github.com/ghc-proposals/ghc-proposals/pull/265 <https://github.com/ghc-proposals/ghc-proposals/pull/265>
> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst <https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst>
> 
> I propose Simon Marlow as the shepherd, as the expert on low-level stuff.
> 
> Please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> I suggest you make a recommendation, in a new e-mail thread with the
> proposal number in the subject, about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
> 
> Thanks,
> Joachim
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> 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/20191202/e8bd544e/attachment.html>

From mail at joachim-breitner.de  Mon Dec  2 16:13:35 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 02 Dec 2019 17:13:35 +0100
Subject: [ghc-steering-committee] Please review #265: Unlifted Datatypes,
 Shepherd: Simon Marlow
In-Reply-To: <CANsrgPLdP3ZEhHD1DofYFvD7ekA44E2Up9B242J_6sTzcTJkQQ@mail.gmail.com>
References: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
 <CANsrgPLdP3ZEhHD1DofYFvD7ekA44E2Up9B242J_6sTzcTJkQQ@mail.gmail.com>
Message-ID: <567b1a8e07c4bed8eedab12ceeb5624c13ecae2f.camel@joachim-breitner.de>

Hi,

Am Montag, den 02.12.2019, 10:12 +0000 schrieb Simon Marlow:
> On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 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.
> 
> BTW, I just checked the proposal process documentation, and it says:
> 
> Now the shepherd proposes to accept or reject the proposal. To do so, they
> * post their recommendation, with a rationale, on the GitHub discussion thread,
> * label the pull request as Pending committee review,
> * re-title the proposal pull request, appending (under review) at the end. (This enables easy email filtering.)
> * drop a short mail to the mailing list informing the committee that discussion has started.
> which isn't exactly in line with the paragraph above.
> Shouldn't the first line be something like "post their
recommendation, with a rationale, to the committee mailing list", and
remove the final bullet?

As Simon PJ says, the proposal process text is the better one, and the
blurb in my mail was just eternaly copy’n’pasted. Will try to rephrase
(or simply point to the process section) in my next mail if I remember.

Cheers,
Joachim

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


From sandy at sandymaguire.me  Tue Dec  3 01:39:20 2019
From: sandy at sandymaguire.me (Sandy Maguire)
Date: Tue, 3 Dec 2019 08:39:20 +0700
Subject: [ghc-steering-committee] #265: Unlifted Datatypes,
 recommendation: accept
In-Reply-To: <1BA87FB4-CC81-493E-95EA-D54900ED217E@richarde.dev>
References: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
 <CANsrgP+2N4_VtvWT+k-3TtstWUm8LF3oZk3KyVx4Sj2uf7xDJw@mail.gmail.com>
 <1BA87FB4-CC81-493E-95EA-D54900ED217E@richarde.dev>
Message-ID: <CADRtjwZORhkcimogzeaDe3s=kzKW43C+x9bMGxFeFJ2B98uiZg@mail.gmail.com>

I am generally out of my depth on this one, but I am swayed by the proposal
being conservative and useful. This is a weak yea from me!

On Mon, Dec 2, 2019 at 7:54 PM Richard Eisenberg <rae at richarde.dev> wrote:

> I’m generally in support of this idea, but I’ve suggested a few tweaks on
> the GitHub thread.
>
> On Dec 2, 2019, at 10:06 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> I recommend that we *accept* proposal #265 (Unlifted Datatypes)
>
> https://github.com/ghc-proposals/ghc-proposals/pull/265
>
> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst
>
> It's a fairly conservative extension: the kind TYPE 'UnliftedRep already
> exists with the required functionality, the only addition here is to allow
> user-defined types to be declared with that kind. The semantics are clear,
> and there already exists a prototype patch to implement it.
>
> There are considerable performance benefits to be had for
> performance-critical code, for instance the containers package.
>
> A couple of minor issues remain:
>
>    - Without special support, the type data unlifted Strict a = Force !a
>    comes with an associated box, so this type isn't as useful as it could be.
>    - It isn't possible to define values of kind TYPE 'UnlifedRep at the
>    top level, which might be a surprising restriction to the programmer.
>    (However, there's a reasonable workaround). Relatedly, GHC cannot lift
>    expressions of kind TYPE 'UnlifedRep to the top level in the
>    optimiser, which can lead to surprising performance behaviour. See
>    https://gitlab.haskell.org/ghc/ghc/issues/17521
>
> Nevertheless, we shouldn't let the perfect be the enemy of the good, and
> Unlifted Datatypes is a clearly useful addition in my view.
>
> Cheers
> Simon
>
>
> On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Dear Committee,
>>
>> this is your secretary speaking:
>>
>> Unlifed Datatypes
>> has been proposed by Sebastian Graf
>> https://github.com/ghc-proposals/ghc-proposals/pull/265
>>
>> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst
>>
>> I propose Simon Marlow as the shepherd, as the expert on low-level stuff.
>>
>> 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
>>
> _______________________________________________
> 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/20191203/b735c0ba/attachment.html>

From simonpj at microsoft.com  Wed Dec  4 15:24:13 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 4 Dec 2019 15:24:13 +0000
Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals]
 Overloaded Quotation Brackets (#246)
In-Reply-To: <ghc-proposals/ghc-proposals/pull/246/c561656750@github.com>
References: <ghc-proposals/ghc-proposals/pull/246@github.com>
 <ghc-proposals/ghc-proposals/pull/246/c561656750@github.com>
Message-ID: <VI1PR8303MB00939C3640ADA0588AEC2336AD5D0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

Dear Steering Committee

I have completed the revisions and wish to resubmit the proposal to the committee. The implementation is also finished an ready for review.
Matthew has revised his proposal #246 Overloaded Quotations<https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/proposals/0000-overloaded-bracket.rst>.  One particular point is that it does explicitly apply to Typed Template Haskell, not just untyped (see “Proposed changes” item 6).

Moreover he has an implementation here: https://gitlab.haskell.org/ghc/ghc/merge_requests/2247

I recommended back in Nov that we accept (see attached email), but I asked him to make some revisions (as you can see in the discussion thread).  All of this connects to (and I believe is compatible with)  #195 (make Q (TExp a) into a newtype),<https://github.com/ghc-proposals/ghc-proposals/pull/195> which we are set to accept too, once the proposal is revised.  Iavor: you are the shepherd for that.

I’ve had support for acceptance from

  *   Joachim
  *   Eric
  *   Sandy
  *   Simon M
  *   Richard
  *   Arnaud
  *   Iavor

I would love to hear from

  *   Chris A
  *   Vitaly B

Others: reply only if you have any comments on the revised proposal.  I’ll accept this at the end of the week.

Simon


From: Matthew Pickering <notifications at github.com>
Sent: 04 December 2019 13:58
To: ghc-proposals/ghc-proposals <ghc-proposals at noreply.github.com>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; Mention <mention at noreply.github.com>
Subject: Re: [ghc-proposals/ghc-proposals] Overloaded Quotation Brackets (#246)


I have completed the revisions and wish to resubmit the proposal to the committee. The implementation is also finished an ready for review.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F246%3Femail_source%3Dnotifications%26email_token%3DAAEOY636NCRXHIEMMDRTHBTQW6ZNTA5CNFSM4H5HNWR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5DHLQ%23issuecomment-561656750&data=02%7C01%7Csimonpj%40microsoft.com%7C6cfb80518ac74d06153508d778c1f133%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110646683835630&sdata=tCNZ5ALBG81l%2FJGwoX9p6jBLIPZqKJCjPNyrlG89Bh4%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAEOY62KELEHCDTSD4HEI73QW6ZNTANCNFSM4H5HNWRQ&data=02%7C01%7Csimonpj%40microsoft.com%7C6cfb80518ac74d06153508d778c1f133%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110646683835630&sdata=EFWou3zjc86I%2BW8HPXHIkzqnHpfNsApjNvMqKV2yZ0M%3D&reserved=0>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191204/081f8894/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RE_ _ghc-steering-committee_ Please review #246_ Overloaded Quotations__Shepherd_ Simon PJ.msg
Type: application/octet-stream
Size: 181248 bytes
Desc: RE_ _ghc-steering-committee_ Please review #246_ Overloaded Quotations__Shepherd_ Simon PJ.msg
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191204/081f8894/attachment-0001.obj>

From iavor.diatchki at gmail.com  Wed Dec  4 15:34:31 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 4 Dec 2019 07:34:31 -0800
Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals]
 Overloaded Quotation Brackets (#246)
In-Reply-To: <VI1PR8303MB00939C3640ADA0588AEC2336AD5D0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <ghc-proposals/ghc-proposals/pull/246@github.com>
 <ghc-proposals/ghc-proposals/pull/246/c561656750@github.com>
 <VI1PR8303MB00939C3640ADA0588AEC2336AD5D0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuq=LvkBkLznAsU1ZpSOQL4VFoOZiNn+Ov=bW-G55HeB4Q@mail.gmail.com>

Well, my response did have a question in it.  Did anyone have any thoughts?

On Wed, Dec 4, 2019 at 7:24 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Dear Steering Committee
>
> I have completed the revisions and wish to resubmit the proposal to the
> committee. The implementation is also finished an ready for review.
>
> Matthew has revised his proposal #246 Overloaded Quotations
> <https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/proposals/0000-overloaded-bracket.rst>.
> One particular point is that it does explicitly apply to Typed Template
> Haskell, not just untyped (see “Proposed changes” item 6).
>
>
>
> Moreover he has an implementation here:
> https://gitlab.haskell.org/ghc/ghc/merge_requests/2247
>
>
>
> I recommended back in Nov that we accept (see attached email), but I asked
> him to make some revisions (as you can see in the discussion thread).  All
> of this connects to (and I believe is compatible with)  #195 (make Q
> (TExp a) into a newtype),
> <https://github.com/ghc-proposals/ghc-proposals/pull/195> which we are
> set to accept too, once the proposal is revised.  Iavor: you are the
> shepherd for that.
>
>
>
> I’ve had support for acceptance from
>
>    - Joachim
>    - Eric
>    - Sandy
>    - Simon M
>    - Richard
>    - Arnaud
>    - Iavor
>
>
>
> I would love to hear from
>
>    - Chris A
>    - Vitaly B
>
>
>
> Others: reply only if you have any comments on the revised proposal.  I’ll
> accept this at the end of the week.
>
>
>
> Simon
>
>
>
>
>
> *From:* Matthew Pickering <notifications at github.com>
> *Sent:* 04 December 2019 13:58
> *To:* ghc-proposals/ghc-proposals <ghc-proposals at noreply.github.com>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>; Mention <
> mention at noreply.github.com>
> *Subject:* Re: [ghc-proposals/ghc-proposals] Overloaded Quotation
> Brackets (#246)
>
>
>
> I have completed the revisions and wish to resubmit the proposal to the
> committee. The implementation is also finished an ready for review.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F246%3Femail_source%3Dnotifications%26email_token%3DAAEOY636NCRXHIEMMDRTHBTQW6ZNTA5CNFSM4H5HNWR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5DHLQ%23issuecomment-561656750&data=02%7C01%7Csimonpj%40microsoft.com%7C6cfb80518ac74d06153508d778c1f133%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110646683835630&sdata=tCNZ5ALBG81l%2FJGwoX9p6jBLIPZqKJCjPNyrlG89Bh4%3D&reserved=0>,
> or unsubscribe
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAEOY62KELEHCDTSD4HEI73QW6ZNTANCNFSM4H5HNWRQ&data=02%7C01%7Csimonpj%40microsoft.com%7C6cfb80518ac74d06153508d778c1f133%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110646683835630&sdata=EFWou3zjc86I%2BW8HPXHIkzqnHpfNsApjNvMqKV2yZ0M%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/20191204/ab732afa/attachment.html>

From simonpj at microsoft.com  Wed Dec  4 15:39:57 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 4 Dec 2019 15:39:57 +0000
Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals]
 Overloaded Quotation Brackets (#246)
In-Reply-To: <CAGK9nuq=LvkBkLznAsU1ZpSOQL4VFoOZiNn+Ov=bW-G55HeB4Q@mail.gmail.com>
References: <ghc-proposals/ghc-proposals/pull/246@github.com>
 <ghc-proposals/ghc-proposals/pull/246/c561656750@github.com>
 <VI1PR8303MB00939C3640ADA0588AEC2336AD5D0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <CAGK9nuq=LvkBkLznAsU1ZpSOQL4VFoOZiNn+Ov=bW-G55HeB4Q@mail.gmail.com>
Message-ID: <VI1PR8303MB0093195C9FB8524D3A2C522DAD5D0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

I think you mean

The issue is that `Code a` is not `Applicative`, because we cannot

define `pure` for all Haskell types.   I wonder if the full power of

`Applicative` is actually needed to do the translation though?  If not, perhaps we should modify `Quote` to reflect the operations that we need.

Is that it?   Could you ask on the discussion thread, so that Matthew can respond?  I actually don’t quite understand the question.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 04 December 2019 15:35
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Overloaded Quotation Brackets (#246)

Well, my response did have a question in it.  Did anyone have any thoughts?

On Wed, Dec 4, 2019 at 7:24 AM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
Dear Steering Committee

I have completed the revisions and wish to resubmit the proposal to the committee. The implementation is also finished an ready for review.
Matthew has revised his proposal #246 Overloaded Quotations<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmpickering%2Fghc-proposals%2Fblob%2Foverloaded-proposal%2Fproposals%2F0000-overloaded-bracket.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C6ea14a87a5724819166708d778cf7c89%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110704852522992&sdata=FhL8LEwt00Yk0HLISSJguj3BSrL2YAK9hEzdC%2B%2FwO%2Fg%3D&reserved=0>.  One particular point is that it does explicitly apply to Typed Template Haskell, not just untyped (see “Proposed changes” item 6).

Moreover he has an implementation here: https://gitlab.haskell.org/ghc/ghc/merge_requests/2247<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F2247&data=02%7C01%7Csimonpj%40microsoft.com%7C6ea14a87a5724819166708d778cf7c89%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110704852532990&sdata=LWPVx%2B5DLEQ0GPEL9eWZ%2FzrkeaVbiUuUQCZMjY92QOQ%3D&reserved=0>

I recommended back in Nov that we accept (see attached email), but I asked him to make some revisions (as you can see in the discussion thread).  All of this connects to (and I believe is compatible with)  #195 (make Q (TExp a) into a newtype),<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F195&data=02%7C01%7Csimonpj%40microsoft.com%7C6ea14a87a5724819166708d778cf7c89%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110704852532990&sdata=dwR6samDLQdPucK%2FnjOnasNhzRZ1nUp73DU7SGn8CvU%3D&reserved=0> which we are set to accept too, once the proposal is revised.  Iavor: you are the shepherd for that.

I’ve had support for acceptance from

  *   Joachim
  *   Eric
  *   Sandy
  *   Simon M
  *   Richard
  *   Arnaud
  *   Iavor

I would love to hear from

  *   Chris A
  *   Vitaly B

Others: reply only if you have any comments on the revised proposal.  I’ll accept this at the end of the week.

Simon


From: Matthew Pickering <notifications at github.com<mailto:notifications at github.com>>
Sent: 04 December 2019 13:58
To: ghc-proposals/ghc-proposals <ghc-proposals at noreply.github.com<mailto:ghc-proposals at noreply.github.com>>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>; Mention <mention at noreply.github.com<mailto:mention at noreply.github.com>>
Subject: Re: [ghc-proposals/ghc-proposals] Overloaded Quotation Brackets (#246)


I have completed the revisions and wish to resubmit the proposal to the committee. The implementation is also finished an ready for review.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F246%3Femail_source%3Dnotifications%26email_token%3DAAEOY636NCRXHIEMMDRTHBTQW6ZNTA5CNFSM4H5HNWR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5DHLQ%23issuecomment-561656750&data=02%7C01%7Csimonpj%40microsoft.com%7C6ea14a87a5724819166708d778cf7c89%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110704852542984&sdata=uajvJO%2F%2Fya4oc3woIHd3lnojErEzV9bT2DyAR2%2FeX%2B0%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAEOY62KELEHCDTSD4HEI73QW6ZNTANCNFSM4H5HNWRQ&data=02%7C01%7Csimonpj%40microsoft.com%7C6ea14a87a5724819166708d778cf7c89%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110704852542984&sdata=GwKp2yhSiEya6pJunHkfD5JfQC6xJSruH8MCbYmj5GM%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%7C6ea14a87a5724819166708d778cf7c89%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110704852552978&sdata=MTCwiGj%2BCyvkLYZj35bZJkR%2Bgm1ClIxKo1TEQvvPo9s%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191204/4b8e0b9a/attachment-0001.html>

From iavor.diatchki at gmail.com  Wed Dec  4 16:13:15 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 4 Dec 2019 08:13:15 -0800
Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals]
 Overloaded Quotation Brackets (#246)
In-Reply-To: <VI1PR8303MB0093195C9FB8524D3A2C522DAD5D0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <ghc-proposals/ghc-proposals/pull/246@github.com>
 <ghc-proposals/ghc-proposals/pull/246/c561656750@github.com>
 <VI1PR8303MB00939C3640ADA0588AEC2336AD5D0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <CAGK9nuq=LvkBkLznAsU1ZpSOQL4VFoOZiNn+Ov=bW-G55HeB4Q@mail.gmail.com>
 <VI1PR8303MB0093195C9FB8524D3A2C522DAD5D0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuq5UwUuS1LYT8scZPXJM2DHKa0+LNrebxvDpOsNzyODJg@mail.gmail.com>

Yes that was it---I posted on #246 and Matt clarified what the plan
was, so I am on board.


On Wed, Dec 4, 2019 at 7:39 AM Simon Peyton Jones <simonpj at microsoft.com> wrote:
>
> I think you mean
>
> The issue is that `Code a` is not `Applicative`, because we cannot
>
> define `pure` for all Haskell types.   I wonder if the full power of
>
> `Applicative` is actually needed to do the translation though?  If not, perhaps we should modify `Quote` to reflect the operations that we need.
>
>
>
> Is that it?   Could you ask on the discussion thread, so that Matthew can respond?  I actually don’t quite understand the question.
>
>
>
> Simon
>
>
>
> From: Iavor Diatchki <iavor.diatchki at gmail.com>
> Sent: 04 December 2019 15:35
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: ghc-steering-committee at haskell.org
> Subject: Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Overloaded Quotation Brackets (#246)
>
>
>
> Well, my response did have a question in it.  Did anyone have any thoughts?
>
>
>
> On Wed, Dec 4, 2019 at 7:24 AM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
> Dear Steering Committee
>
> I have completed the revisions and wish to resubmit the proposal to the committee. The implementation is also finished an ready for review.
>
> Matthew has revised his proposal #246 Overloaded Quotations.  One particular point is that it does explicitly apply to Typed Template Haskell, not just untyped (see “Proposed changes” item 6).
>
>
>
> Moreover he has an implementation here: https://gitlab.haskell.org/ghc/ghc/merge_requests/2247
>
>
>
> I recommended back in Nov that we accept (see attached email), but I asked him to make some revisions (as you can see in the discussion thread).  All of this connects to (and I believe is compatible with)  #195 (make Q (TExp a) into a newtype), which we are set to accept too, once the proposal is revised.  Iavor: you are the shepherd for that.
>
>
>
> I’ve had support for acceptance from
>
> Joachim
> Eric
> Sandy
> Simon M
> Richard
> Arnaud
> Iavor
>
>
>
> I would love to hear from
>
> Chris A
> Vitaly B
>
>
>
> Others: reply only if you have any comments on the revised proposal.  I’ll accept this at the end of the week.
>
>
>
> Simon
>
>
>
>
>
> From: Matthew Pickering <notifications at github.com>
> Sent: 04 December 2019 13:58
> To: ghc-proposals/ghc-proposals <ghc-proposals at noreply.github.com>
> Cc: Simon Peyton Jones <simonpj at microsoft.com>; Mention <mention at noreply.github.com>
> Subject: Re: [ghc-proposals/ghc-proposals] Overloaded Quotation Brackets (#246)
>
>
>
> I have completed the revisions and wish to resubmit the proposal to the committee. The implementation is also finished an ready for review.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or unsubscribe.
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From simonpj at microsoft.com  Thu Dec  5 13:20:42 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 5 Dec 2019 13:20:42 +0000
Subject: [ghc-steering-committee] [EXTERNAL]  #265: Unlifted Datatypes,
	recommendation: accept
In-Reply-To: <CANsrgP+2N4_VtvWT+k-3TtstWUm8LF3oZk3KyVx4Sj2uf7xDJw@mail.gmail.com>
References: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
 <CANsrgP+2N4_VtvWT+k-3TtstWUm8LF3oZk3KyVx4Sj2uf7xDJw@mail.gmail.com>
Message-ID: <VI1PR8303MB00938E74F445A5609780E9D9AD5C0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

I’m in support here.  I’ve commented on the discussion thread.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 02 December 2019 10:06
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: [EXTERNAL] [ghc-steering-committee] #265: Unlifted Datatypes, recommendation: accept

I recommend that we accept proposal #265 (Unlifted Datatypes)

https://github.com/ghc-proposals/ghc-proposals/pull/265<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029253857&sdata=aEWC0cJAxCRJ973miRTP%2F6JtGVp%2F4FG6qqmKjjfKywE%3D&reserved=0>
https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=JCfBIUeVfDO0f6CElwzpmPY9xyYj7pp%2FoojID59kkCo%3D&reserved=0>

It's a fairly conservative extension: the kind TYPE 'UnliftedRep already exists with the required functionality, the only addition here is to allow user-defined types to be declared with that kind. The semantics are clear, and there already exists a prototype patch to implement it.

There are considerable performance benefits to be had for performance-critical code, for instance the containers package.

A couple of minor issues remain:

  *   Without special support, the type data unlifted Strict a = Force !a comes with an associated box, so this type isn't as useful as it could be.
  *   It isn't possible to define values of kind TYPE 'UnlifedRep at the top level, which might be a surprising restriction to the programmer. (However, there's a reasonable workaround). Relatedly, GHC cannot lift expressions of kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead to surprising performance behaviour. See https://gitlab.haskell.org/ghc/ghc/issues/17521<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F17521&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=dgDbIe9AhhI%2FIsnPDPxX7EAoVVkjaKthu%2FNGcyEBOTU%3D&reserved=0>
Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view.

Cheers
Simon


On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

this is your secretary speaking:

Unlifed Datatypes
has been proposed by Sebastian Graf
https://github.com/ghc-proposals/ghc-proposals/pull/265<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=sbtvm3eM43ihY%2FPoTeS4Sp%2BDE2AJUBSqgGOv6HymoKg%3D&reserved=0>
https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=PeFWonpeS4vYeanypRBMEWgLFy9CgVeue3OhHrZa7aM%3D&reserved=0>

I propose Simon Marlow as the shepherd, as the expert on low-level stuff.

Please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=9V5KT%2F6kDmUNU5xMMKByR4egiSf61TMdq6yoHMviGcg%3D&reserved=0>
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<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%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=CSR%2BQeNk7k5o6bjo%2Fv2Ke5Yu6h2hEwqR2gIcu0XMU5U%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%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=taRsN3Xgue2y426KtNoZGzYtwdviS2%2BwyKmnww8yEAs%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191205/25f3e4d1/attachment-0001.html>

From simonpj at microsoft.com  Fri Dec  6 09:18:21 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 6 Dec 2019 09:18:21 +0000
Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals]
 Overloaded Quotation Brackets (#246)
In-Reply-To: <VI1PR8303MB00939C3640ADA0588AEC2336AD5D0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <ghc-proposals/ghc-proposals/pull/246@github.com>
 <ghc-proposals/ghc-proposals/pull/246/c561656750@github.com>
 <VI1PR8303MB00939C3640ADA0588AEC2336AD5D0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <VI1PR8303MB0093FD8C9430DE17A1AF4ADEAD5F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

Nothing from Vitaly B or Chris A.

I declare the proposal accepted.  Joachim, can you merge please?

Simon

From: Simon Peyton Jones <simonpj at microsoft.com>
Sent: 04 December 2019 15:24
To: ghc-steering-committee at haskell.org
Cc: Simon Peyton Jones <simonpj at microsoft.com>
Subject: RE: [ghc-proposals/ghc-proposals] Overloaded Quotation Brackets (#246)

Dear Steering Committee

I have completed the revisions and wish to resubmit the proposal to the committee. The implementation is also finished an ready for review.
Matthew has revised his proposal #246 Overloaded Quotations<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmpickering%2Fghc-proposals%2Fblob%2Foverloaded-proposal%2Fproposals%2F0000-overloaded-bracket.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C7a0ac32c2fcc4d92ea5508d778ce051a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110699587244274&sdata=I0tNA6zLF%2BuduEvm1T0kXcCGDtgEx7h1wa0xgGeHyRQ%3D&reserved=0>.  One particular point is that it does explicitly apply to Typed Template Haskell, not just untyped (see "Proposed changes" item 6).

Moreover he has an implementation here: https://gitlab.haskell.org/ghc/ghc/merge_requests/2247

I recommended back in Nov that we accept (see attached email), but I asked him to make some revisions (as you can see in the discussion thread).  All of this connects to (and I believe is compatible with)  #195 (make Q (TExp a) into a newtype),<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F195&data=02%7C01%7Csimonpj%40microsoft.com%7C7a0ac32c2fcc4d92ea5508d778ce051a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110699587254268&sdata=EflG3cXQIdtlQlKln%2F3PEeK1T%2FRXq%2Fif7%2FIS3csirg4%3D&reserved=0> which we are set to accept too, once the proposal is revised.  Iavor: you are the shepherd for that.

I've had support for acceptance from

  *   Joachim
  *   Eric
  *   Sandy
  *   Simon M
  *   Richard
  *   Arnaud
  *   Iavor

I would love to hear from

  *   Chris A
  *   Vitaly B

Others: reply only if you have any comments on the revised proposal.  I'll accept this at the end of the week.

Simon


From: Matthew Pickering <notifications at github.com<mailto:notifications at github.com>>
Sent: 04 December 2019 13:58
To: ghc-proposals/ghc-proposals <ghc-proposals at noreply.github.com<mailto:ghc-proposals at noreply.github.com>>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>; Mention <mention at noreply.github.com<mailto:mention at noreply.github.com>>
Subject: Re: [ghc-proposals/ghc-proposals] Overloaded Quotation Brackets (#246)


I have completed the revisions and wish to resubmit the proposal to the committee. The implementation is also finished an ready for review.

-
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F246%3Femail_source%3Dnotifications%26email_token%3DAAEOY636NCRXHIEMMDRTHBTQW6ZNTA5CNFSM4H5HNWR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5DHLQ%23issuecomment-561656750&data=02%7C01%7Csimonpj%40microsoft.com%7C7a0ac32c2fcc4d92ea5508d778ce051a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110699587254268&sdata=oWMOjzrjbFa2xG578L%2B3gcqsByM8qXvahpRtlcv3lVk%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAEOY62KELEHCDTSD4HEI73QW6ZNTANCNFSM4H5HNWRQ&data=02%7C01%7Csimonpj%40microsoft.com%7C7a0ac32c2fcc4d92ea5508d778ce051a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637110699587264269&sdata=wXEhToKPA2luvTRw1DY3iPHxernEToQQrt4G3SVchZI%3D&reserved=0>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191206/a3f6356f/attachment-0001.html>

From sandy at sandymaguire.me  Sun Dec  8 05:42:46 2019
From: sandy at sandymaguire.me (Sandy Maguire)
Date: Sun, 8 Dec 2019 12:42:46 +0700
Subject: [ghc-steering-committee] Stepping down
Message-ID: <CADRtjwaUP88jnwUsPEw5OW66RWvz3p8bVo=J0J6vZaMNvxn_RA@mail.gmail.com>

Hi all,

Regrettably, I've decided to step down from the steering committee. My
heart simply isn't in Haskell these days, and I'd prefer to give up my
membership to someone more capable of doing good with it.

For my replacement, I'd like to nominate Tom Harding and Chris Penner (both
cc'd). I don't know of anyone else in the community who is as smart or
dedicated as these two. Both have solid industrial credentials to help
diversify the otherwise academic committee. The community at large would be
very lucky to have either of them helping to steer.

It's been an honour to serve with you all.

Best,
Sandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191208/359f22e0/attachment.html>

From arnaud.spiwack at tweag.io  Mon Dec  9 07:41:13 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 9 Dec 2019 08:41:13 +0100
Subject: [ghc-steering-committee] [EXTERNAL] #265: Unlifted Datatypes,
 recommendation: accept
In-Reply-To: <VI1PR8303MB00938E74F445A5609780E9D9AD5C0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
 <CANsrgP+2N4_VtvWT+k-3TtstWUm8LF3oZk3KyVx4Sj2uf7xDJw@mail.gmail.com>
 <VI1PR8303MB00938E74F445A5609780E9D9AD5C0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQmKsp2+2iY31OLQkQCqRuhqRpbmYHujYtyAd8-DJjK+wg@mail.gmail.com>

There is a bit of a discussion on the thread (which I only got time to
briefly skim) about whether the proposal should mark unlifted newtypes with
a special keyword, or simply by fixing the return kind of the type
constructor to `TYPE 'UnliftedRep`. I'm rather on the side of using the
return kind, it makes more sense to me. SImon PJ also brings a pretty
strong argument in support of this view:
https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-562125048
.

Either way, The proposal should at least discuss this view in the
alternatives before it gets to be accepted or not.

But aside from that, I am absolutely in support of the general idea, and
the proposal itself is good.


On Thu, Dec 5, 2019 at 2:20 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> I’m in support here.  I’ve commented on the discussion thread.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Marlow
> *Sent:* 02 December 2019 10:06
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* ghc-steering-committee at haskell.org
> *Subject:* [EXTERNAL] [ghc-steering-committee] #265: Unlifted Datatypes,
> recommendation: accept
>
>
>
> I recommend that we *accept* proposal #265 (Unlifted Datatypes)
>
>
>
> https://github.com/ghc-proposals/ghc-proposals/pull/265
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029253857&sdata=aEWC0cJAxCRJ973miRTP%2F6JtGVp%2F4FG6qqmKjjfKywE%3D&reserved=0>
>
>
> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=JCfBIUeVfDO0f6CElwzpmPY9xyYj7pp%2FoojID59kkCo%3D&reserved=0>
>
>
>
> It's a fairly conservative extension: the kind TYPE 'UnliftedRep already
> exists with the required functionality, the only addition here is to allow
> user-defined types to be declared with that kind. The semantics are clear,
> and there already exists a prototype patch to implement it.
>
>
>
> There are considerable performance benefits to be had for
> performance-critical code, for instance the containers package.
>
>
>
> A couple of minor issues remain:
>
>    - Without special support, the type data unlifted Strict a = Force !a
>    comes with an associated box, so this type isn't as useful as it could be.
>    - It isn't possible to define values of kind TYPE 'UnlifedRep at the
>    top level, which might be a surprising restriction to the programmer.
>    (However, there's a reasonable workaround). Relatedly, GHC cannot lift
>    expressions of kind TYPE 'UnlifedRep to the top level in the
>    optimiser, which can lead to surprising performance behaviour. See
>    https://gitlab.haskell.org/ghc/ghc/issues/17521
>    <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F17521&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=dgDbIe9AhhI%2FIsnPDPxX7EAoVVkjaKthu%2FNGcyEBOTU%3D&reserved=0>
>
> Nevertheless, we shouldn't let the perfect be the enemy of the good, and
> Unlifted Datatypes is a clearly useful addition in my view.
>
>
>
> Cheers
>
> Simon
>
>
>
>
>
> On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Dear Committee,
>
> this is your secretary speaking:
>
> Unlifed Datatypes
> has been proposed by Sebastian Graf
> https://github.com/ghc-proposals/ghc-proposals/pull/265
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=sbtvm3eM43ihY%2FPoTeS4Sp%2BDE2AJUBSqgGOv6HymoKg%3D&reserved=0>
>
> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=PeFWonpeS4vYeanypRBMEWgLFy9CgVeue3OhHrZa7aM%3D&reserved=0>
>
> I propose Simon Marlow as the shepherd, as the expert on low-level stuff.
>
> Please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=9V5KT%2F6kDmUNU5xMMKByR4egiSf61TMdq6yoHMviGcg%3D&reserved=0>
> 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/
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=CSR%2BQeNk7k5o6bjo%2Fv2Ke5Yu6h2hEwqR2gIcu0XMU5U%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%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=taRsN3Xgue2y426KtNoZGzYtwdviS2%2BwyKmnww8yEAs%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/20191209/8fa9668e/attachment.html>

From marlowsd at gmail.com  Mon Dec  9 07:58:36 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 9 Dec 2019 07:58:36 +0000
Subject: [ghc-steering-committee] [EXTERNAL] #265: Unlifted Datatypes,
 recommendation: accept
In-Reply-To: <CAH6fHQmKsp2+2iY31OLQkQCqRuhqRpbmYHujYtyAd8-DJjK+wg@mail.gmail.com>
References: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
 <CANsrgP+2N4_VtvWT+k-3TtstWUm8LF3oZk3KyVx4Sj2uf7xDJw@mail.gmail.com>
 <VI1PR8303MB00938E74F445A5609780E9D9AD5C0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <CAH6fHQmKsp2+2iY31OLQkQCqRuhqRpbmYHujYtyAd8-DJjK+wg@mail.gmail.com>
Message-ID: <CANsrgPKF5yGQew6SHz5BWe7Vod+vkQeYeyT9430vLXHakO+JCQ@mail.gmail.com>

Shall we put the proposal back into the needs revision state while this is
discussed and the proposal updated?

On Mon, 9 Dec 2019 at 07:42, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> There is a bit of a discussion on the thread (which I only got time to
> briefly skim) about whether the proposal should mark unlifted newtypes with
> a special keyword, or simply by fixing the return kind of the type
> constructor to `TYPE 'UnliftedRep`. I'm rather on the side of using the
> return kind, it makes more sense to me. SImon PJ also brings a pretty
> strong argument in support of this view:
> https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-562125048
> .
>
> Either way, The proposal should at least discuss this view in the
> alternatives before it gets to be accepted or not.
>
> But aside from that, I am absolutely in support of the general idea, and
> the proposal itself is good.
>
>
> On Thu, Dec 5, 2019 at 2:20 PM Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
>> I’m in support here.  I’ve commented on the discussion thread.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon Marlow
>> *Sent:* 02 December 2019 10:06
>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>> *Cc:* ghc-steering-committee at haskell.org
>> *Subject:* [EXTERNAL] [ghc-steering-committee] #265: Unlifted Datatypes,
>> recommendation: accept
>>
>>
>>
>> I recommend that we *accept* proposal #265 (Unlifted Datatypes)
>>
>>
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/265
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029253857&sdata=aEWC0cJAxCRJ973miRTP%2F6JtGVp%2F4FG6qqmKjjfKywE%3D&reserved=0>
>>
>>
>> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=JCfBIUeVfDO0f6CElwzpmPY9xyYj7pp%2FoojID59kkCo%3D&reserved=0>
>>
>>
>>
>> It's a fairly conservative extension: the kind TYPE 'UnliftedRep already
>> exists with the required functionality, the only addition here is to allow
>> user-defined types to be declared with that kind. The semantics are clear,
>> and there already exists a prototype patch to implement it.
>>
>>
>>
>> There are considerable performance benefits to be had for
>> performance-critical code, for instance the containers package.
>>
>>
>>
>> A couple of minor issues remain:
>>
>>    - Without special support, the type data unlifted Strict a = Force !a
>>    comes with an associated box, so this type isn't as useful as it could be.
>>    - It isn't possible to define values of kind TYPE 'UnlifedRep at the
>>    top level, which might be a surprising restriction to the programmer.
>>    (However, there's a reasonable workaround). Relatedly, GHC cannot lift
>>    expressions of kind TYPE 'UnlifedRep to the top level in the
>>    optimiser, which can lead to surprising performance behaviour. See
>>    https://gitlab.haskell.org/ghc/ghc/issues/17521
>>    <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F17521&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=dgDbIe9AhhI%2FIsnPDPxX7EAoVVkjaKthu%2FNGcyEBOTU%3D&reserved=0>
>>
>> Nevertheless, we shouldn't let the perfect be the enemy of the good, and
>> Unlifted Datatypes is a clearly useful addition in my view.
>>
>>
>>
>> Cheers
>>
>> Simon
>>
>>
>>
>>
>>
>> On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>> Dear Committee,
>>
>> this is your secretary speaking:
>>
>> Unlifed Datatypes
>> has been proposed by Sebastian Graf
>> https://github.com/ghc-proposals/ghc-proposals/pull/265
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=sbtvm3eM43ihY%2FPoTeS4Sp%2BDE2AJUBSqgGOv6HymoKg%3D&reserved=0>
>>
>> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=PeFWonpeS4vYeanypRBMEWgLFy9CgVeue3OhHrZa7aM%3D&reserved=0>
>>
>> I propose Simon Marlow as the shepherd, as the expert on low-level stuff.
>>
>> Please reach consensus as described in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=9V5KT%2F6kDmUNU5xMMKByR4egiSf61TMdq6yoHMviGcg%3D&reserved=0>
>> 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/
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=CSR%2BQeNk7k5o6bjo%2Fv2Ke5Yu6h2hEwqR2gIcu0XMU5U%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%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=taRsN3Xgue2y426KtNoZGzYtwdviS2%2BwyKmnww8yEAs%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/20191209/227a4951/attachment-0001.html>

From rae at richarde.dev  Mon Dec  9 10:24:43 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 9 Dec 2019 10:24:43 +0000
Subject: [ghc-steering-committee] [EXTERNAL] #265: Unlifted Datatypes,
 recommendation: accept
In-Reply-To: <CANsrgPKF5yGQew6SHz5BWe7Vod+vkQeYeyT9430vLXHakO+JCQ@mail.gmail.com>
References: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
 <CANsrgP+2N4_VtvWT+k-3TtstWUm8LF3oZk3KyVx4Sj2uf7xDJw@mail.gmail.com>
 <VI1PR8303MB00938E74F445A5609780E9D9AD5C0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <CAH6fHQmKsp2+2iY31OLQkQCqRuhqRpbmYHujYtyAd8-DJjK+wg@mail.gmail.com>
 <CANsrgPKF5yGQew6SHz5BWe7Vod+vkQeYeyT9430vLXHakO+JCQ@mail.gmail.com>
Message-ID: <01B33891-B077-4A35-914D-94A0C6B50F1F@richarde.dev>

I think that is our stated policy, yes.

> On Dec 9, 2019, at 7:58 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> Shall we put the proposal back into the needs revision state while this is discussed and the proposal updated?
> 
> On Mon, 9 Dec 2019 at 07:42, Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> There is a bit of a discussion on the thread (which I only got time to briefly skim) about whether the proposal should mark unlifted newtypes with a special keyword, or simply by fixing the return kind of the type constructor to `TYPE 'UnliftedRep`. I'm rather on the side of using the return kind, it makes more sense to me. SImon PJ also brings a pretty strong argument in support of this view: https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-562125048 <https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-562125048> .
> 
> Either way, The proposal should at least discuss this view in the alternatives before it gets to be accepted or not.
> 
> But aside from that, I am absolutely in support of the general idea, and the proposal itself is good.
> 
> 
> On Thu, Dec 5, 2019 at 2:20 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
> I’m in support here.  I’ve commented on the discussion thread.
> 
>  
> 
> Simon
> 
>  
> 
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Simon Marlow
> Sent: 02 December 2019 10:06
> To: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
> Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> Subject: [EXTERNAL] [ghc-steering-committee] #265: Unlifted Datatypes, recommendation: accept
> 
>  
> 
> I recommend that we accept proposal #265 (Unlifted Datatypes)
> 
>  
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/265 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029253857&sdata=aEWC0cJAxCRJ973miRTP%2F6JtGVp%2F4FG6qqmKjjfKywE%3D&reserved=0>
> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=JCfBIUeVfDO0f6CElwzpmPY9xyYj7pp%2FoojID59kkCo%3D&reserved=0>
>  
> 
> It's a fairly conservative extension: the kind TYPE 'UnliftedRep already exists with the required functionality, the only addition here is to allow user-defined types to be declared with that kind. The semantics are clear, and there already exists a prototype patch to implement it.
> 
>  
> 
> There are considerable performance benefits to be had for performance-critical code, for instance the containers package.
> 
>  
> 
> A couple of minor issues remain:
> 
> Without special support, the type data unlifted Strict a = Force !a comes with an associated box, so this type isn't as useful as it could be.
> It isn't possible to define values of kind TYPE 'UnlifedRep at the top level, which might be a surprising restriction to the programmer. (However, there's a reasonable workaround). Relatedly, GHC cannot lift expressions of kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead to surprising performance behaviour. Seehttps://gitlab.haskell.org/ghc/ghc/issues/17521 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F17521&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=dgDbIe9AhhI%2FIsnPDPxX7EAoVVkjaKthu%2FNGcyEBOTU%3D&reserved=0>
> Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view.
> 
>  
> 
> Cheers
> 
> Simon
> 
>  
> 
>  
> 
> On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> 
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Unlifed Datatypes
> has been proposed by Sebastian Graf
> https://github.com/ghc-proposals/ghc-proposals/pull/265 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=sbtvm3eM43ihY%2FPoTeS4Sp%2BDE2AJUBSqgGOv6HymoKg%3D&reserved=0>
> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=PeFWonpeS4vYeanypRBMEWgLFy9CgVeue3OhHrZa7aM%3D&reserved=0>
> 
> I propose Simon Marlow as the shepherd, as the expert on low-level stuff.
> 
> Please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=9V5KT%2F6kDmUNU5xMMKByR4egiSf61TMdq6yoHMviGcg%3D&reserved=0>
> 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 <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%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=CSR%2BQeNk7k5o6bjo%2Fv2Ke5Yu6h2hEwqR2gIcu0XMU5U%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%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=taRsN3Xgue2y426KtNoZGzYtwdviS2%2BwyKmnww8yEAs%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://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/20191209/91f79931/attachment.html>

From simonpj at microsoft.com  Mon Dec  9 22:57:49 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 9 Dec 2019 22:57:49 +0000
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
Message-ID: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

Dear steering committee

I'm the shepherd for the RecordDotSyntax proposal.
  https://github.com/ghc-proposals/ghc-proposals/pull/282

I recommend acceptance:
https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691

Please reads the proposal, and as much of the discussion as you feel able, and respond in the next week or two to indicate your views.

Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion.

I'd love every member of the committee to express a view.  This proposal has attracted a lot of interest.

Thanks

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Joachim Breitner
| Sent: 28 November 2019 10:11
| To: ghc-steering-committee at haskell.org
| Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
| RecordDotSyntax, Shepherd: Simon PJ
| 
| Dear Committee,
| 
| this is your secretary speaking:
| 
| RecordDotSyntax language extension proposal has been proposed by Neil
| Mitchell and Shayne Fletcher
| https://github.com/ghc-proposals/ghc-proposals/pull/282
| https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-
| syntax/proposals/0000-record-dot-syntax.md
| 
| This is going to be a tricky one. It is partly about whitespace, so it
| has attracted a _lot_ of community interest, by far the most so far. To
| navigate that ship, I propose Simon PJ as the shepherd, because he is a
| excellent moderator and community manager, and because he has the
| necessary authority to hopefully get a verdict accepted.
| 
| 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

From eric at seidel.io  Tue Dec 10 02:56:39 2019
From: eric at seidel.io (Eric Seidel)
Date: Mon, 09 Dec 2019 21:56:39 -0500
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <50066ba6-68ac-4a1e-94d3-799cdfdd180b@www.fastmail.com>

I'm very supportive of the proposal overall, I think it would be a major ergonomic improvement to the language.

On the question of how to interpret `foo .lbl`, I'm still not entirely convinced that a bare `.lbl` should refer to the selector function. To me the alternative reading of `foo .lbl` being the same as `foo.lbl` is more natural. And I worry (without evidence to be fair) that the proposal's interpretation will be a new, common stumbling block for newcomers to the language. I believe I'm in the minority here, and I can certainly train myself to use the proposal's interpretation, so I won't stand in its way. But it would be really nice if the final implementation could provide a helpful suggestion to try `foo.lbl` instead if type-checking fails!

On Mon, Dec 9, 2019, at 17:57, Simon Peyton Jones via ghc-steering-committee wrote:
> Dear steering committee
> 
> I'm the shepherd for the RecordDotSyntax proposal.
>   https://github.com/ghc-proposals/ghc-proposals/pull/282
> 
> I recommend acceptance:
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691
> 
> Please reads the proposal, and as much of the discussion as you feel 
> able, and respond in the next week or two to indicate your views.
> 
> Remember: ask technical questions on the Github discussion thread, and 
> use this mailing list for more evaluative discussion of judgement or 
> opinion.
> 
> I'd love every member of the committee to express a view.  This 
> proposal has attracted a lot of interest.
> 
> Thanks
> 
> Simon
> 
> | -----Original Message-----
> | From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> | On Behalf Of Joachim Breitner
> | Sent: 28 November 2019 10:11
> | To: ghc-steering-committee at haskell.org
> | Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> | RecordDotSyntax, Shepherd: Simon PJ
> | 
> | Dear Committee,
> | 
> | this is your secretary speaking:
> | 
> | RecordDotSyntax language extension proposal has been proposed by Neil
> | Mitchell and Shayne Fletcher
> | https://github.com/ghc-proposals/ghc-proposals/pull/282
> | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-
> | syntax/proposals/0000-record-dot-syntax.md
> | 
> | This is going to be a tricky one. It is partly about whitespace, so it
> | has attracted a _lot_ of community interest, by far the most so far. To
> | navigate that ship, I propose Simon PJ as the shepherd, because he is a
> | excellent moderator and community manager, and because he has the
> | necessary authority to hopefully get a verdict accepted.
> | 
> | 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
> _______________________________________________
> 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  Tue Dec 10 11:40:37 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 10 Dec 2019 12:40:37 +0100
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>

Hi,

TL;DR: Support acceptance, preference for (.foo) over .foo.

I guess many people are excited, so overall good to get this.

I recently stopped using Haskell for something where readability was
the primary goal for lack of nested access and updates. So yay! :-)

I am a bit unhappy about the “Higher-rank fields” problem. Not that I
use such field often, but it came up in the “Overloaded do” proposal.
Maybe accepting this will increase the chances of a getField variant
that works even in impredicative cases.

I hope pattern matching will follow, but no need to have it in this
proposal.


About the contentious issue of (.foo) vs. .foo, I am squarely in the
(.foo) camp, for all the gut-feeling reasons given elsewhere in
abundance. My main reasons: feels like a syntactic section to me, and
less danger of wat effects for people coming from languages with the

  a.foo
   .bar
   .baz

idiom…


I will not veto the current form, but Eric may be in less of a minority
that he thinks.



The precedence rule

   f a.b.c 10

being

   f (a.b.c) 10

makes sense when one comes from Ocaml or similar languages, or has
thought about record updates for a long time. There is a trace of a
feeling that this is un-Haskellish in the same way as

   f a { b = c } 10

is. But at least we don't allow spaces around the dot, so it is
probably fine.


Cheers,
Joachim






Am Montag, den 09.12.2019, 22:57 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> Dear steering committee
> 
> I'm the shepherd for the RecordDotSyntax proposal.
>   https://github.com/ghc-proposals/ghc-proposals/pull/282
> 
> I recommend acceptance:
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691
> 
> Please reads the proposal, and as much of the discussion as you feel able, and respond in the next week or two to indicate your views.
> 
> Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion.
> 
> I'd love every member of the committee to express a view.  This proposal has attracted a lot of interest.
> 
> Thanks
> 
> Simon
> 
> > -----Original Message-----
> > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> > On Behalf Of Joachim Breitner
> > Sent: 28 November 2019 10:11
> > To: ghc-steering-committee at haskell.org
> > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> > RecordDotSyntax, Shepherd: Simon PJ
> > 
> > Dear Committee,
> > 
> > this is your secretary speaking:
> > 
> > RecordDotSyntax language extension proposal has been proposed by Neil
> > Mitchell and Shayne Fletcher
> > https://github.com/ghc-proposals/ghc-proposals/pull/282
> > https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-
> > syntax/proposals/0000-record-dot-syntax.md
> > 
> > This is going to be a tricky one. It is partly about whitespace, so it
> > has attracted a _lot_ of community interest, by far the most so far. To
> > navigate that ship, I propose Simon PJ as the shepherd, because he is a
> > excellent moderator and community manager, and because he has the
> > necessary authority to hopefully get a verdict accepted.
> > 
> > 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From simonpj at microsoft.com  Tue Dec 10 12:47:29 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 Dec 2019 12:47:29 +0000
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
Message-ID: <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

|  About the contentious issue of (.foo) vs. .foo, I am squarely in the
|  (.foo) camp,

Although I recommended allowing naked .foo, if there is a consensus on the committee for (.foo), with a naked .foo being illegal, then I'm quite willing to support that position too.   After all, it just makes more programs illegal, we can always allow naked .foo later.

I don't think anyone is proposing that
	f g .x h .y z
means
	f (g.x) (h.y) z
I would cordially dislike that, as I do the current record update syntax precedence rules.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 10 December 2019 11:41
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] RecordDotSyntax: please express
|  a view
|  
|  Hi,
|  
|  TL;DR: Support acceptance, preference for (.foo) over .foo.
|  
|  I guess many people are excited, so overall good to get this.
|  
|  I recently stopped using Haskell for something where readability was
|  the primary goal for lack of nested access and updates. So yay! :-)
|  
|  I am a bit unhappy about the “Higher-rank fields” problem. Not that I
|  use such field often, but it came up in the “Overloaded do” proposal.
|  Maybe accepting this will increase the chances of a getField variant
|  that works even in impredicative cases.
|  
|  I hope pattern matching will follow, but no need to have it in this
|  proposal.
|  
|  
|  About the contentious issue of (.foo) vs. .foo, I am squarely in the
|  (.foo) camp, for all the gut-feeling reasons given elsewhere in
|  abundance. My main reasons: feels like a syntactic section to me, and
|  less danger of wat effects for people coming from languages with the
|  
|    a.foo
|     .bar
|     .baz
|  
|  idiom…
|  
|  
|  I will not veto the current form, but Eric may be in less of a
|  minority
|  that he thinks.
|  
|  
|  
|  The precedence rule
|  
|     f a.b.c 10
|  
|  being
|  
|     f (a.b.c) 10
|  
|  makes sense when one comes from Ocaml or similar languages, or has
|  thought about record updates for a long time. There is a trace of a
|  feeling that this is un-Haskellish in the same way as
|  
|     f a { b = c } 10
|  
|  is. But at least we don't allow spaces around the dot, so it is
|  probably fine.
|  
|  
|  Cheers,
|  Joachim
|  
|  
|  
|  
|  
|  
|  Am Montag, den 09.12.2019, 22:57 +0000 schrieb Simon Peyton Jones via
|  ghc-steering-committee:
|  > Dear steering committee
|  >
|  > I'm the shepherd for the RecordDotSyntax proposal.
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F282&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C84
|  3ae99c854745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637115748567847774&amp;sdata=gcW6OmpCccSbVaC5AmkFdJtrpwbdo1EIEy7
|  stuHOeq0%3D&amp;reserved=0
|  >
|  > I recommend acceptance:
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282%23issuecomment-
|  563477691&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  48567847774&amp;sdata=9bwoFCaNRGH62hV7LvKvCPbiFXYQjAaSPgUKe6ttLtw%3D&a
|  mp;reserved=0
|  >
|  > Please reads the proposal, and as much of the discussion as you feel
|  able, and respond in the next week or two to indicate your views.
|  >
|  > Remember: ask technical questions on the Github discussion thread,
|  and use this mailing list for more evaluative discussion of judgement
|  or opinion.
|  >
|  > I'd love every member of the committee to express a view.  This
|  proposal has attracted a lot of interest.
|  >
|  > Thanks
|  >
|  > Simon
|  >
|  > > -----Original Message-----
|  > > From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org>
|  > > On Behalf Of Joachim Breitner
|  > > Sent: 28 November 2019 10:11
|  > > To: ghc-steering-committee at haskell.org
|  > > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
|  > > RecordDotSyntax, Shepherd: Simon PJ
|  > >
|  > > Dear Committee,
|  > >
|  > > this is your secretary speaking:
|  > >
|  > > RecordDotSyntax language extension proposal has been proposed by
|  Neil
|  > > Mitchell and Shayne Fletcher
|  > >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F282&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C84
|  3ae99c854745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637115748567847774&amp;sdata=gcW6OmpCccSbVaC5AmkFdJtrpwbdo1EIEy7
|  stuHOeq0%3D&amp;reserved=0
|  > >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-
|  &amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745dc9a3f08d7
|  7d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157485678477
|  74&amp;sdata=Kno9%2Fitm3REWI6roXdLQ88tSpDA%2FeJvY8bb4XKKJI1g%3D&amp;re
|  served=0
|  > > syntax/proposals/0000-record-dot-syntax.md
|  > >
|  > > This is going to be a tricky one. It is partly about whitespace,
|  so it
|  > > has attracted a _lot_ of community interest, by far the most so
|  far. To
|  > > navigate that ship, I propose Simon PJ as the shepherd, because he
|  is a
|  > > excellent moderator and community manager, and because he has the
|  > > necessary authority to hopefully get a verdict accepted.
|  > >
|  > > Please reach consensus as described in
|  > >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fghc-proposals%2Fghc-proposals%23committee-
|  process&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745dc9
|  a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115748
|  567847774&amp;sdata=0eXaTaxw81Z2szF2KGZ3qxbJgSgx3wQZUii8rr1XytM%3D&amp
|  ;reserved=0
|  > > 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
|  > >
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c85
|  4745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7115748567847774&amp;sdata=aeTui1sCsvRGKFzUnyZHzKL%2FwBF0NLDGR%2BmJ5yT
|  UfrE%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%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  48567847774&amp;sdata=hpyFheQhmtsGFHpKDn1US%2FIwi8OmgWdpk1IdT5v3YDo%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%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  48567847774&amp;sdata=hpyFheQhmtsGFHpKDn1US%2FIwi8OmgWdpk1IdT5v3YDo%3D
|  &amp;reserved=0
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c85
|  4745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7115748567857762&amp;sdata=id%2Bw%2FzvZX%2FbgV%2FBovQ85ByF7KFdkU8NKtxU
|  eygGeYKU%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%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  48567857762&amp;sdata=zUhQrs20IkgPfD4lBZIxTYQSBFVlIOP7itXhTTLut6A%3D&a
|  mp;reserved=0

From mail at joachim-breitner.de  Tue Dec 10 12:56:21 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 10 Dec 2019 13:56:21 +0100
Subject: [ghc-steering-committee] #301: Rename PtrRep to BoxedRep,
	recommending: accept
Message-ID: <138e6484b66c931c4e121171e9030a411606cc20.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Rename PtrRep to BoxedRep
has been proposed by Neil Andrew Martin
https://github.com/ghc-proposals/ghc-proposals/pull/301

I’ll shepherd that myself.

It’s a simple renaming in an existing proposal, clarifying a somewhat
misleading name (PtrRep) to a more precise one (BoxedRep). This looks
reasonable and helpful, so I am happy to propose acceptance.

Any objections?



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


From simonpj at microsoft.com  Tue Dec 10 13:06:13 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 Dec 2019 13:06:13 +0000
Subject: [ghc-steering-committee] #301: Rename PtrRep to BoxedRep,
	recommending: accept
In-Reply-To: <138e6484b66c931c4e121171e9030a411606cc20.camel@joachim-breitner.de>
References: <138e6484b66c931c4e121171e9030a411606cc20.camel@joachim-breitner.de>
Message-ID: <VI1PR8303MB0093A625111D21A497B5492BAD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

I'm ok with this.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 10 December 2019 12:56
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] #301: Rename PtrRep to BoxedRep,
|  recommending: accept
|  
|  Dear Committee,
|  
|  this is your secretary speaking:
|  
|  Rename PtrRep to BoxedRep
|  has been proposed by Neil Andrew Martin
|  https://github.com/ghc-proposals/ghc-proposals/pull/301
|  
|  I’ll shepherd that myself.
|  
|  It’s a simple renaming in an existing proposal, clarifying a somewhat
|  misleading name (PtrRep) to a more precise one (BoxedRep). This looks
|  reasonable and helpful, so I am happy to propose acceptance.
|  
|  Any objections?
|  
|  
|  
|  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 rae at richarde.dev  Tue Dec 10 13:41:19 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 10 Dec 2019 13:41:19 +0000
Subject: [ghc-steering-committee] #301: Rename PtrRep to BoxedRep,
 recommending: accept
In-Reply-To: <VI1PR8303MB0093A625111D21A497B5492BAD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <138e6484b66c931c4e121171e9030a411606cc20.camel@joachim-breitner.de>
 <VI1PR8303MB0093A625111D21A497B5492BAD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <B9291F6A-58AF-4D08-BAA1-1197A2C16F89@richarde.dev>

Yes -- I support.

Thanks,
Richard

> On Dec 10, 2019, at 1:06 PM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> I'm ok with this.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Joachim Breitner
> |  Sent: 10 December 2019 12:56
> |  To: ghc-steering-committee at haskell.org
> |  Subject: [ghc-steering-committee] #301: Rename PtrRep to BoxedRep,
> |  recommending: accept
> |  
> |  Dear Committee,
> |  
> |  this is your secretary speaking:
> |  
> |  Rename PtrRep to BoxedRep
> |  has been proposed by Neil Andrew Martin
> |  https://github.com/ghc-proposals/ghc-proposals/pull/301
> |  
> |  I’ll shepherd that myself.
> |  
> |  It’s a simple renaming in an existing proposal, clarifying a somewhat
> |  misleading name (PtrRep) to a more precise one (BoxedRep). This looks
> |  reasonable and helpful, so I am happy to propose acceptance.
> |  
> |  Any objections?
> |  
> |  
> |  
> |  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


From rae at richarde.dev  Tue Dec 10 14:16:53 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 10 Dec 2019 14:16:53 +0000
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>

I'm in support of this proposal.

I don't think it's fantastic. (In particular, I'm bothered about the lack of polymorphic update.) But it seems willfully disdainful of our users if we don't do *something*. This is the closest we've gotten to a solution here. Let's not turn down now. And perhaps with impredicativity, new doors will open up in the future.

As to the Great Whitespace Debate: I prefer requiring the parens for the selector section: (.foo). It makes this more like other sections. A related question (that seems unconsidered by the proposal) is: if we require parens for the section, what does a bare `.foo` mean? If we don't allow

>  x.foo
>   .bar
>   .baz

then what do users do if they have long field names? Are we reduced to writing

>  (x.foo.bar
>     ).baz

? That's awful. I remember this coming up in the commentary, but I'm not quite sure how to search for it.

To be concrete, I propose this:

Position of .      Meaning
--------           -------
tight infix        with a conid before the .: module qualification
                   with anything else before the .: field access
suffix             parse error
prefix             with a ( before the .: field selector
                   otherwise: field access
loose infix        normal, user-definable operator (defined to be composition in the Prelude)

Note that the lexer must tag the . with its position, and then parsing is easy to implement. Effectively, a prefix . slurps up all the preceding whitespace. No weird precedence rules necessary.

To be clear: I don't feel very strongly on this point, and I support the proposal with any discussed conclusion to the Great Whitespace Debate. Yet, as a committee member, I make my vote as I have written here.

Richard


> On Dec 10, 2019, at 12:47 PM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> |  About the contentious issue of (.foo) vs. .foo, I am squarely in the
> |  (.foo) camp,
> 
> Although I recommended allowing naked .foo, if there is a consensus on the committee for (.foo), with a naked .foo being illegal, then I'm quite willing to support that position too.   After all, it just makes more programs illegal, we can always allow naked .foo later.
> 
> I don't think anyone is proposing that
> 	f g .x h .y z
> means
> 	f (g.x) (h.y) z
> I would cordially dislike that, as I do the current record update syntax precedence rules.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Joachim Breitner
> |  Sent: 10 December 2019 11:41
> |  To: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] RecordDotSyntax: please express
> |  a view
> |  
> |  Hi,
> |  
> |  TL;DR: Support acceptance, preference for (.foo) over .foo.
> |  
> |  I guess many people are excited, so overall good to get this.
> |  
> |  I recently stopped using Haskell for something where readability was
> |  the primary goal for lack of nested access and updates. So yay! :-)
> |  
> |  I am a bit unhappy about the “Higher-rank fields” problem. Not that I
> |  use such field often, but it came up in the “Overloaded do” proposal.
> |  Maybe accepting this will increase the chances of a getField variant
> |  that works even in impredicative cases.
> |  
> |  I hope pattern matching will follow, but no need to have it in this
> |  proposal.
> |  
> |  
> |  About the contentious issue of (.foo) vs. .foo, I am squarely in the
> |  (.foo) camp, for all the gut-feeling reasons given elsewhere in
> |  abundance. My main reasons: feels like a syntactic section to me, and
> |  less danger of wat effects for people coming from languages with the
> |  
> |    a.foo
> |     .bar
> |     .baz
> |  
> |  idiom…
> |  
> |  
> |  I will not veto the current form, but Eric may be in less of a
> |  minority
> |  that he thinks.
> |  
> |  
> |  
> |  The precedence rule
> |  
> |     f a.b.c 10
> |  
> |  being
> |  
> |     f (a.b.c) 10
> |  
> |  makes sense when one comes from Ocaml or similar languages, or has
> |  thought about record updates for a long time. There is a trace of a
> |  feeling that this is un-Haskellish in the same way as
> |  
> |     f a { b = c } 10
> |  
> |  is. But at least we don't allow spaces around the dot, so it is
> |  probably fine.
> |  
> |  
> |  Cheers,
> |  Joachim
> |  
> |  
> |  
> |  
> |  
> |  
> |  Am Montag, den 09.12.2019, 22:57 +0000 schrieb Simon Peyton Jones via
> |  ghc-steering-committee:
> |  > Dear steering committee
> |  >
> |  > I'm the shepherd for the RecordDotSyntax proposal.
> |  >
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  ub.com%2Fghc-proposals%2Fghc-
> |  proposals%2Fpull%2F282&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C84
> |  3ae99c854745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> |  7C0%7C637115748567847774&amp;sdata=gcW6OmpCccSbVaC5AmkFdJtrpwbdo1EIEy7
> |  stuHOeq0%3D&amp;reserved=0
> |  >
> |  > I recommend acceptance:
> |  >
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282%23issuecomment-
> |  563477691&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
> |  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
> |  48567847774&amp;sdata=9bwoFCaNRGH62hV7LvKvCPbiFXYQjAaSPgUKe6ttLtw%3D&a
> |  mp;reserved=0
> |  >
> |  > Please reads the proposal, and as much of the discussion as you feel
> |  able, and respond in the next week or two to indicate your views.
> |  >
> |  > Remember: ask technical questions on the Github discussion thread,
> |  and use this mailing list for more evaluative discussion of judgement
> |  or opinion.
> |  >
> |  > I'd love every member of the committee to express a view.  This
> |  proposal has attracted a lot of interest.
> |  >
> |  > Thanks
> |  >
> |  > Simon
> |  >
> |  > > -----Original Message-----
> |  > > From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org>
> |  > > On Behalf Of Joachim Breitner
> |  > > Sent: 28 November 2019 10:11
> |  > > To: ghc-steering-committee at haskell.org
> |  > > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> |  > > RecordDotSyntax, Shepherd: Simon PJ
> |  > >
> |  > > Dear Committee,
> |  > >
> |  > > this is your secretary speaking:
> |  > >
> |  > > RecordDotSyntax language extension proposal has been proposed by
> |  Neil
> |  > > Mitchell and Shayne Fletcher
> |  > >
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  ub.com%2Fghc-proposals%2Fghc-
> |  proposals%2Fpull%2F282&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C84
> |  3ae99c854745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> |  7C0%7C637115748567847774&amp;sdata=gcW6OmpCccSbVaC5AmkFdJtrpwbdo1EIEy7
> |  stuHOeq0%3D&amp;reserved=0
> |  > >
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  ub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-
> |  &amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745dc9a3f08d7
> |  7d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157485678477
> |  74&amp;sdata=Kno9%2Fitm3REWI6roXdLQ88tSpDA%2FeJvY8bb4XKKJI1g%3D&amp;re
> |  served=0
> |  > > syntax/proposals/0000-record-dot-syntax.md
> |  > >
> |  > > This is going to be a tricky one. It is partly about whitespace,
> |  so it
> |  > > has attracted a _lot_ of community interest, by far the most so
> |  far. To
> |  > > navigate that ship, I propose Simon PJ as the shepherd, because he
> |  is a
> |  > > excellent moderator and community manager, and because he has the
> |  > > necessary authority to hopefully get a verdict accepted.
> |  > >
> |  > > Please reach consensus as described in
> |  > >
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  ub.com%2Fghc-proposals%2Fghc-proposals%23committee-
> |  process&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745dc9
> |  a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115748
> |  567847774&amp;sdata=0eXaTaxw81Z2szF2KGZ3qxbJgSgx3wQZUii8rr1XytM%3D&amp
> |  ;reserved=0
> |  > > 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
> |  > >
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
> |  oachim-
> |  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c85
> |  4745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> |  7115748567847774&amp;sdata=aeTui1sCsvRGKFzUnyZHzKL%2FwBF0NLDGR%2BmJ5yT
> |  UfrE%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%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
> |  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
> |  48567847774&amp;sdata=hpyFheQhmtsGFHpKDn1US%2FIwi8OmgWdpk1IdT5v3YDo%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%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
> |  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
> |  48567847774&amp;sdata=hpyFheQhmtsGFHpKDn1US%2FIwi8OmgWdpk1IdT5v3YDo%3D
> |  &amp;reserved=0
> |  --
> |  Joachim Breitner
> |    mail at joachim-breitner.de
> |  
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
> |  oachim-
> |  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c85
> |  4745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> |  7115748567857762&amp;sdata=id%2Bw%2FzvZX%2FbgV%2FBovQ85ByF7KFdkU8NKtxU
> |  eygGeYKU%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%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
> |  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
> |  48567857762&amp;sdata=zUhQrs20IkgPfD4lBZIxTYQSBFVlIOP7itXhTTLut6A%3D&a
> |  mp;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 simonpj at microsoft.com  Tue Dec 10 14:27:42 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 Dec 2019 14:27:42 +0000
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
Message-ID: <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

|  To be concrete, I propose this:

Not concrete enough.  I don't understand 

|  prefix             with a ( before the .: field selector
|                     otherwise: field access

What does (f a .b c .d e) mean?

You may be arguing that naked `.x` is a *postfix operator*, rather like factorial when we write 5!.   If so, it should have a precedence etc, and presumably binds less tightly than function application.  So
	f a .b c .d e
would presumably mean
	((f a).b c).d e

That might be OK.  I don’t recall the discussion articulating it like this, but it seems defensible.

Simon

|  -----Original Message-----
|  From: Richard Eisenberg <rae at richarde.dev>
|  Sent: 10 December 2019 14:17
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-
|  committee at haskell.org
|  Subject: Re: [ghc-steering-committee] RecordDotSyntax: please express
|  a view
|  
|  I'm in support of this proposal.
|  
|  I don't think it's fantastic. (In particular, I'm bothered about the
|  lack of polymorphic update.) But it seems willfully disdainful of our
|  users if we don't do *something*. This is the closest we've gotten to
|  a solution here. Let's not turn down now. And perhaps with
|  impredicativity, new doors will open up in the future.
|  
|  As to the Great Whitespace Debate: I prefer requiring the parens for
|  the selector section: (.foo). It makes this more like other sections.
|  A related question (that seems unconsidered by the proposal) is: if we
|  require parens for the section, what does a bare `.foo` mean? If we
|  don't allow
|  
|  >  x.foo
|  >   .bar
|  >   .baz
|  
|  then what do users do if they have long field names? Are we reduced to
|  writing
|  
|  >  (x.foo.bar
|  >     ).baz
|  
|  ? That's awful. I remember this coming up in the commentary, but I'm
|  not quite sure how to search for it.
|  
|  To be concrete, I propose this:
|  
|  Position of .      Meaning
|  --------           -------
|  tight infix        with a conid before the .: module qualification
|                     with anything else before the .: field access
|  suffix             parse error
|  prefix             with a ( before the .: field selector
|                     otherwise: field access
|  loose infix        normal, user-definable operator (defined to be
|  composition in the Prelude)
|  
|  Note that the lexer must tag the . with its position, and then parsing
|  is easy to implement. Effectively, a prefix . slurps up all the
|  preceding whitespace. No weird precedence rules necessary.
|  
|  To be clear: I don't feel very strongly on this point, and I support
|  the proposal with any discussed conclusion to the Great Whitespace
|  Debate. Yet, as a committee member, I make my vote as I have written
|  here.
|  
|  Richard
|  
|  
|  > On Dec 10, 2019, at 12:47 PM, Simon Peyton Jones via ghc-steering-
|  committee <ghc-steering-committee at haskell.org> wrote:
|  >
|  > |  About the contentious issue of (.foo) vs. .foo, I am squarely in
|  the
|  > |  (.foo) camp,
|  >
|  > Although I recommended allowing naked .foo, if there is a consensus
|  on the committee for (.foo), with a naked .foo being illegal, then I'm
|  quite willing to support that position too.   After all, it just makes
|  more programs illegal, we can always allow naked .foo later.
|  >
|  > I don't think anyone is proposing that
|  > 	f g .x h .y z
|  > means
|  > 	f (g.x) (h.y) z
|  > I would cordially dislike that, as I do the current record update
|  syntax precedence rules.
|  >
|  > Simon
|  >
|  > |  -----Original Message-----
|  > |  From: ghc-steering-committee <ghc-steering-committee-
|  > |  bounces at haskell.org> On Behalf Of Joachim Breitner
|  > |  Sent: 10 December 2019 11:41
|  > |  To: ghc-steering-committee at haskell.org
|  > |  Subject: Re: [ghc-steering-committee] RecordDotSyntax: please
|  express
|  > |  a view
|  > |
|  > |  Hi,
|  > |
|  > |  TL;DR: Support acceptance, preference for (.foo) over .foo.
|  > |
|  > |  I guess many people are excited, so overall good to get this.
|  > |
|  > |  I recently stopped using Haskell for something where readability
|  was
|  > |  the primary goal for lack of nested access and updates. So yay!
|  :-)
|  > |
|  > |  I am a bit unhappy about the “Higher-rank fields” problem. Not
|  that I
|  > |  use such field often, but it came up in the “Overloaded do”
|  proposal.
|  > |  Maybe accepting this will increase the chances of a getField
|  variant
|  > |  that works even in impredicative cases.
|  > |
|  > |  I hope pattern matching will follow, but no need to have it in
|  this
|  > |  proposal.
|  > |
|  > |
|  > |  About the contentious issue of (.foo) vs. .foo, I am squarely in
|  the
|  > |  (.foo) camp, for all the gut-feeling reasons given elsewhere in
|  > |  abundance. My main reasons: feels like a syntactic section to me,
|  and
|  > |  less danger of wat effects for people coming from languages with
|  the
|  > |
|  > |    a.foo
|  > |     .bar
|  > |     .baz
|  > |
|  > |  idiom…
|  > |
|  > |
|  > |  I will not veto the current form, but Eric may be in less of a
|  > |  minority
|  > |  that he thinks.
|  > |
|  > |
|  > |
|  > |  The precedence rule
|  > |
|  > |     f a.b.c 10
|  > |
|  > |  being
|  > |
|  > |     f (a.b.c) 10
|  > |
|  > |  makes sense when one comes from Ocaml or similar languages, or
|  has
|  > |  thought about record updates for a long time. There is a trace of
|  a
|  > |  feeling that this is un-Haskellish in the same way as
|  > |
|  > |     f a { b = c } 10
|  > |
|  > |  is. But at least we don't allow spaces around the dot, so it is
|  > |  probably fine.
|  > |
|  > |
|  > |  Cheers,
|  > |  Joachim
|  > |
|  > |
|  > |
|  > |
|  > |
|  > |
|  > |  Am Montag, den 09.12.2019, 22:57 +0000 schrieb Simon Peyton Jones
|  via
|  > |  ghc-steering-committee:
|  > |  > Dear steering committee
|  > |  >
|  > |  > I'm the shepherd for the RecordDotSyntax proposal.
|  > |  >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > |  ub.com%2Fghc-proposals%2Fghc-
|  > |
|  proposals%2Fpull%2F282&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C84
|  > |
|  3ae99c854745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  > |
|  7C0%7C637115748567847774&amp;sdata=gcW6OmpCccSbVaC5AmkFdJtrpwbdo1EIEy7
|  > |  stuHOeq0%3D&amp;reserved=0
|  > |  >
|  > |  > I recommend acceptance:
|  > |  >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > |  ub.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F282%23issuecomment-
|  > |
|  563477691&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  > |
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  > |
|  48567847774&amp;sdata=9bwoFCaNRGH62hV7LvKvCPbiFXYQjAaSPgUKe6ttLtw%3D&a
|  > |  mp;reserved=0
|  > |  >
|  > |  > Please reads the proposal, and as much of the discussion as you
|  feel
|  > |  able, and respond in the next week or two to indicate your views.
|  > |  >
|  > |  > Remember: ask technical questions on the Github discussion
|  thread,
|  > |  and use this mailing list for more evaluative discussion of
|  judgement
|  > |  or opinion.
|  > |  >
|  > |  > I'd love every member of the committee to express a view.  This
|  > |  proposal has attracted a lot of interest.
|  > |  >
|  > |  > Thanks
|  > |  >
|  > |  > Simon
|  > |  >
|  > |  > > -----Original Message-----
|  > |  > > From: ghc-steering-committee <ghc-steering-committee-
|  > |  bounces at haskell.org>
|  > |  > > On Behalf Of Joachim Breitner
|  > |  > > Sent: 28 November 2019 10:11
|  > |  > > To: ghc-steering-committee at haskell.org
|  > |  > > Subject: [EXTERNAL] [ghc-steering-committee] Please review
|  #282:
|  > |  > > RecordDotSyntax, Shepherd: Simon PJ
|  > |  > >
|  > |  > > Dear Committee,
|  > |  > >
|  > |  > > this is your secretary speaking:
|  > |  > >
|  > |  > > RecordDotSyntax language extension proposal has been proposed
|  by
|  > |  Neil
|  > |  > > Mitchell and Shayne Fletcher
|  > |  > >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > |  ub.com%2Fghc-proposals%2Fghc-
|  > |
|  proposals%2Fpull%2F282&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C84
|  > |
|  3ae99c854745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  > |
|  7C0%7C637115748567847774&amp;sdata=gcW6OmpCccSbVaC5AmkFdJtrpwbdo1EIEy7
|  > |  stuHOeq0%3D&amp;reserved=0
|  > |  > >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > |  ub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-
|  > |
|  &amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745dc9a3f08d7
|  > |
|  7d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157485678477
|  > |
|  74&amp;sdata=Kno9%2Fitm3REWI6roXdLQ88tSpDA%2FeJvY8bb4XKKJI1g%3D&amp;re
|  > |  served=0
|  > |  > > syntax/proposals/0000-record-dot-syntax.md
|  > |  > >
|  > |  > > This is going to be a tricky one. It is partly about
|  whitespace,
|  > |  so it
|  > |  > > has attracted a _lot_ of community interest, by far the most
|  so
|  > |  far. To
|  > |  > > navigate that ship, I propose Simon PJ as the shepherd,
|  because he
|  > |  is a
|  > |  > > excellent moderator and community manager, and because he has
|  the
|  > |  > > necessary authority to hopefully get a verdict accepted.
|  > |  > >
|  > |  > > Please reach consensus as described in
|  > |  > >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > |  ub.com%2Fghc-proposals%2Fghc-proposals%23committee-
|  > |
|  process&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745dc9
|  > |
|  a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115748
|  > |
|  567847774&amp;sdata=0eXaTaxw81Z2szF2KGZ3qxbJgSgx3wQZUii8rr1XytM%3D&amp
|  > |  ;reserved=0
|  > |  > > 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
|  > |  > >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  > |  oachim-
|  > |
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c85
|  > |
|  4745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  > |
|  7115748567847774&amp;sdata=aeTui1sCsvRGKFzUnyZHzKL%2FwBF0NLDGR%2BmJ5yT
|  > |  UfrE%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%2Fmail
|  > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  > |
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  > |
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  > |
|  48567847774&amp;sdata=hpyFheQhmtsGFHpKDn1US%2FIwi8OmgWdpk1IdT5v3YDo%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%2Fmail
|  > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  > |
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  > |
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  > |
|  48567847774&amp;sdata=hpyFheQhmtsGFHpKDn1US%2FIwi8OmgWdpk1IdT5v3YDo%3D
|  > |  &amp;reserved=0
|  > |  --
|  > |  Joachim Breitner
|  > |    mail at joachim-breitner.de
|  > |
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  > |  oachim-
|  > |
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c85
|  > |
|  4745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  > |
|  7115748567857762&amp;sdata=id%2Bw%2FzvZX%2FbgV%2FBovQ85ByF7KFdkU8NKtxU
|  > |  eygGeYKU%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%2Fmail
|  > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  > |
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  > |
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  > |
|  48567857762&amp;sdata=zUhQrs20IkgPfD4lBZIxTYQSBFVlIOP7itXhTTLut6A%3D&a
|  > |  mp;reserved=0
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cc4905b1dc7a4474
|  4c43b08d77d7b9d5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371158
|  42192614669&amp;sdata=Xh0SopxeypTlM%2B31iuHJNQMRzNt2sTLGXbdmYjGu3CQ%3D
|  &amp;reserved=0


From rae at richarde.dev  Tue Dec 10 14:33:01 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 10 Dec 2019 14:33:01 +0000
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
 <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <F4C020F4-59E4-40D1-AA04-9283658D0F80@richarde.dev>



> On Dec 10, 2019, at 2:27 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> |  To be concrete, I propose this:
> 
> Not concrete enough.  I don't understand 
> 
> |  prefix             with a ( before the .: field selector
> |                     otherwise: field access
> 
> What does (f a .b c .d e) mean?

According to my table, we have two prefix `.`s. These are field accesses. Just like the tight infix positioning of `.`. So, (f a .b c .d e) means the exact same thing as (f a.b c.d e), which is, presumably (f (a.b) (c.d) e).

Perhaps that's not what we like. But it is simple and comes straight from my table. And it is not too bad for programmers: prefix `.` is *just like* tight infix `.`. The only exception is at the beginning of a section, where tight-infix does not make sense.

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

From cma at bitemyapp.com  Tue Dec 10 14:54:31 2019
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 10 Dec 2019 08:54:31 -0600
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <CADnndOrvA9j9YHMaXDmHzz6Lt=kzjkkySBdmsVADjdawR50-7g@mail.gmail.com>

This proposal should be rejected.

The contention over what whitespace around the dot operator should
make it clear that even expert Haskellers aren't sure what to expect
from this proposal in an intuitive way. We should wait until there's a
more compelling benefit that would justify forking the syntax this
dramatically. The proposal feels over-determined by present trends in
lens libraries, but that's not something I have the energy to
prosecute very far. I could imagine a less contentious way forward is
possible but I think it's unlikely with the technical particulars at
hand. I don't believe the enhanced type inference brought by
RecordDotSyntax merits its inclusion given how it complicates the
syntax and compatibility story. You can achieve the same with
libraries now. That the existing extensions aren't as useful as they
ought as compared with using a lens library is symptomatic of
half-baked proposals being incorporated into GHC.

We can wait until the juice is worth the squeeze and avoid an unforced
error here.

On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
> Dear steering committee
>
> I'm the shepherd for the RecordDotSyntax proposal.
>   https://github.com/ghc-proposals/ghc-proposals/pull/282
>
> I recommend acceptance:
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691
>
> Please reads the proposal, and as much of the discussion as you feel able, and respond in the next week or two to indicate your views.
>
> Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion.
>
> I'd love every member of the committee to express a view.  This proposal has attracted a lot of interest.
>
> Thanks
>
> Simon
>
> | -----Original Message-----
> | From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> | On Behalf Of Joachim Breitner
> | Sent: 28 November 2019 10:11
> | To: ghc-steering-committee at haskell.org
> | Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> | RecordDotSyntax, Shepherd: Simon PJ
> |
> | Dear Committee,
> |
> | this is your secretary speaking:
> |
> | RecordDotSyntax language extension proposal has been proposed by Neil
> | Mitchell and Shayne Fletcher
> | https://github.com/ghc-proposals/ghc-proposals/pull/282
> | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-
> | syntax/proposals/0000-record-dot-syntax.md
> |
> | This is going to be a tricky one. It is partly about whitespace, so it
> | has attracted a _lot_ of community interest, by far the most so far. To
> | navigate that ship, I propose Simon PJ as the shepherd, because he is a
> | excellent moderator and community manager, and because he has the
> | necessary authority to hopefully get a verdict accepted.
> |
> | 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
> _______________________________________________
> 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 cma at bitemyapp.com  Tue Dec 10 14:55:38 2019
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 10 Dec 2019 08:55:38 -0600
Subject: [ghc-steering-committee] #301: Rename PtrRep to BoxedRep,
 recommending: accept
In-Reply-To: <138e6484b66c931c4e121171e9030a411606cc20.camel@joachim-breitner.de>
References: <138e6484b66c931c4e121171e9030a411606cc20.camel@joachim-breitner.de>
Message-ID: <CADnndOrLbCpNFgpCEdSCHdoqPqHQqSXT=ftTLGPurHrb0OADjA@mail.gmail.com>

Seems more clear. In favor.

On Tue, Dec 10, 2019 at 6:56 AM Joachim Breitner
<mail at joachim-breitner.de> wrote:
>
> Dear Committee,
>
> this is your secretary speaking:
>
> Rename PtrRep to BoxedRep
> has been proposed by Neil Andrew Martin
> https://github.com/ghc-proposals/ghc-proposals/pull/301
>
> I’ll shepherd that myself.
>
> It’s a simple renaming in an existing proposal, clarifying a somewhat
> misleading name (PtrRep) to a more precise one (BoxedRep). This looks
> reasonable and helpful, so I am happy to propose acceptance.
>
> Any objections?
>
>
>
> 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 simonpj at microsoft.com  Tue Dec 10 14:56:53 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 Dec 2019 14:56:53 +0000
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <F4C020F4-59E4-40D1-AA04-9283658D0F80@richarde.dev>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
 <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <F4C020F4-59E4-40D1-AA04-9283658D0F80@richarde.dev>
Message-ID: <VI1PR8303MB0093CE8DF3235059C9C95E16AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

According to my table, we have two prefix `.`s. These are field accesses. Just like the tight infix positioning of `.`. So, (f a .b c .d e) means the exact same thing as (f a.b c.d e), which is, presumably (f (a.b) (c.d) e).

So `.x` behaves like a postfix operator with precedence tighter than function application.   Indeed, personally, I don't like that!

Also I realise that it might be good to write

  xs  .map double

      .filter isEven

      .map square
and that would indeed be what you could say with a postfix operator.  It would parse as

  (((xs.map) double).filter isEven).map square

Simon

From: Richard Eisenberg <rae at richarde.dev>
Sent: 10 December 2019 14:33
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] RecordDotSyntax: please express a view




On Dec 10, 2019, at 2:27 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

|  To be concrete, I propose this:

Not concrete enough.  I don't understand

|  prefix             with a ( before the .: field selector
|                     otherwise: field access

What does (f a .b c .d e) mean?

According to my table, we have two prefix `.`s. These are field accesses. Just like the tight infix positioning of `.`. So, (f a .b c .d e) means the exact same thing as (f a.b c.d e), which is, presumably (f (a.b) (c.d) e).

Perhaps that's not what we like. But it is simple and comes straight from my table. And it is not too bad for programmers: prefix `.` is *just like* tight infix `.`. The only exception is at the beginning of a section, where tight-infix does not make sense.

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

From rae at richarde.dev  Tue Dec 10 15:25:09 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 10 Dec 2019 15:25:09 +0000
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <CADnndOrvA9j9YHMaXDmHzz6Lt=kzjkkySBdmsVADjdawR50-7g@mail.gmail.com>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <CADnndOrvA9j9YHMaXDmHzz6Lt=kzjkkySBdmsVADjdawR50-7g@mail.gmail.com>
Message-ID: <AD85BE8B-6CBD-4B43-9766-1F97AF1B1AF0@richarde.dev>

Thanks for your comments!

> On Dec 10, 2019, at 2:54 PM, Christopher Allen <cma at bitemyapp.com> wrote:
> 
> This proposal should be rejected.
> 
> The contention over what whitespace around the dot operator should
> make it clear that even expert Haskellers aren't sure what to expect
> from this proposal in an intuitive way.

Then there is an easy solution: just don't allow unparenthesized .foo -- that is, make it a parse error. I don't think there is any contention over what (.foo) should mean, and if plain .foo is a parse error, then there is no fork.

> You can achieve the same with
> libraries now.

True -- but at significant cost, both in the effort to learn the (complex) libraries and in the need for Template Haskell, which cannot be used in cross-compilation, for example. I think the warm reception of this proposal suggests that, despite the library-based solution, something more is wanted.

> That the existing extensions aren't as useful as they
> ought as compared with using a lens library is symptomatic of
> half-baked proposals being incorporated into GHC.

I'm curious which proposals you're thinking of here. The strangest one, I think, is DisambiguateRecordFields. That was added before the proposals process. I don't think it would have survived the current process -- at least, not in the form in which it has appeared. I would welcome exploring ways of removing it.

> 
> We can wait until the juice is worth the squeeze and avoid an unforced
> error here.

This is tempting. But I worry that this may be the best we get, and I think inaction is hurting us.

Richard

> 
> On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>> 
>> Dear steering committee
>> 
>> I'm the shepherd for the RecordDotSyntax proposal.
>>  https://github.com/ghc-proposals/ghc-proposals/pull/282
>> 
>> I recommend acceptance:
>> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691
>> 
>> Please reads the proposal, and as much of the discussion as you feel able, and respond in the next week or two to indicate your views.
>> 
>> Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion.
>> 
>> I'd love every member of the committee to express a view.  This proposal has attracted a lot of interest.
>> 
>> Thanks
>> 
>> Simon
>> 
>> | -----Original Message-----
>> | From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
>> | On Behalf Of Joachim Breitner
>> | Sent: 28 November 2019 10:11
>> | To: ghc-steering-committee at haskell.org
>> | Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
>> | RecordDotSyntax, Shepherd: Simon PJ
>> |
>> | Dear Committee,
>> |
>> | this is your secretary speaking:
>> |
>> | RecordDotSyntax language extension proposal has been proposed by Neil
>> | Mitchell and Shayne Fletcher
>> | https://github.com/ghc-proposals/ghc-proposals/pull/282
>> | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-
>> | syntax/proposals/0000-record-dot-syntax.md
>> |
>> | This is going to be a tricky one. It is partly about whitespace, so it
>> | has attracted a _lot_ of community interest, by far the most so far. To
>> | navigate that ship, I propose Simon PJ as the shepherd, because he is a
>> | excellent moderator and community manager, and because he has the
>> | necessary authority to hopefully get a verdict accepted.
>> |
>> | 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
>> _______________________________________________
>> 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From eric at seidel.io  Tue Dec 10 16:14:40 2019
From: eric at seidel.io (Eric Seidel)
Date: Tue, 10 Dec 2019 11:14:40 -0500
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <AD85BE8B-6CBD-4B43-9766-1F97AF1B1AF0@richarde.dev>
References: <AD85BE8B-6CBD-4B43-9766-1F97AF1B1AF0@richarde.dev>
Message-ID: <83E2D220-1A50-4B37-9074-A0F77E8A00EF@seidel.io>

I agree with Richard, I think it would be valuable to think of this as two separate proposals. 

1. Introduce the dot syntax for projection and nested matching/update. Projection is written ‘foo.lbl’ (no white space allowed) and a bare .lbl is a syntax error. This piece seems largely uncontroversial. 

2. Give a meaning to a bare ‘.lbl’. The controversy entirely surrounds what this form should mean. 

I think (1) is a perfectly good proposal on its own, so I’d much prefer us to accept (1) and defer a decision on (2) over rejecting the entire proposal. 

Sent from my iPhone

> On Dec 10, 2019, at 10:26, Richard Eisenberg <rae at richarde.dev> wrote:
> 
> Thanks for your comments!
> 
>> On Dec 10, 2019, at 2:54 PM, Christopher Allen <cma at bitemyapp.com> wrote:
>> 
>> This proposal should be rejected.
>> 
>> The contention over what whitespace around the dot operator should
>> make it clear that even expert Haskellers aren't sure what to expect
>> from this proposal in an intuitive way.
> 
> Then there is an easy solution: just don't allow unparenthesized .foo -- that is, make it a parse error. I don't think there is any contention over what (.foo) should mean, and if plain .foo is a parse error, then there is no fork.
> 
>> You can achieve the same with
>> libraries now.
> 
> True -- but at significant cost, both in the effort to learn the (complex) libraries and in the need for Template Haskell, which cannot be used in cross-compilation, for example. I think the warm reception of this proposal suggests that, despite the library-based solution, something more is wanted.
> 
>> That the existing extensions aren't as useful as they
>> ought as compared with using a lens library is symptomatic of
>> half-baked proposals being incorporated into GHC.
> 
> I'm curious which proposals you're thinking of here. The strangest one, I think, is DisambiguateRecordFields. That was added before the proposals process. I don't think it would have survived the current process -- at least, not in the form in which it has appeared. I would welcome exploring ways of removing it.
> 
>> 
>> We can wait until the juice is worth the squeeze and avoid an unforced
>> error here.
> 
> This is tempting. But I worry that this may be the best we get, and I think inaction is hurting us.
> 
> Richard
> 
>> 
>>> On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via
>>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>> 
>>> Dear steering committee
>>> 
>>> I'm the shepherd for the RecordDotSyntax proposal.
>>> https://github.com/ghc-proposals/ghc-proposals/pull/282
>>> 
>>> I recommend acceptance:
>>> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691
>>> 
>>> Please reads the proposal, and as much of the discussion as you feel able, and respond in the next week or two to indicate your views.
>>> 
>>> Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion.
>>> 
>>> I'd love every member of the committee to express a view.  This proposal has attracted a lot of interest.
>>> 
>>> Thanks
>>> 
>>> Simon
>>> 
>>> | -----Original Message-----
>>> | From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
>>> | On Behalf Of Joachim Breitner
>>> | Sent: 28 November 2019 10:11
>>> | To: ghc-steering-committee at haskell.org
>>> | Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
>>> | RecordDotSyntax, Shepherd: Simon PJ
>>> |
>>> | Dear Committee,
>>> |
>>> | this is your secretary speaking:
>>> |
>>> | RecordDotSyntax language extension proposal has been proposed by Neil
>>> | Mitchell and Shayne Fletcher
>>> | https://github.com/ghc-proposals/ghc-proposals/pull/282
>>> | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-
>>> | syntax/proposals/0000-record-dot-syntax.md
>>> |
>>> | This is going to be a tricky one. It is partly about whitespace, so it
>>> | has attracted a _lot_ of community interest, by far the most so far. To
>>> | navigate that ship, I propose Simon PJ as the shepherd, because he is a
>>> | excellent moderator and community manager, and because he has the
>>> | necessary authority to hopefully get a verdict accepted.
>>> |
>>> | 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
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From mail at joachim-breitner.de  Tue Dec 10 16:25:00 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 10 Dec 2019 17:25:00 +0100
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <83E2D220-1A50-4B37-9074-A0F77E8A00EF@seidel.io>
References: <AD85BE8B-6CBD-4B43-9766-1F97AF1B1AF0@richarde.dev>
 <83E2D220-1A50-4B37-9074-A0F77E8A00EF@seidel.io>
Message-ID: <482e1870d68dd7e3b36a9be4e3517f4854ebeec7.camel@joachim-breitner.de>

Hi,

also, thinking about it, is (\x->x.foo) too bad? At least initially?

Maybe people come up with a nice name for (\x->x.…)  (similar to “happy
monkey” for (:[]) ) then maybe they will warm up to it :-)

Cheers,
Joachim


Am Dienstag, den 10.12.2019, 11:14 -0500 schrieb Eric Seidel:
> I agree with Richard, I think it would be valuable to think of this
> as two separate proposals. 
> 
> 1. Introduce the dot syntax for projection and nested
> matching/update. Projection is written ‘foo.lbl’ (no white space
> allowed) and a bare .lbl is a syntax error. This piece seems largely
> uncontroversial. 
> 
> 2. Give a meaning to a bare ‘.lbl’. The controversy entirely
> surrounds what this form should mean. 
> 
> I think (1) is a perfectly good proposal on its own, so I’d much
> prefer us to accept (1) and defer a decision on (2) over rejecting
> the entire proposal. 
> 
> Sent from my iPhone
> 
> > On Dec 10, 2019, at 10:26, Richard Eisenberg <rae at richarde.dev> wrote:
> > 
> > Thanks for your comments!
> > 
> > > On Dec 10, 2019, at 2:54 PM, Christopher Allen <cma at bitemyapp.com> wrote:
> > > 
> > > This proposal should be rejected.
> > > 
> > > The contention over what whitespace around the dot operator should
> > > make it clear that even expert Haskellers aren't sure what to expect
> > > from this proposal in an intuitive way.
> > 
> > Then there is an easy solution: just don't allow unparenthesized .foo -- that is, make it a parse error. I don't think there is any contention over what (.foo) should mean, and if plain .foo is a parse error, then there is no fork.
> > 
> > > You can achieve the same with
> > > libraries now.
> > 
> > True -- but at significant cost, both in the effort to learn the (complex) libraries and in the need for Template Haskell, which cannot be used in cross-compilation, for example. I think the warm reception of this proposal suggests that, despite the library-based solution, something more is wanted.
> > 
> > > That the existing extensions aren't as useful as they
> > > ought as compared with using a lens library is symptomatic of
> > > half-baked proposals being incorporated into GHC.
> > 
> > I'm curious which proposals you're thinking of here. The strangest one, I think, is DisambiguateRecordFields. That was added before the proposals process. I don't think it would have survived the current process -- at least, not in the form in which it has appeared. I would welcome exploring ways of removing it.
> > 
> > > We can wait until the juice is worth the squeeze and avoid an unforced
> > > error here.
> > 
> > This is tempting. But I worry that this may be the best we get, and I think inaction is hurting us.
> > 
> > Richard
> > 
> > > > On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via
> > > > ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> > > > 
> > > > Dear steering committee
> > > > 
> > > > I'm the shepherd for the RecordDotSyntax proposal.
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/282
> > > > 
> > > > I recommend acceptance:
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691
> > > > 
> > > > Please reads the proposal, and as much of the discussion as you feel able, and respond in the next week or two to indicate your views.
> > > > 
> > > > Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion.
> > > > 
> > > > I'd love every member of the committee to express a view.  This proposal has attracted a lot of interest.
> > > > 
> > > > Thanks
> > > > 
> > > > Simon
> > > > 
> > > > > -----Original Message-----
> > > > > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> > > > > On Behalf Of Joachim Breitner
> > > > > Sent: 28 November 2019 10:11
> > > > > To: ghc-steering-committee at haskell.org
> > > > > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> > > > > RecordDotSyntax, Shepherd: Simon PJ
> > > > > 
> > > > > Dear Committee,
> > > > > 
> > > > > this is your secretary speaking:
> > > > > 
> > > > > RecordDotSyntax language extension proposal has been proposed by Neil
> > > > > Mitchell and Shayne Fletcher
> > > > > https://github.com/ghc-proposals/ghc-proposals/pull/282
> > > > > https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-
> > > > > syntax/proposals/0000-record-dot-syntax.md
> > > > > 
> > > > > This is going to be a tricky one. It is partly about whitespace, so it
> > > > > has attracted a _lot_ of community interest, by far the most so far. To
> > > > > navigate that ship, I propose Simon PJ as the shepherd, because he is a
> > > > > excellent moderator and community manager, and because he has the
> > > > > necessary authority to hopefully get a verdict accepted.
> > > > > 
> > > > > 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
> > > > _______________________________________________
> > > > 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
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From iavor.diatchki at gmail.com  Tue Dec 10 18:07:53 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 10 Dec 2019 10:07:53 -0800
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <482e1870d68dd7e3b36a9be4e3517f4854ebeec7.camel@joachim-breitner.de>
References: <AD85BE8B-6CBD-4B43-9766-1F97AF1B1AF0@richarde.dev>
 <83E2D220-1A50-4B37-9074-A0F77E8A00EF@seidel.io>
 <482e1870d68dd7e3b36a9be4e3517f4854ebeec7.camel@joachim-breitner.de>
Message-ID: <CAGK9nurwYM+opZ_0LNW9JVdkyJTYLb2P4RW_gOYWQAnTgwaPUA@mail.gmail.com>

Just wanted to chime in, that if we are to accept this, I also think that
we should use the explicit section notation for selector functions.

I don't think we should split this into multiple proposals, even though it
introduces many features.

In fact, for me, the most useful part of the proposal is the ability to do
nested updates, which is quite orthogonal to using "dot" as a selector.



On Tue, Dec 10, 2019 at 8:25 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> also, thinking about it, is (\x->x.foo) too bad? At least initially?
>
> Maybe people come up with a nice name for (\x->x.…)  (similar to “happy
> monkey” for (:[]) ) then maybe they will warm up to it :-)
>
> Cheers,
> Joachim
>
>
> Am Dienstag, den 10.12.2019, 11:14 -0500 schrieb Eric Seidel:
> > I agree with Richard, I think it would be valuable to think of this
> > as two separate proposals.
> >
> > 1. Introduce the dot syntax for projection and nested
> > matching/update. Projection is written ‘foo.lbl’ (no white space
> > allowed) and a bare .lbl is a syntax error. This piece seems largely
> > uncontroversial.
> >
> > 2. Give a meaning to a bare ‘.lbl’. The controversy entirely
> > surrounds what this form should mean.
> >
> > I think (1) is a perfectly good proposal on its own, so I’d much
> > prefer us to accept (1) and defer a decision on (2) over rejecting
> > the entire proposal.
> >
> > Sent from my iPhone
> >
> > > On Dec 10, 2019, at 10:26, Richard Eisenberg <rae at richarde.dev> wrote:
> > >
> > > Thanks for your comments!
> > >
> > > > On Dec 10, 2019, at 2:54 PM, Christopher Allen <cma at bitemyapp.com>
> wrote:
> > > >
> > > > This proposal should be rejected.
> > > >
> > > > The contention over what whitespace around the dot operator should
> > > > make it clear that even expert Haskellers aren't sure what to expect
> > > > from this proposal in an intuitive way.
> > >
> > > Then there is an easy solution: just don't allow unparenthesized .foo
> -- that is, make it a parse error. I don't think there is any contention
> over what (.foo) should mean, and if plain .foo is a parse error, then
> there is no fork.
> > >
> > > > You can achieve the same with
> > > > libraries now.
> > >
> > > True -- but at significant cost, both in the effort to learn the
> (complex) libraries and in the need for Template Haskell, which cannot be
> used in cross-compilation, for example. I think the warm reception of this
> proposal suggests that, despite the library-based solution, something more
> is wanted.
> > >
> > > > That the existing extensions aren't as useful as they
> > > > ought as compared with using a lens library is symptomatic of
> > > > half-baked proposals being incorporated into GHC.
> > >
> > > I'm curious which proposals you're thinking of here. The strangest
> one, I think, is DisambiguateRecordFields. That was added before the
> proposals process. I don't think it would have survived the current process
> -- at least, not in the form in which it has appeared. I would welcome
> exploring ways of removing it.
> > >
> > > > We can wait until the juice is worth the squeeze and avoid an
> unforced
> > > > error here.
> > >
> > > This is tempting. But I worry that this may be the best we get, and I
> think inaction is hurting us.
> > >
> > > Richard
> > >
> > > > > On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via
> > > > > ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> > > > >
> > > > > Dear steering committee
> > > > >
> > > > > I'm the shepherd for the RecordDotSyntax proposal.
> > > > > https://github.com/ghc-proposals/ghc-proposals/pull/282
> > > > >
> > > > > I recommend acceptance:
> > > > >
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691
> > > > >
> > > > > Please reads the proposal, and as much of the discussion as you
> feel able, and respond in the next week or two to indicate your views.
> > > > >
> > > > > Remember: ask technical questions on the Github discussion thread,
> and use this mailing list for more evaluative discussion of judgement or
> opinion.
> > > > >
> > > > > I'd love every member of the committee to express a view.  This
> proposal has attracted a lot of interest.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Simon
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org>
> > > > > > On Behalf Of Joachim Breitner
> > > > > > Sent: 28 November 2019 10:11
> > > > > > To: ghc-steering-committee at haskell.org
> > > > > > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> > > > > > RecordDotSyntax, Shepherd: Simon PJ
> > > > > >
> > > > > > Dear Committee,
> > > > > >
> > > > > > this is your secretary speaking:
> > > > > >
> > > > > > RecordDotSyntax language extension proposal has been proposed by
> Neil
> > > > > > Mitchell and Shayne Fletcher
> > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/282
> > > > > >
> https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-
> > > > > > syntax/proposals/0000-record-dot-syntax.md
> > > > > >
> > > > > > This is going to be a tricky one. It is partly about whitespace,
> so it
> > > > > > has attracted a _lot_ of community interest, by far the most so
> far. To
> > > > > > navigate that ship, I propose Simon PJ as the shepherd, because
> he is a
> > > > > > excellent moderator and community manager, and because he has the
> > > > > > necessary authority to hopefully get a verdict accepted.
> > > > > >
> > > > > > 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
> > > > > _______________________________________________
> > > > > 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
> > > > _______________________________________________
> > > > 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/20191210/7c46329a/attachment-0001.html>

From arnaud.spiwack at tweag.io  Tue Dec 10 18:16:40 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 10 Dec 2019 19:16:40 +0100
Subject: [ghc-steering-committee] #301: Rename PtrRep to BoxedRep,
 recommending: accept
In-Reply-To: <CADnndOrLbCpNFgpCEdSCHdoqPqHQqSXT=ftTLGPurHrb0OADjA@mail.gmail.com>
References: <138e6484b66c931c4e121171e9030a411606cc20.camel@joachim-breitner.de>
 <CADnndOrLbCpNFgpCEdSCHdoqPqHQqSXT=ftTLGPurHrb0OADjA@mail.gmail.com>
Message-ID: <CAH6fHQkVXuSE-8a5A=Df0eUPHef97QPeEBa-pa2BsWFof0-GiQ@mail.gmail.com>

I have no opinion either way.

On Tue, Dec 10, 2019 at 3:56 PM Christopher Allen <cma at bitemyapp.com> wrote:

> Seems more clear. In favor.
>
> On Tue, Dec 10, 2019 at 6:56 AM Joachim Breitner
> <mail at joachim-breitner.de> wrote:
> >
> > Dear Committee,
> >
> > this is your secretary speaking:
> >
> > Rename PtrRep to BoxedRep
> > has been proposed by Neil Andrew Martin
> > https://github.com/ghc-proposals/ghc-proposals/pull/301
> >
> > I’ll shepherd that myself.
> >
> > It’s a simple renaming in an existing proposal, clarifying a somewhat
> > misleading name (PtrRep) to a more precise one (BoxedRep). This looks
> > reasonable and helpful, so I am happy to propose acceptance.
> >
> > Any objections?
> >
> >
> >
> > 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
> _______________________________________________
> 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/20191210/c4a60781/attachment.html>

From simonpj at microsoft.com  Tue Dec 10 22:25:18 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 Dec 2019 22:25:18 +0000
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <CAGK9nurwYM+opZ_0LNW9JVdkyJTYLb2P4RW_gOYWQAnTgwaPUA@mail.gmail.com>
References: <AD85BE8B-6CBD-4B43-9766-1F97AF1B1AF0@richarde.dev>
 <83E2D220-1A50-4B37-9074-A0F77E8A00EF@seidel.io>
 <482e1870d68dd7e3b36a9be4e3517f4854ebeec7.camel@joachim-breitner.de>
 <CAGK9nurwYM+opZ_0LNW9JVdkyJTYLb2P4RW_gOYWQAnTgwaPUA@mail.gmail.com>
Message-ID: <HE1PR8303MB008927319BF41BDA1067B671AD5B0@HE1PR8303MB0089.EURPRD83.prod.outlook.com>

Just wanted to chime in, that if we are to accept this, I also think that we should use the explicit section notation for selector functions.
To be clear,  you prefer that (.foo) is the selector function, and .foo (sans parens) is illegal?  Or do you have something else in mind for .foo?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 10 December 2019 18:08
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] RecordDotSyntax: please express a view

Just wanted to chime in, that if we are to accept this, I also think that we should use the explicit section notation for selector functions.

I don't think we should split this into multiple proposals, even though it introduces many features.

In fact, for me, the most useful part of the proposal is the ability to do nested updates, which is quite orthogonal to using "dot" as a selector.



On Tue, Dec 10, 2019 at 8:25 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,

also, thinking about it, is (\x->x.foo) too bad? At least initially?

Maybe people come up with a nice name for (\x->x.…)  (similar to “happy
monkey” for (:[]) ) then maybe they will warm up to it :-)

Cheers,
Joachim


Am Dienstag, den 10.12.2019, 11:14 -0500 schrieb Eric Seidel:
> I agree with Richard, I think it would be valuable to think of this
> as two separate proposals.
>
> 1. Introduce the dot syntax for projection and nested
> matching/update. Projection is written ‘foo.lbl’ (no white space
> allowed) and a bare .lbl is a syntax error. This piece seems largely
> uncontroversial.
>
> 2. Give a meaning to a bare ‘.lbl’. The controversy entirely
> surrounds what this form should mean.
>
> I think (1) is a perfectly good proposal on its own, so I’d much
> prefer us to accept (1) and defer a decision on (2) over rejecting
> the entire proposal.
>
> Sent from my iPhone
>
> > On Dec 10, 2019, at 10:26, Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:
> >
> > Thanks for your comments!
> >
> > > On Dec 10, 2019, at 2:54 PM, Christopher Allen <cma at bitemyapp.com<mailto:cma at bitemyapp.com>> wrote:
> > >
> > > This proposal should be rejected.
> > >
> > > The contention over what whitespace around the dot operator should
> > > make it clear that even expert Haskellers aren't sure what to expect
> > > from this proposal in an intuitive way.
> >
> > Then there is an easy solution: just don't allow unparenthesized .foo -- that is, make it a parse error. I don't think there is any contention over what (.foo) should mean, and if plain .foo is a parse error, then there is no fork.
> >
> > > You can achieve the same with
> > > libraries now.
> >
> > True -- but at significant cost, both in the effort to learn the (complex) libraries and in the need for Template Haskell, which cannot be used in cross-compilation, for example. I think the warm reception of this proposal suggests that, despite the library-based solution, something more is wanted.
> >
> > > That the existing extensions aren't as useful as they
> > > ought as compared with using a lens library is symptomatic of
> > > half-baked proposals being incorporated into GHC.
> >
> > I'm curious which proposals you're thinking of here. The strangest one, I think, is DisambiguateRecordFields. That was added before the proposals process. I don't think it would have survived the current process -- at least, not in the form in which it has appeared. I would welcome exploring ways of removing it.
> >
> > > We can wait until the juice is worth the squeeze and avoid an unforced
> > > error here.
> >
> > This is tempting. But I worry that this may be the best we get, and I think inaction is hurting us.
> >
> > Richard
> >
> > > > On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via
> > > > ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
> > > >
> > > > Dear steering committee
> > > >
> > > > I'm the shepherd for the RecordDotSyntax proposal.
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/282<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021935354&sdata=YMrBWZyrnmy%2FcJ2e5x3TAmvTo7DQamaxZu5IQzkRPS8%3D&reserved=0>
> > > >
> > > > I recommend acceptance:
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282%23issuecomment-563477691&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021935354&sdata=MLMWuA10JgKqndNIg2gufvvsuMxtKLTiOzHZOBScsLc%3D&reserved=0>
> > > >
> > > > Please reads the proposal, and as much of the discussion as you feel able, and respond in the next week or two to indicate your views.
> > > >
> > > > Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion.
> > > >
> > > > I'd love every member of the committee to express a view.  This proposal has attracted a lot of interest.
> > > >
> > > > Thanks
> > > >
> > > > Simon
> > > >
> > > > > -----Original Message-----
> > > > > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>>
> > > > > On Behalf Of Joachim Breitner
> > > > > Sent: 28 November 2019 10:11
> > > > > To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> > > > > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> > > > > RecordDotSyntax, Shepherd: Simon PJ
> > > > >
> > > > > Dear Committee,
> > > > >
> > > > > this is your secretary speaking:
> > > > >
> > > > > RecordDotSyntax language extension proposal has been proposed by Neil
> > > > > Mitchell and Shayne Fletcher
> > > > > https://github.com/ghc-proposals/ghc-proposals/pull/282<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021945348&sdata=seXtl%2FufSwR3Yx6O1KdRNTL9jn9Gdh378Dh69czXORo%3D&reserved=0>
> > > > > https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021955345&sdata=zc73B6VSW9yzhUlwPU7vcTVb115ZSMoOE%2FDa0APlDhE%3D&reserved=0>
> > > > > syntax/proposals/0000-record-dot-syntax.md
> > > > >
> > > > > This is going to be a tricky one. It is partly about whitespace, so it
> > > > > has attracted a _lot_ of community interest, by far the most so far. To
> > > > > navigate that ship, I propose Simon PJ as the shepherd, because he is a
> > > > > excellent moderator and community manager, and because he has the
> > > > > necessary authority to hopefully get a verdict accepted.
> > > > >
> > > > > Please reach consensus as described in
> > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021955345&sdata=SrIQa28Rtyx7evKGUK850hI8banF7HDEiMZ%2FJjShEC4%3D&reserved=0>
> > > > > 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<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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021965332&sdata=n195w9oPoKziOv7zBQ6KpPoi3NRwXYe%2BbzSxl%2FUlo1Q%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021975327&sdata=2GxTlecHJQEngX7dEd7RXbqU%2FcOud%2BuuqacsrPTdkZE%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021975327&sdata=2GxTlecHJQEngX7dEd7RXbqU%2FcOud%2BuuqacsrPTdkZE%3D&reserved=0>
> > >
> > >
> > > --
> > > Chris Allen
> > > Currently working on http://haskellbook.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021985324&sdata=6LiqHhWXBwozb2Tsdmu0XF93XzNrCUf3tZEqHGa%2BqjQ%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021985324&sdata=j9JRF42QBPvEWM4ZF0quDoPFRr1TgCN2GPBXgWNKMa8%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021995336&sdata=ask0ZPCDBtLB6XkE3BeeFuTE2%2Be0QOcgkifDpNDhC7E%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022005321&sdata=Z898U%2B2wyaLpqEoSwQ8RBjgxiGkQfSoiCPL2Ftki2OE%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022005321&sdata=Xnqi8KguWWaNazTwElo1qfddKAyEAJR9n1UmPZ3rqk8%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022015315&sdata=qJuM%2FqqR3gFjlHh2u00murQ3Xf64n9vactZht19lDSI%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191210/0814b2c9/attachment-0001.html>

From simonpj at microsoft.com  Tue Dec 10 22:46:15 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 Dec 2019 22:46:15 +0000
Subject: [ghc-steering-committee] Stepping down
In-Reply-To: <CADRtjwaUP88jnwUsPEw5OW66RWvz3p8bVo=J0J6vZaMNvxn_RA@mail.gmail.com>
References: <CADRtjwaUP88jnwUsPEw5OW66RWvz3p8bVo=J0J6vZaMNvxn_RA@mail.gmail.com>
Message-ID: <HE1PR8303MB00898F4D350A51BE8E9BBF3CAD5B0@HE1PR8303MB0089.EURPRD83.prod.outlook.com>

Dear Sandy,

I’m very sorry to see you go.  Thank you for your steady contribution to the Haskell community, and in particular to the GHC steering group.

Thanks too for your suggestions of Chris and Tom; that too is most helpful.

With thanks and warm good wishes

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Sandy Maguire
Sent: 08 December 2019 05:43
To: Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>
Cc: christopher.penner at gmail.com; tomjharding at live.co.uk
Subject: [ghc-steering-committee] Stepping down

Hi all,
Regrettably, I've decided to step down from the steering committee. My heart simply isn't in Haskell these days, and I'd prefer to give up my membership to someone more capable of doing good with it.
For my replacement, I'd like to nominate Tom Harding and Chris Penner (both cc'd). I don't know of anyone else in the community who is as smart or dedicated as these two. Both have solid industrial credentials to help diversify the otherwise academic committee. The community at large would be very lucky to have either of them helping to steer.
It's been an honour to serve with you all.
Best,
Sandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191210/a9bf3e7d/attachment.html>

From mail at joachim-breitner.de  Tue Dec 10 23:21:16 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 11 Dec 2019 00:21:16 +0100
Subject: [ghc-steering-committee] New member process
In-Reply-To: <HE1PR8303MB00898F4D350A51BE8E9BBF3CAD5B0@HE1PR8303MB0089.EURPRD83.prod.outlook.com>
References: <CADRtjwaUP88jnwUsPEw5OW66RWvz3p8bVo=J0J6vZaMNvxn_RA@mail.gmail.com>
 <HE1PR8303MB00898F4D350A51BE8E9BBF3CAD5B0@HE1PR8303MB0089.EURPRD83.prod.outlook.com>
Message-ID: <40fb39628f7d56630038946ec89be0956cdcb391.camel@joachim-breitner.de>

Hi,

I too am sorry to see Sandy leave us again, I wish we had more of his
contributions, which I found valuable.

So it seems we have a slot to fill. Same procedure as last time? Or any
tweaks wanted?

This was the last announcement:
https://mail.haskell.org/pipermail/ghc-steering-committee/2019-June/001121.html


Not sure if Christmas is the best time to ask for nominations. Or maybe
it is precisely the best time? 

Cheers,
Joachim



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


From iavor.diatchki at gmail.com  Tue Dec 10 23:36:29 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 10 Dec 2019 15:36:29 -0800
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <HE1PR8303MB008927319BF41BDA1067B671AD5B0@HE1PR8303MB0089.EURPRD83.prod.outlook.com>
References: <AD85BE8B-6CBD-4B43-9766-1F97AF1B1AF0@richarde.dev>
 <83E2D220-1A50-4B37-9074-A0F77E8A00EF@seidel.io>
 <482e1870d68dd7e3b36a9be4e3517f4854ebeec7.camel@joachim-breitner.de>
 <CAGK9nurwYM+opZ_0LNW9JVdkyJTYLb2P4RW_gOYWQAnTgwaPUA@mail.gmail.com>
 <HE1PR8303MB008927319BF41BDA1067B671AD5B0@HE1PR8303MB0089.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuoGT-vg=_SrgYgCwGZ39vSB44FjCnGj1w6pMb9BLCVFWg@mail.gmail.com>

I am not really sure what to do with `.foo` on its own.  Probably simplest
to just make it into a syntax error.




On Tue, Dec 10, 2019 at 2:25 PM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Just wanted to chime in, that if we are to accept this, I also think that
> we should use the explicit section notation for selector functions.
>
> To be clear,  you prefer that (.foo) is the selector function, and .foo
> (sans parens) is illegal?  Or do you have something else in mind for .foo?
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Iavor Diatchki
> *Sent:* 10 December 2019 18:08
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] RecordDotSyntax: please express a
> view
>
>
>
> Just wanted to chime in, that if we are to accept this, I also think that
> we should use the explicit section notation for selector functions.
>
>
>
> I don't think we should split this into multiple proposals, even though it
> introduces many features.
>
>
>
> In fact, for me, the most useful part of the proposal is the ability to do
> nested updates, which is quite orthogonal to using "dot" as a selector.
>
>
>
>
>
>
>
> On Tue, Dec 10, 2019 at 8:25 AM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi,
>
> also, thinking about it, is (\x->x.foo) too bad? At least initially?
>
> Maybe people come up with a nice name for (\x->x.…)  (similar to “happy
> monkey” for (:[]) ) then maybe they will warm up to it :-)
>
> Cheers,
> Joachim
>
>
> Am Dienstag, den 10.12.2019, 11:14 -0500 schrieb Eric Seidel:
> > I agree with Richard, I think it would be valuable to think of this
> > as two separate proposals.
> >
> > 1. Introduce the dot syntax for projection and nested
> > matching/update. Projection is written ‘foo.lbl’ (no white space
> > allowed) and a bare .lbl is a syntax error. This piece seems largely
> > uncontroversial.
> >
> > 2. Give a meaning to a bare ‘.lbl’. The controversy entirely
> > surrounds what this form should mean.
> >
> > I think (1) is a perfectly good proposal on its own, so I’d much
> > prefer us to accept (1) and defer a decision on (2) over rejecting
> > the entire proposal.
> >
> > Sent from my iPhone
> >
> > > On Dec 10, 2019, at 10:26, Richard Eisenberg <rae at richarde.dev> wrote:
> > >
> > > Thanks for your comments!
> > >
> > > > On Dec 10, 2019, at 2:54 PM, Christopher Allen <cma at bitemyapp.com>
> wrote:
> > > >
> > > > This proposal should be rejected.
> > > >
> > > > The contention over what whitespace around the dot operator should
> > > > make it clear that even expert Haskellers aren't sure what to expect
> > > > from this proposal in an intuitive way.
> > >
> > > Then there is an easy solution: just don't allow unparenthesized .foo
> -- that is, make it a parse error. I don't think there is any contention
> over what (.foo) should mean, and if plain .foo is a parse error, then
> there is no fork.
> > >
> > > > You can achieve the same with
> > > > libraries now.
> > >
> > > True -- but at significant cost, both in the effort to learn the
> (complex) libraries and in the need for Template Haskell, which cannot be
> used in cross-compilation, for example. I think the warm reception of this
> proposal suggests that, despite the library-based solution, something more
> is wanted.
> > >
> > > > That the existing extensions aren't as useful as they
> > > > ought as compared with using a lens library is symptomatic of
> > > > half-baked proposals being incorporated into GHC.
> > >
> > > I'm curious which proposals you're thinking of here. The strangest
> one, I think, is DisambiguateRecordFields. That was added before the
> proposals process. I don't think it would have survived the current process
> -- at least, not in the form in which it has appeared. I would welcome
> exploring ways of removing it.
> > >
> > > > We can wait until the juice is worth the squeeze and avoid an
> unforced
> > > > error here.
> > >
> > > This is tempting. But I worry that this may be the best we get, and I
> think inaction is hurting us.
> > >
> > > Richard
> > >
> > > > > On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via
> > > > > ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> > > > >
> > > > > Dear steering committee
> > > > >
> > > > > I'm the shepherd for the RecordDotSyntax proposal.
> > > > > https://github.com/ghc-proposals/ghc-proposals/pull/282
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021935354&sdata=YMrBWZyrnmy%2FcJ2e5x3TAmvTo7DQamaxZu5IQzkRPS8%3D&reserved=0>
> > > > >
> > > > > I recommend acceptance:
> > > > >
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282%23issuecomment-563477691&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021935354&sdata=MLMWuA10JgKqndNIg2gufvvsuMxtKLTiOzHZOBScsLc%3D&reserved=0>
> > > > >
> > > > > Please reads the proposal, and as much of the discussion as you
> feel able, and respond in the next week or two to indicate your views.
> > > > >
> > > > > Remember: ask technical questions on the Github discussion thread,
> and use this mailing list for more evaluative discussion of judgement or
> opinion.
> > > > >
> > > > > I'd love every member of the committee to express a view.  This
> proposal has attracted a lot of interest.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Simon
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org>
> > > > > > On Behalf Of Joachim Breitner
> > > > > > Sent: 28 November 2019 10:11
> > > > > > To: ghc-steering-committee at haskell.org
> > > > > > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> > > > > > RecordDotSyntax, Shepherd: Simon PJ
> > > > > >
> > > > > > Dear Committee,
> > > > > >
> > > > > > this is your secretary speaking:
> > > > > >
> > > > > > RecordDotSyntax language extension proposal has been proposed by
> Neil
> > > > > > Mitchell and Shayne Fletcher
> > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/282
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021945348&sdata=seXtl%2FufSwR3Yx6O1KdRNTL9jn9Gdh378Dh69czXORo%3D&reserved=0>
> > > > > >
> https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021955345&sdata=zc73B6VSW9yzhUlwPU7vcTVb115ZSMoOE%2FDa0APlDhE%3D&reserved=0>
> > > > > > syntax/proposals/0000-record-dot-syntax.md
> > > > > >
> > > > > > This is going to be a tricky one. It is partly about whitespace,
> so it
> > > > > > has attracted a _lot_ of community interest, by far the most so
> far. To
> > > > > > navigate that ship, I propose Simon PJ as the shepherd, because
> he is a
> > > > > > excellent moderator and community manager, and because he has the
> > > > > > necessary authority to hopefully get a verdict accepted.
> > > > > >
> > > > > > Please reach consensus as described in
> > > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021955345&sdata=SrIQa28Rtyx7evKGUK850hI8banF7HDEiMZ%2FJjShEC4%3D&reserved=0>
> > > > > > 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/
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021965332&sdata=n195w9oPoKziOv7zBQ6KpPoi3NRwXYe%2BbzSxl%2FUlo1Q%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021975327&sdata=2GxTlecHJQEngX7dEd7RXbqU%2FcOud%2BuuqacsrPTdkZE%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021975327&sdata=2GxTlecHJQEngX7dEd7RXbqU%2FcOud%2BuuqacsrPTdkZE%3D&reserved=0>
> > > >
> > > >
> > > > --
> > > > Chris Allen
> > > > Currently working on http://haskellbook.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021985324&sdata=6LiqHhWXBwozb2Tsdmu0XF93XzNrCUf3tZEqHGa%2BqjQ%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021985324&sdata=j9JRF42QBPvEWM4ZF0quDoPFRr1TgCN2GPBXgWNKMa8%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021995336&sdata=ask0ZPCDBtLB6XkE3BeeFuTE2%2Be0QOcgkifDpNDhC7E%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022005321&sdata=Z898U%2B2wyaLpqEoSwQ8RBjgxiGkQfSoiCPL2Ftki2OE%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022005321&sdata=Xnqi8KguWWaNazTwElo1qfddKAyEAJR9n1UmPZ3rqk8%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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022015315&sdata=qJuM%2FqqR3gFjlHh2u00murQ3Xf64n9vactZht19lDSI%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191210/d88de122/attachment-0001.html>

From eric at seidel.io  Wed Dec 11 03:27:57 2019
From: eric at seidel.io (Eric Seidel)
Date: Tue, 10 Dec 2019 22:27:57 -0500
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
 <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <df4411d4-6a1d-45f0-9591-af35b5edab9c@www.fastmail.com>

On Tue, Dec 10, 2019, at 09:27, Simon Peyton Jones via ghc-steering-committee wrote:
> You may be arguing that naked `.x` is a *postfix operator*, rather like 
> factorial when we write 5!.  

I brought this up at some point during the discussion. Treating a bare `.x` as a postfix operator feels very natural to me, and then `(.x)` would be a natural way to refer to the operator itself.

I'm not at all sure what the precedence of such an operator should be, however. When I see an example like

> 	f a .b c .d e

I want to parse it (if at all) as

> 	f (a .b) (c .d) e

rather than

> 	((f a).b c).d e

However, when confronted with

>   xs  .map double
>       .filter isEven
>       .map square

I instinctively want to flip the precedences and parse it as

>   (((xs.map) double).filter isEven).map square

What a difference some newlines (or is it the real names?) makes! 

Perhaps some more examples will be instructive. Another example that came up was deeply nested field accesses that don't fit onto a single line.

>  x.foo
>   .bar
>   .baz

This will be parsed as

> ((x.foo).bar).baz

regardless of precedence, as there is no function application. What if we add one?

>  f x.foo
>     .bar
>     .baz

If function application binds more tightly than field selection, this would parse as

> ((f x.foo).bar).baz

If you instead wanted

> f (x.foo.bar.baz)

you could add parens

>  f (x.foo
>      .bar
>      .baz)

which still looks reasonable to me.

So I think I would be happy with bare `.lbl` being a postfix operator that binds less tightly than function application.

From rae at richarde.dev  Wed Dec 11 09:03:35 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 11 Dec 2019 09:03:35 +0000
Subject: [ghc-steering-committee] New member process
In-Reply-To: <40fb39628f7d56630038946ec89be0956cdcb391.camel@joachim-breitner.de>
References: <CADRtjwaUP88jnwUsPEw5OW66RWvz3p8bVo=J0J6vZaMNvxn_RA@mail.gmail.com>
 <HE1PR8303MB00898F4D350A51BE8E9BBF3CAD5B0@HE1PR8303MB0089.EURPRD83.prod.outlook.com>
 <40fb39628f7d56630038946ec89be0956cdcb391.camel@joachim-breitner.de>
Message-ID: <19A7E1D6-A789-4921-9CD4-451F97CDBB98@richarde.dev>



> On Dec 10, 2019, at 11:21 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> So it seems we have a slot to fill. Same procedure as last time? Or any
> tweaks wanted?

I'm happy with the old process. I do think we should explicitly reach out to the two people that Sandy nominated, after the general call. Those two would then go through the same process as anyone else.
> 
> 
> Not sure if Christmas is the best time to ask for nominations. Or maybe
> it is precisely the best time? 

Hard to say. But if previous calls have not been at Christmas, then maybe a call at Christmas might reach different people. I don't think we should engineer around this... except perhaps to allow more time, not counting the week between Christmas and New Years.

Richard

From rae at richarde.dev  Wed Dec 11 09:11:19 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 11 Dec 2019 09:11:19 +0000
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <df4411d4-6a1d-45f0-9591-af35b5edab9c@www.fastmail.com>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
 <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <df4411d4-6a1d-45f0-9591-af35b5edab9c@www.fastmail.com>
Message-ID: <E25BF1F4-7F90-4E35-8058-B2979445863F@richarde.dev>



> On Dec 11, 2019, at 3:27 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> So I think I would be happy with bare `.lbl` being a postfix operator that binds less tightly than function application.

This means that `f x .bar` is `(f x) .bar` while `f x.bar` is `f (x.bar)`. A bit too subtle for me.

Another alternative is to make `.foo` a postfix operator that does not associate with function application. That is, `f x .bar` would be a parse error. So we can write `x .foo .bar` to mean the same as `x.foo.bar`, but we don't have to commit to any strange parsing rules around `f a .b c .d e`.

But I'm starting to lean toward just making bare `.foo` a syntax error and revisit this debate with more experience.

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

From simonpj at microsoft.com  Wed Dec 11 09:37:34 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 11 Dec 2019 09:37:34 +0000
Subject: [ghc-steering-committee] New member process
In-Reply-To: <40fb39628f7d56630038946ec89be0956cdcb391.camel@joachim-breitner.de>
References: <CADRtjwaUP88jnwUsPEw5OW66RWvz3p8bVo=J0J6vZaMNvxn_RA@mail.gmail.com>
 <HE1PR8303MB00898F4D350A51BE8E9BBF3CAD5B0@HE1PR8303MB0089.EURPRD83.prod.outlook.com>
 <40fb39628f7d56630038946ec89be0956cdcb391.camel@joachim-breitner.de>
Message-ID: <HE1PR8303MB0089CB91CFED8B3F859598D1AD5A0@HE1PR8303MB0089.EURPRD83.prod.outlook.com>

I think

* Same procedure as last time
* Give some extra time over Xmas
* Let's encourage the two that Sandy recommended to self-nominate,
  or (even better) encourage Sandy to nominate them.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 10 December 2019 23:21
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] New member process
|  
|  Hi,
|  
|  I too am sorry to see Sandy leave us again, I wish we had more of his
|  contributions, which I found valuable.
|  
|  So it seems we have a slot to fill. Same procedure as last time? Or
|  any
|  tweaks wanted?
|  
|  This was the last announcement:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fpipermail%2Fghc-steering-committee%2F2019-
|  June%2F001121.html&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C66445f
|  af22134c9e6ae408d77dc7af81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
|  7C637116168911648772&amp;sdata=UQNGJYgsYwrH4hEMEr%2FVhSJ7DzU8D17ie4PkM
|  WyTYGA%3D&amp;reserved=0
|  
|  
|  Not sure if Christmas is the best time to ask for nominations. Or
|  maybe
|  it is precisely the best time?
|  
|  Cheers,
|  Joachim
|  
|  
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C66445faf22
|  134c9e6ae408d77dc7af81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7116168911648772&amp;sdata=tqNsg4N6Ci2GXkA1VPd72Q8VNtiA1eGXq%2FUIsjSWa
|  GI%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%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C66445faf22134c9
|  e6ae408d77dc7af81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371161
|  68911648772&amp;sdata=XuIJA3ki2qvGeTMI62592FMjA%2FbMv1BaArqPdzZfrYo%3D
|  &amp;reserved=0

From mail at joachim-breitner.de  Wed Dec 11 10:10:10 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 11 Dec 2019 11:10:10 +0100
Subject: [ghc-steering-committee] Request for Nominations to the GHC
	Steering Committee
Message-ID: <c5ff9334a703bbad7c68860798686ca27c4921cb.camel@joachim-breitner.de>

Dear Haskell community,

the GHC Steering committee is seeking nominations for one new member.

The committee scrutinizes, nitpicks, improves, weights and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC.
Our processes are described at
   https://github.com/ghc-proposals/ghc-proposals
which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability 
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and 
   specifications,
 * comment constructively and improve the proposals,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

We look for committee members who have some of these properties:
 * have substantial experience in writing Haskell applications or
   libraries, which they can use to inform judgements about the
   utility or otherwise of proposed features,
 * have made active contributions to the Haskell community, for
   some time,
 * have expertise in language design and implementation, in either
   Haskell or related languages, which they can share with us.

The committee’s work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. We
estimate the workload to be around 2 hours per week, and our process
works best if members usually respond to technical emails within 1-2
weeks (within days is even better). Please keep that in mind if your
email inbox is already overflowing.

The GHC developers themselves are already well represented already.  We
seek Haskell _users_ more than GHC hackers.

There is no shortage of people who are eager to get fancy new
features into the language, both in the committee and the wider
community. But each new feature imposes a cost, to implement, to learn,
(particularly) through its unexpected interaction with other features.
We need to strike a balance, one that encourages innovation (as GHC
always has) while still making Haskell attractive for real-world
production use and for teaching. We therefore explicitly invite
“conservative” members of the community to join the committee.

To make a nomination, please send an email to me (as the committee
secretary) at mail at joachim-breitner.de until January 2nd. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

We explicitly encourage self-nominations. You can nominate others, but
please obtain their explicit consent to do so. (We don’t want to choose
someone who turns out to be unable to serve.)

On behalf of the committee,
Joachim Breitner

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


From marlowsd at gmail.com  Thu Dec 12 08:12:29 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 12 Dec 2019 08:12:29 +0000
Subject: [ghc-steering-committee] Stepping down
In-Reply-To: <HE1PR8303MB00898F4D350A51BE8E9BBF3CAD5B0@HE1PR8303MB0089.EURPRD83.prod.outlook.com>
References: <CADRtjwaUP88jnwUsPEw5OW66RWvz3p8bVo=J0J6vZaMNvxn_RA@mail.gmail.com>
 <HE1PR8303MB00898F4D350A51BE8E9BBF3CAD5B0@HE1PR8303MB0089.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgPK0+LKOZq2ptL+D1kvio3r6JjNVmG9mx3dokAY-2_OvQA@mail.gmail.com>

Seconded; many thanks Sandy.

Simon

On Tue, 10 Dec 2019 at 22:46, Simon Peyton Jones via ghc-steering-committee
<ghc-steering-committee at haskell.org> wrote:

> Dear Sandy,
>
>
>
> I’m very sorry to see you go.  Thank you for your steady contribution to
> the Haskell community, and in particular to the GHC steering group.
>
>
>
> Thanks too for your suggestions of Chris and Tom; that too is most helpful.
>
>
>
> With thanks and warm good wishes
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Sandy Maguire
> *Sent:* 08 December 2019 05:43
> *To:* Simon Peyton Jones via ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> *Cc:* christopher.penner at gmail.com; tomjharding at live.co.uk
> *Subject:* [ghc-steering-committee] Stepping down
>
>
>
> Hi all,
>
> Regrettably, I've decided to step down from the steering committee. My
> heart simply isn't in Haskell these days, and I'd prefer to give up my
> membership to someone more capable of doing good with it.
>
> For my replacement, I'd like to nominate Tom Harding and Chris Penner
> (both cc'd). I don't know of anyone else in the community who is as smart
> or dedicated as these two. Both have solid industrial credentials to help
> diversify the otherwise academic committee. The community at large would be
> very lucky to have either of them helping to steer.
>
> It's been an honour to serve with you all.
>
> Best,
>
> Sandy
> _______________________________________________
> 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/20191212/37c69ead/attachment.html>

From marlowsd at gmail.com  Thu Dec 12 08:40:48 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 12 Dec 2019 08:40:48 +0000
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgPKpPmrbDTEHYjCo2mqE1usjoFd+b7=5PjRmnAWvOrz59Q@mail.gmail.com>

I'm not a huge fan of this proposal mostly due to the confusion it
introduces between "a . b" and "a.b". However we already decided we didn't
care too much about that when we introduced qualified names, so I think
that ship has sailed. (In fact I'd rather like us to pick a different
symbol for function composition, heretical a suggestion as that may be,
given that we've effectively deprecated the significance . as function
composition by introducing two more meanings for it).

So to be clear, I am weakly in favour of acceptance.

I would much prefer (.foo) to .foo for the standalone selector syntax,
though.

Cheers
Simon

On Mon, 9 Dec 2019 at 22:58, Simon Peyton Jones via ghc-steering-committee <
ghc-steering-committee at haskell.org> wrote:

> Dear steering committee
>
> I'm the shepherd for the RecordDotSyntax proposal.
>   https://github.com/ghc-proposals/ghc-proposals/pull/282
>
> I recommend acceptance:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691
>
> Please reads the proposal, and as much of the discussion as you feel able,
> and respond in the next week or two to indicate your views.
>
> Remember: ask technical questions on the Github discussion thread, and use
> this mailing list for more evaluative discussion of judgement or opinion.
>
> I'd love every member of the committee to express a view.  This proposal
> has attracted a lot of interest.
>
> Thanks
>
> Simon
>
> | -----Original Message-----
> | From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org
> >
> | On Behalf Of Joachim Breitner
> | Sent: 28 November 2019 10:11
> | To: ghc-steering-committee at haskell.org
> | Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> | RecordDotSyntax, Shepherd: Simon PJ
> |
> | Dear Committee,
> |
> | this is your secretary speaking:
> |
> | RecordDotSyntax language extension proposal has been proposed by Neil
> | Mitchell and Shayne Fletcher
> | https://github.com/ghc-proposals/ghc-proposals/pull/282
> | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-
> | syntax/proposals/0000-record-dot-syntax.md
> |
> | This is going to be a tricky one. It is partly about whitespace, so it
> | has attracted a _lot_ of community interest, by far the most so far. To
> | navigate that ship, I propose Simon PJ as the shepherd, because he is a
> | excellent moderator and community manager, and because he has the
> | necessary authority to hopefully get a verdict accepted.
> |
> | 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
> _______________________________________________
> 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/20191212/bcde9730/attachment.html>

From arnaud.spiwack at tweag.io  Thu Dec 12 09:04:31 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 12 Dec 2019 10:04:31 +0100
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <E25BF1F4-7F90-4E35-8058-B2979445863F@richarde.dev>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
 <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <df4411d4-6a1d-45f0-9591-af35b5edab9c@www.fastmail.com>
 <E25BF1F4-7F90-4E35-8058-B2979445863F@richarde.dev>
Message-ID: <CAH6fHQnT42N4diWQ96P5EMxKFkuFEYwCijxptct671iVztbryg@mail.gmail.com>

I'm having most trouble forming an opinion on this.

Let me try to formulate my thoughts

This proposal solves

1. A dot syntax for record selector
2. A nested record update syntax
3. Shared record field names

This proposal doesn't address

4. Partial selection
5. Partial update

This proposal breaks

6. Type-changing record update
7. Polymorphic (rank 2+) fields

Does it balance out?

1. is nice, but honestly pretty trivial. The real reason for 1, though, is
to enable 3.
2. is pretty cool. When you need nested update, not having syntax for it is
pretty painful. It seems to be an oft repeated reason why Haskell records
“suck”. That being said, how many languages don't have nested update, and
of these do people complain about records “sucking”. As an example, Ocaml
doesn't have nested updates, and Ocaml programmers don't complain about
records. Still, pretty cool.
3. again a common complaint about Haskell records. In this respect this
proposal can be seen as an improvement on what's already been done in
-XDuplicateRecordFields (I don't have much of an experience with
-XDuplicateRecordFields, but I believe it's an improvement); or a way to
use -XNoFieldSelectors without resorting to lenses. To draw a comparison
with Ocaml, again: shared record fields are a reasonably recent feature
there too; it was welcome, but rather as fixing a minor inconvenience
(programmers just namespaced their record fields). Maybe they are more
pressing in Haskell because namespacing is less convenient. I'm not sure
4. is a rather unfortunate behaviour of Haskell's record semantic. It's not
too hard to avoid its pitfalls, so it's ok
5. is more problematic. In fact, before this whole conversation started, if
someone had asked me why people didn't like Haskell records, I would have
told them about partial updates. So this leaves me a bit more dubious
(though I also recognise that it is a hard problem to solve).
6/7. these are broken by this proposal in that the proposal removes syntax
for those. In my very local experience, in record-heavy code, they are
rather uncommon. So those programmers who would really like 2 and 3, are
probably not the same who would be affected by this proposal. But this
carries a risk: we seem to have taken the habit of being suspicious of
fork-like extension. Don't 6 and 7 make this proposal fork-like? (note: 6
can probably be fixed later by adding type parameters to `HasField` (though
the functional dependencies would become more subtle), I'm not sure we have
any plan that would begin to address 7).

I wrote all that, but it hasn't helped me make an opinion. Some people are
very enthusiastic about this proposal, they probably deserve that we
accept. It's definitely not a bad idea. We may want to be worried about the
fork-like aspects; maybe they are not that bad though.

As per syntax, Simon PJ's suggestions, on the github thread, sound pretty
sensible to me. And I'm squarely in team (.foo) (section parentheses for
usage as a function).

Apologies if this message wasn't useful (it probably wasn't). I'll probably
stay a neutral party for the rest of this process.

On Wed, Dec 11, 2019 at 10:11 AM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Dec 11, 2019, at 3:27 AM, Eric Seidel <eric at seidel.io> wrote:
>
> So I think I would be happy with bare `.lbl` being a postfix operator that
> binds less tightly than function application.
>
>
> This means that `f x .bar` is `(f x) .bar` while `f x.bar` is `f (x.bar)`.
> A bit too subtle for me.
>
> Another alternative is to make `.foo` a postfix operator that does not
> associate with function application. That is, `f x .bar` would be a parse
> error. So we can write `x .foo .bar` to mean the same as `x.foo.bar`, but
> we don't have to commit to any strange parsing rules around `f a .b c .d e`.
>
> But I'm starting to lean toward just making bare `.foo` a syntax error and
> revisit this debate with more experience.
>
> Richard
> _______________________________________________
> 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/20191212/4dd7ae61/attachment-0001.html>

From mail at joachim-breitner.de  Thu Dec 12 09:14:53 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 12 Dec 2019 10:14:53 +0100
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <CAH6fHQnT42N4diWQ96P5EMxKFkuFEYwCijxptct671iVztbryg@mail.gmail.com>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
 <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <df4411d4-6a1d-45f0-9591-af35b5edab9c@www.fastmail.com>
 <E25BF1F4-7F90-4E35-8058-B2979445863F@richarde.dev>
 <CAH6fHQnT42N4diWQ96P5EMxKFkuFEYwCijxptct671iVztbryg@mail.gmail.com>
Message-ID: <839e5c524fc2e1dad46b768504ca0b2f34f6828c.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 12.12.2019, 10:04 +0100 schrieb Spiwack, Arnaud:
> Apologies if this message wasn't useful (it probably wasn't). I'll probably stay a neutral party for the rest of this process.

I find it very useful. Especially as it reminds us that there is more
to the proposal than the question about what a space left of the .
means (which seems to suck in all the attention).

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


From arnaud.spiwack at tweag.io  Thu Dec 12 09:19:40 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 12 Dec 2019 10:19:40 +0100
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <839e5c524fc2e1dad46b768504ca0b2f34f6828c.camel@joachim-breitner.de>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
 <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <df4411d4-6a1d-45f0-9591-af35b5edab9c@www.fastmail.com>
 <E25BF1F4-7F90-4E35-8058-B2979445863F@richarde.dev>
 <CAH6fHQnT42N4diWQ96P5EMxKFkuFEYwCijxptct671iVztbryg@mail.gmail.com>
 <839e5c524fc2e1dad46b768504ca0b2f34f6828c.camel@joachim-breitner.de>
Message-ID: <CAH6fHQksnaTCjFycGXDBhwBqkXWxfL8eTSreYi651yt4Q7GtvA@mail.gmail.com>

After I clicked “send”, and after some verification, I realised that there
was a yet undocumented interaction with pattern synonyms. Namely,
record-pattern-synonym update. I asked the author to document it in the
proposal:
https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-56491971
.

On Thu, Dec 12, 2019 at 10:15 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Donnerstag, den 12.12.2019, 10:04 +0100 schrieb Spiwack, Arnaud:
> > Apologies if this message wasn't useful (it probably wasn't). I'll
> probably stay a neutral party for the rest of this process.
>
> I find it very useful. Especially as it reminds us that there is more
> to the proposal than the question about what a space left of the .
> means (which seems to suck in all the attention).
>
> 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/20191212/1ad9140e/attachment.html>

From simonpj at microsoft.com  Thu Dec 12 09:44:05 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 12 Dec 2019 09:44:05 +0000
Subject: [ghc-steering-committee] Precedence of r.x
Message-ID: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

A question for the committee.  

What does 
	f r.x
mean, where there is no white space on either side of the dot?

A. The proposal says it means (f (r.x))
B. Joachim wants it to mean ((f r).x)

In trying to guide the discussion to a conclusion I proposed to fix on (A).  I don't think it was controversial in the public discussion, it's compatible with qualified names, and forcing `f (r.x)` looks horribly clumsy to me.

Partly it's a question of whether your starting point is
(a) "." is fundamentally an operator, albeit with 
    some special extra rules, or
(b) R.x, r.x, and .x are new syntactic forms,
    unrelated to the infix operator (.)
I'm definitely thinking of it in the latter way.

I don't really want to re-open this question, and I'm not sure if the authors of the proposal could live with (B). However, if the committee wants to reopen the question, then that is what we should do.   Can you express a view on this narrow question?

Simon

From marlowsd at gmail.com  Thu Dec 12 09:49:26 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 12 Dec 2019 09:49:26 +0000
Subject: [ghc-steering-committee] Precedence of r.x
In-Reply-To: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgPKsYFaBTxj54RNODHDVuqkY=JSi4h_Ji_V_ZBZDua8hTw@mail.gmail.com>

Definitely (A).

On Thu, 12 Dec 2019 at 09:44, Simon Peyton Jones via ghc-steering-committee
<ghc-steering-committee at haskell.org> wrote:

> A question for the committee.
>
> What does
>         f r.x
> mean, where there is no white space on either side of the dot?
>
> A. The proposal says it means (f (r.x))
> B. Joachim wants it to mean ((f r).x)
>
> In trying to guide the discussion to a conclusion I proposed to fix on
> (A).  I don't think it was controversial in the public discussion, it's
> compatible with qualified names, and forcing `f (r.x)` looks horribly
> clumsy to me.
>
> Partly it's a question of whether your starting point is
> (a) "." is fundamentally an operator, albeit with
>     some special extra rules, or
> (b) R.x, r.x, and .x are new syntactic forms,
>     unrelated to the infix operator (.)
> I'm definitely thinking of it in the latter way.
>
> I don't really want to re-open this question, and I'm not sure if the
> authors of the proposal could live with (B). However, if the committee
> wants to reopen the question, then that is what we should do.   Can you
> express a view on this narrow question?
>
> Simon
> _______________________________________________
> 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/20191212/556cbc18/attachment.html>

From arnaud.spiwack at tweag.io  Thu Dec 12 10:01:52 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 12 Dec 2019 11:01:52 +0100
Subject: [ghc-steering-committee] Precedence of r.x
In-Reply-To: <CANsrgPKsYFaBTxj54RNODHDVuqkY=JSi4h_Ji_V_ZBZDua8hTw@mail.gmail.com>
References: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <CANsrgPKsYFaBTxj54RNODHDVuqkY=JSi4h_Ji_V_ZBZDua8hTw@mail.gmail.com>
Message-ID: <CAH6fHQn4BuTfmKcEqAvmQUs0c2zyBcdZWpo5WPzivipddyESSA@mail.gmail.com>

When I first picked up Haskell professionally, I was told “we don’t write
f.g, we write f . g, because when someone manages to add the record syntax,
the former will be record selection”. So I’ve always considered f.g to be
forbidden syntax. Morally a syntax error, if you will, that the parser
accidentally didn’t catch.

So, while it is true that *today* f r.x parses as (f r).x (that is, (B)). I
see no objection for (A), which does make more visual sense to me.

On Thu, Dec 12, 2019 at 10:49 AM Simon Marlow <marlowsd at gmail.com> wrote:

> Definitely (A).
>
> On Thu, 12 Dec 2019 at 09:44, Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
>> A question for the committee.
>>
>> What does
>>         f r.x
>> mean, where there is no white space on either side of the dot?
>>
>> A. The proposal says it means (f (r.x))
>> B. Joachim wants it to mean ((f r).x)
>>
>> In trying to guide the discussion to a conclusion I proposed to fix on
>> (A).  I don't think it was controversial in the public discussion, it's
>> compatible with qualified names, and forcing `f (r.x)` looks horribly
>> clumsy to me.
>>
>> Partly it's a question of whether your starting point is
>> (a) "." is fundamentally an operator, albeit with
>>     some special extra rules, or
>> (b) R.x, r.x, and .x are new syntactic forms,
>>     unrelated to the infix operator (.)
>> I'm definitely thinking of it in the latter way.
>>
>> I don't really want to re-open this question, and I'm not sure if the
>> authors of the proposal could live with (B). However, if the committee
>> wants to reopen the question, then that is what we should do.   Can you
>> express a view on this narrow question?
>>
>> Simon
>> _______________________________________________
>> 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/20191212/df19791c/attachment-0001.html>

From mail at joachim-breitner.de  Thu Dec 12 10:23:56 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 12 Dec 2019 11:23:56 +0100
Subject: [ghc-steering-committee] Precedence of r.x
In-Reply-To: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <07dec94df3f6edd99cf6d7251accff63a9648042.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 12.12.2019, 09:44 +0000 schrieb Simon Peyton Jones. 
> f r.x
> A. The proposal says it means (f (r.x)) 
> B. Joachim wants it to mean ((f r).x)

to give credit where credit is due, this wasn’t my idea:

I came to that conclusion after reading Eric’s mail on this list (from
Tue, 10 Dec 2019 22:27:57 -0500) and Chris Done’s nice summary and
digestion of Eric’s mail as posted in 
https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-564465807

I expect the ability to freely add whitespace on (at least) one side of
a dot, without changing the meaning, is also advantageous to be able to
lay out code nicely.

It seems we gain a lot (e.g. chaining with argument) if we let go of of
the desire to not have to parenthesize non-atomic arguments (in 
`f (r.x) (s.x)`), which we otherwise _always_ do in Haskell (as in
`f (x!!5) (y!!5)`).

Cheers,
Joachim

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


From rae at richarde.dev  Thu Dec 12 11:30:33 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 12 Dec 2019 11:30:33 +0000
Subject: [ghc-steering-committee] Precedence of r.x
In-Reply-To: <07dec94df3f6edd99cf6d7251accff63a9648042.camel@joachim-breitner.de>
References: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <07dec94df3f6edd99cf6d7251accff63a9648042.camel@joachim-breitner.de>
Message-ID: <93E3D6BE-C7A3-45C6-A2A6-DC4632200231@richarde.dev>

My first reaction was "surely (A)". After reading Joachim's argument, my answer is now "(A)", but without the "surely".

Yes, I see your (Joachim's) point here. But I worry that moving away from (A) optimizes the less common case of long field names / chaining over the more common case of passing a field value as a function argument.

As for laying out long names, we always have

> f.foo &
>  (.bar) &
>  (.baz)

Not fantastic, but also not terrible. (Recall that (&) = flip ($).)

The chaining examples (which look like x.f1(biz, baz).f2(wurble).f3() in Java) seem less likely in Haskell.

Richard

> On Dec 12, 2019, at 10:23 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Donnerstag, den 12.12.2019, 09:44 +0000 schrieb Simon Peyton Jones. 
>> f r.x
>> A. The proposal says it means (f (r.x)) 
>> B. Joachim wants it to mean ((f r).x)
> 
> to give credit where credit is due, this wasn’t my idea:
> 
> I came to that conclusion after reading Eric’s mail on this list (from
> Tue, 10 Dec 2019 22:27:57 -0500) and Chris Done’s nice summary and
> digestion of Eric’s mail as posted in 
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-564465807
> 
> I expect the ability to freely add whitespace on (at least) one side of
> a dot, without changing the meaning, is also advantageous to be able to
> lay out code nicely.
> 
> It seems we gain a lot (e.g. chaining with argument) if we let go of of
> the desire to not have to parenthesize non-atomic arguments (in 
> `f (r.x) (s.x)`), which we otherwise _always_ do in Haskell (as in
> `f (x!!5) (y!!5)`).
> 
> 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 rae at richarde.dev  Thu Dec 12 12:30:49 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 12 Dec 2019 12:30:49 +0000
Subject: [ghc-steering-committee] Precedence of r.x
In-Reply-To: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <0EDC2082-5CE7-47CA-944A-B921886112C9@richarde.dev>



> On Dec 12, 2019, at 9:44 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> What does 
> 	f r.x
> mean, where there is no white space on either side of the dot?
> 
> A. The proposal says it means (f (r.x))
> B. Joachim wants it to mean ((f r).x)

I have now read (most of) the comments posted in the last 24 hours on the GitHub trail. And it's changing my view of all this.

I'm now more in favor of (B).

To me, the clearest argument for this is that it is true already. That is, if I write `f x.y` in code today, it means `(f x) . y`. Of course, we're changing the meaning of `.`. But it doesn't mean we have to change the parsing. And somehow, no one complains about it today. (Well, that's not true -- beginners complain. They get used to it.)

I would also like to propose

(C). Syntax error.

That is, a tight-infix use of `.` does not associate with a function application on its left. A prefix occurrence of `.` would: `f x .y` would be `(f x) .y`.

We could also just make this a warning.

Somehow, this all reminds me a bit of the precedence of the * prefix operator and field selection in C/C++. In these languages, *foo.bar.baz means *(foo.bar.baz), which I've always found surprising. More often, we want (*foo).bar.baz. And indeed to satisfy their users, they came up with a totally new operator: foo->bar is precisely (*foo).bar. My point here is that we are not alone in grappling with this issue, and that "field access is always the highest-precedence operator" is not always a good idea.

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

From eric at seidel.io  Thu Dec 12 13:57:52 2019
From: eric at seidel.io (Eric Seidel)
Date: Thu, 12 Dec 2019 08:57:52 -0500
Subject: [ghc-steering-committee] Precedence of r.x
In-Reply-To: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <514f2240-dbbd-4352-9e5f-871c247f6205@www.fastmail.com>

I instinctively read it as `(f (r.x))`, but I also like the conceptual simplicity of always treating `.x` as a postfix operator. And I'm not as bothered by having to write `f (r.x)`.

I think I would be quite happy with Richard's suggestion (C), `f r.x` is a syntax error, please add parentheses either way.

---

I'm also somewhat skeptical of the method-chaining arguments.

  xs.map (+1) .filter even

will not type check in any case, as [] has no `map` or `filter` fields. Yes you could add "virtual" fields to sorta kinda make things work (it seems like there are a number of caveats), but this feels like an abuse of the HasField machinery to me. And I find it quite unlikely that doing so would unlock the dot-based autocompletion reliably.

On Thu, Dec 12, 2019, at 04:44, Simon Peyton Jones via ghc-steering-committee wrote:
> A question for the committee.  
> 
> What does 
> 	f r.x
> mean, where there is no white space on either side of the dot?
> 
> A. The proposal says it means (f (r.x))
> B. Joachim wants it to mean ((f r).x)
> 
> In trying to guide the discussion to a conclusion I proposed to fix on 
> (A).  I don't think it was controversial in the public discussion, it's 
> compatible with qualified names, and forcing `f (r.x)` looks horribly 
> clumsy to me.
> 
> Partly it's a question of whether your starting point is
> (a) "." is fundamentally an operator, albeit with 
>     some special extra rules, or
> (b) R.x, r.x, and .x are new syntactic forms,
>     unrelated to the infix operator (.)
> I'm definitely thinking of it in the latter way.
> 
> I don't really want to re-open this question, and I'm not sure if the 
> authors of the proposal could live with (B). However, if the committee 
> wants to reopen the question, then that is what we should do.   Can you 
> express a view on this narrow question?
> 
> Simon
> _______________________________________________
> 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 Dec 12 14:00:30 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 12 Dec 2019 15:00:30 +0100
Subject: [ghc-steering-committee] Precedence of r.x
In-Reply-To: <0EDC2082-5CE7-47CA-944A-B921886112C9@richarde.dev>
References: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <0EDC2082-5CE7-47CA-944A-B921886112C9@richarde.dev>
Message-ID: <49ea3fe5e71db4f7cc5504ad9324734573debd08.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 12.12.2019, 12:30 +0000 schrieb Richard Eisenberg:
> I would also like to propose
> 
> (C). Syntax error.
> 
> That is, a tight-infix use of `.` does not associate with a function application on its left. A prefix occurrence of `.` would: `f x .y` would be `(f x) .y`.
> 
> 
> We could also just make this a warning.

such a warning was actually also proposed in the monster GitHub thread:
https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-564597503
as -Wproximity, which could warn about any misleading spacing, so not only
`f x.y` (whether this is a record access or function composition), but also
`x * y+z` etc.

Sounds very nice! Probably orthogonal to this proposal, but maybe a way
to make people worry less about the confusion that `f x.y` may bring?

Cheers,
Joachim

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


From iavor.diatchki at gmail.com  Thu Dec 12 18:16:27 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 12 Dec 2019 10:16:27 -0800
Subject: [ghc-steering-committee] Precedence of r.x
In-Reply-To: <49ea3fe5e71db4f7cc5504ad9324734573debd08.camel@joachim-breitner.de>
References: <VI1PR8303MB00936AD39017D55FDF095D8BAD550@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <0EDC2082-5CE7-47CA-944A-B921886112C9@richarde.dev>
 <49ea3fe5e71db4f7cc5504ad9324734573debd08.camel@joachim-breitner.de>
Message-ID: <CAGK9nuo7O8tHbPm7jqReaY3LwabAP6ZPui=QHKk9KSLsdpv16g@mail.gmail.com>

I think that `f x.y` should mean `f (x.y)`.

On Thu, Dec 12, 2019 at 6:00 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Donnerstag, den 12.12.2019, 12:30 +0000 schrieb Richard Eisenberg:
> > I would also like to propose
> >
> > (C). Syntax error.
> >
> > That is, a tight-infix use of `.` does not associate with a function
> application on its left. A prefix occurrence of `.` would: `f x .y` would
> be `(f x) .y`.
> >
> >
> > We could also just make this a warning.
>
> such a warning was actually also proposed in the monster GitHub thread:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-564597503
> as -Wproximity, which could warn about any misleading spacing, so not only
> `f x.y` (whether this is a record access or function composition), but also
> `x * y+z` etc.
>
> Sounds very nice! Probably orthogonal to this proposal, but maybe a way
> to make people worry less about the confusion that `f x.y` may bring?
>
> 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/20191212/3231fc9a/attachment-0001.html>

From mail at joachim-breitner.de  Fri Dec 13 09:14:22 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 13 Dec 2019 10:14:22 +0100
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <CAH6fHQksnaTCjFycGXDBhwBqkXWxfL8eTSreYi651yt4Q7GtvA@mail.gmail.com>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
 <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <df4411d4-6a1d-45f0-9591-af35b5edab9c@www.fastmail.com>
 <E25BF1F4-7F90-4E35-8058-B2979445863F@richarde.dev>
 <CAH6fHQnT42N4diWQ96P5EMxKFkuFEYwCijxptct671iVztbryg@mail.gmail.com>
 <839e5c524fc2e1dad46b768504ca0b2f34f6828c.camel@joachim-breitner.de>
 <CAH6fHQksnaTCjFycGXDBhwBqkXWxfL8eTSreYi651yt4Q7GtvA@mail.gmail.com>
Message-ID: <df07e1d0801b1ccca97f66d15aa7be31af3f0521.camel@joachim-breitner.de>

Hi,

unsurprisingly, Wadler’s law holds also within the committee. It looks
like we have to accept that this one will not likely be solved by
consensus (at least not “enthusiastic consensus”). But that is fine:
The main point of the committee is to make _a_ decision, and we can
vote and probably all live with the outcome.

I’m not calling a vote yet (I’ll leave that to Simon when he feels that
likely no new insights are going to emerge), but would like to outline
the procedure.

We could do a simple majority yes/no vote on the proposal as it stands.
But I believe we can do better, by collecting all (reasonable) options
that have been discussed, and doing a ranked voting.

At the risk of secretarysplaining I’d like to point out that that
voting tends to favor more widly acceptable outcomes: If 35% want .foo
to be the selector, 30% want .foo to be a selection even with spaces on
the left, and 25% are prefer to be conservative and forbid free-
standing .foo for now, then it may be that that last option wins, as
the most consensusable, wins.

So if we do it this way, you should be able to express your genuine
ranking preference, and not worry about strategic voting.


So what options are on the table?

I tried to find a small set of representative examples that explore all
contentious corners of the design space, and came up with this:

  r.field
  f x.field y
  f x .field y
  f x (.field) y
  f x (.field y)

I believe our reasonable options are (and there are many…)


Reject:    
  r.field        = \a -> r (field a)
  f x.field y    = \a -> f x (field y a)
  f x .field y   = \a -> f x (field y a)
  f x (.field) y = f x (\a -> a . field) y
  f x (.field y) = f x (\a -> a . field y)

OnlySelection:
  r.field        = getField @"field" r
  f x.field y    = f (x.field) y
  f x .field y   -- NOT ALLOWED
  f x (.field) y -- NOPE
  f x (.field y) -- NAY

SectionSelector:
  r.field        = getField @"field" r
  f x.field y    = f (x.field) y
  f x .field y   -- VERBOTEN!
  f x (.field) y = f x (\r->r.field) y
  f x (.field y) -- BAD!

PlainSelector:        -- this is the proposal as it stands, I believe
  r.field        = getField @"field" r
  f x.field y    = f (x.field) y
  f x .field y   = f x (\r->r.field) y
  f x (.field) y = f x (\r->r.field) y
  f x (.field y) = f x ((\r->r.field) y) = f x (field y) -- !

Ocaml: 
  r.field        = getField @"field" r
  f x.field y    = f (x.field) y
  f x .field y   = f (x.field) y
  f x (.field) y -- NOT ALLOWED
  f x (.field y) -- CAN’T DO THAT

Ocaml+Section: 
  r.field        = getField @"field" r
  f x.field y    = f (x.field) y
  f x .field y   = f (x.field) y
  f x (.field) y = f (\r->r.field) y
  f x (.field y) -- NO NO NO

JS: 
  r.field        = getField @"field" r
  f x.field y    = ((f x).field) y
  f x .field y   = ((f x).field) y
  f x (.field) y -- IMPOSSIBLE!
  f x (.field y) -- STOP IT PLEASE!

JS+Section: 
  r.field        = getField @"field" r
  f x.field y    = ((f x).field) y
  f x .field y   = ((f x).field) y
  f x (.field) y = f x (\r->r.field) y
  f x (.field y) = f x (\r->(r.field) y)


(Ocaml = . binds more tightly than function application to the left,
JS = .foo has same precendence and associativity as function
application.)

In writing this I noticed that `f x (.field y)` hasn’t been given much
discussion, and it seems to only really make sense in the JS-inspired
variant where chaining becomes possible, and (.field y) is the
“obvious” section syntax for the chaining use of .field. It should
probably be prohibited in the variants that want (.field) to be
parenthesized. 


Am I missing any reasonable point in the design space?
Do I need to add more examples to the list of representative examples?


I am not including the option to print a warning for misleading code
(e.g. if `f x.field y = ((f x).field) y`), as that is a separate idea
that applies to more than just records. But if people want to express,
say, “JS, but only if we get such a warning”, we can add these variants
to the ballot.


Cheers,
Joachim

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


From rae at richarde.dev  Sat Dec 14 11:41:48 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Sat, 14 Dec 2019 11:41:48 +0000
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <df07e1d0801b1ccca97f66d15aa7be31af3f0521.camel@joachim-breitner.de>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
 <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <df4411d4-6a1d-45f0-9591-af35b5edab9c@www.fastmail.com>
 <E25BF1F4-7F90-4E35-8058-B2979445863F@richarde.dev>
 <CAH6fHQnT42N4diWQ96P5EMxKFkuFEYwCijxptct671iVztbryg@mail.gmail.com>
 <839e5c524fc2e1dad46b768504ca0b2f34f6828c.camel@joachim-breitner.de>
 <CAH6fHQksnaTCjFycGXDBhwBqkXWxfL8eTSreYi651yt4Q7GtvA@mail.gmail.com>
 <df07e1d0801b1ccca97f66d15aa7be31af3f0521.camel@joachim-breitner.de>
Message-ID: <18590B71-7AB2-4617-A11E-BF659BFEB29E@richarde.dev>

Your very helpful delineation of the space assumes (.) = \ f g x -> f (g x) and then inlines. I actually think it would be clearer not to do this. I have taken your taxonomy and kept (.) abstract. Some examples also left (x.field) uninterpreted. I have expanded these to use getField. To be clear, this is *not* a reproposal or intended to make *any* change to Joachim's dichotomy. I am just restating it a way I understand better. Perhaps others will also find this to be clearer. Each individual committee member can use *either* my presentation or Joachim's. They (are intended to) have *the same* semantics.

Reject:    
 r.field        = (.) r field
 f x.field y    = (.) (f x) (field y)
 f x .field y   = (.) (f x) (field y)
 f x (.field) y = f x (\a -> (.) a field) y
 f x (.field y) = f x (\a -> (.) a (field y))

OnlySelection:
 r.field        = getField @"field" r
 f x.field y    = f (getField @"field" x) y
 f x .field y   -- NOT ALLOWED
 f x (.field) y -- NOPE
 f x (.field y) -- NAY

SectionSelector:
 r.field        = getField @"field" r
 f x.field y    = f (getField @"field" x) y
 f x .field y   -- VERBOTEN!
 f x (.field) y = f x (\r -> getField @"field" r) y
 f x (.field y) -- BAD!

PlainSelector:        -- this is the proposal as it stands, I believe
 r.field        = getField @"field" r
 f x.field y    = f (getField @"field" x) y
 f x .field y   = f x (\r -> getField @"field" r) y
 f x (.field) y = f x (\r -> getField @"field" r) y
 f x (.field y) = f x ((\r -> getField @"field" r) y) = f x (getField @"field" y) -- !

Ocaml: 
 r.field        = getField @"field" r
 f x.field y    = f (getField @"field" x) y
 f x .field y   = f (getField @"field" x) y
 f x (.field) y -- NOT ALLOWED
 f x (.field y) -- CAN’T DO THAT

Ocaml+Section: 
 r.field        = getField @"field" r
 f x.field y    = f (getField @"field" x) y
 f x .field y   = f (getField @"field" x) y
 f x (.field) y = f (\r -> getField @"field" r) y
 f x (.field y) -- NO NO NO

JS: 
 r.field        = getField @"field" r
 f x.field y    = (getField @"field" (f x)) y
 f x .field y   = (getField @"field" (f x)) y
 f x (.field) y -- IMPOSSIBLE!
 f x (.field y) -- STOP IT PLEASE!

JS+Section: 
 r.field        = getField @"field" r
 f x.field y    = (getField @"field" (f x)) y
 f x .field y   = (getField @"field" (f x)) y
 f x (.field) y = f x (\r -> getField @"field" r) y
 f x (.field y) = f x (\r -> (getField @"field" r) y)

I hope this is helpful!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191214/f34102ec/attachment-0001.html>

From mail at joachim-breitner.de  Sun Dec 15 10:37:10 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 15 Dec 2019 11:37:10 +0100
Subject: [ghc-steering-committee] Atze Dijkstra is ghc-proposals repo admin?
Message-ID: <26d715cfcba4934452e416a0a932ffb11c210595.camel@joachim-breitner.de>

Hi Atze, dear committee,


I noticed that Atze Dijkstra is a GitHub admin for the 
https://github.com/ghc-proposals/ghc-proposals repo.
Is that intentional?


Cheers,
Joachim

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


From mail at joachim-breitner.de  Sun Dec 15 10:54:01 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 15 Dec 2019 11:54:01 +0100
Subject: [ghc-steering-committee] Status
Message-ID: <097843cafe0fbe58f2246fb24e017fb92aa2776d.camel@joachim-breitner.de>

Dear Committee,

since the last status, it seems we have become much more willing to
send proposals back for revision. (BTW, you can make my life easier to
always mention a status change like this on the mailing list.)

Also,

 * Sandy Maguire stepped down, and we started a call for nominations.
   (I have already received two self-nominations)

 * we were asked to review these proposals:
   #177: Simple constrained type families, Shepherd: Richard
   #273: Local Types, Shepherd: Eric
   #285: -XNoImplicitForAll, Shepherd: Simon Marlow
   #246: Overloaded Quotations, Shepherd: Simon PJ
   #265: Unlifted Datatypes, Shepherd: Simon Marlow
   #282: RecordDotSyntax, Shepherd: Simon PJ
   #301: Rename PtrRep to BoxedRep, Shepherd: Joachim

 * we have a recommendation from the shepherd about:
   #195: newtype Q (Texp a) (rec: accept)
   #285: -XNoImplicitForAll (rec: accept)
   #246: Overloaded Quotations (rec: accept)
   #194: Updated partial type signatures (rec: accept)
   #293: Tweaks to #229 (rec: accept)
   #273: Local Types (rec: needs revision)
   #265: Unlifted Datatypes (rec: accept)
   #301: Rename PtrRep to BoxedRep (rec: accept)

 * we have sent the following proposals back to revision
   #177: Simple constrained type families
   #285: -XNoImplicitForAll
  
#273: Local Types
   #194: Updated partial type signatures
   #195:
newtype Q (Texp a)
   #274: Quick Look Impredicativity (rec: accept)

 * we decided about the following proposals
   #246: Overloaded Quotations (accept)
   #293: Tweaks to #229 (accept)


We currently have to act on the following 2 proposals, down by one!

## Waiting for Shepherd action

RecordDotSyntax language extension proposal 
Shepherd: Simon PJ
https://github.com/ghc-proposals/ghc-proposals/pull/282
(Being a prime example of Wadler’s law, it may come to voting.)


## Waiting for committee decision

Rename PtrRep to BoxedRep
Shepherd: Joachim
https://github.com/ghc-proposals/ghc-proposals/pull/301
Acceptance imminent.



Cheers and merry Christmas to those who care about that,
Joachim

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


From iavor.diatchki at gmail.com  Sun Dec 15 17:18:01 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun, 15 Dec 2019 09:18:01 -0800
Subject: [ghc-steering-committee] Status
In-Reply-To: <097843cafe0fbe58f2246fb24e017fb92aa2776d.camel@joachim-breitner.de>
References: <097843cafe0fbe58f2246fb24e017fb92aa2776d.camel@joachim-breitner.de>
Message-ID: <CAGK9nurXO1MH=a=T1FLSRP9a_ypWEP5hAD3e_kn=o3JZ8aoEmw@mail.gmail.com>

Hi Joachim,

I believe the status of #195 is "Needs Revision" currently, with the
understanding that once all the required clarifications are added to the
proposal we'd accept it.  So it is not yet accepted, as far as I know.

-Iavor

On Sun, Dec 15, 2019 at 2:54 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> since the last status, it seems we have become much more willing to
> send proposals back for revision. (BTW, you can make my life easier to
> always mention a status change like this on the mailing list.)
>
> Also,
>
>  * Sandy Maguire stepped down, and we started a call for nominations.
>    (I have already received two self-nominations)
>
>  * we were asked to review these proposals:
>    #177: Simple constrained type families, Shepherd: Richard
>    #273: Local Types, Shepherd: Eric
>    #285: -XNoImplicitForAll, Shepherd: Simon Marlow
>    #246: Overloaded Quotations, Shepherd: Simon PJ
>    #265: Unlifted Datatypes, Shepherd: Simon Marlow
>    #282: RecordDotSyntax, Shepherd: Simon PJ
>    #301: Rename PtrRep to BoxedRep, Shepherd: Joachim
>
>  * we have a recommendation from the shepherd about:
>    #195: newtype Q (Texp a) (rec: accept)
>    #285: -XNoImplicitForAll (rec: accept)
>    #246: Overloaded Quotations (rec: accept)
>    #194: Updated partial type signatures (rec: accept)
>    #293: Tweaks to #229 (rec: accept)
>    #273: Local Types (rec: needs revision)
>    #265: Unlifted Datatypes (rec: accept)
>    #301: Rename PtrRep to BoxedRep (rec: accept)
>
>  * we have sent the following proposals back to revision
>    #177: Simple constrained type families
>    #285: -XNoImplicitForAll
>
> #273: Local Types
>    #194: Updated partial type signatures
>    #195:
> newtype Q (Texp a)
>    #274: Quick Look Impredicativity (rec: accept)
>
>  * we decided about the following proposals
>    #246: Overloaded Quotations (accept)
>    #293: Tweaks to #229 (accept)
>
>
> We currently have to act on the following 2 proposals, down by one!
>
> ## Waiting for Shepherd action
>
> RecordDotSyntax language extension proposal
> Shepherd: Simon PJ
> https://github.com/ghc-proposals/ghc-proposals/pull/282
> (Being a prime example of Wadler’s law, it may come to voting.)
>
>
> ## Waiting for committee decision
>
> Rename PtrRep to BoxedRep
> Shepherd: Joachim
> https://github.com/ghc-proposals/ghc-proposals/pull/301
> Acceptance imminent.
>
>
>
> Cheers and merry Christmas to those who care about that,
> 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/20191215/a132ab13/attachment.html>

From mail at joachim-breitner.de  Sun Dec 15 22:48:54 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 15 Dec 2019 23:48:54 +0100
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nurXO1MH=a=T1FLSRP9a_ypWEP5hAD3e_kn=o3JZ8aoEmw@mail.gmail.com>
References: <097843cafe0fbe58f2246fb24e017fb92aa2776d.camel@joachim-breitner.de>
 <CAGK9nurXO1MH=a=T1FLSRP9a_ypWEP5hAD3e_kn=o3JZ8aoEmw@mail.gmail.com>
Message-ID: <e9f7e9816aac9a6e4d73506e8799bbbc3becf430.camel@joachim-breitner.de>

Hi,

quite right; that’s why it is also listed under “we have sent the
following proposals back to revision”.

(The first half of the mail is a list of events, with some proposals
appearing in multiple subsections; the second half a summary of the
status.)

But thanks for checking!

Cheeers,
Joachim

Am Sonntag, den 15.12.2019, 09:18 -0800 schrieb Iavor Diatchki:
> I believe the status of #195 is "Needs Revision" currently, with the understanding that once all the required clarifications are added to the proposal we'd accept it.  So it is not yet accepted, as far as I know.
> 
> -Iavor
> 
> On Sun, Dec 15, 2019 at 2:54 AM Joachim Breitner <mail at joachim-breitner.de> wrote:
> > Dear Committee,
> > 
> > since the last status, it seems we have become much more willing to
> > send proposals back for revision. (BTW, you can make my life easier to
> > always mention a status change like this on the mailing list.)
> > 
> > Also,
> > 
> >  * Sandy Maguire stepped down, and we started a call for nominations.
> >    (I have already received two self-nominations)
> > 
> >  * we were asked to review these proposals:
> >    #177: Simple constrained type families, Shepherd: Richard
> >    #273: Local Types, Shepherd: Eric
> >    #285: -XNoImplicitForAll, Shepherd: Simon Marlow
> >    #246: Overloaded Quotations, Shepherd: Simon PJ
> >    #265: Unlifted Datatypes, Shepherd: Simon Marlow
> >    #282: RecordDotSyntax, Shepherd: Simon PJ
> >    #301: Rename PtrRep to BoxedRep, Shepherd: Joachim
> > 
> >  * we have a recommendation from the shepherd about:
> >    #195: newtype Q (Texp a) (rec: accept)
> >    #285: -XNoImplicitForAll (rec: accept)
> >    #246: Overloaded Quotations (rec: accept)
> >    #194: Updated partial type signatures (rec: accept)
> >    #293: Tweaks to #229 (rec: accept)
> >    #273: Local Types (rec: needs revision)
> >    #265: Unlifted Datatypes (rec: accept)
> >    #301: Rename PtrRep to BoxedRep (rec: accept)
> > 
> >  * we have sent the following proposals back to revision
> >    #177: Simple constrained type families
> >    #285: -XNoImplicitForAll
> > 
> > #273: Local Types
> >    #194: Updated partial type signatures
> >    #195:
> > newtype Q (Texp a)
> >    #274: Quick Look Impredicativity (rec: accept)
> > 
> >  * we decided about the following proposals
> >    #246: Overloaded Quotations (accept)
> >    #293: Tweaks to #229 (accept)
> > 
> > 
> > We currently have to act on the following 2 proposals, down by one!
> > 
> > ## Waiting for Shepherd action
> > 
> > RecordDotSyntax language extension proposal 
> > Shepherd: Simon PJ
> > https://github.com/ghc-proposals/ghc-proposals/pull/282
> > (Being a prime example of Wadler’s law, it may come to voting.)
> > 
> > 
> > ## Waiting for committee decision
> > 
> > Rename PtrRep to BoxedRep
> > Shepherd: Joachim
> > https://github.com/ghc-proposals/ghc-proposals/pull/301
> > Acceptance imminent.
> > 
> > 
> > 
> > Cheers and merry Christmas to those who care about that,
> > Joachim
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From rae at richarde.dev  Sun Dec 15 23:22:42 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Sun, 15 Dec 2019 23:22:42 +0000
Subject: [ghc-steering-committee] Atze Dijkstra is ghc-proposals repo
 admin?
In-Reply-To: <26d715cfcba4934452e416a0a932ffb11c210595.camel@joachim-breitner.de>
References: <26d715cfcba4934452e416a0a932ffb11c210595.camel@joachim-breitner.de>
Message-ID: <6761D7C7-9C54-439C-9883-2503D46938E4@richarde.dev>

That's unexpected.

cc'ing Ben, who (if memory serves) may have been part of setting up this repo.

Richard

> On Dec 15, 2019, at 10:37 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi Atze, dear committee,
> 
> 
> I noticed that Atze Dijkstra is a GitHub admin for the 
> https://github.com/ghc-proposals/ghc-proposals repo.
> Is that intentional?
> 
> 
> 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 atzedijkstra at gmail.com  Sun Dec 15 23:37:26 2019
From: atzedijkstra at gmail.com (Atze Dijkstra)
Date: Sun, 15 Dec 2019 23:37:26 +0000
Subject: [ghc-steering-committee] Atze Dijkstra is ghc-proposals repo
	admin?
In-Reply-To: <26d715cfcba4934452e416a0a932ffb11c210595.camel@joachim-breitner.de>
References: <26d715cfcba4934452e416a0a932ffb11c210595.camel@joachim-breitner.de>
Message-ID: <136BEBD2-50ED-4D4A-A0B4-EBF3EAAF0694@gmail.com>

Hi Joachim,

There is no need for me to be admin. Although I follow the mails here I do so passively only.

Kind regards
Atze


--
Atze Dijkstra

> On 15 Dec 2019, at 10:37, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi Atze, dear committee,
> 
> 
> I noticed that Atze Dijkstra is a GitHub admin for the 
> https://github.com/ghc-proposals/ghc-proposals repo.
> Is that intentional?
> 
> 
> Cheers,
> Joachim
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 

From mail at joachim-breitner.de  Mon Dec 16 14:05:35 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 16 Dec 2019 15:05:35 +0100
Subject: [ghc-steering-committee] Atze Dijkstra is ghc-proposals repo
 admin?
In-Reply-To: <136BEBD2-50ED-4D4A-A0B4-EBF3EAAF0694@gmail.com>
References: <26d715cfcba4934452e416a0a932ffb11c210595.camel@joachim-breitner.de>
 <136BEBD2-50ED-4D4A-A0B4-EBF3EAAF0694@gmail.com>
Message-ID: <078ebf881c7268d1641b71133c3d3f7e3368b47d.camel@joachim-breitner.de>

Hi,

ok, I removed you. Thanks for whatever made you be in admin in the past
:-)

Cheers,
Joachim



Am Sonntag, den 15.12.2019, 23:37 +0000 schrieb Atze Dijkstra:
> Hi Joachim,
> 
> There is no need for me to be admin. Although I follow the mails here I do so passively only.
> 
> Kind regards
> Atze
> 
> 
> --
> Atze Dijkstra
> 
> > On 15 Dec 2019, at 10:37, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > Hi Atze, dear committee,
> > 
> > 
> > I noticed that Atze Dijkstra is a GitHub admin for the 
> > https://github.com/ghc-proposals/ghc-proposals repo.
> > Is that intentional?
> > 
> > 
> > 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
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From bravit111 at gmail.com  Mon Dec 16 15:19:33 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Mon, 16 Dec 2019 18:19:33 +0300
Subject: [ghc-steering-committee] RecordDotSyntax: please express a view
In-Reply-To: <18590B71-7AB2-4617-A11E-BF659BFEB29E@richarde.dev>
References: <VI1PR8303MB00930BC11D4ED1CA0E30C5B6AD580@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <206e6c8314733f439dc2d35340667f34238e2d06.camel@joachim-breitner.de>
 <VI1PR8303MB009332C9264F39C53FAD68A4AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <029E63C2-209D-4CE8-9665-CFCA20989779@richarde.dev>
 <VI1PR8303MB009373695D7CA8AD84CBF040AD5B0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <df4411d4-6a1d-45f0-9591-af35b5edab9c@www.fastmail.com>
 <E25BF1F4-7F90-4E35-8058-B2979445863F@richarde.dev>
 <CAH6fHQnT42N4diWQ96P5EMxKFkuFEYwCijxptct671iVztbryg@mail.gmail.com>
 <839e5c524fc2e1dad46b768504ca0b2f34f6828c.camel@joachim-breitner.de>
 <CAH6fHQksnaTCjFycGXDBhwBqkXWxfL8eTSreYi651yt4Q7GtvA@mail.gmail.com>
 <df07e1d0801b1ccca97f66d15aa7be31af3f0521.camel@joachim-breitner.de>
 <18590B71-7AB2-4617-A11E-BF659BFEB29E@richarde.dev>
Message-ID: <CALpVSmN0XXxwRbA9qZs8XKb27o9=juZdp7qn7hcN0YdOLO6KeA@mail.gmail.com>

Hi everyone,

Joachim and Richard, thank you very much for creating this framework to
think about this proposal. It is very helpful.

As an educator, I'd vote for rejection. My reason is that the proposal
introduces yet another style of programming in Haskell, in addition to
traditional functional and lenses-like ones. I can easily imagine imitating
object-oriented style with fields-functions and it will be too tempting to
use it by those with OO-background (and this includes almost everyone these
days given the trends in higher education). The proposal also limits ways
to use function composition (especially in sections) which is another sad
thing. I don't like all this happening to Haskell as a purely functional
PL.

Regards,
Vitaly


сб, 14 дек. 2019 г. в 14:42, Richard Eisenberg <rae at richarde.dev>:

> Your very helpful delineation of the space assumes (.) = \ f g x -> f (g
> x) and then inlines. I actually think it would be clearer not to do this. I
> have taken your taxonomy and kept (.) abstract. Some examples also left
> (x.field) uninterpreted. I have expanded these to use getField. To be
> clear, this is *not* a reproposal or intended to make *any* change to
> Joachim's dichotomy. I am just restating it a way I understand better.
> Perhaps others will also find this to be clearer. Each individual committee
> member can use *either* my presentation or Joachim's. They (are intended
> to) have *the same* semantics.
>
> Reject:
>  r.field        = (.) r field
>  f x.field y    = (.) (f x) (field y)
>  f x .field y   = (.) (f x) (field y)
>  f x (.field) y = f x (\a -> (.) a field) y
>  f x (.field y) = f x (\a -> (.) a (field y))
>
> OnlySelection:
>  r.field        = getField @"field" r
>  f x.field y    = f (getField @"field" x) y
>  f x .field y   -- NOT ALLOWED
>  f x (.field) y -- NOPE
>  f x (.field y) -- NAY
>
> SectionSelector:
>  r.field        = getField @"field" r
>  f x.field y    = f (getField @"field" x) y
>  f x .field y   -- VERBOTEN!
>  f x (.field) y = f x (\r -> getField @"field" r) y
>  f x (.field y) -- BAD!
>
> PlainSelector:        -- this is the proposal as it stands, I believe
>  r.field        = getField @"field" r
>  f x.field y    = f (getField @"field" x) y
>  f x .field y   = f x (\r -> getField @"field" r) y
>  f x (.field) y = f x (\r -> getField @"field" r) y
>  f x (.field y) = f x ((\r -> getField @"field" r) y) = f x (getField
> @"field" y) -- !
>
> Ocaml:
>  r.field        = getField @"field" r
>  f x.field y    = f (getField @"field" x) y
>  f x .field y   = f (getField @"field" x) y
>  f x (.field) y -- NOT ALLOWED
>  f x (.field y) -- CAN’T DO THAT
>
> Ocaml+Section:
>  r.field        = getField @"field" r
>  f x.field y    = f (getField @"field" x) y
>  f x .field y   = f (getField @"field" x) y
>  f x (.field) y = f (\r -> getField @"field" r) y
>  f x (.field y) -- NO NO NO
>
> JS:
>  r.field        = getField @"field" r
>  f x.field y    = (getField @"field" (f x)) y
>  f x .field y   = (getField @"field" (f x)) y
>  f x (.field) y -- IMPOSSIBLE!
>  f x (.field y) -- STOP IT PLEASE!
>
> JS+Section:
>  r.field        = getField @"field" r
>  f x.field y    = (getField @"field" (f x)) y
>  f x .field y   = (getField @"field" (f x)) y
>  f x (.field) y = f x (\r -> getField @"field" r) y
>  f x (.field y) = f x (\r -> (getField @"field" r) y)
>
> I hope this is helpful!
> Richard
> _______________________________________________
> 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/20191216/189e549c/attachment-0001.html>

From simonpj at microsoft.com  Mon Dec 16 23:48:08 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 16 Dec 2019 23:48:08 +0000
Subject: [ghc-steering-committee] Records again
Message-ID: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

Dear steering committee
I am keen to prevent the record-syntax debate from spiralling outwards.  This has happened before, and is the main reason Haskell has remained stuck with sub-standard records for so long.  So I'm playing a more active, even directive, shepherding role than usual.
Vitaly, thanks for your response, but I continue to believe that we should accept some version of this proposal.   I can elaborate more if needed, but I think that most of the committee agrees with the direction of travel.  (But please say if you want to join Vitaly in outright rejection.)
Assuming that we want to accept some version, I'd like to propose that we adopt the idea that `f r.x` means `f (r.x)`, and not the record selection `(f r).x`, nor the function composition `(f r) . x`.
Joachim floated the `(f r).x` idea recently and Richard supported him.  I consulted the authors who said "Interestingly, the very first version of the prototype implemented exactly that. That behaviour surprised the heck out of everyone (including you) and we were quickly and overwhelmingly convinced that it was the wrong parse and updated the proposal accordingly."  I had a long conversation with Richard, who (I think) finds both alternatives acceptable.
I agree strongly with the authors; I think `(f r).x` would be horrible, and would vote against such a proposal.  So, in the interests of making progress, I recommend that we adopt the `f (r.x)` parse.   Talking to Richard I realise that a lot depends on your starting point:

  1.  I regard `M.N.x` and `r.x.y` as a single token, where `.` is punctuation.  Space is always significant for dot; `M . x` is quite different to `M.x`.  Another example is the unbounded enumeration `[Z ..]` where you must put the space; if you write `[Z..]` you'll get the dot-operator imported from module Z.

>From this point of view, Haskell's use of `(.)` as an infix operator for composition is an aberration.   And parsing `f r.x` as `f (r.x)` is consistent with our parse of `f M.x`.

  1.  An alternative point of view is to regard `(.)` as a fully fledged operator, and all the stuff about qualified names, enumerations and so on, as a sad aberration.  Under this point of view, record selection just makes the aberration worse.
I realise that one reason I want the `f (r.x)` parse so strongly is my previously-implicit espousal of (A); perhaps making that explicit will help frame the conversation.  I'm also very un-keen on making `r.x` illegal, which is another alternative in theory.
TL;DR.  Does anyone (who wants to accept the proposal in some form) seriously oppose the `f (r.x)` parse for `f r.x`?  I hope that it'll be at least acceptable to everyone, and we can more on.
Thanks
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191216/b16be054/attachment.html>

From iavor.diatchki at gmail.com  Tue Dec 17 00:25:07 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 16 Dec 2019 16:25:07 -0800
Subject: [ghc-steering-committee] Records again
In-Reply-To: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuq8qQstdpd2pJKmU1F0LG_eWBbA4KF6ZVdCEMV+V9RGsg@mail.gmail.com>

Personally, I am not thrilled about this proposal, and I am unlikely to use
it, if it is implemented.

As I said before, I am fine with accepting it, if others would find it
useful, as long as we have the option to not use it---
I realize I am in the minority here, but think Haskell's records actually
work pretty well as they are and I use them all the time
without significant problems.

As for the concrete design question: I agree that `f x.y` should mean `f
(x.y)`.

-Iavor











On Mon, Dec 16, 2019 at 3:48 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Dear steering committee
>
> I am keen to prevent the record-syntax debate from spiralling outwards.
> This has happened before, and is the main reason Haskell has remained stuck
> with sub-standard records for so long.  So I'm playing a more active, even
> directive, shepherding role than usual.
>
> Vitaly, thanks for your response, but I continue to believe that we should
> accept some version of this proposal.   I can elaborate more if needed, but
> I think that most of the committee agrees with the direction of travel.
> (But please say if you want to join Vitaly in outright rejection.)
>
> Assuming that we want to accept some version, *I'd like to propose that
> we adopt the idea that `f r.x` means `f (r.x)`*, and not the record
> selection `(f r).x`, nor the function composition `(f r) . x`.
>
> Joachim floated the `(f r).x` idea recently and Richard supported him.  I
> consulted the authors who said "Interestingly, the very first version of
> the prototype implemented exactly that. That behaviour surprised the heck
> out of everyone (including you) and we were quickly and overwhelmingly
> convinced that it was the wrong parse and updated the proposal
> accordingly."  I had a long conversation with Richard, who (I think) finds
> both alternatives acceptable.
>
> I agree strongly with the authors; I think `(f r).x` would be horrible,
> and would vote against such a proposal.  So, in the interests of making
> progress, I recommend that we adopt the `f (r.x)` parse.   Talking to
> Richard I realise that a lot depends on your starting point:
>
>    1. I regard `M.N.x` and `r.x.y` as a single token, where `.` is
>    punctuation.  Space is always significant for dot; `M . x` is quite
>    different to `M.x`.  Another example is the unbounded enumeration `[Z ..]`
>    where you must put the space; if you write `[Z..]` you'll get the
>    dot-operator imported from module Z.
>
> From this point of view, Haskell's use of `(.)` as an infix operator for
> composition is an aberration.   And parsing `f r.x` as `f (r.x)` is
> consistent with our parse of `f M.x`.
>
>    1. An alternative point of view is to regard `(.)` as a fully fledged
>    operator, and all the stuff about qualified names, enumerations and so on,
>    as a sad aberration.  Under this point of view, record selection just makes
>    the aberration worse.
>
> I realise that one reason I want the `f (r.x)` parse so strongly is my
> previously-implicit espousal of (A); perhaps making that explicit will help
> frame the conversation.  I’m also very un-keen on making `r.x` illegal,
> which is another alternative in theory.
>
> TL;DR.  Does anyone (who wants to accept the proposal in some form)
> seriously oppose the `f (r.x)` parse for `f r.x`?  I hope that it'll be at
> least acceptable to everyone, and we can more on.
>
> Thanks
>
> Simon
> _______________________________________________
> 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/20191216/d5746421/attachment-0001.html>

From eric at seidel.io  Tue Dec 17 01:57:46 2019
From: eric at seidel.io (Eric Seidel)
Date: Mon, 16 Dec 2019 20:57:46 -0500
Subject: [ghc-steering-committee] Records again
In-Reply-To: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>

On Mon, Dec 16, 2019, at 18:48, Simon Peyton Jones via ghc-steering-committee wrote:
> Assuming that we want to accept some version, *I'd like to propose that 
> we adopt the idea that `f r.x` means `f (r.x)`*, and not the record 
> selection `(f r).x`

I would be content with either parse. The thing I found compelling about
Joachim's suggestion was that it makes the syntax around `.` a bit less
whitespace-sensitive.

My concerns have been mostly around the meaning of a bare `.x`, as in

 f r.x
 .y

It seems like the committee is largely in agreement that a bare `.x` should
not desugar to `\r -> r.x`. My reasoning is similar to what Chris Done[1] and
Chris Smith[2] have articulated on the GitHub thread, namely that you should
be able to split a deep record access across multiple lines without resorting
to syntactic contortions like

 f (r.x
 ).y

So, if we are all content with `f r.x` meaning `f (r.x)` and with a bare `.x` not
desugaring to `\r -> r.x`, there's still a question of how to parse

 f r.x
 .y

Does it parse as

 f ((r.x) -- (A)
 .y)

or

 (f (r.x)) -- (B)
 .y

or

 ERROR -- (C)

(A) would mean that field access binds more tightly than function application. I
think the result is intuitive, but the only precedent we have for binding tighter
than function application is record syntax, which is widely criticized (including
by myself).

(B) means the opposite, application binds more tightly than field access. I'm not
sure how I feel about this. It seems prone to misinterpretation, but perhaps we can
learn to adapt to it (ironically) the way we've adapted to record syntax.

(C) means that function application and field access don't associate. I believe
Richard suggested this previously, and I think it's actually a pretty sensible
solution. If you want to combine the two, you must disambiguate for us. This
means that I'd have to write my example as

 f (r.x
 .y)

which still looks perfectly fine to me.

Eric

[1]: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-546645661
[2]: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-547606770

> Joachim floated the `(f r).x` idea recently and Richard supported him. 
> I consulted the authors who said "Interestingly, the very first version 
> of the prototype implemented exactly that. That behaviour surprised the 
> heck out of everyone (including you) and we were quickly and 
> overwhelmingly convinced that it was the wrong parse and updated the 
> proposal accordingly." I had a long conversation with Richard, who (I 
> think) finds both alternatives acceptable.
> 
> I agree strongly with the authors; I think `(f r).x` would be horrible, 
> and would vote against such a proposal. So, in the interests of making 
> progress, I recommend that we adopt the `f (r.x)` parse. Talking to 
> Richard I realise that a lot depends on your starting point:
> 
> 1. I regard `M.N.x` and `r.x.y` as a single token, where `.` is 
> punctuation. Space is always significant for dot; `M . x` is quite 
> different to `M.x`. Another example is the unbounded enumeration `[Z 
> ..]` where you must put the space; if you write `[Z..]` you'll get the 
> dot-operator imported from module Z. 
> From this point of view, Haskell's use of `(.)` as an infix operator 
> for composition is an aberration. And parsing `f r.x` as `f (r.x)` is 
> consistent with our parse of `f M.x`.
> 
> 1. An alternative point of view is to regard `(.)` as a fully fledged 
> operator, and all the stuff about qualified names, enumerations and so 
> on, as a sad aberration. Under this point of view, record selection 
> just makes the aberration worse.
> I realise that one reason I want the `f (r.x)` parse so strongly is my 
> previously-implicit espousal of (A); perhaps making that explicit will 
> help frame the conversation. I’m also very un-keen on making `r.x` 
> illegal, which is another alternative in theory.
> 
> TL;DR. Does anyone (who wants to accept the proposal in some form) 
> seriously oppose the `f (r.x)` parse for `f r.x`? I hope that it'll be 
> at least acceptable to everyone, and we can more on.
> 
> Thanks
> 
> Simon
> 
> _______________________________________________
> 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/20191216/24e06828/attachment.html>

From arnaud.spiwack at tweag.io  Tue Dec 17 07:17:29 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 17 Dec 2019 08:17:29 +0100
Subject: [ghc-steering-committee] Records again
In-Reply-To: <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
Message-ID: <CAH6fHQmTehwDfsxQBMZ22ZCDgeD_WeNYFWn-nnbZEauekX4WGA@mail.gmail.com>

Simon,

I'm happy with letting you choose the syntax. You've got more stake in all
this than any of us, and this is a conversation which can't end without
someone having a final word.

Let's give ourselves a deadline, after which whatever we've decided (for
example by letting Simon choose :-) ) isn't up to debate anymore.

Then we can go back to deciding on the specifics of the proposal.

On Tue, Dec 17, 2019 at 2:58 AM Eric Seidel <eric at seidel.io> wrote:

> On Mon, Dec 16, 2019, at 18:48, Simon Peyton Jones via
> ghc-steering-committee wrote:
> > Assuming that we want to accept some version, *I'd like to propose that
> > we adopt the idea that `f r.x` means `f (r.x)`*, and not the record
> > selection `(f r).x`
>
> I would be content with either parse. The thing I found compelling about
> Joachim's suggestion was that it makes the syntax around `.` a bit less
> whitespace-sensitive.
>
> My concerns have been mostly around the meaning of a bare `.x`, as in
>
>   f r.x
>      .y
>
> It seems like the committee is largely in agreement that a bare `.x` should
> not desugar to `\r -> r.x`. My reasoning is similar to what Chris Done[1]
> and
> Chris Smith[2] have articulated on the GitHub thread, namely that you
> should
> be able to split a deep record access across multiple lines without
> resorting
> to syntactic contortions like
>
>   f (r.x
>      ).y
>
> So, if we are all content with `f r.x` meaning `f (r.x)` and with a bare
> `.x` not
> desugaring to `\r -> r.x`, there's still a question of how to parse
>
>   f r.x
>      .y
>
> Does it parse as
>
>   f ((r.x)   -- (A)
>      .y)
>
> or
>
>   (f (r.x))  -- (B)
>      .y
>
> or
>
>   ERROR      -- (C)
>
> (A) would mean that field access binds more tightly than function
> application. I
> think the result is intuitive, but the only precedent we have for binding
> tighter
> than function application is record syntax, which is widely criticized
> (including
> by myself).
>
> (B) means the opposite, application binds more tightly than field access.
> I'm not
> sure how I feel about this. It seems prone to misinterpretation, but
> perhaps we can
> learn to adapt to it (ironically) the way we've adapted to record syntax.
>
> (C) means that function application and field access don't associate. I
> believe
> Richard suggested this previously, and I think it's actually a pretty
> sensible
> solution. If you want to combine the two, you must disambiguate for us.
> This
> means that I'd have to write my example as
>
>   f (r.x
>       .y)
>
> which still looks perfectly fine to me.
>
> Eric
>
> [1]:
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-546645661
> [2]:
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-547606770
>
> > Joachim floated the `(f r).x` idea recently and Richard supported him.
> > I consulted the authors who said "Interestingly, the very first version
> > of the prototype implemented exactly that. That behaviour surprised the
> > heck out of everyone (including you) and we were quickly and
> > overwhelmingly convinced that it was the wrong parse and updated the
> > proposal accordingly." I had a long conversation with Richard, who (I
> > think) finds both alternatives acceptable.
> >
> > I agree strongly with the authors; I think `(f r).x` would be horrible,
> > and would vote against such a proposal. So, in the interests of making
> > progress, I recommend that we adopt the `f (r.x)` parse. Talking to
> > Richard I realise that a lot depends on your starting point:
> >
> >  1. I regard `M.N.x` and `r.x.y` as a single token, where `.` is
> > punctuation. Space is always significant for dot; `M . x` is quite
> > different to `M.x`. Another example is the unbounded enumeration `[Z
> > ..]` where you must put the space; if you write `[Z..]` you'll get the
> > dot-operator imported from module Z.
> > From this point of view, Haskell's use of `(.)` as an infix operator
> > for composition is an aberration. And parsing `f r.x` as `f (r.x)` is
> > consistent with our parse of `f M.x`.
> >
> >  1. An alternative point of view is to regard `(.)` as a fully fledged
> > operator, and all the stuff about qualified names, enumerations and so
> > on, as a sad aberration. Under this point of view, record selection
> > just makes the aberration worse.
> > I realise that one reason I want the `f (r.x)` parse so strongly is my
> > previously-implicit espousal of (A); perhaps making that explicit will
> > help frame the conversation. I’m also very un-keen on making `r.x`
> > illegal, which is another alternative in theory.
> >
> > TL;DR. Does anyone (who wants to accept the proposal in some form)
> > seriously oppose the `f (r.x)` parse for `f r.x`? I hope that it'll be
> > at least acceptable to everyone, and we can more on.
> >
> > Thanks
> >
> > Simon
> >
> > _______________________________________________
> > 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/20191217/f28fb96a/attachment-0001.html>

From mail at joachim-breitner.de  Tue Dec 17 10:05:25 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 17 Dec 2019 11:05:25 +0100
Subject: [ghc-steering-committee] #301: Rename PtrRep to BoxedRep,
 recommending: accept
In-Reply-To: <138e6484b66c931c4e121171e9030a411606cc20.camel@joachim-breitner.de>
References: <138e6484b66c931c4e121171e9030a411606cc20.camel@joachim-breitner.de>
Message-ID: <5e95bb9865db2eb62ffe003742459d07ac6059a8.camel@joachim-breitner.de>

Hi,

accepted!

Cheers,
Joachim

Am Dienstag, den 10.12.2019, 13:56 +0100 schrieb Joachim Breitner:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Rename PtrRep to BoxedRep
> has been proposed by Neil Andrew Martin
> https://github.com/ghc-proposals/ghc-proposals/pull/301
> 
> I’ll shepherd that myself.
> 
> It’s a simple renaming in an existing proposal, clarifying a somewhat
> misleading name (PtrRep) to a more precise one (BoxedRep). This looks
> reasonable and helpful, so I am happy to propose acceptance.
> 
> Any objections?
> 
> 
> 
> Cheers,
> Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From mail at joachim-breitner.de  Tue Dec 17 10:32:30 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 17 Dec 2019 11:32:30 +0100
Subject: [ghc-steering-committee] Records again
In-Reply-To: <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
Message-ID: <17a99d416f45ef771f70c3fbeafc1c35e4851d7a.camel@joachim-breitner.de>

Hi,

Eric nicely summarizes my thoughts

I am a happy user of

  f r.x .y = f (r.x.y)

in Ocaml, and I agree that it is not an absolutely horrible choice, and
will likely vote it over Reject.


I would find it bad, though, if we have

  f r.x.y = f (r.x.y)

but disallow or give completely different meaning (as in the bare .y
variants) to

  f r.x .y

(where the space could still be a newline). Record accessors can
possibly be deeply nested, so it should be possible to nicely wrap or
vertically align the code. This indicates that postfix .x should parse
similar to postfix `{x=1}` (what a nice coincidence that both relate to
records).

So while I fully understand the analogy to module qualifiers, this
aspect already makes them different.


In the end I am a big fan of the fundamental rule of mentally parsing
Haskell code, namely “function composition binds most tightly and
associates to the left”.
Yes, there are exceptions (qualified names, record updates).
And yes, variant “JS” and “JS+Section” are still a slight exception to
that rule (as there record accessors associate with function
application).

So maybe my current thinking is

 JS+Section > JS > Ocaml+Section > Ocaml > SectionSelector
    > Reject > OnlySelection > PlainSelector


I.e. I will support `f r.x = f (r.x)`, if I can still add space
before the .x.

I am not yet completely decided what to think of disallowing `f r .x`.



Oh, and here is a nice way to justify the JS variants functionally. Not
sure if it is helpful…
A record r with fields foo and bar can be thought of as a _function_
with domain {.foo, .bar}. In that point of view,  the syntax 
   f .foo




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


From mail at joachim-breitner.de  Tue Dec 17 10:36:53 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 17 Dec 2019 11:36:53 +0100
Subject: [ghc-steering-committee] Records again
In-Reply-To: <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
Message-ID: <b317d8895b51226eecccedc2210e4bc2a0f09646.camel@joachim-breitner.de>

[continuation, hit sent too soon, sorry]

Oh, and here is a nice way to justify the JS variant in a very
functionally motivated way. Not sure if it is helpful, though, but it
certainly is a cute angle…

A record r with fields foo and bar can be thought of as a _function_
with domain {.foo, .bar} (and a dependent return type, but we are
talking syntax, not types).

With that point of view, the syntax 

   r .foo

_is_ simply function application. And we do not need _any_ custom
mental parsing rules at all, and get

  f r.field y    = ((f r).field) y
  f r .field y   = ((f r).field) y

and now of course you write

  f (r.x)

or

  f (r .x)

just like you would write

  f (g x)




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


From rae at richarde.dev  Tue Dec 17 10:39:39 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 17 Dec 2019 10:39:39 +0000
Subject: [ghc-steering-committee] Records again
In-Reply-To: <17a99d416f45ef771f70c3fbeafc1c35e4851d7a.camel@joachim-breitner.de>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
 <17a99d416f45ef771f70c3fbeafc1c35e4851d7a.camel@joachim-breitner.de>
Message-ID: <EC225264-890D-4E12-B99E-05F810CD17B5@richarde.dev>



> On Dec 17, 2019, at 10:32 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> I would find it bad, though, if we have
> 
>  f r.x.y = f (r.x.y)
> 
> but disallow or give completely different meaning (as in the bare .y
> variants) to
> 
>  f r.x .y


Just to repeat one of Simon's arguments he used against me yesterday: How do you feel about `f x_y` vs `f x _y`? We have no trouble accepting that whitespace is significant there. If we accept that `.` is part of the construction of a token, then this is all very natural. Somehow, we read `_` this way. If we view `.` as something else, then it's much harder.

I'm in the "view as something else" camp, but the argument above made me realize that I didn't have to revise the whole way I parse Haskell in order to understand the new syntax -- I just have to reclassify the lexical category of `.`.

In the end, I don't feel strongly about this all. And (for me) the authors' comments that `f r.x = (f r).x` is abhorrent carries weight.

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

From mail at joachim-breitner.de  Tue Dec 17 11:21:02 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 17 Dec 2019 12:21:02 +0100
Subject: [ghc-steering-committee] Records again
In-Reply-To: <EC225264-890D-4E12-B99E-05F810CD17B5@richarde.dev>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
 <17a99d416f45ef771f70c3fbeafc1c35e4851d7a.camel@joachim-breitner.de>
 <EC225264-890D-4E12-B99E-05F810CD17B5@richarde.dev>
Message-ID: <fd9be8897fb500597d12fdeef2b0bb5ab31932ff.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 17.12.2019, 10:39 +0000 schrieb Richard Eisenberg:
> How do you feel about `f x_y` vs `f x _y`? We have no trouble
> accepting that whitespace is significant there.

or even `f x'y` vs. `f x 'y`!


> If we accept that `.` is part of the construction of a token, then
> this is all very natural. Somehow, we read `_` this way. If we view
> `.` as something else, then it's much harder.

I find that argument not very strong. Clearly f_x or f'x is one atomic
token on a very different level than f.x is a token.

Of course, I am sure I’ll as quickly adapt to parsing `f r.x` as
`f (r.x)` as I did parsing `f r{x=1}` as `f (r {x=1})`.

Cheers,
Joachim

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


From simonpj at microsoft.com  Tue Dec 17 11:46:04 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 17 Dec 2019 11:46:04 +0000
Subject: [ghc-steering-committee] Records again
In-Reply-To: <17a99d416f45ef771f70c3fbeafc1c35e4851d7a.camel@joachim-breitner.de>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
 <17a99d416f45ef771f70c3fbeafc1c35e4851d7a.camel@joachim-breitner.de>
Message-ID: <VI1PR8303MB0093B8C242269634F89D0EA0AD500@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

| I.e. I will support `f r.x = f (r.x)`, if I can still add space before the
| .x.

That gets into a separate question, the "naked selector" question.  There we have the following viable alternatives

(1) .x is illegal
(2) .x means (\r. r.x)
(3) .x is a postfix operator

Certainly (3) would all you to write
	r .x .y        meaning r.x.y
or
	f (r .x .y)    meaning f (r.x.y)

But I was trying to close the discussion of (f r.x) before opening the discussion about 1/2/3 for naked selectors.

Simon

-----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Joachim Breitner
| Sent: 17 December 2019 10:33
| To: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] Records again
| 
| Hi,
| 
| Eric nicely summarizes my thoughts
| 
| I am a happy user of
| 
|   f r.x .y = f (r.x.y)
| 
| in Ocaml, and I agree that it is not an absolutely horrible choice, and
| will likely vote it over Reject.
| 
| 
| I would find it bad, though, if we have
| 
|   f r.x.y = f (r.x.y)
| 
| but disallow or give completely different meaning (as in the bare .y
| variants) to
| 
|   f r.x .y
| 
| (where the space could still be a newline). Record accessors can possibly
| be deeply nested, so it should be possible to nicely wrap or vertically
| align the code. This indicates that postfix .x should parse similar to
| postfix `{x=1}` (what a nice coincidence that both relate to records).
| 
| So while I fully understand the analogy to module qualifiers, this aspect
| already makes them different.
| 
| 
| In the end I am a big fan of the fundamental rule of mentally parsing
| Haskell code, namely “function composition binds most tightly and
| associates to the left”.
| Yes, there are exceptions (qualified names, record updates).
| And yes, variant “JS” and “JS+Section” are still a slight exception to that
| rule (as there record accessors associate with function application).
| 
| So maybe my current thinking is
| 
|  JS+Section > JS > Ocaml+Section > Ocaml > SectionSelector
|     > Reject > OnlySelection > PlainSelector
| 
| 
| I.e. I will support `f r.x = f (r.x)`, if I can still add space before the
| .x.
| 
| I am not yet completely decided what to think of disallowing `f r .x`.
| 
| 
| 
| Oh, and here is a nice way to justify the JS variants functionally. Not
| sure if it is helpful… A record r with fields foo and bar can be thought of
| as a _function_ with domain {.foo, .bar}. In that point of view,  the
| syntax
|    f .foo
| 
| 
| 
| 
| 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  Tue Dec 17 14:26:27 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 17 Dec 2019 15:26:27 +0100
Subject: [ghc-steering-committee] Records again
In-Reply-To: <VI1PR8303MB0093B8C242269634F89D0EA0AD500@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
 <17a99d416f45ef771f70c3fbeafc1c35e4851d7a.camel@joachim-breitner.de>
 <VI1PR8303MB0093B8C242269634F89D0EA0AD500@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <a22e9f800b04f7bb9032ffb0fa38ebcad3af8cba.camel@joachim-breitner.de>

Hi,


Am Dienstag, den 17.12.2019, 11:46 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> > I.e. I will support `f r.x = f (r.x)`, if I can still add space before the
> > .x.
> 
> That gets into a separate question, the "naked selector" question.  There we have the following viable alternatives
> 
> (1) .x is illegal
> (2) .x means (\r. r.x)
> (3) .x is a postfix operator
> 
> Certainly (3) would all you to write
> 	r .x .y        meaning r.x.y
> or
> 	f (r .x .y)    meaning f (r.x.y)
> 
> But I was trying to close the discussion of (f r.x) before opening the discussion about 1/2/3 for naked selectors.

I don't think it can be answered separately. Maybe it can be seen as a
clearly separate question if one strongly believes that `r.f` is the
roughly the same thing as `M.f`. While I understand that view, I do not
strongly believe in it, e.g. because we have `(complex expression).f`
and `r.f.g.h`, and this shows me that `e.f` is a more complex and less
atomic notion than a qualified name `M.f`.

In order to form a decision about `f r.x = f (r.x)` I also need to know
whether I can, for example, align vertically (a very Haskelly desire)
without changing meaning:

   printf "%s %s"  grandfather.first_name  grandfather.last_name
   printf "%s %s"  mom        .first_name  mom        .last_name
   printf "%s %s"  (kid!!0   ).first_name  (kid!!0)   .last_name


(I am not saying that this is universally good style, but it is also
not completely unreasonable.)

Cheers,
Joachim

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


From simonpj at microsoft.com  Tue Dec 17 16:05:00 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 17 Dec 2019 16:05:00 +0000
Subject: [ghc-steering-committee] Records again
In-Reply-To: <a22e9f800b04f7bb9032ffb0fa38ebcad3af8cba.camel@joachim-breitner.de>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
 <17a99d416f45ef771f70c3fbeafc1c35e4851d7a.camel@joachim-breitner.de>
 <VI1PR8303MB0093B8C242269634F89D0EA0AD500@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <a22e9f800b04f7bb9032ffb0fa38ebcad3af8cba.camel@joachim-breitner.de>
Message-ID: <VI1PR8303MB0093479ABBEC094F0DEE8DF2AD500@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

|  In order to form a decision about `f r.x = f (r.x)` I also need to
|  know
|  whether I can, for example, align vertically (a very Haskelly desire)
|  without changing meaning:
|  
|     printf "%s %s"  grandfather.first_name  grandfather.last_name
|     printf "%s %s"  mom        .first_name  mom        .last_name
|     printf "%s %s"  (kid!!0   ).first_name  (kid!!0)   .last_name

If we choose (1) for naked selectors then the second and third are illegal because .x is illegal.

If we choose (3) for naked selectors then you can do what you want, but with parens:

|     printf "%s %s"   grandfather.first_name    grandfather.last_name
|     printf "%s %s"  (mom        .first_name)  (mom        .last_name)
|     printf "%s %s"  ((kid!!0   ).first_name)  ((kid!!0)   .last_name)

The parens are only reqd if you want spaces.

Simon


|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 17 December 2019 14:26
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Records again
|  
|  Hi,
|  
|  
|  Am Dienstag, den 17.12.2019, 11:46 +0000 schrieb Simon Peyton Jones
|  via
|  ghc-steering-committee:
|  > > I.e. I will support `f r.x = f (r.x)`, if I can still add space
|  before the
|  > > .x.
|  >
|  > That gets into a separate question, the "naked selector" question.
|  There we have the following viable alternatives
|  >
|  > (1) .x is illegal
|  > (2) .x means (\r. r.x)
|  > (3) .x is a postfix operator
|  >
|  > Certainly (3) would all you to write
|  > 	r .x .y        meaning r.x.y
|  > or
|  > 	f (r .x .y)    meaning f (r.x.y)
|  >
|  > But I was trying to close the discussion of (f r.x) before opening
|  the discussion about 1/2/3 for naked selectors.
|  
|  I don't think it can be answered separately. Maybe it can be seen as a
|  clearly separate question if one strongly believes that `r.f` is the
|  roughly the same thing as `M.f`. While I understand that view, I do
|  not
|  strongly believe in it, e.g. because we have `(complex expression).f`
|  and `r.f.g.h`, and this shows me that `e.f` is a more complex and less
|  atomic notion than a qualified name `M.f`.
|  
|  In order to form a decision about `f r.x = f (r.x)` I also need to
|  know
|  whether I can, for example, align vertically (a very Haskelly desire)
|  without changing meaning:
|  
|     printf "%s %s"  grandfather.first_name  grandfather.last_name
|     printf "%s %s"  mom        .first_name  mom        .last_name
|     printf "%s %s"  (kid!!0   ).first_name  (kid!!0)   .last_name
|  
|  
|  (I am not saying that this is universally good style, but it is also
|  not completely unreasonable.)
|  
|  Cheers,
|  Joachim
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cada7e617f6
|  5f48d4bb0608d782fd24de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7121896074980463&amp;sdata=QgmqcOorDYvxZZV%2Frwc1D1nI2fgi75cvA7yVRf5H1
|  Ws%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%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cada7e617f65f48d
|  4bb0608d782fd24de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371218
|  96074980463&amp;sdata=kggIGRSDlzD%2FIX2zwO8mWL59ZzK9YzUNcnakt3Qt4EU%3D
|  &amp;reserved=0

From marlowsd at gmail.com  Wed Dec 18 14:28:05 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 18 Dec 2019 14:28:05 +0000
Subject: [ghc-steering-committee] Records again
In-Reply-To: <EC225264-890D-4E12-B99E-05F810CD17B5@richarde.dev>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
 <17a99d416f45ef771f70c3fbeafc1c35e4851d7a.camel@joachim-breitner.de>
 <EC225264-890D-4E12-B99E-05F810CD17B5@richarde.dev>
Message-ID: <CANsrgPJPipdUDJpku4L7y3048KvR29WujzsurjNPjZ3eE0uWKQ@mail.gmail.com>

On Tue, 17 Dec 2019 at 11:10, Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Dec 17, 2019, at 10:32 AM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> I would find it bad, though, if we have
>
>  f r.x.y = f (r.x.y)
>
> but disallow or give completely different meaning (as in the bare .y
> variants) to
>
>  f r.x .y
>
>
> Just to repeat one of Simon's arguments he used against me yesterday: How
> do you feel about `f x_y` vs `f x _y`? We have no trouble accepting that
> whitespace is significant there. If we accept that `.` is part of the
> construction of a token, then this is all very natural. Somehow, we read
> `_` this way. If we view `.` as something else, then it's much harder.
>

The counter-argument to this is that "x" and "_y" are lexemes of the same
class (varid) but "." and "y" are not. A principle I like to use when
designing syntax is that whitespace should be necessary only for separating
lexemes of the same class, otherwise it should be optional.

(as an interesting exercise see if you can find places where this is
violated in the Haskell 2010 lexical syntax. And then see if you can find
the (many more) places it's violated in GHC's lexical syntax).

Cheers
Simon


I'm in the "view as something else" camp, but the argument above made me
> realize that I didn't have to revise the whole way I parse Haskell in order
> to understand the new syntax -- I just have to reclassify the lexical
> category of `.`.
>
> In the end, I don't feel strongly about this all. And (for me) the
> authors' comments that `f r.x = (f r).x` is abhorrent carries weight.
>
> Richard
> _______________________________________________
> 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/20191218/b00897c0/attachment.html>

From iavor.diatchki at gmail.com  Wed Dec 18 18:36:05 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 18 Dec 2019 10:36:05 -0800
Subject: [ghc-steering-committee] Records again
In-Reply-To: <CANsrgPJPipdUDJpku4L7y3048KvR29WujzsurjNPjZ3eE0uWKQ@mail.gmail.com>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
 <17a99d416f45ef771f70c3fbeafc1c35e4851d7a.camel@joachim-breitner.de>
 <EC225264-890D-4E12-B99E-05F810CD17B5@richarde.dev>
 <CANsrgPJPipdUDJpku4L7y3048KvR29WujzsurjNPjZ3eE0uWKQ@mail.gmail.com>
Message-ID: <CAGK9nuowEjcpZoYHP2_vc5k3MXE=PF2Gx_aS7aHLbw1LwZovaw@mail.gmail.com>

That's a very good point---I guess I tend to do this too, but I had never
really thought about the underlying rule.  Thanks!

On Wed, Dec 18, 2019 at 6:28 AM Simon Marlow <marlowsd at gmail.com> wrote:

>
> On Tue, 17 Dec 2019 at 11:10, Richard Eisenberg <rae at richarde.dev> wrote:
>
>>
>>
>> On Dec 17, 2019, at 10:32 AM, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>> I would find it bad, though, if we have
>>
>>  f r.x.y = f (r.x.y)
>>
>> but disallow or give completely different meaning (as in the bare .y
>> variants) to
>>
>>  f r.x .y
>>
>>
>> Just to repeat one of Simon's arguments he used against me yesterday: How
>> do you feel about `f x_y` vs `f x _y`? We have no trouble accepting that
>> whitespace is significant there. If we accept that `.` is part of the
>> construction of a token, then this is all very natural. Somehow, we read
>> `_` this way. If we view `.` as something else, then it's much harder.
>>
>
> The counter-argument to this is that "x" and "_y" are lexemes of the same
> class (varid) but "." and "y" are not. A principle I like to use when
> designing syntax is that whitespace should be necessary only for separating
> lexemes of the same class, otherwise it should be optional.
>
> (as an interesting exercise see if you can find places where this is
> violated in the Haskell 2010 lexical syntax. And then see if you can find
> the (many more) places it's violated in GHC's lexical syntax).
>
> Cheers
> Simon
>
>
> I'm in the "view as something else" camp, but the argument above made me
>> realize that I didn't have to revise the whole way I parse Haskell in order
>> to understand the new syntax -- I just have to reclassify the lexical
>> category of `.`.
>>
>> In the end, I don't feel strongly about this all. And (for me) the
>> authors' comments that `f r.x = (f r).x` is abhorrent carries weight.
>>
>> Richard
>> _______________________________________________
>> 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/20191218/0fbfca09/attachment.html>

From marlowsd at gmail.com  Thu Dec 19 08:58:12 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 19 Dec 2019 08:58:12 +0000
Subject: [ghc-steering-committee] Records again
In-Reply-To: <VI1PR8303MB0093B8C242269634F89D0EA0AD500@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB0093CD63958CAC2441994C47AD510@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <c31b28ee-c7b7-4ffe-b6f5-51bac0c0185d@www.fastmail.com>
 <17a99d416f45ef771f70c3fbeafc1c35e4851d7a.camel@joachim-breitner.de>
 <VI1PR8303MB0093B8C242269634F89D0EA0AD500@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgPKaGcjZWdVNCDCvQ-0Oee_29icThdJywQKbRAmg3d_L6g@mail.gmail.com>

The treatment of ".x" as a postfix operator that binds more tightly than
function application seems like a reasonable position to me. It accounts
for

 f r.x =>  f (r.x)

and also means that we can split a chain of record selectors over multiple
lines. It does diverge from qualified name syntax, but I think that was
already the case since we intend that the left-hand side of a record
selection is an expression, not an identifier - in fact it would be an aexp
in terms of the Haskell grammar.  So the new lexeme is the ".varid" record
selector and we're only discussing what happens at the context-free grammar
level.

Cheers
Simon


On Tue, 17 Dec 2019 at 11:46, Simon Peyton Jones via ghc-steering-committee
<ghc-steering-committee at haskell.org> wrote:

> | I.e. I will support `f r.x = f (r.x)`, if I can still add space before
> the
> | .x.
>
> That gets into a separate question, the "naked selector" question.  There
> we have the following viable alternatives
>
> (1) .x is illegal
> (2) .x means (\r. r.x)
> (3) .x is a postfix operator
>
> Certainly (3) would all you to write
>         r .x .y        meaning r.x.y
> or
>         f (r .x .y)    meaning f (r.x.y)
>
> But I was trying to close the discussion of (f r.x) before opening the
> discussion about 1/2/3 for naked selectors.
>
> Simon
>
> -----Original Message-----
> | From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org
> >
> | On Behalf Of Joachim Breitner
> | Sent: 17 December 2019 10:33
> | To: ghc-steering-committee at haskell.org
> | Subject: Re: [ghc-steering-committee] Records again
> |
> | Hi,
> |
> | Eric nicely summarizes my thoughts
> |
> | I am a happy user of
> |
> |   f r.x .y = f (r.x.y)
> |
> | in Ocaml, and I agree that it is not an absolutely horrible choice, and
> | will likely vote it over Reject.
> |
> |
> | I would find it bad, though, if we have
> |
> |   f r.x.y = f (r.x.y)
> |
> | but disallow or give completely different meaning (as in the bare .y
> | variants) to
> |
> |   f r.x .y
> |
> | (where the space could still be a newline). Record accessors can possibly
> | be deeply nested, so it should be possible to nicely wrap or vertically
> | align the code. This indicates that postfix .x should parse similar to
> | postfix `{x=1}` (what a nice coincidence that both relate to records).
> |
> | So while I fully understand the analogy to module qualifiers, this aspect
> | already makes them different.
> |
> |
> | In the end I am a big fan of the fundamental rule of mentally parsing
> | Haskell code, namely “function composition binds most tightly and
> | associates to the left”.
> | Yes, there are exceptions (qualified names, record updates).
> | And yes, variant “JS” and “JS+Section” are still a slight exception to
> that
> | rule (as there record accessors associate with function application).
> |
> | So maybe my current thinking is
> |
> |  JS+Section > JS > Ocaml+Section > Ocaml > SectionSelector
> |     > Reject > OnlySelection > PlainSelector
> |
> |
> | I.e. I will support `f r.x = f (r.x)`, if I can still add space before
> the
> | .x.
> |
> | I am not yet completely decided what to think of disallowing `f r .x`.
> |
> |
> |
> | Oh, and here is a nice way to justify the JS variants functionally. Not
> | sure if it is helpful… A record r with fields foo and bar can be thought
> of
> | as a _function_ with domain {.foo, .bar}. In that point of view,  the
> | syntax
> |    f .foo
> |
> |
> |
> |
> | 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/20191219/9589f7ed/attachment-0001.html>