<div dir="ltr"><div>I've been thinking a bit more about the list of choices. First of all, I agree with the spirit of Cale's last comment: having so many "natural" possibilities means that none of them are really "natural".<br></div><div><br></div><div>In fact, I found some variation of choice 2b which I feel as "natural" and "useful". I support making .x illegal, but allowing (.x) as a section. The problem is that that does not allow nested record queries, as in (.name.first), which I think is where the strength of this proposal comes from (otherwise, which not just use `x` since it's already a field selector?).</div><div><br></div><div>Apart from that, I think that we should ban any other possibly-ambiguous choice, by making more use of the "tight operator" rule. I don't think losing the ability to write selector accross multiple lines is so terrible compared to being puzzled about `f r.x` not parsing as `f (r.x)`.</div><div><br></div><div>Alejandro<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El dom., 15 mar. 2020 a las 3:32, Cale Gibbard (<<a href="mailto:cgibbard@gmail.com">cgibbard@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I registered my "aye" as well, but I'd just like to reiterate that I<br>
think the language is already hard enough for beginners and experts<br>
alike to parse. The fact that all of these options are probably what<br>
*someone* would intuitively expect and that there are so many axes<br>
along which we're not sure how to disambiguate various expressions<br>
seems like a strong signal that this whole thing is ill-advised.<br>
<br>
If this makes its way into GHC, it'll be banned where I work for being<br>
much too confusing and unnecessary, but that still won't absolve us of<br>
needing to deal with it, as it'll much harder to guarantee that none<br>
of our dependencies will ever start using it.<br>
<br>
Actually, I just changed my mind, maybe there's one other option that<br>
should make it in as a second option in case we're unable to kill this<br>
proposal: none of the ambiguous expressions that are taken as examples<br>
there is valid. Take the record-selection-dot to be at the same level<br>
of precedence as function application, and therefore it must be<br>
parenthesized when used alongside function applications. I still don't<br>
like the proposal with that option, but it's better than C2-C6.<br>
<br>
Should we add it?<br>
<br>
On Sat, 14 Mar 2020 at 12:21, Christopher Allen <<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</a>> wrote:<br>
><br>
> Marked myself AYE for the choices.<br>
><br>
> On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> Simon<br>
><br>
> From: Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>><br>
> Sent: 13 March 2020 17:30<br>
> To: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
> Cc: Christopher Allen <<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</a>>; Cale Gibbard <<a href="mailto:cgibbard@gmail.com" target="_blank">cgibbard@gmail.com</a>>; ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
> Subject: Re: RecordDotSyntax proposal: next steps<br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> Cheers<br>
><br>
> Simon<br>
><br>
><br>
><br>
> On Fri, 13 Mar 2020 at 10:38, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br>
><br>
> Chris, Cale, Simon<br>
> I wonder if you might have a moment to respond to this email?<br>
> Thanks<br>
> Simon<br>
><br>
> From: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
> Sent: 09 March 2020 09:56<br>
> To: ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
> Cc: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
> Subject: RE: RecordDotSyntax proposal: next steps<br>
><br>
> Colleagues<br>
> Thanks for your various replies.   I have<br>
><br>
> Added a couple more examples (please check)<br>
> Split (C2a) and (C2b) – thank you Joachim for filling out the list.<br>
> Add a Notes section that identifies some consequences, hopefully objectively.<br>
> Added a list  at the end where you can add your AYE when happy.<br>
><br>
> Can you review, and Christopher, Richard, Cale, Simon, Eric, Alejandro, Arnaud: please add AYE or suggest further changes.<br>
> 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.<br>
> Thanks<br>
> Simon<br>
><br>
> From: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
> Sent: 06 March 2020 17:59<br>
> To: ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
> Cc: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
> Subject: RecordDotSyntax proposal: next steps<br>
><br>
> Colleagues<br>
> 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.<br>
> 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.<br>
> So here’s what I propose<br>
><br>
> 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<br>
><br>
> Complete: no choices that people really want are omitted.<br>
> Clear and unambiguous.  When we vote we must know exactly what we are voting for!<br>
><br>
> Can you all respond about that, including “Aye” if you think it is both complete and clear.<br>
><br>
> 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.<br>
><br>
> Please also let me know if you think we should be doing anything else.<br>
> Thanks!<br>
> Simon<br>
><br>
><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>