[ghc-steering-committee] Record dot notation

Tue Feb 11 10:33:28 UTC 2020

In my message on 7th I said that the first step would be to identify the alternatives on which we could subsequently vote.   Since then

  *   Joachim suggested (5)
  *   I suggested a refinement to that (yesterday), treating r.x as a lexeme like M.x, but otherwise like (5)

Does anyone have any other alternatives they actively want to see on the list? Then I’ll gather them together and invite you to express your votes.

Simon

From: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
Sent: 11 February 2020 07:59
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Record dot notation

I'm swaying back and forth, but I'll go with my gut feeling:
4>3>2>1

On Fri, Feb 7, 2020 at 6:13 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
Colleagues

I've been slow on the records front; apologies.

I think Joachim is right: we've discussed a lot of options, but in the
end much of this is a judgement call with no perfect answers, and it
now seems simplest to express our judgement through voting. I think
we are all keen to decide this and move on.

Proposal: https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/proposals/0000-record-dot-syntax.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-syntax%2Fproposals%2F0000-record-dot-syntax.md&data=02%7C01%7Csimonpj%40microsoft.com%7C2ec11b916c3c40b82aa908d7aec860aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637170047953657130&sdata=NWy9iShBf7S4tdyrcRbodn6ndJwzmFXxf%2B9LTkrkTpE%3D&reserved=0>
Lengthy discussion: https://github.com/ghc-proposals/ghc-proposals/pull/282<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C2ec11b916c3c40b82aa908d7aec860aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637170047953667118&sdata=hpHYTOzXELGfc2s4lfvY9VyFn58biKD1D0S9a2coq%2FQ%3D&reserved=0>

Here are the alternatives I propose we vote on.  The first order of
business is to check that they are all clear; and that I haven't omitted
a worthy alternative.  Here they are:

1. Reject the proposal

2. Naked .x is illegal

3. Naked .x is a postfix operator, binding exactly
   like application:  f r .x   means (f r).x

4. Naked .x is a postfix operator, binding more tightly
   than application: f r .x   means   f (r.x)

Under all of (2,3,4) I think we are content that
  - (f r.x) means  (f (r.x))
  - (.x)    means  (\r -> r.x)

By "naked .x" I mean "not preceded by an identifier (e.g. r.x),
or an open paren (e.g. (.x)), or a close paren (e.g. (f 3).x)

We could re-open more of this, but I'd prefer to keep it to 1-4.

Let's just check everyone is happy with these alternatives.  Then we can
vote by putting in rank order, and Joachim can run his STV algorithm.

I'm the shepherd for this proposal, so let me add my recommendations.

I strongly urge that we do not adopt (1); that is, we accept the
proposal in some form.  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.

But there was incremental progress, sketched here:
https://gitlab.haskell.org/ghc/ghc/wikis/records/overloaded-record-fields<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fwikis%2Frecords%2Foverloaded-record-fields&data=02%7C01%7Csimonpj%40microsoft.com%7C2ec11b916c3c40b82aa908d7aec860aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637170047953667118&sdata=6pEL%2FH5MBhMuiu%2FmrhwwMqMh5x6af5owTypjc5lln2U%3D&reserved=0>

* 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, which
has a particularly high benefit/cost ratio.

Now, judgements may differ about the importance of syntactic sugar --
that's why we have a committee with a diversity of views -- but I
believe that dot-notation for record selection is super-important.
I've wanted it for ages.  Every other language has it.  We have
accepted other syntactic sugar with much lower utility.  And
the dot is already a special case, via qualified names.

I respect the fact that others may differ, but I really think
think this is worth it.  It would be a crying shame to reject
this.  Unlike Chris, I don't think anything better is going to
emerge, however long we wait.

I am more relaxed about 2/3/4.  Personally I hate (4) because
I don't like *any* notation in which something binds more tightly
than function application.  e.g. I cordially dislike (f K {x=3})
meaning (f (K {x=3})).

My preference is for (3), which allows record selection with
spaces (which some argue for).  But (2) represents at most a lost
opportunity, not a bad thing.

Thanks

Simon

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto: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%7C2ec11b916c3c40b82aa908d7aec860aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637170047953677114&sdata=RTbRved4sbRlFZMjrbXXh8%2FuRBJ5%2FubHzMzzOMc6kzw%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200211/13edf60d/attachment-0001.html>