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

[Simon Peyton Jones]

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

Indeed.  I’m intrigued by how strenuously you dislike C6 (you would prefer to reject the entire proposal than have C6), even though C6 is but a mild variation of qualified names.  Would you like to say why?

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 24 March 2020 17:32
To: Cale Gibbard <cgibbard at gmail.com>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote

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<mailto: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<mailto: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<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C402e189bd282458f6e2c08d7d0195732%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637206679602452262&sdata=AKJugFGwXrHJLrLEFU8xioCtibCWRnOml%2FWzNv7zzr0%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200324/afa49e9b/attachment.html>