I just added my vote to the document, apologies for the delay. It is quite interesting looking at the other votes, as some of them seem to be exactly the opposite of what I think should be done :-) Hope everyone is staying healthy! Cheers, -Iavor On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard wrote:

On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via ghc-steering-committee wrote:

...

Overall, I strongly urge that we accept the proposal in some form; that is, we should not do (C1). I have been unhappy with GHC's story for records for two decades. (E.g. Lightweight extensible records for Haskell, Haskell Workshop, Paris 1999.) But the design space is so complicated that we never found something that felt "obviously right". So we did nothing drastic, and I think that was right.

I'm not sure any of these proposed options feels "obviously right" either. The fact that we're voting between many different ways to interpret the same syntax sugar should make it clear that this isn't so obvious.

...

But there was incremental progress, sketched here:

DuplicateRecordFields lets you have multiple records with the same field name. The HasField class lets us define overloaded record selection and update functions.

The proposal we are now discussing has no type-system component; it is only about syntactic sugar, allowing you to use dot-notation for field selection. (Various extensions about syntax for update were discussed, but no longer form part of the proposal; what is left is the core.)

I really think this change has vastly higher impact and utility than many other accepted proposals. I know that some members of the committee differ from this view; that's fair enough.

While I'd agree it has vastly higher impact that a lot of accepted proposals, I'm not sure that impact is actually in the direction of making it easier to read and understand programs that are written in Haskell. It's syntactic sugar that we've pretty reasonably done without for a long time. Piling on yet another option for how to select fields from records amidst a sea of libraries that already help with this in various ways that go far beyond the capabilities of the syntax sugar that's proposed here seems a bit strange to me at this point. It feels like the complaint is "but I want to type exactly this string of characters and no other will do", which seems kind of absurd to me, but other languages exist in the world, and DAML for instance is a thing which exists now and should satisfy those people. I don't particularly get why it's of great importance for Haskell to support accessing fields with *this* syntax, and not dozens of almost-equivalent syntaxes that one could already achieve.

If there were no confusion over what the infix dot meant and how it interacted with the rest of Haskell's syntax, then maybe there wouldn't be anything much to be unhappy about in adding in this extra bit of sugar. But it is manifestly confusing or else we wouldn't be having this vote and so many clarifications about what consequences the options had wouldn't have been needed. All these syntactic questions that have been asked and debated in this thread are something that every beginner will have to contend with, and all the consequences of whatever option is selected are something every expert will have to live with. I don't feel that it's worth the extremely meagre benefit of the difference between this and just opting to use lens or otherwise just using the already existing mechanisms.

