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

[Simon Peyton Jones]

|  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

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.

Would you like to add C7 so we all vote for the same thing?  Or not -- it's up to you.

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