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

[Iavor Diatchki]

I don't like C6 because `e.x` has completely different meaning when `e` is
a variable vs. when it is not.   This strikes me as quite an odd wart, and
I see no benefits to it whatsoever.  In fact, I can see it leading to bugs,
as most Haskell programmers I know assume that you can more or less freely
name or inline pure expressions without changing the meaning of the
program.

-Iavor



On Tue, Mar 24, 2020 at 12:19 PM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> 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 :-)
>
>
>
> Indeed.  I’m intrigued by how strenuously you dislike C6 (you would prefer
> to reject the entire proposal than have C6), even though C6 is but a mild
> variation of qualified names.  Would you like to say why?
>
>
>
> Simon
>
>
>
> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Sent:* 24 March 2020 17:32
> *To:* Cale Gibbard <cgibbard at gmail.com>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Record dot syntax: time to vote
>
>
>
> 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
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C402e189bd282458f6e2c08d7d0195732%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637206679602452262&sdata=AKJugFGwXrHJLrLEFU8xioCtibCWRnOml%2FWzNv7zzr0%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200324/072ef061/attachment.html>