Frankly, I still mostly use Haskell's ordinary field accessors unless there's a real need for abstracting over a lens (at which point I'll switch to using Ed's lens library), or just abstracting over field access (at which point I'll probably define my own class), and DuplicateRecordFields and the associated machinery is not something that I have had a whole lot of love for in the first place. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon, Alejandro, we are awaiting your votes. https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7i... Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Eric Seidel | Sent: 24 March 2020 18:09 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote | | I noticed the same thing, I don't see anything remotely resembling a | consensus in the votes. Just out of curiousity Joachim, does the Schulze | method have any metric of how close or far from a consensus the votes are? | If so, I'd be very interested to see what it says about the votes here. | | Let me also take a moment to explain why I voted for C4 as my first | choice, since it seems to be particularly polarizing. The two factors that | pushed me to favor C4 are its simplicity and its consistency with the rest | of Haskell's record syntax. | | C4 is a very simple rule, it introduces a single new lexeme ('.x') and a | single rule for parsing it (it's a postfix operator that binds tighter | than application). In my opinion it's the simplest rule after C2b (which I | also ranked highly). The other rules all introduce extra complexity into | the syntax, often around treating 'r.x' or 'M.r.x' as a single lexeme in | constrast to the interpretation of a bare '.x'. The simplest solution is | not always the best one, but I believe C4 will at least be easier to learn | and become comfortable with, even if it doesn't always produce the parses | you would like. | | C4 is also consistent with Haskell's record creation/update syntax. I know | a lot of people dislike the fact that record creation/update binds tighter | than application. Simon PJ says he would argue strenuously against it if | we were designing Haskell from scratch today, and I'm pretty sympathetic | to that position. But we aren't redesigning Haskell's syntax today, we're | trying to fit a new piece of syntax into an existing grammar. Given those | constraints, I think it makes a lot of sense to lean on the intuitions | that people have already built about how record syntax behaves. | | Hope everyone is well, and not going too stir crazy at home! | Eric | | On Tue, Mar 24, 2020, at 13:32, Iavor Diatchki wrote: | > I just added my vote to the document, apologies for the delay. It is | > quite interesting looking at the other votes, as some of them seem to | > be exactly the opposite of what I think should be done :-) | > | > Hope everyone is staying healthy! | > Cheers, | > -Iavor | > | > On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard wrote: | > > On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via | > > ghc-steering-committee wrote: | > > > Overall, I strongly urge that we accept the proposal in some form; | that is, we should not do (C1). I have been unhappy with GHC's story for | records for two decades. (E.g. Lightweight extensible records for Haskell, | Haskell Workshop, Paris 1999.) But the design space is so complicated that | we never found something that felt "obviously right". So we did nothing | drastic, and I think that was right. | > > | > > I'm not sure any of these proposed options feels "obviously right" | > > either. The fact that we're voting between many different ways to | > > interpret the same syntax sugar should make it clear that this isn't | > > so obvious. | > > | > > > But there was incremental progress, sketched here: | > > > | > > > DuplicateRecordFields lets you have multiple records with the same | field name. | > > > The HasField class lets us define overloaded record selection and | update functions. | > > > | > > > The proposal we are now discussing has no type-system component; it | is only about syntactic sugar, allowing you to use dot-notation for field | selection. (Various extensions about syntax for update were discussed, but | no longer form part of the proposal; what is left is the core.) | > > > | > > > I really think this change has vastly higher impact and utility | than many other accepted proposals. I know that some members of the | committee differ from this view; that's fair enough. | > > | > > While I'd agree it has vastly higher impact that a lot of accepted | > > proposals, I'm not sure that impact is actually in the direction of | > > making it easier to read and understand programs that are written in | > > Haskell. It's syntactic sugar that we've pretty reasonably done | > > without for a long time. Piling on yet another option for how to | > > select fields from records amidst a sea of libraries that already | help | > > with this in various ways that go far beyond the capabilities of the | > > syntax sugar that's proposed here seems a bit strange to me at this | > > point. It feels like the complaint is "but I want to type exactly | this | > > string of characters and no other will do", which seems kind of | absurd | > > to me, but other languages exist in the world, and DAML for instance | > > is a thing which exists now and should satisfy those people. I don't | > > particularly get why it's of great importance for Haskell to support | > > accessing fields with *this* syntax, and not dozens of | > > almost-equivalent syntaxes that one could already achieve. | > > | > > If there were no confusion over what the infix dot meant and how it | > > interacted with the rest of Haskell's syntax, then maybe there | > > wouldn't be anything much to be unhappy about in adding in this extra | > > bit of sugar. But it is manifestly confusing or else we wouldn't be | > > having this vote and so many clarifications about what consequences | > > the options had wouldn't have been needed. All these syntactic | > > questions that have been asked and debated in this thread are | > > something that every beginner will have to contend with, and all the | > > consequences of whatever option is selected are something every | expert | > > will have to live with. I don't feel that it's worth the extremely | > > meagre benefit of the difference between this and just opting to use | > > lens or otherwise just using the already existing mechanisms. | > > | > > Frankly, I still mostly use Haskell's ordinary field accessors unless | > > there's a real need for abstracting over a lens (at which point I'll | > > switch to using Ed's lens library), or just abstracting over field | > > access (at which point I'll probably define my own class), and | > > DuplicateRecordFields and the associated machinery is not something | > > that I have had a whole lot of love for in the first place. | > > _______________________________________________ | > > ghc-steering-committee mailing list | > > ghc-steering-committee@haskell.org | > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee | > | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Alejandro: most likely what happened indeed. I hadn't voted yet. Now fixed. On Tue, Mar 24, 2020 at 8:20 PM Alejandro Serrano Mena wrote:

This is weird, I voted a couple of days ago. Maybe I wrote my votes in Arnaud's place?

El mar., 24 mar. 2020 20:18, Simon Peyton Jones escribió:

...

Simon, Alejandro, we are awaiting your votes.

https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7i...

Simon

| -----Original Message----- | From: ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> | On Behalf Of Eric Seidel | Sent: 24 March 2020 18:09 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote | | I noticed the same thing, I don't see anything remotely resembling a | consensus in the votes. Just out of curiousity Joachim, does the Schulze | method have any metric of how close or far from a consensus the votes are? | If so, I'd be very interested to see what it says about the votes here. | | Let me also take a moment to explain why I voted for C4 as my first | choice, since it seems to be particularly polarizing. The two factors that | pushed me to favor C4 are its simplicity and its consistency with the rest | of Haskell's record syntax. | | C4 is a very simple rule, it introduces a single new lexeme ('.x') and a | single rule for parsing it (it's a postfix operator that binds tighter | than application). In my opinion it's the simplest rule after C2b (which I | also ranked highly). The other rules all introduce extra complexity into | the syntax, often around treating 'r.x' or 'M.r.x' as a single lexeme in | constrast to the interpretation of a bare '.x'. The simplest solution is | not always the best one, but I believe C4 will at least be easier to learn | and become comfortable with, even if it doesn't always produce the parses | you would like. | | C4 is also consistent with Haskell's record creation/update syntax. I know | a lot of people dislike the fact that record creation/update binds tighter | than application. Simon PJ says he would argue strenuously against it if | we were designing Haskell from scratch today, and I'm pretty sympathetic | to that position. But we aren't redesigning Haskell's syntax today, we're | trying to fit a new piece of syntax into an existing grammar. Given those | constraints, I think it makes a lot of sense to lean on the intuitions | that people have already built about how record syntax behaves. | | Hope everyone is well, and not going too stir crazy at home! | Eric | | On Tue, Mar 24, 2020, at 13:32, Iavor Diatchki wrote: | > I just added my vote to the document, apologies for the delay. It is | > quite interesting looking at the other votes, as some of them seem to | > be exactly the opposite of what I think should be done :-) | > | > Hope everyone is staying healthy! | > Cheers, | > -Iavor | > | > On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard wrote: | > > On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via | > > ghc-steering-committee wrote: | > > > Overall, I strongly urge that we accept the proposal in some form; | that is, we should not do (C1). I have been unhappy with GHC's story for | records for two decades. (E.g. Lightweight extensible records for Haskell, | Haskell Workshop, Paris 1999.) But the design space is so complicated that | we never found something that felt "obviously right". So we did nothing | drastic, and I think that was right. | > > | > > I'm not sure any of these proposed options feels "obviously right" | > > either. The fact that we're voting between many different ways to | > > interpret the same syntax sugar should make it clear that this isn't | > > so obvious. | > > | > > > But there was incremental progress, sketched here: | > > > | > > > DuplicateRecordFields lets you have multiple records with the same | field name. | > > > The HasField class lets us define overloaded record selection and | update functions. | > > > | > > > The proposal we are now discussing has no type-system component; it | is only about syntactic sugar, allowing you to use dot-notation for field | selection. (Various extensions about syntax for update were discussed, but | no longer form part of the proposal; what is left is the core.) | > > > | > > > I really think this change has vastly higher impact and utility | than many other accepted proposals. I know that some members of the | committee differ from this view; that's fair enough. | > > | > > While I'd agree it has vastly higher impact that a lot of accepted | > > proposals, I'm not sure that impact is actually in the direction of | > > making it easier to read and understand programs that are written in | > > Haskell. It's syntactic sugar that we've pretty reasonably done | > > without for a long time. Piling on yet another option for how to | > > select fields from records amidst a sea of libraries that already | help | > > with this in various ways that go far beyond the capabilities of the | > > syntax sugar that's proposed here seems a bit strange to me at this | > > point. It feels like the complaint is "but I want to type exactly | this | > > string of characters and no other will do", which seems kind of | absurd | > > to me, but other languages exist in the world, and DAML for instance | > > is a thing which exists now and should satisfy those people. I don't | > > particularly get why it's of great importance for Haskell to support | > > accessing fields with *this* syntax, and not dozens of | > > almost-equivalent syntaxes that one could already achieve. | > > | > > If there were no confusion over what the infix dot meant and how it | > > interacted with the rest of Haskell's syntax, then maybe there | > > wouldn't be anything much to be unhappy about in adding in this extra | > > bit of sugar. But it is manifestly confusing or else we wouldn't be | > > having this vote and so many clarifications about what consequences | > > the options had wouldn't have been needed. All these syntactic | > > questions that have been asked and debated in this thread are | > > something that every beginner will have to contend with, and all the | > > consequences of whatever option is selected are something every | expert | > > will have to live with. I don't feel that it's worth the extremely | > > meagre benefit of the difference between this and just opting to use | > > lens or otherwise just using the already existing mechanisms. | > > | > > Frankly, I still mostly use Haskell's ordinary field accessors unless | > > there's a real need for abstracting over a lens (at which point I'll | > > switch to using Ed's lens library), or just abstracting over field | > > access (at which point I'll probably define my own class), and | > > DuplicateRecordFields and the associated machinery is not something | > > that I have had a whole lot of love for in the first place. | > > _______________________________________________ | > > ghc-steering-committee mailing list | > > ghc-steering-committee@haskell.org | > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee | > | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

