Thanks Cale. You’ve made helpful clarifications on the Google doc. I think I understand the proposal now. Simon | -----Original Message----- | From: Cale Gibbard <cgibbard@gmail.com> | Sent: 16 March 2020 14:56 | To: Simon Peyton Jones <simonpj@microsoft.com> | Cc: Christopher Allen <cma@bitemyapp.com>; Simon Marlow | <marlowsd@gmail.com>; ghc-steering-committee <ghc-steering- | committee@haskell.org> | Subject: Re: RecordDotSyntax proposal: next steps | | On Mon, 16 Mar 2020 at 10:28, Simon Peyton Jones | <simonpj@microsoft.com> 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 <cgibbard@gmail.com> | > | Sent: 15 March 2020 02:32 | > | To: Christopher Allen <cma@bitemyapp.com> | > | Cc: Simon Peyton Jones <simonpj@microsoft.com>; Simon Marlow | > | <marlowsd@gmail.com>; ghc-steering-committee <ghc-steering- | > | 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 | <cma@bitemyapp.com> wrote: | > | > | > | > Marked myself AYE for the choices. | > | > | > | > On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones | <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 <marlowsd@gmail.com> | > | > Sent: 13 March 2020 17:30 | > | > To: Simon Peyton Jones <simonpj@microsoft.com> | > | > Cc: Christopher Allen <cma@bitemyapp.com>; Cale Gibbard | > | <cgibbard@gmail.com>; ghc-steering-committee <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 | <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 <simonpj@microsoft.com> | > | > Sent: 09 March 2020 09:56 | > | > To: ghc-steering-committee <ghc-steering-committee@haskell.org> | > | > Cc: Simon Peyton Jones <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 <simonpj@microsoft.com> | > | > Sent: 06 March 2020 17:59 | > | > To: ghc-steering-committee <ghc-steering-committee@haskell.org> | > | > Cc: Simon Peyton Jones <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 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 | > | > | > | >