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

[Cale Gibbard]

On Mon, 16 Mar 2020 at 10:28, Simon Peyton Jones <simonpj at 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 at gmail.com>
> |  Sent: 15 March 2020 02:32
> |  To: Christopher Allen <cma at bitemyapp.com>
> |  Cc: Simon Peyton Jones <simonpj at microsoft.com>; Simon Marlow
> |  <marlowsd at gmail.com>; ghc-steering-committee <ghc-steering-
> |  committee at 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 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
> |  >
> |  >