It is quite interesting looking at the other votes, as some of them seem to be exactly the opposite of what I think should be done :-) Indeed. I’m intrigued by how strenuously you dislike C6 (you would prefer to reject the entire proposal than have C6), even though C6 is but a mild variation of qualified names. Would you like to say why? Simon From: Iavor Diatchki Sent: 24 March 2020 17:32 To: Cale Gibbard Cc: Simon Peyton Jones ; ghc-steering-committee Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote I just added my vote to the document, apologies for the delay. It is quite interesting looking at the other votes, as some of them seem to be exactly the opposite of what I think should be done :-) Hope everyone is staying healthy! Cheers, -Iavor On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard mailto:cgibbard@gmail.com> wrote: On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote:

Overall, I strongly urge that we accept the proposal in some form; that is, we should not do (C1). I have been unhappy with GHC's story for records for two decades. (E.g. Lightweight extensible records for Haskell, Haskell Workshop, Paris 1999.) But the design space is so complicated that we never found something that felt "obviously right". So we did nothing drastic, and I think that was right.

I'm not sure any of these proposed options feels "obviously right" either. The fact that we're voting between many different ways to interpret the same syntax sugar should make it clear that this isn't so obvious.

But there was incremental progress, sketched here:

DuplicateRecordFields lets you have multiple records with the same field name. The HasField class lets us define overloaded record selection and update functions.

The proposal we are now discussing has no type-system component; it is only about syntactic sugar, allowing you to use dot-notation for field selection. (Various extensions about syntax for update were discussed, but no longer form part of the proposal; what is left is the core.)

I really think this change has vastly higher impact and utility than many other accepted proposals. I know that some members of the committee differ from this view; that's fair enough.

While I'd agree it has vastly higher impact that a lot of accepted proposals, I'm not sure that impact is actually in the direction of making it easier to read and understand programs that are written in Haskell. It's syntactic sugar that we've pretty reasonably done without for a long time. Piling on yet another option for how to select fields from records amidst a sea of libraries that already help with this in various ways that go far beyond the capabilities of the syntax sugar that's proposed here seems a bit strange to me at this point. It feels like the complaint is "but I want to type exactly this string of characters and no other will do", which seems kind of absurd to me, but other languages exist in the world, and DAML for instance is a thing which exists now and should satisfy those people. I don't particularly get why it's of great importance for Haskell to support accessing fields with *this* syntax, and not dozens of almost-equivalent syntaxes that one could already achieve. If there were no confusion over what the infix dot meant and how it interacted with the rest of Haskell's syntax, then maybe there wouldn't be anything much to be unhappy about in adding in this extra bit of sugar. But it is manifestly confusing or else we wouldn't be having this vote and so many clarifications about what consequences the options had wouldn't have been needed. All these syntactic questions that have been asked and debated in this thread are something that every beginner will have to contend with, and all the consequences of whatever option is selected are something every expert will have to live with. I don't feel that it's worth the extremely meagre benefit of the difference between this and just opting to use lens or otherwise just using the already existing mechanisms. Frankly, I still mostly use Haskell's ordinary field accessors unless there's a real need for abstracting over a lens (at which point I'll switch to using Ed's lens library), or just abstracting over field access (at which point I'll probably define my own class), and DuplicateRecordFields and the associated machinery is not something that I have had a whole lot of love for in the first place. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7C402e189bd282458f6e2c08d7d0195732%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637206679602452262&sdata=AKJugFGwXrHJLrLEFU8xioCtibCWRnOml%2FWzNv7zzr0%3D&reserved=0

I don't like C6 because `e.x` has completely different meaning when `e` is a variable vs. when it is not. But that is true today! Specifically, qualified names. M.x means something very different to (f y).x What’s attractive to me about C6 is that it simply and uniformly extends qualified names. But I said that before, and your judgement differs, which is fair enough. Simon From: Iavor Diatchki Sent: 24 March 2020 19:51 To: Simon Peyton Jones Cc: Cale Gibbard ; ghc-steering-committee Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote I don't like C6 because `e.x` has completely different meaning when `e` is a variable vs. when it is not. This strikes me as quite an odd wart, and I see no benefits to it whatsoever. In fact, I can see it leading to bugs, as most Haskell programmers I know assume that you can more or less freely name or inline pure expressions without changing the meaning of the program. -Iavor On Tue, Mar 24, 2020 at 12:19 PM Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: It is quite interesting looking at the other votes, as some of them seem to be exactly the opposite of what I think should be done :-) Indeed. I’m intrigued by how strenuously you dislike C6 (you would prefer to reject the entire proposal than have C6), even though C6 is but a mild variation of qualified names. Would you like to say why? Simon From: Iavor Diatchki mailto:iavor.diatchki@gmail.com> Sent: 24 March 2020 17:32 To: Cale Gibbard mailto:cgibbard@gmail.com> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com>; ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote I just added my vote to the document, apologies for the delay. It is quite interesting looking at the other votes, as some of them seem to be exactly the opposite of what I think should be done :-) Hope everyone is staying healthy! Cheers, -Iavor On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard mailto:cgibbard@gmail.com> wrote: On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote:

Overall, I strongly urge that we accept the proposal in some form; that is, we should not do (C1). I have been unhappy with GHC's story for records for two decades. (E.g. Lightweight extensible records for Haskell, Haskell Workshop, Paris 1999.) But the design space is so complicated that we never found something that felt "obviously right". So we did nothing drastic, and I think that was right.

I'm not sure any of these proposed options feels "obviously right" either. The fact that we're voting between many different ways to interpret the same syntax sugar should make it clear that this isn't so obvious.

But there was incremental progress, sketched here:

DuplicateRecordFields lets you have multiple records with the same field name. The HasField class lets us define overloaded record selection and update functions.

The proposal we are now discussing has no type-system component; it is only about syntactic sugar, allowing you to use dot-notation for field selection. (Various extensions about syntax for update were discussed, but no longer form part of the proposal; what is left is the core.)

I really think this change has vastly higher impact and utility than many other accepted proposals. I know that some members of the committee differ from this view; that's fair enough.

While I'd agree it has vastly higher impact that a lot of accepted proposals, I'm not sure that impact is actually in the direction of making it easier to read and understand programs that are written in Haskell. It's syntactic sugar that we've pretty reasonably done without for a long time. Piling on yet another option for how to select fields from records amidst a sea of libraries that already help with this in various ways that go far beyond the capabilities of the syntax sugar that's proposed here seems a bit strange to me at this point. It feels like the complaint is "but I want to type exactly this string of characters and no other will do", which seems kind of absurd to me, but other languages exist in the world, and DAML for instance is a thing which exists now and should satisfy those people. I don't particularly get why it's of great importance for Haskell to support accessing fields with *this* syntax, and not dozens of almost-equivalent syntaxes that one could already achieve. If there were no confusion over what the infix dot meant and how it interacted with the rest of Haskell's syntax, then maybe there wouldn't be anything much to be unhappy about in adding in this extra bit of sugar. But it is manifestly confusing or else we wouldn't be having this vote and so many clarifications about what consequences the options had wouldn't have been needed. All these syntactic questions that have been asked and debated in this thread are something that every beginner will have to contend with, and all the consequences of whatever option is selected are something every expert will have to live with. I don't feel that it's worth the extremely meagre benefit of the difference between this and just opting to use lens or otherwise just using the already existing mechanisms. Frankly, I still mostly use Haskell's ordinary field accessors unless there's a real need for abstracting over a lens (at which point I'll switch to using Ed's lens library), or just abstracting over field access (at which point I'll probably define my own class), and DuplicateRecordFields and the associated machinery is not something that I have had a whole lot of love for in the first place. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7Cb584cb955faa458e38b808d7d02cb8b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637206762802861085&sdata=xfd76JSbk1LMcql5RrRjdNgepcZf5PTuKL4DT0QdU4A%3D&reserved=0

