[ghc-steering-committee] Record dot syntax: time to vote
Alejandro Serrano Mena
trupill at gmail.com
Tue Mar 24 19:20:12 UTC 2020
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 <simonpj at microsoft.com>
escribió:
> Simon, Alejandro, we are awaiting your votes.
>
> https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74/edit
>
> Simon
>
>
> | -----Original Message-----
> | From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org>
> | On Behalf Of Eric Seidel
> | Sent: 24 March 2020 18:09
> | To: ghc-steering-committee at 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 <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
> | >
> | _______________________________________________
> | ghc-steering-committee mailing list
> | ghc-steering-committee at haskell.org
> |
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200324/014a18e1/attachment-0001.html>
More information about the ghc-steering-committee
mailing list