<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>1, 2, (and that's it)<br>
</p>
<div class="moz-cite-prefix">On 2/7/20 1:06 PM, Iavor Diatchki
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGK9nuppA_X24KnzGpjAcuwi72mENkBXGPM6Dqw+1gbEWhhv+g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">ghc-steering-committee@haskell.org</a><br>
<a
href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ghc-steering-committee mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a>
<a class="moz-txt-link-freetext" href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a>
</pre>
</blockquote>
</body>
</html>