Interesting. It is quite surprising to me that people prefer C2a to C4, when they are basically the same thing, except C4 is easier to specify/implement. C2a is basically C4 but with some additional work to prohibit white white space between the selector and the preceding expression (whatever that means exactly). On Wed, Mar 25, 2020 at 2:35 AM Joachim Breitner wrote:

Hi,

if we had a simpler voting scheme, it would be obvious to everyone where wer are standing. But I don’t expect that any of us can just glance at the Google Sheet and see how things are standing.

But this obscurity is of course not intended!

So to give a preview (with Simon Marlow’s vote still missing, and of course everyone still able to refine their votes) we currently have this result:

C2a > C2b > C4 > C6 = C1 > C3 = C7 > C5

where C2a beats all other options by 6:4 or more.

In a way, C2a is one of the less bold moves. It is a typical property of ranked voting schemes that they tend to elect more moderate options.

Fun fact: While we have a natural Condorcet winner (an option preferred over any other option by a majority), we do not have a Condorcet loser: _Every_ option is preferred over some other option by a majority, because C5 beats C1, C1 beats C3, C3 beats C5.

(Now I wonder: did I confuse C2a and C2b in my vote last week? What was my intention back then? Not sure any more… I guess I valued the concept that you can take `x` and replace it with `(f x)` without affecting the surrounding concepts.)

Cheers, Joachim

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I think this is a fine conclusion to the saga, personally. C2a is one of the more middle-of-the-ground options, and it's refreshing to have an election that chooses such a candidate. It's been slow, yes, but I think this phase of the saga has highlighted the strengths of the committee process, in that we had a deliberate, carefully reasoned vote. Thanks for running the vote algorithm, Joachim, and for your careful shepherding, Simon. Richard

On Mar 30, 2020, at 5:48 PM, Joachim Breitner wrote:

Dear Committe,

thanks all for voting. The ranking of votes is now

C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5

In particular C2a beats every other options by 7:4 or more, and is therefore the result of this poll.

You can see more statistics at https://www.condorcet.vote/Vote/AB23CE70AC/

So, does this conclude this saga?

Cheers, Joachim

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I'd be very interested too. I also think it would be good to summarize our discussion here, in particular the rationale for C2a, and post the summary on the GitHub thread. I noticed some concerns on the GitHub thread about the lack of consensus and the omission of `map .lbl xs` (IIRC we did discuss this option and there actually *was* consensus that we didn't like it), we should address those concerns too. Eric On Mon, Mar 30, 2020, at 13:06, Iavor Diatchki wrote:

Thanks Joachim! I'd be curious the hear an opinion from someone who prefers `C2a` to `C4`, about why it is better? To me `C2a` just looks like a more complicated version of `C4`.

-Iavor

On Mon, Mar 30, 2020 at 9:58 AM Richard Eisenberg wrote:

...

I think this is a fine conclusion to the saga, personally. C2a is one of the more middle-of-the-ground options, and it's refreshing to have an election that chooses such a candidate.

It's been slow, yes, but I think this phase of the saga has highlighted the strengths of the committee process, in that we had a deliberate, carefully reasoned vote.

Thanks for running the vote algorithm, Joachim, and for your careful shepherding, Simon.

Richard

...

On Mar 30, 2020, at 5:48 PM, Joachim Breitner wrote:

Dear Committe,

thanks all for voting. The ranking of votes is now

C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5

In particular C2a beats every other options by 7:4 or more, and is therefore the result of this poll.

You can see more statistics at https://www.condorcet.vote/Vote/AB23CE70AC/

So, does this conclude this saga?

Cheers, Joachim

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Montag, den 30.03.2020, 21:27 +0200 schrieb Alejandro Serrano Mena:

for me the syntax "r .x", with a space in between the element and the field name, looks completely alien and different from what other languages do [1,2,3]. Furthermore, several examples in C4 are very surprising to me. For example, "f r .x" meaning "f (r.x)".

you list Ocaml here, but that C4 is _precisely_ what Ocaml does (and in my earlier list of options, where I tired to be more systematic about option names, i was called “Ocaml”): utop # type r = { x : int };; type r = { x : int; } utop # let r = { x = 0 };; val r : r = {x = 0} utop # let f : int -> int = fun n -> n;; val f : int -> int = <fun> utop # f r .x;; - : int = 0 Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Thanks Joachim. Everyone: I have extended our choices document with a draft post to the Github thread. https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7i... Can you review it, for both tone and content? You have edit permission, so by all means improve the wording. Look for omissions. I want to bring the discussion to a close, not re-ignite further debate, but be respectful of those who disagree. Could you do so this week, by end Friday? I propose to leave the votes recorded there, but when posting I'll move the post from the document (deleting it from there) to GitHub. I'm cc'ing Neil and Shayne, the authors. Neil, Shayne: I think (and desperately hope!) you'll be content with this outcome. Can you review my draft post too? Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 30 March 2020 17:48 | To: ghc-steering-committee | Subject: Re: [ghc-steering-committee] Record dot syntax: vote results | | Dear Committe, | | thanks all for voting. The ranking of votes is now | | C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5 | | In particular C2a beats every other options by 7:4 or more, and is | therefore the result of this poll. | | You can see more statistics at | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cond | orcet.vote%2FVote%2FAB23CE70AC%2F&data=02%7C01%7Csimonpj%40microsoft.c | om%7Ce27e9c8f455b436e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7 | C1%7C0%7C637211837260982595&sdata=LLWCxVjXxyLqcJUZ9iMgB%2B5QYGMuHFzJga | u9agTakiQ%3D&reserved=0 | | So, does this conclude this saga? | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b43 | 6e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372118372 | 60982595&sdata=GE%2BBYN7rA7zWgwuKlArv4PR%2Fm3IlmZ7PqWbGpgXUyms%3D& | reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b436e2be | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= | 0

Before we accept the proposal I think we should have a precise description of the changes to the syntax. For example, we don't address the question of whether a field name can be an operator or not. We explicitly left these questions until later; wouldn't now be the right time to address them? Yes I put that under “What happens next”. You are right about operators – I’ve added that. Anything else to add? Also worth bringing up at this point, since we landed on C2a: Note 5 says Yes this is why I argued for (C6) which avoids all this difficulty 😊. But the consensus was otherwise. I think the right thing is to ask the authors to elaborate this point. Simon From: Simon Marlow Sent: 31 March 2020 11:41 To: Simon Peyton Jones Cc: Joachim Breitner ; ghc-steering-committee ; Neil Mitchell ; Shayne Fletcher Subject: Re: [ghc-steering-committee] Record dot syntax: vote results On Tue, 31 Mar 2020 at 11:08, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote: Thanks Joachim. Everyone: I have extended our choices document with a draft post to the Github thread. https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7i...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b21c188d2540ed9d4108d7d560076c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212480725127579&sdata=7qbW8kQDOgQ4l%2BYt8SG4aLpZWtZuZGFAql4nZsHda6w%3D&reserved=0 Can you review it, for both tone and content? You have edit permission, so by all means improve the wording. Look for omissions. I want to bring the discussion to a close, not re-ignite further debate, but be respectful of those who disagree. Before we accept the proposal I think we should have a precise description of the changes to the syntax. For example, we don't address the question of whether a field name can be an operator or not. We explicitly left these questions until later; wouldn't now be the right time to address them? Also worth bringing up at this point, since we landed on C2a: Note 5 says One mechanism for handling this is given in the proposalhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-syntax%2Fproposals%2F0000-record-dot-syntax.md%232322-parsing-of-field-selections&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b21c188d2540ed9d4108d7d560076c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212480725137574&sdata=Oi8HNd1uPpmvFwdHkOjOqREjYzq%2FAXvPMuatyxtsNk0%3D&reserved=0. It involves no changes to the lexer, but instead an adjacency test one production of the parser. I'm not sure about this as a language design. (1) it's an ad-hoc side-condition that can't be expressed in the lexical or context-free grammar (however there's precedent for this kind of thing in the form of the layout rule of course), and (2) it's quite a costly feature in terms of implementation effort to add to the language, because your AST needs complete and accurate source-span information. We can do it in GHC, and haskell-src-exts can do it nowadays, but earlier versions of haskell-src-exts before complete SrcSpanInfo was added wouldn't have been able to implement this rule. Arguably we're only accepting this as a GHC extension and not a Haskell extension in general, but as we know GHC is the testbed for future language extensions, so it's a good time to consider these issues. The alternative of course is to go with some variant of * Use the “tight infix” mechanism from this (accepted) GHC proposalhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F229&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b21c188d2540ed9d4108d7d560076c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212480725137574&sdata=k7u9AQaqYTwKg4aYyCY2FpkqbleUI4vRe3cDjCeCB70%3D&reserved=0 which is also an ad-hoc side-condition sadly, but could be implemented in the lexer. Nevertheless, all this needs to be nailed down before the proposal can be accepted, IMO. Cheers Simon Could you do so this week, by end Friday? I propose to leave the votes recorded there, but when posting I'll move the post from the document (deleting it from there) to GitHub. I'm cc'ing Neil and Shayne, the authors. Neil, Shayne: I think (and desperately hope!) you'll be content with this outcome. Can you review my draft post too? Simon | -----Original Message----- | From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> | On Behalf Of Joachim Breitner | Sent: 30 March 2020 17:48 | To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> | Subject: Re: [ghc-steering-committee] Record dot syntax: vote results | | Dear Committe, | | thanks all for voting. The ranking of votes is now | | C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5 | | In particular C2a beats every other options by 7:4 or more, and is | therefore the result of this poll. | | You can see more statistics at | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cond | orcet.votehttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Forcet.vote%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b21c188d2540ed9d4108d7d560076c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212480725147571&sdata=f8WfZcvlMqcpblxUfvaT8%2BawbK6cH4210XkRCvFu6UY%3D&reserved=0%2FVote%2FAB23CE70AC%2F&data=02%7C01%7Csimonpj%40microsoft.c | om%7Ce27e9c8f455b436e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7 | C1%7C0%7C637211837260982595&sdata=LLWCxVjXxyLqcJUZ9iMgB%2B5QYGMuHFzJga | u9agTakiQ%3D&reserved=0 | | So, does this conclude this saga? | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.demailto:mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.dehttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b21c188d2540ed9d4108d7d560076c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212480725147571&sdata=fLDeA9p1vKtFcjTuILtNaCKvcp99pAiD9ETn2RMADp4%3D&reserved=0%2F&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b21c188d2540ed9d4108d7d560076c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212480725157562&sdata=kvvP%2FMLlPZ9KYbhiDysRi742vtthy7Xblhgi47ydig8%3D&reserved=0%7Ce27e9c8f455b43 | 6e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372118372 | 60982595&sdata=GE%2BBYN7rA7zWgwuKlArv4PR%2Fm3IlmZ7PqWbGpgXUyms%3D& | reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b21c188d2540ed9d4108d7d560076c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212480725157562&sdata=VjbX%2FXp6vYXvKl48clU5WRaGPHVySY3oev7sdHB4Qjk%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b21c188d2540ed9d4108d7d560076c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212480725157562&sdata=kvvP%2FMLlPZ9KYbhiDysRi742vtthy7Xblhgi47ydig8%3D&reserved=0%7Ce27e9c8f455b436e2be | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= | 0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7Ca1b21c188d2540ed9d4108d7d560076c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212480725167555&sdata=dtdX3frE5vODjryKcu2D2osa2kIEQzaXvDLCj4wxLgU%3D&reserved=0

The proposal is entirely about syntax; and specifically about introducing the form `r.x` for record field selection. No changes to the type system, or any other aspect of the language, are

