<div dir="ltr">Alejandro: most likely what happened indeed. I hadn't voted yet. Now fixed.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020 at 8:20 PM Alejandro Serrano Mena <<a href="mailto:trupill@gmail.com" target="_blank">trupill@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"><div dir="auto">This is weird, I voted a couple of days ago. Maybe I wrote my votes in Arnaud's place?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 24 mar. 2020 20:18, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Simon, Alejandro, we are awaiting your votes.<br>
<a href="https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74/edit" rel="noreferrer noreferrer" target="_blank">https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74/edit</a><br>
<br>
Simon<br>
<br>
<br>
| -----Original Message-----<br>
| From: ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" rel="noreferrer" target="_blank">ghc-steering-committee-bounces@haskell.org</a>><br>
| On Behalf Of Eric Seidel<br>
| Sent: 24 March 2020 18:09<br>
| To: <a href="mailto:ghc-steering-committee@haskell.org" rel="noreferrer" target="_blank">ghc-steering-committee@haskell.org</a><br>
| Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote<br>
| <br>
| I noticed the same thing, I don't see anything remotely resembling a<br>
| consensus in the votes. Just out of curiousity Joachim, does the Schulze<br>
| method have any metric of how close or far from a consensus the votes are?<br>
| If so, I'd be very interested to see what it says about the votes here.<br>
| <br>
| Let me also take a moment to explain why I voted for C4 as my first<br>
| choice, since it seems to be particularly polarizing. The two factors that<br>
| pushed me to favor C4 are its simplicity and its consistency with the rest<br>
| of Haskell's record syntax.<br>
| <br>
| C4 is a very simple rule, it introduces a single new lexeme ('.x') and a<br>
| single rule for parsing it (it's a postfix operator that binds tighter<br>
| than application). In my opinion it's the simplest rule after C2b (which I<br>
| also ranked highly). The other rules all introduce extra complexity into<br>
| the syntax, often around treating 'r.x' or 'M.r.x' as a single lexeme in<br>
| constrast to the interpretation of a bare '.x'. The simplest solution is<br>
| not always the best one, but I believe C4 will at least be easier to learn<br>
| and become comfortable with, even if it doesn't always produce the parses<br>
| you would like.<br>
| <br>
| C4 is also consistent with Haskell's record creation/update syntax. I know<br>
| a lot of people dislike the fact that record creation/update binds tighter<br>
| than application. Simon PJ says he would argue strenuously against it if<br>
| we were designing Haskell from scratch today, and I'm pretty sympathetic<br>
| to that position. But we aren't redesigning Haskell's syntax today, we're<br>
| trying to fit a new piece of syntax into an existing grammar. Given those<br>
| constraints, I think it makes a lot of sense to lean on the intuitions<br>
| that people have already built about how record syntax behaves.<br>
| <br>
| Hope everyone is well, and not going too stir crazy at home!<br>
| Eric<br>
| <br>
| On Tue, Mar 24, 2020, at 13:32, Iavor Diatchki wrote:<br>
| > I just added my vote to the document, apologies for the delay. It is<br>
| > quite interesting looking at the other votes, as some of them seem to<br>
| > be exactly the opposite of what I think should be done :-)<br>
| ><br>
| > Hope everyone is staying healthy!<br>
| > Cheers,<br>
| > -Iavor<br>
| ><br>
| > On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard <<a href="mailto:cgibbard@gmail.com" rel="noreferrer" target="_blank">cgibbard@gmail.com</a>> wrote:<br>
| > > On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via<br>
| > > ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" rel="noreferrer" target="_blank">ghc-steering-committee@haskell.org</a>> wrote:<br>
| > > > Overall, I strongly urge that we accept the proposal in some form;<br>
| that is, we should not do (C1). I have been unhappy with GHC's story for<br>
| records for two decades. (E.g. Lightweight extensible records for Haskell,<br>
| Haskell Workshop, Paris 1999.) But the design space is so complicated that<br>
| we never found something that felt "obviously right". So we did nothing<br>
| 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<br>
| field name.<br>
| > > > The HasField class lets us define overloaded record selection and<br>
| update functions.<br>
| > > ><br>
| > > > The proposal we are now discussing has no type-system component; it<br>
| is only about syntactic sugar, allowing you to use dot-notation for field<br>
| selection. (Various extensions about syntax for update were discussed, but<br>
| 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<br>
| than many other accepted proposals. I know that some members of the<br>
| 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<br>
| 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<br>
| this<br>
| > > string of characters and no other will do", which seems kind of<br>
| 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<br>
| 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" rel="noreferrer" target="_blank">ghc-steering-committee@haskell.org</a><br>
| > > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-" rel="noreferrer noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-</a><br>
| committee<br>
| > _______________________________________________<br>
| > ghc-steering-committee mailing list<br>
| > <a href="mailto:ghc-steering-committee@haskell.org" rel="noreferrer" target="_blank">ghc-steering-committee@haskell.org</a><br>
| > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
| ><br>
| _______________________________________________<br>
| ghc-steering-committee mailing list<br>
| <a href="mailto:ghc-steering-committee@haskell.org" rel="noreferrer" target="_blank">ghc-steering-committee@haskell.org</a><br>
| <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
_______________________________________________<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>