I made one more correction to the notes, otherwise Aye! On Mon, Mar 9, 2020, at 07:03, Richard Eisenberg wrote:

I am happy with this list: Aye!

...

On Mar 9, 2020, at 9:56 AM, Simon Peyton Jones via ghc-steering-committee wrote:

Colleagues

...

Thanks for your various replies. I have

...

* Added a couple more examples (please check) * Split (C2a) and (C2b) – thank you Joachim for filling out the list. * Add a Notes section that identifies some consequences, hopefully objectively. * Added a list at the end where you can add your AYE when happy. Can you review, and Christopher, Richard, Cale, Simon, Eric, Alejandro, Arnaud: please add AYE or suggest further changes.

...

This is painstaking but I think it is clarifying. I have found writing out the examples is quite helpful. Feel free to suggest more if you think there are some cases that are unclear.

...

Thanks

...

Simon

...

*From:* Simon Peyton Jones *Sent:* 06 March 2020 17:59 *To:* ghc-steering-committee *Cc:* Simon Peyton Jones *Subject:* RecordDotSyntax proposal: next steps

...

Colleagues

...

I’m sorry to have been dragging my feet on the records proposal. First there was half term holiday, and then the ICFP deadline, so I’ve been out of action for several weeks.

...

It’s pretty clear that we are not going to achieve 100% consensus, so the right thing to do is to vote, using the single-transferrable-vote scheme that Joachim runs. It’s worth striving for consensus, because the debate can be clarifying (and has been!). But I don’t regard non-consensus as a failure. These things are all judgement calls, and people’s judgement can legitimately differ. Voting lets us nevertheless reach a conclusion.

...

So here’s what I propose

...

* I’ve put up a list of choices for us to vote on here 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%7Cdf9d9fcc96344d61da8108d7c1f81154%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637191143491204686&sdata=ScGCAmSEiqXCePZcx03YYQXl08Fc38UC7rWx3Zg%2Fz1o%3D&reserved=0, informed by our most recent email exchanges. The first thing is to ensure that this list is 1. *Complete*: no choices that people really want are omitted. 2. *Clear* *and unambiguous*. When we vote we must know exactly what we are voting for! *Can you all respond about that, including “Aye” if you think it is both complete and clear*.

...

* Once we are all satisfied, I’ll invite you to vote. The easiest way to do so might be to edit the Google doc directly, so there’s a single point of reference. Please also let me know if you think we should be doing anything else.

...

Thanks!

...

Simon

...

_______________________________________________ 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

Chris, Cale, Simon I wonder if you might have a moment to respond to this email? Thanks Simon From: Simon Peyton Jones Sent: 09 March 2020 09:56 To: ghc-steering-committee Cc: Simon Peyton Jones Subject: RE: RecordDotSyntax proposal: next steps Colleagues Thanks for your various replies. I have * Added a couple more examples (please check) * Split (C2a) and (C2b) - thank you Joachim for filling out the list. * Add a Notes section that identifies some consequences, hopefully objectively. * Added a list at the end where you can add your AYE when happy. Can you review, and Christopher, Richard, Cale, Simon, Eric, Alejandro, Arnaud: please add AYE or suggest further changes. This is painstaking but I think it is clarifying. I have found writing out the examples is quite helpful. Feel free to suggest more if you think there are some cases that are unclear. Thanks Simon From: Simon Peyton Jones mailto:simonpj@microsoft.com> Sent: 06 March 2020 17:59 To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com> Subject: RecordDotSyntax proposal: next steps Colleagues I'm sorry to have been dragging my feet on the records proposal. First there was half term holiday, and then the ICFP deadline, so I've been out of action for several weeks. It's pretty clear that we are not going to achieve 100% consensus, so the right thing to do is to vote, using the single-transferrable-vote scheme that Joachim runs. It's worth striving for consensus, because the debate can be clarifying (and has been!). But I don't regard non-consensus as a failure. These things are all judgement calls, and people's judgement can legitimately differ. Voting lets us nevertheless reach a conclusion. So here's what I propose * I've put up a list of choices for us to vote on herehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7Cc4d44b2094af411a0db008d7c41020da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193445856931710&sdata=Z7Bn2UD3HWSEJs70ANTNbS6IbvI6%2BuRHXRiGDYlR7xs%3D&reserved=0, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * Clear and unambiguous. When we vote we must know exactly what we are voting for! Can you all respond about that, including "Aye" if you think it is both complete and clear. * Once we are all satisfied, I'll invite you to vote. The easiest way to do so might be to edit the Google doc directly, so there's a single point of reference. Please also let me know if you think we should be doing anything else. Thanks! Simon

