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

[Simon Marlow]

After voting I feel like writing down the rationale I used, and I'll
probably forget myself if I don't write this down:

1. Of greatest importance to me is the ability to replace an identifier by
a parenthesized expression without changing meaning. So "(f x).y" must mean
the same as "r.y". That rules out C2b and C6. (this rationale doesn't apply
to qualified names because we don't have first-class modules, and maybe one
day if that changes we will want to revisit the syntax for qualified names
too.)

2. I'm downranking proposals where selection binds "like application"
because I think it will end up being confusing. So that's C3, C5, C6.

3. All other things being equal, less whitespace-sensitivity is to be
preferred, so C4 > C2a > C7.

Cheers
Simon


On Thu, 19 Mar 2020 at 11:33, Simon Peyton Jones via ghc-steering-committee
<ghc-steering-committee at haskell.org> wrote:

> Colleagues
>
> Now that we have agreed a set of alternatives on using dot notation for
> records, let's vote.  We all recognise and respect that syntactic choices
> are a judgement call, and that reasonable people may diff in their
> judgements. But we need to come to as resolution and voting is a good way
> to do that.
>
> *Please put your votes on the Google doc.*  I've make a section for that
> at the end. The document is here
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7Ca528b11e503e43cc660308d7cbe97ac1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637202075954123160&sdata=8Wd6L7caSByus%2F8zwmLq6vbRqbifNCjkbYuWaSER0Aw%3D&reserved=0>
> .
>
> Just write down your preferences, in order, preferred ones first.
>
> Joachim runs an election algorithm that makes it worth specifying a total
> order on all options, *including ones you don't like*.  For any you omit,
> you are saying "if these ones are the top contenders I have no preference
> between them".  You can specify ties, again meaning "no preference between
> these".  For the over-interested, the algorithm is Condorcet
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCondorcet_method&data=02%7C01%7Csimonpj%40microsoft.com%7Ca528b11e503e43cc660308d7cbe97ac1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637202075954133147&sdata=9HmtR634TMUXHozP81lnvMR0SvYIXlBtfRTiDyUkWq8%3D&reserved=0>;
> in the unlikely case that it does not produce a winner, we revert to
> Schultze
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSchulze_method&data=02%7C01%7Csimonpj%40microsoft.com%7Ca528b11e503e43cc660308d7cbe97ac1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637202075954133147&sdata=GIzAX0Wvw1lWtUfUGvv3VmdLGLEFX7o8asdeuVbu6U8%3D&reserved=0>
>
> Please read the document, including the Notes, carefully!  We have ended
> up with a lot of variations, and their numbering is historical not logical.
> (I considered renumbering but thought that would be more confusing than
> helpful.)
>
> As the shepherd I am supposed to make a recommendation; it is below.
>
> Simon
>
>
> Shepherd's recommendations
>
> Here is my recommendation:
>
> *  C6 > C2b > C3 > C2a > C7 > C4 > C5 > C1*
> I recommend acceptance
>
> 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.
>
> 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.
> Alternatives I like:
>
>    - I urge us to adopt (C6).  I really really want *(f M.N.x) *to parse
>    the same as *(f M.n.x)**,* where the only difference is the
>    capitalisation of the second-last element of *M.n.x*.
>
> *I'm leaning strongly on the connection with qualified names*.   We
> already have qualified names, and they are incredibly useful.  Qualified
> names already treat “.” specially.  Moreover the proposal uses “.” in
> precisely the same way as qualified names:  a qualified name M.x allows you
> to pick x from the module M; this proposal allows r.x to pick a field x
> from a value r.  I like this uniformity of both concept and syntax.
>
>    - (C2b) is a weakened form of (C6) that does not allow naked
>    selectors, thus *(f  .x)* where there is a space before the ".".  I
>    don't see any difficulty with the postfix operator story, so I prefer
>    (C6).  But (C2b) is a little more conservative.
>
> Alternatives I actively dislike:
>
>    - I urge against (C1) as I say above.
>    - I dislike (C5) strongly, because it makes *(f M.N.x)* parse
>    completely differently from *(f M.n.x).*  The authors of the proposal
>    say that they would withdraw the proposal outright (or at least
>    disassociate themselves) if we adopted (C5).
>    - I dislike (C7) for the same reason: *(f M.N.x)* is legal but *(f
>    M.n.x)* is not.
>    - I dislike (C4) because nothing should bind more tightly than
>    function application.  I hate that *(f r .x s .y*) would mean * (f
>    (r.x) (s.y)).* Yes, we already have that *(f r {x=2})* means *(f (r
>    {x=2}))*, but I think that's terrible, and we should not perpetuate it.
>
> Alternatives in the middle
>
>    - (C2a) and (C3) are just like (C2b) and (C6), but additionally allow
>    a tightly-binding record selection after a parenthesised expression. Thus *(f
>    (g x).y)* means *(f ((g x).y)).*
>
> Allowing this is a bit tricky to specify, and the link to qualified names
> is much weaker.  I don't think it pays its way.
>
>
>
>
> _______________________________________________
> 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/20200330/40f59e90/attachment.html>