What features of the proposal document are actually a part of the proposal? Well, all of it! I had supposed that had been clear for some time; my apologies if not. If are other aspects of the proposal that you don’t like, please say so now! There are two pretty much orthogonal things going on 1. Syntax for record selection r.x; this proposal 2. Using overloading to resolve duplicate record labels, via getField/setField It’s true (2) pretty much precludes selection/update for records with polymorphic fields (unless we have impredicativity, which I think we should ignore for now). That has always been true. If you don’t want (2) then (1) is still useful. Maybe the proposal should have different desugaring rules with and without OverloadedRecordFields. That would be an additional box in the matrix, which I suppose we might want to fill in. Including Shayne and Neil in this conversation. Simon From: Richard Eisenberg Sent: 31 March 2020 12:37 To: Simon Marlow Cc: Simon Peyton Jones ; Neil Mitchell ; ghc-steering-committee ; Joachim Breitner ; Shayne Fletcher Subject: Re: [ghc-steering-committee] Record dot syntax: vote results Quoting from the document: proposed. The original proposal was more elaborate, providing ways to update fields as well as set them, but was simplified to focus on the essentials. Is this fact enshrined in the proposal document? I view that as ground truth. And it describes, e.g., that (e { field = val }) now means (setField ...), which means that polymorphic record update is incompatible with -XRecordDotSyntax. What features of the proposal document are actually a part of the proposal? Otherwise, I am happy with the tone and content of the post. Thanks, Richard On Mar 31, 2020, at 11:40 AM, Simon Marlow mailto:marlowsd@gmail.com> wrote: On Tue, 31 Mar 2020 at 11:08, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote: Thanks Joachim. Everyone: I have extended our choices document with a draft post to the Github thread. https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7i...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7Cd3178be33a584af741f808d7d567c97c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212514046325345&sdata=LeXgcQuZXFbZ8qwKu%2FmvA0PYYMAv46JlTIuYHagDJcE%3D&reserved=0 Can you review it, for both tone and content? You have edit permission, so by all means improve the wording. Look for omissions. I want to bring the discussion to a close, not re-ignite further debate, but be respectful of those who disagree. Before we accept the proposal I think we should have a precise description of the changes to the syntax. For example, we don't address the question of whether a field name can be an operator or not. We explicitly left these questions until later; wouldn't now be the right time to address them? Also worth bringing up at this point, since we landed on C2a: Note 5 says One mechanism for handling this is given in the proposalhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-syntax%2Fproposals%2F0000-record-dot-syntax.md%232322-parsing-of-field-selections&data=02%7C01%7Csimonpj%40microsoft.com%7Cd3178be33a584af741f808d7d567c97c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212514046325345&sdata=Pcac6GXwXXCfPJt8u62ZTd1Vmq0hViqV2eRUPdYv358%3D&reserved=0. It involves no changes to the lexer, but instead an adjacency test one production of the parser. I'm not sure about this as a language design. (1) it's an ad-hoc side-condition that can't be expressed in the lexical or context-free grammar (however there's precedent for this kind of thing in the form of the layout rule of course), and (2) it's quite a costly feature in terms of implementation effort to add to the language, because your AST needs complete and accurate source-span information. We can do it in GHC, and haskell-src-exts can do it nowadays, but earlier versions of haskell-src-exts before complete SrcSpanInfo was added wouldn't have been able to implement this rule. Arguably we're only accepting this as a GHC extension and not a Haskell extension in general, but as we know GHC is the testbed for future language extensions, so it's a good time to consider these issues. The alternative of course is to go with some variant of * Use the “tight infix” mechanism from this (accepted) GHC proposalhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F229&data=02%7C01%7Csimonpj%40microsoft.com%7Cd3178be33a584af741f808d7d567c97c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212514046335298&sdata=r7FVNdNPqkn1N7N5NIViELWI%2F%2BjtdOjcArHCK%2BeP1oA%3D&reserved=0 which is also an ad-hoc side-condition sadly, but could be implemented in the lexer. Nevertheless, all this needs to be nailed down before the proposal can be accepted, IMO. Cheers Simon Could you do so this week, by end Friday? I propose to leave the votes recorded there, but when posting I'll move the post from the document (deleting it from there) to GitHub. I'm cc'ing Neil and Shayne, the authors. Neil, Shayne: I think (and desperately hope!) you'll be content with this outcome. Can you review my draft post too? Simon | -----Original Message----- | From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> | On Behalf Of Joachim Breitner | Sent: 30 March 2020 17:48 | To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> | Subject: Re: [ghc-steering-committee] Record dot syntax: vote results | | Dear Committe, | | thanks all for voting. The ranking of votes is now | | C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5 | | In particular C2a beats every other options by 7:4 or more, and is | therefore the result of this poll. | | You can see more statistics at | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cond | orcet.votehttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Forcet.vote%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cd3178be33a584af741f808d7d567c97c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212514046335298&sdata=rkSKjyK%2FJA8uBNPwPVr0%2Bv6aN8pzNwRVawnY6dsvnhw%3D&reserved=0%2FVote%2FAB23CE70AC%2F&data=02%7C01%7Csimonpj%40microsoft.c | om%7Ce27e9c8f455b436e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7 | C1%7C0%7C637211837260982595&sdata=LLWCxVjXxyLqcJUZ9iMgB%2B5QYGMuHFzJga | u9agTakiQ%3D&reserved=0 | | So, does this conclude this saga? | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.demailto:mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.dehttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cd3178be33a584af741f808d7d567c97c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212514046345257&sdata=O4msxBE2EnRV4wi3CIE7BuCTKnSLQc%2Fo8CUZhZ9TGMQ%3D&reserved=0%2F&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cd3178be33a584af741f808d7d567c97c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212514046345257&sdata=c1iYCTMomIKk1T2lYXikl5lNyOYq%2F8YbpH6ZBtDAbX0%3D&reserved=0%7Ce27e9c8f455b43 | 6e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372118372 | 60982595&sdata=GE%2BBYN7rA7zWgwuKlArv4PR%2Fm3IlmZ7PqWbGpgXUyms%3D& | reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cd3178be33a584af741f808d7d567c97c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212514046355208&sdata=%2B7s13qqQMwrJgTbslSo6ppv6ps8CF3VPOQ2U7HbXBMI%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cd3178be33a584af741f808d7d567c97c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212514046355208&sdata=nHkhSCRoeCjBsRbmD96XnuzpwjFpW%2BHSXEeI7oDmAc8%3D&reserved=0%7Ce27e9c8f455b436e2be | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= | 0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7Cd3178be33a584af741f808d7d567c97c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212514046355208&sdata=a%2Btj9HkTV1ZQVM5Qfy%2FXTME01q824TGEpsjLFIhlOxE%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7Cd3178be33a584af741f808d7d567c97c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212514046365166&sdata=5c1qnL0DD%2BPRpq0sLCfzersKVXGqTw9ENbk9JZODU8M%3D&reserved=0

The proposal is entirely about syntax; and specifically about introducing the form `r.x` for record field selection. No changes to the type system, or any other aspect of the language, are

The proposal is entirely about syntax; and specifically about introducing the form `r.x` for record field selection. No changes to the type system, or any other aspect of the language, are