Thanks. You can’t vote if you don’t understand the alternatives! And if you can’t maybe others can’t – or will do so based on different understandings of the same thing. That would be Bad. I’m not well positioned to fix this because I don’t know where the ambiguities are. Would you like to ask some clarifying questions? Simon From: Simon Marlow Sent: 13 March 2020 17:30 To: Simon Peyton Jones Cc: Christopher Allen ; Cale Gibbard ; ghc-steering-committee Subject: Re: RecordDotSyntax proposal: next steps It's still a bit hard (IMO) to understand what precise changes each proposal would make to the syntax, but I don't want to hold things up so I've added an AYE. Cheers Simon On Fri, 13 Mar 2020 at 10:38, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: Chris, Cale, Simon I wonder if you might have a moment to respond to this email? Thanks Simon From: Simon Peyton Jones mailto:simonpj@microsoft.com> Sent: 09 March 2020 09:56 To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com> Subject: RE: RecordDotSyntax proposal: next steps Colleagues Thanks for your various replies. I have * Added a couple more examples (please check) * Split (C2a) and (C2b) – thank you Joachim for filling out the list. * Add a Notes section that identifies some consequences, hopefully objectively. * Added a list at the end where you can add your AYE when happy. Can you review, and Christopher, Richard, Cale, Simon, Eric, Alejandro, Arnaud: please add AYE or suggest further changes. This is painstaking but I think it is clarifying. I have found writing out the examples is quite helpful. Feel free to suggest more if you think there are some cases that are unclear. Thanks Simon From: Simon Peyton Jones mailto:simonpj@microsoft.com> Sent: 06 March 2020 17:59 To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com> Subject: RecordDotSyntax proposal: next steps Colleagues I’m sorry to have been dragging my feet on the records proposal. First there was half term holiday, and then the ICFP deadline, so I’ve been out of action for several weeks. It’s pretty clear that we are not going to achieve 100% consensus, so the right thing to do is to vote, using the single-transferrable-vote scheme that Joachim runs. It’s worth striving for consensus, because the debate can be clarifying (and has been!). But I don’t regard non-consensus as a failure. These things are all judgement calls, and people’s judgement can legitimately differ. Voting lets us nevertheless reach a conclusion. So here’s what I propose * I’ve put up a list of choices for us to vote on herehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7C22fa0d7eb4444f6487f408d7c77421bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637197173899607531&sdata=RXQVT9CP1IPjbGdDpuInQ%2BHvqG1%2FScBL9OqKf12g12s%3D&reserved=0, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * Clear and unambiguous. When we vote we must know exactly what we are voting for! Can you all respond about that, including “Aye” if you think it is both complete and clear. * Once we are all satisfied, I’ll invite you to vote. The easiest way to do so might be to edit the Google doc directly, so there’s a single point of reference. Please also let me know if you think we should be doing anything else. Thanks! Simon

I registered my "aye" as well, but I'd just like to reiterate that I think the language is already hard enough for beginners and experts alike to parse. The fact that all of these options are probably what *someone* would intuitively expect and that there are so many axes along which we're not sure how to disambiguate various expressions seems like a strong signal that this whole thing is ill-advised. If this makes its way into GHC, it'll be banned where I work for being much too confusing and unnecessary, but that still won't absolve us of needing to deal with it, as it'll much harder to guarantee that none of our dependencies will ever start using it. Actually, I just changed my mind, maybe there's one other option that should make it in as a second option in case we're unable to kill this proposal: none of the ambiguous expressions that are taken as examples there is valid. Take the record-selection-dot to be at the same level of precedence as function application, and therefore it must be parenthesized when used alongside function applications. I still don't like the proposal with that option, but it's better than C2-C6. Should we add it? On Sat, 14 Mar 2020 at 12:21, Christopher Allen wrote:

Marked myself AYE for the choices.

On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones wrote:

Thanks. You can’t vote if you don’t understand the alternatives! And if you can’t maybe others can’t – or will do so based on different understandings of the same thing. That would be Bad.

I’m not well positioned to fix this because I don’t know where the ambiguities are. Would you like to ask some clarifying questions?

Simon

From: Simon Marlow Sent: 13 March 2020 17:30 To: Simon Peyton Jones Cc: Christopher Allen ; Cale Gibbard ; ghc-steering-committee Subject: Re: RecordDotSyntax proposal: next steps

It's still a bit hard (IMO) to understand what precise changes each proposal would make to the syntax, but I don't want to hold things up so I've added an AYE.

Cheers

Simon

On Fri, 13 Mar 2020 at 10:38, Simon Peyton Jones wrote:

Chris, Cale, Simon I wonder if you might have a moment to respond to this email? Thanks Simon

