Re: [ghc-steering-committee] 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 | 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 | > | >