But: if you agree (and it sounds like you do) that the proposal's text is definitive, I can update the text above to try to iron out these potential sources of confusion. Yes I do. Please do! And, it’s terribly late in the day, but if anyone wants to raise a new issue, please do so. I do wonder about explicitly calling out the possibility of having (a) the syntactic sugar of this proposal with (b) no overloading. So that r.x desugars to (x r) e { x = e2 } desugars to case e of K { .. } -> K { x=e2, .. } or something like that. That is strictly beyond what the proposal currently does, which is to *always* use setField/getField. But that means that for records with polymorphic fields you simply can’t use the proposal at all. Simon From: Richard Eisenberg Sent: 31 March 2020 13:52 To: Simon Peyton Jones Cc: Simon Marlow ; Neil Mitchell ; ghc-steering-committee ; Joachim Breitner ; Shayne Fletcher Subject: Re: [ghc-steering-committee] Record dot syntax: vote results On Mar 31, 2020, at 12:48 PM, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: What features of the proposal document are actually a part of the proposal? Well, all of it! Good -- that's very clear, then. And it had been clear for some time (to me) -- it's just that I find it disagrees with the proposed text on the document, which reads: proposed. The original proposal was more elaborate, providing ways to update fields as well as set them, but was simplified to focus on the essentials. If we look at the proposal (https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/p...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-syntax%2Fproposals%2F0000-record-dot-syntax.md%23211-syntax&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520732428&sdata=ET%2BCsjDS8EjsUysIIqvE9%2F5OvA1EVnI91kvjbHqy2Nc%3D&reserved=0), we see a range of syntactic transformations. One of these repurposes record-update syntax, and assigns it new typing rules. To me, this changes the type system. Some of these rules propose new ways to update fields. (I see now you were thinking of the fact that syntax like `+=` has been abandoned. That's true, but I read the text above is referring to record-update.) So my reading of the rules leads to a different picture than the text above. But: if you agree (and it sounds like you do) that the proposal's text is definitive, I can update the text above to try to iron out these potential sources of confusion. Richard There are two pretty much orthogonal things going on 1. Syntax for record selection r.x; this proposal 2. Using overloading to resolve duplicate record labels, via getField/setField It’s true (2) pretty much precludes selection/update for records with polymorphic fields (unless we have impredicativity, which I think we should ignore for now). That has always been true. If you don’t want (2) then (1) is still useful. Maybe the proposal should have different desugaring rules with and without OverloadedRecordFields. That would be an additional box in the matrix, which I suppose we might want to fill in. Including Shayne and Neil in this conversation. Simon From: Richard Eisenberg mailto:rae@richarde.dev> Sent: 31 March 2020 12:37 To: Simon Marlow mailto:marlowsd@gmail.com> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com>; Neil Mitchell mailto:ndmitchell@gmail.com>; ghc-steering-committee mailto:ghc-steering-committee@haskell.org>; Joachim Breitner mailto:mail@joachim-breitner.de>; Shayne Fletcher mailto:shayne.fletcher@daml.com> Subject: Re: [ghc-steering-committee] Record dot syntax: vote results Quoting from the document: proposed. The original proposal was more elaborate, providing ways to update fields as well as set them, but was simplified to focus on the essentials. Is this fact enshrined in the proposal document? I view that as ground truth. And it describes, e.g., that (e { field = val }) now means (setField ...), which means that polymorphic record update is incompatible with -XRecordDotSyntax. What features of the proposal document are actually a part of the proposal? Otherwise, I am happy with the tone and content of the post. Thanks, Richard On Mar 31, 2020, at 11:40 AM, Simon Marlow mailto:marlowsd@gmail.com> wrote: On Tue, 31 Mar 2020 at 11:08, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote: Thanks Joachim. Everyone: I have extended our choices document with a draft post to the Github thread. https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7i...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520742428&sdata=W4hHo9WZaOANfbjfI9DOE5zwAgyAm%2BJjcKBrcLV8Dyw%3D&reserved=0 Can you review it, for both tone and content? You have edit permission, so by all means improve the wording. Look for omissions. I want to bring the discussion to a close, not re-ignite further debate, but be respectful of those who disagree. Before we accept the proposal I think we should have a precise description of the changes to the syntax. For example, we don't address the question of whether a field name can be an operator or not. We explicitly left these questions until later; wouldn't now be the right time to address them? Also worth bringing up at this point, since we landed on C2a: Note 5 says One mechanism for handling this is given in the proposalhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-syntax%2Fproposals%2F0000-record-dot-syntax.md%232322-parsing-of-field-selections&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520752420&sdata=culW9AOiRxeFt0BhYpfHIfrPBdyG4Y%2Bnkd%2B4oWweoFA%3D&reserved=0. It involves no changes to the lexer, but instead an adjacency test one production of the parser. I'm not sure about this as a language design. (1) it's an ad-hoc side-condition that can't be expressed in the lexical or context-free grammar (however there's precedent for this kind of thing in the form of the layout rule of course), and (2) it's quite a costly feature in terms of implementation effort to add to the language, because your AST needs complete and accurate source-span information. We can do it in GHC, and haskell-src-exts can do it nowadays, but earlier versions of haskell-src-exts before complete SrcSpanInfo was added wouldn't have been able to implement this rule. Arguably we're only accepting this as a GHC extension and not a Haskell extension in general, but as we know GHC is the testbed for future language extensions, so it's a good time to consider these issues. The alternative of course is to go with some variant of * Use the “tight infix” mechanism from this (accepted) GHC proposalhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F229&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520752420&sdata=UCCPvDoBPnWdYW6GvmVGA1RxMuXxJnuHMEB5qsbRMlY%3D&reserved=0 which is also an ad-hoc side-condition sadly, but could be implemented in the lexer. Nevertheless, all this needs to be nailed down before the proposal can be accepted, IMO. Cheers Simon Could you do so this week, by end Friday? I propose to leave the votes recorded there, but when posting I'll move the post from the document (deleting it from there) to GitHub. I'm cc'ing Neil and Shayne, the authors. Neil, Shayne: I think (and desperately hope!) you'll be content with this outcome. Can you review my draft post too? Simon | -----Original Message----- | From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> | On Behalf Of Joachim Breitner | Sent: 30 March 2020 17:48 | To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> | Subject: Re: [ghc-steering-committee] Record dot syntax: vote results | | Dear Committe, | | thanks all for voting. The ranking of votes is now | | C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5 | | In particular C2a beats every other options by 7:4 or more, and is | therefore the result of this poll. | | You can see more statistics at | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cond | orcet.votehttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Forcet.vote%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520762414&sdata=qvWZwZHab3%2Bl%2FO%2B8NNhjQoUdkFZrnytynA6vhf%2BtRgA%3D&reserved=0%2FVote%2FAB23CE70AC%2F&data=02%7C01%7Csimonpj%40microsoft.c | om%7Ce27e9c8f455b436e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7 | C1%7C0%7C637211837260982595&sdata=LLWCxVjXxyLqcJUZ9iMgB%2B5QYGMuHFzJga | u9agTakiQ%3D&reserved=0 | | So, does this conclude this saga? | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.demailto:mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.dehttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520772409&sdata=fkEUbbqDLSs4SFvGZ3aL4QCs4nfkH1Ix44Ec7bbFX8g%3D&reserved=0%2F&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520782404&sdata=5Mq5i%2Fn98FWwwK8b3ySXY5X6NEiFx8QAl6cgOWDkU3A%3D&reserved=0%7Ce27e9c8f455b43 | 6e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372118372 | 60982595&sdata=GE%2BBYN7rA7zWgwuKlArv4PR%2Fm3IlmZ7PqWbGpgXUyms%3D& | reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520782404&sdata=7K%2B%2F6daWxe9rrJjsupSB7AtnnQSJfoaJUv2Bvs7ep5g%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520792402&sdata=roywGXR%2Fxe53OFW60wrqvaWqJ57KNjDL5DCkK8YCOv8%3D&reserved=0%7Ce27e9c8f455b436e2be | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= | 0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520802397&sdata=Z3ygxZmFZ9Pwv1zkPijWD8PkUEYaIcd5BnbK3PN3B8I%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520802397&sdata=Z3ygxZmFZ9Pwv1zkPijWD8PkUEYaIcd5BnbK3PN3B8I%3D&reserved=0

Hello, I think accepting (C2a) over (C4) is a mistake, and reading Simon's specification of (C2a) does nothing to dispel my uneasiness about this choice. To Alejandro's points: - As Joachim pointed out, (C4) is how OCaml works, not (C2a). I wonder what the additional complexity of the specification buys us? In the draft document Simon describes it as "more conservative", but it actually requires more work to both implement and specify. - Indeed, you could write some expressions that might look confusing at first, but I don't see why would you? After all, one could use the exact same argument for many other notations in pretty much any programming language (e.g., operator precedences can be used to write confusing code---it doesn't mean that they are not very useful sometime). - Using white space in selectors is probably not going to be used a lot, but I could imagine it being useful if you have some nested records, and the field names are long. For example, I could see myself writing something like this: ``` someRecord .outterField .innerField ``` I realize this style could be a matter of taste, but I don't see any reason for us to go out of our way to disallow it. -Iavor On Tue, Mar 31, 2020 at 7:21 AM Richard Eisenberg wrote:

