<div dir="ltr">Those seem like reasonable options to me. <div><br></div><div>I think my preference would be: 2,4,3,1.<div><br></div><div>My justification is that I find the naked selectors a bit odd, but if we are going to have them I find (4)</div><div>a bit easier to explain: the rule is that record selection has higher precedence than function application,</div><div>and white space does not need to be discussed at all.</div><div><br></div><div>I agree that this might not be the most elegant of proposals, but having recently tried to use the `getField`</div><div>class method in anger without the syntactic sugar, I think that my code would be a lot more readable with this extension<br>than without.<br></div><div><br></div><div>-Iavor</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 7, 2020 at 9:13 AM Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Colleagues<br>
<br>
I've been slow on the records front; apologies.<br>
<br>
I think Joachim is right: we've discussed a lot of options, but in the<br>
end much of this is a judgement call with no perfect answers, and it<br>
now seems simplest to express our judgement through voting. I think<br>
we are all keen to decide this and move on.<br>
<br>
Proposal: <a href="https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/proposals/0000-record-dot-syntax.md" rel="noreferrer" target="_blank">https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/proposals/0000-record-dot-syntax.md</a><br>
Lengthy discussion: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/282" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/282</a><br>
<br>
Here are the alternatives I propose we vote on. The first order of<br>
business is to check that they are all clear; and that I haven't omitted<br>
a worthy alternative. Here they are:<br>
<br>
1. Reject the proposal<br>
<br>
2. Naked .x is illegal<br>
<br>
3. Naked .x is a postfix operator, binding exactly<br>
like application: f r .x means (f r).x<br>
<br>
4. Naked .x is a postfix operator, binding more tightly<br>
than application: f r .x means f (r.x)<br>
<br>
Under all of (2,3,4) I think we are content that<br>
- (f r.x) means (f (r.x))<br>
- (.x) means (\r -> r.x)<br>
<br>
By "naked .x" I mean "not preceded by an identifier (e.g. r.x),<br>
or an open paren (e.g. (.x)), or a close paren (e.g. (f 3).x)<br>
<br>
We could re-open more of this, but I'd prefer to keep it to 1-4.<br>
<br>
Let's just check everyone is happy with these alternatives. Then we can<br>
vote by putting in rank order, and Joachim can run his STV algorithm.<br>
<br>
<br>
I'm the shepherd for this proposal, so let me add my recommendations.<br>
<br>
I strongly urge that we do not adopt (1); that is, we accept the<br>
proposal in some form. I have been unhappy with GHC's story for<br>
records for two decades. (E.g. Lightweight extensible records for<br>
Haskell, Haskell Workshop, Paris 1999.) But the design space is so<br>
complicated that we never found something that felt "obviously right".<br>
So we did nothing drastic, and I think that was right.<br>
<br>
But there was incremental progress, sketched here:<br>
<a href="https://gitlab.haskell.org/ghc/ghc/wikis/records/overloaded-record-fields" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/wikis/records/overloaded-record-fields</a><br>
<br>
* DuplicateRecordFields lets you have multiple records with the<br>
same field name.<br>
* The HasField class lets us define overloaded record selection<br>
and update functions.<br>
<br>
The proposal we are now discussing has no type-system component;<br>
it is *only* about syntactic sugar, allowing you to use dot-notation<br>
for field selection.<br>
<br>
Various extensions about syntax for update were discussed, but no<br>
longer form part of the proposal; what is left is the core, which<br>
has a particularly high benefit/cost ratio.<br>
<br>
Now, judgements may differ about the importance of syntactic sugar --<br>
that's why we have a committee with a diversity of views -- but I<br>
believe that dot-notation for record selection is super-important.<br>
I've wanted it for ages. Every other language has it. We have<br>
accepted other syntactic sugar with much lower utility. And<br>
the dot is already a special case, via qualified names.<br>
<br>
I respect the fact that others may differ, but I really think<br>
think this is worth it. It would be a crying shame to reject<br>
this. Unlike Chris, I don't think anything better is going to<br>
emerge, however long we wait.<br>
<br>
I am more relaxed about 2/3/4. Personally I hate (4) because<br>
I don't like *any* notation in which something binds more tightly<br>
than function application. e.g. I cordially dislike (f K {x=3})<br>
meaning (f (K {x=3})).<br>
<br>
My preference is for (3), which allows record selection with<br>
spaces (which some argue for). But (2) represents at most a lost<br>
opportunity, not a bad thing.<br>
<br>
Thanks<br>
<br>
Simon<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>