<div dir="ltr"><div>After voting I feel like writing down the rationale I used, and I'll probably forget myself if I don't write this down:</div><div><br></div><div>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.)<br></div><div><br></div><div>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.</div><div><br></div><div>3. All other things being equal, less whitespace-sensitivity is to be preferred, so C4 > C2a > C7.</div><div><br></div><div>Cheers</div><div>Simon<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 19 Mar 2020 at 11:33, 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">
<div lang="EN-GB">
<div class="gmail-m_-8839245059705794267WordSection1">
<p class="MsoNormal">Colleagues<u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><b>Please put your votes on the Google doc.</b> I've make a section for that at the end.
<a href="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" target="_blank">
The document is here</a>.<u></u><u></u></p>
<p class="MsoNormal">Just write down your preferences, in order, preferred ones first.
<u></u><u></u></p>
<p class="MsoNormal">Joachim runs an election algorithm that makes it worth specifying a total order on all options,
<b>including ones you don't like</b>. 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
<a href="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" target="_blank">
Condorcet</a>; in the unlikely case that it does not produce a winner, we revert to
<a href="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" target="_blank">
Schultze</a><u></u><u></u></p>
<p class="MsoNormal">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.)<u></u><u></u></p>
<p class="MsoNormal">As the shepherd I am supposed to make a recommendation; it is below.<u></u><u></u></p>
<p class="MsoNormal">Simon<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<h1>Shepherd's recommendations<u></u><u></u></h1>
<p class="MsoNormal">Here is my recommendation:<u></u><u></u></p>
<p class="MsoNormal"><b> C6 > C2b > C3 > C2a > C7 > C4 > C5 > C1<u></u><u></u></b></p>
<h2>I recommend acceptance<u></u><u></u></h2>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal">But there was incremental progress, <a>
sketched here</a>:<u></u><u></u></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-8839245059705794267MsoListParagraph" style="margin-left:0cm">DuplicateRecordFields lets you have multiple records with the same field name.<u></u><u></u></li><li class="gmail-m_-8839245059705794267MsoListParagraph" style="margin-left:0cm">The HasField class lets us define overloaded record selection and update functions.<u></u><u></u></li></ul>
<p class="MsoNormal">The proposal we are now discussing has no type-system component; it is
<b>only</b> 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.)<u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<h2>Alternatives I like:<u></u><u></u></h2>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-8839245059705794267MsoListParagraph" style="margin-left:0cm">I urge us to adopt (C6). I really really want
<b><span style="font-family:"Courier New"">(f M.N.x) </span></b>to parse the same as
<b><span style="font-family:"Courier New"">(f M.n.x)</span></b><b>,</b> where the only difference is the capitalisation of the second-last element of
<b><span style="font-family:"Courier New"">M.n.x</span></b>. <u></u><u></u></li></ul>
<p class="gmail-m_-8839245059705794267MsoListParagraph"><b><i>I'm leaning strongly on the connection with qualified names</i></b>. 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.<u></u><u></u></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-8839245059705794267MsoListParagraph" style="margin-left:0cm">(C2b) is a weakened form of (C6) that does not allow naked selectors, thus
<b><span style="font-family:"Courier New"">(f .x)</span></b><b> </b>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.<u></u><u></u></li></ul>
<h2>Alternatives I actively dislike:<u></u><u></u></h2>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-8839245059705794267MsoListParagraph" style="margin-left:0cm">I urge against (C1) as I say above.<u></u><u></u></li><li class="gmail-m_-8839245059705794267MsoListParagraph" style="margin-left:0cm">I dislike (C5) strongly, because it makes
<b><span style="font-family:"Courier New"">(f M.N.x)</span></b> parse completely differently from
<b><span style="font-family:"Courier New"">(f M.n.x).</span></b> The authors of the proposal say that they would withdraw the proposal outright (or at least disassociate themselves) if we adopted (C5).<u></u><u></u></li><li class="gmail-m_-8839245059705794267MsoListParagraph" style="margin-left:0cm">I dislike (C7) for the same reason:
<b><span style="font-family:"Courier New"">(f M.N.x)</span></b> is legal but <b><span style="font-family:"Courier New"">(f M.n.x)</span></b> is not.<u></u><u></u></li><li class="gmail-m_-8839245059705794267MsoListParagraph" style="margin-left:0cm">I dislike (C4) because nothing should bind more tightly than function application. I hate that
<b><span style="font-family:"Courier New"">(f r .x s .y</span></b>) would mean <b>
<span style="font-family:"Courier New"">(f (r.x) (s.y)).</span></b> Yes, we already have that
<b><span style="font-family:"Courier New"">(f r {x=2})</span></b> means <b><span style="font-family:"Courier New"">(f (r {x=2}))</span></b><span style="font-family:"Courier New"">,</span> but I think that's terrible, and we should not perpetuate it.<u></u><u></u></li></ul>
<h2>Alternatives in the middle<u></u><u></u></h2>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-8839245059705794267MsoListParagraph" style="margin-left:0cm">(C2a) and (C3) are just like (C2b) and (C6), but additionally allow a tightly-binding record selection after a parenthesised expression. Thus
<b><span style="font-family:"Courier New"">(f (g x).y)</span></b> means <b><span style="font-family:"Courier New"">(f ((g x).y)).</span></b><u></u><u></u></li></ul>
<p class="gmail-m_-8839245059705794267MsoListParagraph">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
_______________________________________________<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>