<div dir="ltr">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 :-) <div><br></div><div><div>Hope everyone is staying healthy!</div></div><div>Cheers,</div><div>-Iavor</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard <<a href="mailto:cgibbard@gmail.com">cgibbard@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via<br>
ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>> wrote:<br>
> 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.<br>
<br>
I'm not sure any of these proposed options feels "obviously right"<br>
either. The fact that we're voting between many different ways to<br>
interpret the same syntax sugar should make it clear that this isn't<br>
so obvious.<br>
<br>
> But there was incremental progress, sketched here:<br>
><br>
> DuplicateRecordFields lets you have multiple records with the same field name.<br>
> The HasField class lets us define overloaded record selection and update functions.<br>
><br>
> 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.)<br>
><br>
> 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.<br>
<br>
While I'd agree it has vastly higher impact that a lot of accepted<br>
proposals, I'm not sure that impact is actually in the direction of<br>
making it easier to read and understand programs that are written in<br>
Haskell. It's syntactic sugar that we've pretty reasonably done<br>
without for a long time. Piling on yet another option for how to<br>
select fields from records amidst a sea of libraries that already help<br>
with this in various ways that go far beyond the capabilities of the<br>
syntax sugar that's proposed here seems a bit strange to me at this<br>
point. It feels like the complaint is "but I want to type exactly this<br>
string of characters and no other will do", which seems kind of absurd<br>
to me, but other languages exist in the world, and DAML for instance<br>
is a thing which exists now and should satisfy those people. I don't<br>
particularly get why it's of great importance for Haskell to support<br>
accessing fields with *this* syntax, and not dozens of<br>
almost-equivalent syntaxes that one could already achieve.<br>
<br>
If there were no confusion over what the infix dot meant and how it<br>
interacted with the rest of Haskell's syntax, then maybe there<br>
wouldn't be anything much to be unhappy about in adding in this extra<br>
bit of sugar. But it is manifestly confusing or else we wouldn't be<br>
having this vote and so many clarifications about what consequences<br>
the options had wouldn't have been needed. All these syntactic<br>
questions that have been asked and debated in this thread are<br>
something that every beginner will have to contend with, and all the<br>
consequences of whatever option is selected are something every expert<br>
will have to live with. I don't feel that it's worth the extremely<br>
meagre benefit of the difference between this and just opting to use<br>
lens or otherwise just using the already existing mechanisms.<br>
<br>
Frankly, I still mostly use Haskell's ordinary field accessors unless<br>
there's a real need for abstracting over a lens (at which point I'll<br>
switch to using Ed's lens library), or just abstracting over field<br>
access (at which point I'll probably define my own class), and<br>
DuplicateRecordFields and the associated machinery is not something<br>
that I have had a whole lot of love for in the first place.<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>