From: Simon Peyton Jones Sent: 09 March 2020 09:56 To: ghc-steering-committee Cc: Simon Peyton Jones Subject: RE: RecordDotSyntax proposal: next steps

Colleagues Thanks for your various replies. I have

Added a couple more examples (please check) Split (C2a) and (C2b) – thank you Joachim for filling out the list. Add a Notes section that identifies some consequences, hopefully objectively. Added a list at the end where you can add your AYE when happy.

Can you review, and Christopher, Richard, Cale, Simon, Eric, Alejandro, Arnaud: please add AYE or suggest further changes. This is painstaking but I think it is clarifying. I have found writing out the examples is quite helpful. Feel free to suggest more if you think there are some cases that are unclear. Thanks Simon

From: Simon Peyton Jones Sent: 06 March 2020 17:59 To: ghc-steering-committee Cc: Simon Peyton Jones Subject: RecordDotSyntax proposal: next steps

Colleagues I’m sorry to have been dragging my feet on the records proposal. First there was half term holiday, and then the ICFP deadline, so I’ve been out of action for several weeks. It’s pretty clear that we are not going to achieve 100% consensus, so the right thing to do is to vote, using the single-transferrable-vote scheme that Joachim runs. It’s worth striving for consensus, because the debate can be clarifying (and has been!). But I don’t regard non-consensus as a failure. These things are all judgement calls, and people’s judgement can legitimately differ. Voting lets us nevertheless reach a conclusion. So here’s what I propose

I’ve put up a list of choices for us to vote on here, informed by our most recent email exchanges. The first thing is to ensure that this list is

Complete: no choices that people really want are omitted. Clear and unambiguous. When we vote we must know exactly what we are voting for!

Can you all respond about that, including “Aye” if you think it is both complete and clear.

Once we are all satisfied, I’ll invite you to vote. The easiest way to do so might be to edit the Google doc directly, so there’s a single point of reference.

Please also let me know if you think we should be doing anything else. Thanks! Simon

| Actually, I just changed my mind, maybe there's one other option that | should make it in as a second option in case we're unable to kill this | proposal: none of the ambiguous expressions that are taken as examples | there is valid. Take the record-selection-dot to be at the same level | of precedence as function application, and therefore it must be | parenthesized when used alongside function applications. Cale, if you'd like to add (C7) by all means do so. But I'm not clear what you have in mind. I understand that all the examples in (C2-6) would be illegal. But what about r .x .y r.x.y r .x.y r.x .y I think you intend that all these would be illegal f r.x f r .x r .x y So somehow postfix record selection has the same precedence as function application, and is left-associative with itself, but is non-associative with function application. That's a new concept. I suspect what you intend is that naked .x is illegal altogether, except in parens, thus (.x). So you would allow r.x.y as a single lexeme, but not have any of this postfix operator stuff. Would you like to add C7 so we all vote for the same thing? Or not -- it's up to you. Thanks Simon | -----Original Message----- | From: Cale Gibbard | Sent: 15 March 2020 02:32 | To: Christopher Allen | Cc: Simon Peyton Jones ; Simon Marlow | ; ghc-steering-committee | Subject: Re: RecordDotSyntax proposal: next steps | | I registered my "aye" as well, but I'd just like to reiterate that I | think the language is already hard enough for beginners and experts | alike to parse. The fact that all of these options are probably what | *someone* would intuitively expect and that there are so many axes | along which we're not sure how to disambiguate various expressions | seems like a strong signal that this whole thing is ill-advised. | | If this makes its way into GHC, it'll be banned where I work for being | much too confusing and unnecessary, but that still won't absolve us of | needing to deal with it, as it'll much harder to guarantee that none | of our dependencies will ever start using it. | | Actually, I just changed my mind, maybe there's one other option that | should make it in as a second option in case we're unable to kill this | proposal: none of the ambiguous expressions that are taken as examples | there is valid. Take the record-selection-dot to be at the same level | of precedence as function application, and therefore it must be | parenthesized when used alongside function applications. I still don't | like the proposal with that option, but it's better than C2-C6. | | Should we add it? | | On Sat, 14 Mar 2020 at 12:21, Christopher Allen wrote: | > | > Marked myself AYE for the choices. | > | > On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones | wrote: | > | > Thanks. You can’t vote if you don’t understand the alternatives! And | if you can’t maybe others can’t – or will do so based on different | understandings of the same thing. That would be Bad. | > | > I’m not well positioned to fix this because I don’t know where the | ambiguities are. Would you like to ask some clarifying questions? | > | > Simon | > | > From: Simon Marlow | > Sent: 13 March 2020 17:30 | > To: Simon Peyton Jones | > Cc: Christopher Allen ; Cale Gibbard | ; ghc-steering-committee | > Subject: Re: RecordDotSyntax proposal: next steps | > | > | > It's still a bit hard (IMO) to understand what precise changes each | proposal would make to the syntax, but I don't want to hold things up so | I've added an AYE. | > | > | > | > Cheers | > | > Simon | > | > | > | > On Fri, 13 Mar 2020 at 10:38, Simon Peyton Jones | wrote: | > | > Chris, Cale, Simon | > I wonder if you might have a moment to respond to this email? | > Thanks | > Simon | > | > From: Simon Peyton Jones | > Sent: 09 March 2020 09:56 | > To: ghc-steering-committee | > Cc: Simon Peyton Jones | > Subject: RE: RecordDotSyntax proposal: next steps | > | > Colleagues | > Thanks for your various replies. I have | > | > Added a couple more examples (please check) | > Split (C2a) and (C2b) – thank you Joachim for filling out the list. | > Add a Notes section that identifies some consequences, hopefully | objectively. | > Added a list at the end where you can add your AYE when happy. | > | > Can you review, and Christopher, Richard, Cale, Simon, Eric, Alejandro, | Arnaud: please add AYE or suggest further changes. | > This is painstaking but I think it is clarifying. I have found writing | out the examples is quite helpful. Feel free to suggest more if you think | there are some cases that are unclear. | > Thanks | > Simon | > | > From: Simon Peyton Jones | > Sent: 06 March 2020 17:59 | > To: ghc-steering-committee | > Cc: Simon Peyton Jones | > Subject: RecordDotSyntax proposal: next steps | > | > Colleagues | > I’m sorry to have been dragging my feet on the records proposal. First | there was half term holiday, and then the ICFP deadline, so I’ve been out | of action for several weeks. | > It’s pretty clear that we are not going to achieve 100% consensus, so | the right thing to do is to vote, using the single-transferrable-vote | scheme that Joachim runs. It’s worth striving for consensus, because the | debate can be clarifying (and has been!). But I don’t regard non- | consensus as a failure. These things are all judgement calls, and | people’s judgement can legitimately differ. Voting lets us nevertheless | reach a conclusion. | > So here’s what I propose | > | > I’ve put up a list of choices for us to vote on here, informed by our | most recent email exchanges. The first thing is to ensure that this list | is | > | > Complete: no choices that people really want are omitted. | > Clear and unambiguous. When we vote we must know exactly what we are | voting for! | > | > Can you all respond about that, including “Aye” if you think it is both | complete and clear. | > | > Once we are all satisfied, I’ll invite you to vote. The easiest way to | do so might be to edit the Google doc directly, so there’s a single point | of reference. | > | > Please also let me know if you think we should be doing anything else. | > Thanks! | > Simon | > | >

Thanks Cale. You’ve made helpful clarifications on the Google doc. I think I understand the proposal now. Simon | -----Original Message----- | From: Cale Gibbard | Sent: 16 March 2020 14:56 | To: Simon Peyton Jones | Cc: Christopher Allen ; Simon Marlow | ; ghc-steering-committee | Subject: Re: RecordDotSyntax proposal: next steps | | On Mon, 16 Mar 2020 at 10:28, Simon Peyton Jones | wrote: | > | > | Actually, I just changed my mind, maybe there's one other option | that | > | should make it in as a second option in case we're unable to kill | this | > | proposal: none of the ambiguous expressions that are taken as | examples | > | there is valid. Take the record-selection-dot to be at the same | level | > | of precedence as function application, and therefore it must be | > | parenthesized when used alongside function applications. | > | > Cale, if you'd like to add (C7) by all means do so. But I'm not | clear what you have in mind. I understand that all the examples in | (C2-6) would be illegal. But what about | > | > r .x .y | > r.x.y | > r .x.y | > r.x .y | | Of those, I think only r.x.y should be legal, as I can't guess what | the rest would mean. Of course, you could add parens in various ways: | | (r.x) (.y) would be a valid function application of the function (r.x) | to the record selection section (.y) | | r (.x) (.y) would be a function application of the function r to the | arguments (.x) and (.y) which are record selection sections. | | r (.x.y) I'm not sure about whether to allow, but if so, it's a | function application equivalent to r (\t -> t.x.y) | | > I think you intend that all these would be illegal | > f r.x | > f r .x | > r .x y | > | > So somehow postfix record selection has the same precedence as | function application, and is left-associative with itself, but is non- | associative with function application. That's a new concept. | > | > I suspect what you intend is that naked .x is illegal altogether, | except in parens, thus (.x). So you would allow | > r.x.y | > as a single lexeme, but not have any of this postfix operator stuff. | | Yes. | | > Would you like to add C7 so we all vote for the same thing? Or not | -- it's up to you. | | Doing so now :) | | > Thanks | > | > Simon | > | > | -----Original Message----- | > | From: Cale Gibbard | > | Sent: 15 March 2020 02:32 | > | To: Christopher Allen | > | Cc: Simon Peyton Jones ; Simon Marlow | > | ; ghc-steering-committee | committee@haskell.org> | > | Subject: Re: RecordDotSyntax proposal: next steps | > | | > | I registered my "aye" as well, but I'd just like to reiterate | that I | > | think the language is already hard enough for beginners and | experts | > | alike to parse. The fact that all of these options are probably | what | > | *someone* would intuitively expect and that there are so many | axes | > | along which we're not sure how to disambiguate various | expressions | > | seems like a strong signal that this whole thing is ill-advised. | > | | > | If this makes its way into GHC, it'll be banned where I work for | being | > | much too confusing and unnecessary, but that still won't absolve | us of | > | needing to deal with it, as it'll much harder to guarantee that | none | > | of our dependencies will ever start using it. | > | | > | Actually, I just changed my mind, maybe there's one other option | that | > | should make it in as a second option in case we're unable to kill | this | > | proposal: none of the ambiguous expressions that are taken as | examples | > | there is valid. Take the record-selection-dot to be at the same | level | > | of precedence as function application, and therefore it must be | > | parenthesized when used alongside function applications. I still | don't | > | like the proposal with that option, but it's better than C2-C6. | > | | > | Should we add it? | > | | > | On Sat, 14 Mar 2020 at 12:21, Christopher Allen | wrote: | > | > | > | > Marked myself AYE for the choices. | > | > | > | > On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones | | > | wrote: | > | > | > | > Thanks. You can’t vote if you don’t understand the | alternatives! And | > | if you can’t maybe others can’t – or will do so based on | different | > | understandings of the same thing. That would be Bad. | > | > | > | > I’m not well positioned to fix this because I don’t know where | the | > | ambiguities are. Would you like to ask some clarifying | questions? | > | > | > | > Simon | > | > | > | > From: Simon Marlow | > | > Sent: 13 March 2020 17:30 | > | > To: Simon Peyton Jones | > | > Cc: Christopher Allen ; Cale Gibbard | > | ; ghc-steering-committee | committee@haskell.org> | > | > Subject: Re: RecordDotSyntax proposal: next steps | > | > | > | > | > | > It's still a bit hard (IMO) to understand what precise changes | each | > | proposal would make to the syntax, but I don't want to hold | things up so | > | I've added an AYE. | > | > | > | > | > | > | > | > Cheers | > | > | > | > Simon | > | > | > | > | > | > | > | > On Fri, 13 Mar 2020 at 10:38, Simon Peyton Jones | | > | wrote: | > | > | > | > Chris, Cale, Simon | > | > I wonder if you might have a moment to respond to this email? | > | > Thanks | > | > Simon | > | > | > | > From: Simon Peyton Jones | > | > Sent: 09 March 2020 09:56 | > | > To: ghc-steering-committee | > | > Cc: Simon Peyton Jones | > | > Subject: RE: RecordDotSyntax proposal: next steps | > | > | > | > Colleagues | > | > Thanks for your various replies. I have | > | > | > | > Added a couple more examples (please check) | > | > Split (C2a) and (C2b) – thank you Joachim for filling out the | list. | > | > Add a Notes section that identifies some consequences, | hopefully | > | objectively. | > | > Added a list at the end where you can add your AYE when happy. | > | > | > | > Can you review, and Christopher, Richard, Cale, Simon, Eric, | Alejandro, | > | Arnaud: please add AYE or suggest further changes. | > | > This is painstaking but I think it is clarifying. I have found | writing | > | out the examples is quite helpful. Feel free to suggest more if | you think | > | there are some cases that are unclear. | > | > Thanks | > | > Simon | > | > | > | > From: Simon Peyton Jones | > | > Sent: 06 March 2020 17:59 | > | > To: ghc-steering-committee | > | > Cc: Simon Peyton Jones | > | > Subject: RecordDotSyntax proposal: next steps | > | > | > | > Colleagues | > | > I’m sorry to have been dragging my feet on the records | proposal. First | > | there was half term holiday, and then the ICFP deadline, so I’ve | been out | > | of action for several weeks. | > | > It’s pretty clear that we are not going to achieve 100% | consensus, so | > | the right thing to do is to vote, using the single-transferrable- | vote | > | scheme that Joachim runs. It’s worth striving for consensus, | because the | > | debate can be clarifying (and has been!). But I don’t regard | non- | > | consensus as a failure. These things are all judgement calls, | and | > | people’s judgement can legitimately differ. Voting lets us | nevertheless | > | reach a conclusion. | > | > So here’s what I propose | > | > | > | > I’ve put up a list of choices for us to vote on here, informed | by our | > | most recent email exchanges. The first thing is to ensure that | this list | > | is | > | > | > | > Complete: no choices that people really want are omitted. | > | > Clear and unambiguous. When we vote we must know exactly what | we are | > | voting for! | > | > | > | > Can you all respond about that, including “Aye” if you think it | is both | > | complete and clear. | > | > | > | > Once we are all satisfied, I’ll invite you to vote. The | easiest way to | > | do so might be to edit the Google doc directly, so there’s a | single point | > | of reference. | > | > | > | > Please also let me know if you think we should be doing | anything else. | > | > Thanks! | > | > Simon | > | > | > | >

The examples are good, but I know from experience it's easy to overlook things if we don't consider what the precise grammar is, both at the lexical and context-free levels. So I wouldn't feel comfortable voting on a proposal where the grammar isn't completely clear. I agree with that in principle, but I don’t want to ask the authors to work up 6 or 7 different full syntaxes, just to us to accept at most one. If it turns that the one we accept (if indeed we accept any) is hard to define, let’s revisit. * Is (.a.b) legal? Under which alternatives? What about (.a .b)? What about (. .x)? I have added some new words to clarify lexical syntax, which should answer your question. Please say if not. * Does ( .x) mean (.x) or (. x)? Same as any other operator like (+). You can write (+ ) or ( +) or (+) or ( + ). But since (. x) has lexeme for “.” and one for “x”, that’s different. See the new words. * I presume under C2a things like 3.x, "abc".y, and [1,2,3].z would be legal… One of the great disadvantages of C2a and C3 is the awkwardness of defining tight infix for dot. See Note 4. * data R = R { (.) :: Int } This is a good point which applies to the entire proposal. It needs to be addressed. But it’s very much a corner case, and we should not let the tail wag the dog. * Can I use a record selector infix by surrounding it with ``? i.e. is `.x` a legal infix operator? (I'm guessing not) You can clearly say `(.x)`. I would guess that you can’t omit the parens. Again, should ultimately be nailed down but doesn’t really affect our decision making. Do the clarifications in the document allow you enough clarity to make an informed choice? Simon From: Simon Marlow Sent: 15 March 2020 13:22 To: Simon Peyton Jones Cc: Christopher Allen ; Cale Gibbard ; ghc-steering-committee Subject: Re: RecordDotSyntax proposal: next steps The examples are good, but I know from experience it's easy to overlook things if we don't consider what the precise grammar is, both at the lexical and context-free levels. So I wouldn't feel comfortable voting on a proposal where the grammar isn't completely clear. Some questions that come to mind given the current set of proposals: Is (.a.b) legal? Under which alternatives? What about (.a .b)? What about (. .x)? Does ( .x) mean (.x) or (. x)? I presume under C2a things like 3.x, "abc".y, and [1,2,3].z would be legal, given suitable instances for Integral, IsString, or IsList? Which other proposals does that apply to? If I have a record with a varsym field name, can I use dot syntax with it? e.g. data R = R { (.) :: Int } Now can I say r.(.) or r..? (note that the qualified name equivalent of this is M.. which is legal). If r.. is legal, presumably I should be able to use (..)? I suspect there are a lot of worms in this can :) Can I use a record selector infix by surrounding it with ``? i.e. is `.x` a legal infix operator? (I'm guessing not) By the way, I understand the authors of the original proposal are against C5 so if that were the committee's preferred option then someone else would need to adopt the proposal. Cheers Simon On Fri, 13 Mar 2020 at 17:43, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: Thanks. You can’t vote if you don’t understand the alternatives! And if you can’t maybe others can’t – or will do so based on different understandings of the same thing. That would be Bad. I’m not well positioned to fix this because I don’t know where the ambiguities are. Would you like to ask some clarifying questions? Simon From: Simon Marlow mailto:marlowsd@gmail.com> Sent: 13 March 2020 17:30 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: Christopher Allen mailto:cma@bitemyapp.com>; Cale Gibbard mailto:cgibbard@gmail.com>; ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Subject: Re: RecordDotSyntax proposal: next steps It's still a bit hard (IMO) to understand what precise changes each proposal would make to the syntax, but I don't want to hold things up so I've added an AYE. Cheers Simon On Fri, 13 Mar 2020 at 10:38, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: Chris, Cale, Simon I wonder if you might have a moment to respond to this email? Thanks Simon From: Simon Peyton Jones mailto:simonpj@microsoft.com> Sent: 09 March 2020 09:56 To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com> Subject: RE: RecordDotSyntax proposal: next steps Colleagues Thanks for your various replies. I have * Added a couple more examples (please check) * Split (C2a) and (C2b) – thank you Joachim for filling out the list. * Add a Notes section that identifies some consequences, hopefully objectively. * Added a list at the end where you can add your AYE when happy. Can you review, and Christopher, Richard, Cale, Simon, Eric, Alejandro, Arnaud: please add AYE or suggest further changes. This is painstaking but I think it is clarifying. I have found writing out the examples is quite helpful. Feel free to suggest more if you think there are some cases that are unclear. Thanks Simon From: Simon Peyton Jones mailto:simonpj@microsoft.com> Sent: 06 March 2020 17:59 To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com> Subject: RecordDotSyntax proposal: next steps Colleagues I’m sorry to have been dragging my feet on the records proposal. First there was half term holiday, and then the ICFP deadline, so I’ve been out of action for several weeks. It’s pretty clear that we are not going to achieve 100% consensus, so the right thing to do is to vote, using the single-transferrable-vote scheme that Joachim runs. It’s worth striving for consensus, because the debate can be clarifying (and has been!). But I don’t regard non-consensus as a failure. These things are all judgement calls, and people’s judgement can legitimately differ. Voting lets us nevertheless reach a conclusion. So here’s what I propose * I’ve put up a list of choices for us to vote on herehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7C6211b3c422ef483414b708d7c8e3d967%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637198753236487549&sdata=PZo0sVH3fsQPAecTzN5DCsN9UNbaaGi563PxuO2%2BnaI%3D&reserved=0, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * Clear and unambiguous. When we vote we must know exactly what we are voting for! Can you all respond about that, including “Aye” if you think it is both complete and clear. * Once we are all satisfied, I’ll invite you to vote. The easiest way to do so might be to edit the Google doc directly, so there’s a single point of reference. Please also let me know if you think we should be doing anything else. Thanks! Simon

Should the text "except when parenthesised (.x)" in C2b also be added to C2a? Note 5 should apply to C7 too, now? Yes to both. Thanks. Re Note 5, I’d like to point you all to this part of the proposalhttps://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/p..., which I had previously missed entirely. It describes how to use SrcSpan in the parser to decide if two lexemes are juxtaposed with no white space whatsoever. I think that’s a pretty interesting thought. For example, we might be able to use it to parse qualified names, rather than have complicated rules in the lexer. But meanwhile, it’s a decent response to Note 5. I think we have all AYEs. Don’t vote yet – I want to review the slate first. Simon From: Simon Marlow Sent: 17 March 2020 13:31 To: Simon Peyton Jones Cc: Christopher Allen ; Cale Gibbard ; ghc-steering-committee Subject: Re: RecordDotSyntax proposal: next steps Should the text "except when parenthesised (.x)" in C2b also be added to C2a? Note 5 should apply to C7 too, now? On Mon, 16 Mar 2020 at 14:43, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: The examples are good, but I know from experience it's easy to overlook things if we don't consider what the precise grammar is, both at the lexical and context-free levels. So I wouldn't feel comfortable voting on a proposal where the grammar isn't completely clear. I agree with that in principle, but I don’t want to ask the authors to work up 6 or 7 different full syntaxes, just to us to accept at most one. If it turns that the one we accept (if indeed we accept any) is hard to define, let’s revisit. OK, sounds reasonable. * Is (.a.b) legal? Under which alternatives? What about (.a .b)? What about (. .x)? I have added some new words to clarify lexical syntax, which should answer your question. Please say if not. * Does ( .x) mean (.x) or (. x)? Same as any other operator like (+). You can write (+ ) or ( +) or (+) or ( + ). But since (. x) has lexeme for “.” and one for “x”, that’s different. See the new words. * I presume under C2a things like 3.x, "abc".y, and [1,2,3].z would be legal… One of the great disadvantages of C2a and C3 is the awkwardness of defining tight infix for dot. See Note 4. * data R = R { (.) :: Int } This is a good point which applies to the entire proposal. It needs to be addressed. But it’s very much a corner case, and we should not let the tail wag the dog. OK. But the misdesign of qualified identifiers led to the situation where no Haskell compiler conforms to the spec, since the spec is silly (eg. the spec says M... lexes as the two lexemes M.. .). We should strive to avoid making that situation worse. * * Can I use a record selector infix by surrounding it with ``? i.e. is `.x` a legal infix operator? (I'm guessing not) You can clearly say `(.x)`. I would guess that you can’t omit the parens. Again, should ultimately be nailed down but doesn’t really affect our decision making. Really? You can't say `(+)` right now in Haskell, so it would be surprising if you could say `(.x)` Do the clarifications in the document allow you enough clarity to make an informed choice? Kind of :) I'm happy to proceed on the basis that we're choosing high-level direction and the details will be worked out later, but it may be that some or all of these proposals lead to significant ugliness in their full specification. Cheers Simon Simon From: Simon Marlow mailto:marlowsd@gmail.com> Sent: 15 March 2020 13:22 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: Christopher Allen mailto:cma@bitemyapp.com>; Cale Gibbard mailto:cgibbard@gmail.com>; ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Subject: Re: RecordDotSyntax proposal: next steps The examples are good, but I know from experience it's easy to overlook things if we don't consider what the precise grammar is, both at the lexical and context-free levels. So I wouldn't feel comfortable voting on a proposal where the grammar isn't completely clear. Some questions that come to mind given the current set of proposals: Is (.a.b) legal? Under which alternatives? What about (.a .b)? What about (. .x)? Does ( .x) mean (.x) or (. x)? I presume under C2a things like 3.x, "abc".y, and [1,2,3].z would be legal, given suitable instances for Integral, IsString, or IsList? Which other proposals does that apply to? If I have a record with a varsym field name, can I use dot syntax with it? e.g. data R = R { (.) :: Int } Now can I say r.(.) or r..? (note that the qualified name equivalent of this is M.. which is legal). If r.. is legal, presumably I should be able to use (..)? I suspect there are a lot of worms in this can :) Can I use a record selector infix by surrounding it with ``? i.e. is `.x` a legal infix operator? (I'm guessing not) By the way, I understand the authors of the original proposal are against C5 so if that were the committee's preferred option then someone else would need to adopt the proposal. Cheers Simon On Fri, 13 Mar 2020 at 17:43, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: Thanks. You can’t vote if you don’t understand the alternatives! And if you can’t maybe others can’t – or will do so based on different understandings of the same thing. That would be Bad. I’m not well positioned to fix this because I don’t know where the ambiguities are. Would you like to ask some clarifying questions? Simon From: Simon Marlow mailto:marlowsd@gmail.com> Sent: 13 March 2020 17:30 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: Christopher Allen mailto:cma@bitemyapp.com>; Cale Gibbard mailto:cgibbard@gmail.com>; ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Subject: Re: RecordDotSyntax proposal: next steps It's still a bit hard (IMO) to understand what precise changes each proposal would make to the syntax, but I don't want to hold things up so I've added an AYE. Cheers Simon On Fri, 13 Mar 2020 at 10:38, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: Chris, Cale, Simon I wonder if you might have a moment to respond to this email? Thanks Simon From: Simon Peyton Jones mailto:simonpj@microsoft.com> Sent: 09 March 2020 09:56 To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com> Subject: RE: RecordDotSyntax proposal: next steps Colleagues Thanks for your various replies. I have * Added a couple more examples (please check) * Split (C2a) and (C2b) – thank you Joachim for filling out the list. * Add a Notes section that identifies some consequences, hopefully objectively. * Added a list at the end where you can add your AYE when happy. Can you review, and Christopher, Richard, Cale, Simon, Eric, Alejandro, Arnaud: please add AYE or suggest further changes. This is painstaking but I think it is clarifying. I have found writing out the examples is quite helpful. Feel free to suggest more if you think there are some cases that are unclear. Thanks Simon From: Simon Peyton Jones mailto:simonpj@microsoft.com> Sent: 06 March 2020 17:59 To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com> Subject: RecordDotSyntax proposal: next steps Colleagues I’m sorry to have been dragging my feet on the records proposal. First there was half term holiday, and then the ICFP deadline, so I’ve been out of action for several weeks. It’s pretty clear that we are not going to achieve 100% consensus, so the right thing to do is to vote, using the single-transferrable-vote scheme that Joachim runs. It’s worth striving for consensus, because the debate can be clarifying (and has been!). But I don’t regard non-consensus as a failure. These things are all judgement calls, and people’s judgement can legitimately differ. Voting lets us nevertheless reach a conclusion. So here’s what I propose * I’ve put up a list of choices for us to vote on herehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7C8280bbafd4554ecdfa2908d7ca77853f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637200487060704430&sdata=L4xcFwe736HvI2X8oikT7pwQXVdl4DgqMdc3wcOVt%2FA%3D&reserved=0, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * Clear and unambiguous. When we vote we must know exactly what we are voting for! Can you all respond about that, including “Aye” if you think it is both complete and clear. * Once we are all satisfied, I’ll invite you to vote. The easiest way to do so might be to edit the Google doc directly, so there’s a single point of reference. Please also let me know if you think we should be doing anything else. Thanks! Simon