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

[Simon Peyton Jones]

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 at gmail.com>
|  Sent: 16 March 2020 14:56
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Christopher Allen <cma at bitemyapp.com>; Simon Marlow
|  <marlowsd at gmail.com>; ghc-steering-committee <ghc-steering-
|  committee at haskell.org>
|  Subject: Re: RecordDotSyntax proposal: next steps
|  
|  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
|  > |  >
|  > |  >