[ghc-steering-committee] RecordDotSyntax proposal: next steps

Sun Mar 15 10:27:27 UTC 2020

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".

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?).

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)`.

Alejandro

El dom., 15 mar. 2020 a las 3:32, Cale Gibbard (<cgibbard at gmail.com>)
escribió:

> 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 at bitemyapp.com> wrote:
> >
> > Marked myself AYE for the choices.
> >
> > On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones <simonpj at 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 at gmail.com>
> > Sent: 13 March 2020 17:30
> > To: Simon Peyton Jones <simonpj at microsoft.com>
> > Cc: Christopher Allen <cma at bitemyapp.com>; Cale Gibbard <
> cgibbard at gmail.com>; ghc-steering-committee <
> ghc-steering-committee at 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 at 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 at microsoft.com>
> > Sent: 09 March 2020 09:56
> > To: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > Cc: Simon Peyton Jones <simonpj at 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 at microsoft.com>
> > Sent: 06 March 2020 17:59
> > To: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > Cc: Simon Peyton Jones <simonpj at 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
> >
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200315/0768f26d/attachment-0001.html>