[ghc-steering-committee] Record dot syntax: time to vote

[Simon Peyton Jones]

Simon, Alejandro, we are awaiting your votes.
https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74/edit

Simon


|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Eric Seidel
|  Sent: 24 March 2020 18:09
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote
|  
|  I noticed the same thing, I don't see anything remotely resembling a
|  consensus in the votes. Just out of curiousity Joachim, does the Schulze
|  method have any metric of how close or far from a consensus the votes are?
|  If so, I'd be very interested to see what it says about the votes here.
|  
|  Let me also take a moment to explain why I voted for C4 as my first
|  choice, since it seems to be particularly polarizing. The two factors that
|  pushed me to favor C4 are its simplicity and its consistency with the rest
|  of Haskell's record syntax.
|  
|  C4 is a very simple rule, it introduces a single new lexeme ('.x') and a
|  single rule for parsing it (it's a postfix operator that binds tighter
|  than application). In my opinion it's the simplest rule after C2b (which I
|  also ranked highly). The other rules all introduce extra complexity into
|  the syntax, often around treating 'r.x' or 'M.r.x' as a single lexeme in
|  constrast to the interpretation of a bare '.x'. The simplest solution is
|  not always the best one, but I believe C4 will at least be easier to learn
|  and become comfortable with, even if it doesn't always produce the parses
|  you would like.
|  
|  C4 is also consistent with Haskell's record creation/update syntax. I know
|  a lot of people dislike the fact that record creation/update binds tighter
|  than application. Simon PJ says he would argue strenuously against it if
|  we were designing Haskell from scratch today, and I'm pretty sympathetic
|  to that position. But we aren't redesigning Haskell's syntax today, we're
|  trying to fit a new piece of syntax into an existing grammar. Given those
|  constraints, I think it makes a lot of sense to lean on the intuitions
|  that people have already built about how record syntax behaves.
|  
|  Hope everyone is well, and not going too stir crazy at home!
|  Eric
|  
|  On Tue, Mar 24, 2020, at 13:32, Iavor Diatchki wrote:
|  > I just added my vote to the document, apologies for the delay. It is
|  > quite interesting looking at the other votes, as some of them seem to
|  > be exactly the opposite of what I think should be done :-)
|  >
|  > Hope everyone is staying healthy!
|  > Cheers,
|  > -Iavor
|  >
|  > On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard <cgibbard at gmail.com> wrote:
|  > > On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via
|  > >  ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
|  > >  > Overall, I strongly urge that we accept the proposal in some form;
|  that is, we should not do (C1). I have been unhappy with GHC's story for
|  records for two decades. (E.g. Lightweight extensible records for Haskell,
|  Haskell Workshop, Paris 1999.) But the design space is so complicated that
|  we never found something that felt "obviously right". So we did nothing
|  drastic, and I think that was right.
|  > >
|  > >  I'm not sure any of these proposed options feels "obviously right"
|  > >  either. The fact that we're voting between many different ways to
|  > >  interpret the same syntax sugar should make it clear that this isn't
|  > >  so obvious.
|  > >
|  > >  > But there was incremental progress, sketched here:
|  > >  >
|  > >  > DuplicateRecordFields lets you have multiple records with the same
|  field name.
|  > >  > The HasField class lets us define overloaded record selection and
|  update functions.
|  > >  >
|  > >  > The proposal we are now discussing has no type-system component; it
|  is only about syntactic sugar, allowing you to use dot-notation for field
|  selection. (Various extensions about syntax for update were discussed, but
|  no longer form part of the proposal; what is left is the core.)
|  > >  >
|  > >  > I really think this change has vastly higher impact and utility
|  than many other accepted proposals. I know that some members of the
|  committee differ from this view; that's fair enough.
|  > >
|  > >  While I'd agree it has vastly higher impact that a lot of accepted
|  > >  proposals, I'm not sure that impact is actually in the direction of
|  > >  making it easier to read and understand programs that are written in
|  > >  Haskell. It's syntactic sugar that we've pretty reasonably done
|  > >  without for a long time. Piling on yet another option for how to
|  > >  select fields from records amidst a sea of libraries that already
|  help
|  > >  with this in various ways that go far beyond the capabilities of the
|  > >  syntax sugar that's proposed here seems a bit strange to me at this
|  > >  point. It feels like the complaint is "but I want to type exactly
|  this
|  > >  string of characters and no other will do", which seems kind of
|  absurd
|  > >  to me, but other languages exist in the world, and DAML for instance
|  > >  is a thing which exists now and should satisfy those people. I don't
|  > >  particularly get why it's of great importance for Haskell to support
|  > >  accessing fields with *this* syntax, and not dozens of
|  > >  almost-equivalent syntaxes that one could already achieve.
|  > >
|  > >  If there were no confusion over what the infix dot meant and how it
|  > >  interacted with the rest of Haskell's syntax, then maybe there
|  > >  wouldn't be anything much to be unhappy about in adding in this extra
|  > >  bit of sugar. But it is manifestly confusing or else we wouldn't be
|  > >  having this vote and so many clarifications about what consequences
|  > >  the options had wouldn't have been needed. All these syntactic
|  > >  questions that have been asked and debated in this thread are
|  > >  something that every beginner will have to contend with, and all the
|  > >  consequences of whatever option is selected are something every
|  expert
|  > >  will have to live with. I don't feel that it's worth the extremely
|  > >  meagre benefit of the difference between this and just opting to use
|  > >  lens or otherwise just using the already existing mechanisms.
|  > >
|  > >  Frankly, I still mostly use Haskell's ordinary field accessors unless
|  > >  there's a real need for abstracting over a lens (at which point I'll
|  > >  switch to using Ed's lens library), or just abstracting over field
|  > >  access (at which point I'll probably define my own class), and
|  > >  DuplicateRecordFields and the associated machinery is not something
|  > >  that I have had a whole lot of love for in the first place.
|  > >  _______________________________________________
|  > >  ghc-steering-committee mailing list
|  > > ghc-steering-committee at haskell.org
|  > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  committee
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
|  >
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee