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

[Eric Seidel]

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
>