On Mar 31, 2020, at 2:09 PM, Simon Peyton Jones wrote:

Yes I do. Please do! And, it’s terribly late in the day, but if anyone wants to raise a new issue, please do so.

Done. Tiny changes, but I think they will avoid the mistakes I made in interpretation.

I do wonder about explicitly calling out the possibility of having (a) the syntactic sugar of this proposal with (b) no overloading. So that r.x desugars to (x r) e { x = e2 } desugars to case e of K { .. } -> K { x=e2, .. } or something like that. That is strictly beyond what the proposal currently does, which is to **always** use setField/getField. But that means that for records with polymorphic fields you simply can’t use the proposal at all.

That is interesting, but I say that it is too late. Effectively, we've accepted this proposal (modulo "what happens next"). You're welcome to write a fresh proposal with that idea. :)

Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

El mié., 1 abr. 2020 a las 0:09, Iavor Diatchki () escribió:

Hello,

- Indeed, you could write some expressions that might look confusing at first, but I don't see why would you? After all, one could use the exact same argument for many other notations in pretty much any programming language (e.g., operator precedences can be used to write confusing code---it doesn't mean that they are not very useful sometime).

But I think it's important to think also of potentially confusing type errors which may arise if we allow such freedom. I find easier to simply say "f r .x" cannot be parsed, and then asking the user to disambiguate between "(f r).x" or "f r.x" than to allow it in the parser and then obtain a huge error message. Part of the reason why I'm so concerned about it is that my prediction is that this is not "just" any other extension. Many people, including beginners, will enable this by default, since it makes one slightly alien part of Haskell (field access) look like what they might be used to.

Well, this was not a problem 30 years ago: [image: 2020-04-01 19.45.59.jpg] Vitaly ср, 1 апр. 2020 г. в 12:44, Richard Eisenberg :

Small note: It sounds like we're getting ready to wrap this up with that post of Simon's on GitHub. Might I humbly suggest we wait one more day? Declaring the committee's vote today, April 1, might only sow confusion. :)

Richard

On Apr 1, 2020, at 7:00 AM, Alejandro Serrano Mena wrote:

El mié., 1 abr. 2020 a las 0:09, Iavor Diatchki () escribió:

...

Hello,

- Indeed, you could write some expressions that might look confusing at first, but I don't see why would you? After all, one could use the exact same argument for many other notations in pretty much any programming language (e.g., operator precedences can be used to write confusing code---it doesn't mean that they are not very useful sometime).

But I think it's important to think also of potentially confusing type errors which may arise if we allow such freedom. I find easier to simply say "f r .x" cannot be parsed, and then asking the user to disambiguate between "(f r).x" or "f r.x" than to allow it in the parser and then obtain a huge error message.

Part of the reason why I'm so concerned about it is that my prediction is that this is not "just" any other extension. Many people, including beginners, will enable this by default, since it makes one slightly alien part of Haskell (field access) look like what they might be used to.

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

All: only a couple of people have commented on the draft post -- see "Draft post" section of https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7i... Usually I prefer explicit assent, but here I'm going to take silence for assent. Is everyone content for me to post tomorrow? Simon | -----Original Message----- | From: Simon Peyton Jones | Sent: 31 March 2020 11:09 | To: Joachim Breitner ; ghc-steering-committee | | Cc: Simon Peyton Jones ; Neil Mitchell | ; Shayne Fletcher | Subject: RE: [ghc-steering-committee] Record dot syntax: vote results | | Thanks Joachim. | | Everyone: I have extended our choices document with a draft post to the | Github thread. | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goo | gle.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fed | it%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7Cc8647a2c84 | e5492710ab08d7d55b7d5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212 | 461226216730&sdata=ix%2FweGNzFIokAcesdcwqM4dufVpxputAQZH5DNv7ouc%3D&am | p;reserved=0 | | Can you review it, for both tone and content? You have edit permission, | so by all means improve the wording. Look for omissions. I want to bring | the discussion to a close, not re-ignite further debate, but be respectful | of those who disagree. | | Could you do so this week, by end Friday? I propose to leave the votes | recorded there, but when posting I'll move the post from the document | (deleting it from there) to GitHub. | | I'm cc'ing Neil and Shayne, the authors. Neil, Shayne: I think (and | desperately hope!) you'll be content with this outcome. Can you review my | draft post too? | | Simon | | | -----Original Message----- | | From: ghc-steering-committee | | On Behalf Of Joachim Breitner | | Sent: 30 March 2020 17:48 | | To: ghc-steering-committee | | Subject: Re: [ghc-steering-committee] Record dot syntax: vote results | | | | Dear Committe, | | | | thanks all for voting. The ranking of votes is now | | | | C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5 | | | | In particular C2a beats every other options by 7:4 or more, and is | | therefore the result of this poll. | | | | You can see more statistics at | | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cond | | | orcet.vote%2FVote%2FAB23CE70AC%2F&data=02%7C01%7Csimonpj%40microsoft.c | | | om%7Ce27e9c8f455b436e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7 | | | C1%7C0%7C637211837260982595&sdata=LLWCxVjXxyLqcJUZ9iMgB%2B5QYGMuHFzJga | | u9agTakiQ%3D&reserved=0 | | | | So, does this conclude this saga? | | | | Cheers, | | Joachim | | | | -- | | Joachim Breitner | | mail@joachim-breitner.de | | | | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | | im- | | | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b43 | | | 6e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372118372 | | | 60982595&sdata=GE%2BBYN7rA7zWgwuKlArv4PR%2Fm3IlmZ7PqWbGpgXUyms%3D& | | reserved=0 | | | | | | _______________________________________________ | | ghc-steering-committee mailing list | | ghc-steering-committee@haskell.org | | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | | | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b436e2be | | | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 | | | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= | | 0