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

This is weird, I voted a couple of days ago. Maybe I wrote my votes in Arnaud's place? El mar., 24 mar. 2020 20:18, Simon Peyton Jones escribió:

Simon, Alejandro, we are awaiting your votes.

https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7i...

Simon

| -----Original Message----- | From: ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> | On Behalf Of Eric Seidel | Sent: 24 March 2020 18:09 | To: ghc-steering-committee@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 wrote: | > > On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via | > > ghc-steering-committee 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@haskell.org | > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee | > | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee