[ghc-steering-committee] Record dot syntax: time to vote
Spiwack, Arnaud
arnaud.spiwack at tweag.io
Wed Mar 25 07:50:54 UTC 2020
Alejandro: most likely what happened indeed. I hadn't voted yet. Now fixed.
On Tue, Mar 24, 2020 at 8:20 PM Alejandro Serrano Mena <trupill at gmail.com>
wrote:
> 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
>>
> _______________________________________________
> 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/20200325/f77e9447/attachment.html>
More information about the ghc-steering-committee
mailing list