<div dir="ltr"><div>My inclination was (3) over (2), because it seems more elegant:<br></div><div>* it explains the interpretation of "f r.x", as you said, and</div><div>* it means that "f r .x" is not different from "f r.x" (I prefer to avoid whitespace-sensitivity if we can)<br></div><div><br></div><div>But I'm somewhat persuaded by the "f.map double .filter isEven" example. So there are swings and roundabouts here, I don't see an obvious best choice between (2) and (3).<br></div><div><br></div><div>Cheers</div><div>Simon<br></div><div dir="ltr"><br></div><div dir="ltr">On Tue, 7 Jan 2020 at 11:29, Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a>> wrote:<br></div><div class="gmail_quote"><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_9750716804452988WordSection1">
<p class="MsoNormal">Friends<u></u><u></u></p>
<p class="MsoNormal">I’d like to move our record-syntax discussion forward.  Link to
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/282" target="_blank">proposal discussion</a>, and
<a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2019-December/thread.html#1387" target="_blank">
December GHC steering committee debates</a>.<u></u><u></u></p>
<h2><b>No-space arguments<u></u><u></u></b></h2>
<p class="MsoNormal">I believe have agreed that <u></u><u></u></p>
<p class="MsoNormal">               f r.x<u></u><u></u></p>
<p class="MsoNormal">(with no spaces around the dot, and no parens around r.x) means<u></u><u></u></p>
<p class="MsoNormal">               f (r.x)<u></u><u></u></p>
<p class="MsoNormal">That is, treat it consistently with qualified names.  I asked everyone to express a view; Iavor, Eric, Arnaud, Joachim, and Richard all said it was at least acceptable; others expressed no view.  So let’s take that as a decision, at least
 for now.<u></u><u></u></p>
<h2><b>Naked selectors<u></u><u></u></b></h2>
<p class="MsoNormal">Next question: how should we treat a “naked selector”, namely .x where there is no space after the dot, but there is a space before.  I think there are three viable choices:<u></u><u></u></p>
<ol style="margin-top:0cm" type="1" start="1">
<li class="gmail-m_9750716804452988MsoListParagraph" style="margin-left:0cm"><b>It’s simply illegal</b>.   This defers the choice;  perhaps later we will have more experience to go on.<u></u><u></u></li><li class="gmail-m_9750716804452988MsoListParagraph" style="margin-left:0cm"><b>It’s a postfix operator</b>, binding less tightly than function application, but more tightly than any infix operator.   So then (r .x) means r.x, and (r .x .y) means r.x.y.   But
 (f r .x) means (f r).x.<u></u><u></u></li></ol>
<p class="gmail-m_9750716804452988MsoListParagraph">This choice naturally supports chaining (nice to have, but not essential).  We can write<u></u><u></u></p>
<p class="gmail-m_9750716804452988Code" style="margin-left:72pt">f .map double<u></u><u></u></p>
<p class="gmail-m_9750716804452988Code" style="margin-left:72pt">  .filter isEven<u></u><u></u></p>
<p class="gmail-m_9750716804452988MsoListParagraph">meaning <b><span style="font-family:"Courier New"">(f.map double).filter isEven</span></b><u></u><u></u></p>
<ol style="margin-top:0cm" type="1" start="3">
<li class="gmail-m_9750716804452988MsoListParagraph" style="margin-left:0cm"><b>It’s a postfix operator</b>, binding more tightly than function application, just as record update does.  So then (f r .x) means (f r.x), and (f r .x .y s .z) means (f r.x.y s.z).<u></u><u></u></li></ol>
<p class="gmail-m_9750716804452988MsoListParagraph">This choice allows us to regard our decision about (f r.x) as what naturally happens if we parse it as three lexemes: f, r, and .x.  But it also breaks the “function application binds more tightly than anything else” rule, just as
 (f r {x=3}) sadly does already.<u></u><u></u></p>
<p class="gmail-m_9750716804452988MsoListParagraph">It does not permit chaining, at least not without stacked-up parens.<u></u><u></u></p>
<p class="MsoNormal">In all three cases we allow (.x), meaning (\r. r.x).   For (2) and (3) we can regard it as a “section”, like infix operators only simpler because there is no argument.<u></u><u></u></p>
<p class="MsoNormal">I think this is the last major question we have to answer.<u></u><u></u></p>
<p class="MsoNormal">What are your views?   Personally I lean towards (2), but I could certainly live with (1).  I’m a bit reluctant to adopt (3).<u></u><u></u></p>
<p class="MsoNormal">Simon<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></div>