<div dir="ltr"><div>Simon,</div><div><br></div><div>I'm happy with letting you choose the syntax. You've got more stake in all this than any of us, and this is a conversation which can't end without someone having a final word.</div><div><br></div><div>Let's give ourselves a deadline, after which whatever we've decided (for example by letting Simon choose :-) ) isn't up to debate anymore.</div><div><br></div><div>Then we can go back to deciding on the specifics of the proposal.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 17, 2019 at 2:58 AM Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</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"><u></u><div><div>On Mon, Dec 16, 2019, at 18:48, Simon Peyton Jones via ghc-steering-committee wrote:<br></div><div>> Assuming that we want to accept some version, *I'd like to propose that <br></div><div>> we adopt the idea that `f r.x` means `f (r.x)`*, and not the record <br></div><div>> selection `(f r).x`<br></div><div><br></div><div>I would be content with either parse. The thing I found compelling about<br></div><div>Joachim's suggestion was that it makes the syntax around `.` a bit less<br></div><div>whitespace-sensitive.</div><div><br></div><div>My concerns have been mostly around the meaning of a bare `.x`, as in<br></div><div><br></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> f r.x<br></span></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> .y<br></span></div><div><br></div><div>It seems like the committee is largely in agreement that a bare `.x` should<br></div><div>not desugar to `\r -> r.x`. My reasoning is similar to what Chris Done[1] and<br></div><div>Chris Smith[2] have articulated on the GitHub thread, namely that you should<br></div><div>be able to split a deep record access across multiple lines without resorting<br></div><div>to syntactic contortions like<br></div><div><br></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> f (r.x<br></span></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> ).y<br></span></div><div><br></div><div>So, if we are all content with `f r.x` meaning `f (r.x)` and with a bare `.x` not<br></div><div>desugaring to `\r -> r.x`, there's still a question of how to parse<br></div><div><br></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> f r.x<br></span></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> .y<br></span></div><div><br></div><div>Does it parse as<br></div><div><br></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> f ((r.x) -- (A)<br></span></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> .y)<br></span></div><div><br></div><div>or<br></div><div><br></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> (f (r.x)) -- (B)<br></span></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> .y<br></span></div><div><br></div><div>or<br></div><div><br></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> ERROR -- (C)<br></span></div><div><br></div><div>(A) would mean that field access binds more tightly than function application. I<br></div><div>think the result is intuitive, but the only precedent we have for binding tighter<br></div><div>than function application is record syntax, which is widely criticized (including<br></div><div>by myself).<br></div><div><br></div><div>(B) means the opposite, application binds more tightly than field access. I'm not<br></div><div>sure how I feel about this. It seems prone to misinterpretation, but perhaps we can<br></div><div>learn to adapt to it (ironically) the way we've adapted to record syntax.<br></div><div><br></div><div>(C) means that function application and field access don't associate. I believe<br></div><div>Richard suggested this previously, and I think it's actually a pretty sensible<br></div><div>solution. If you want to combine the two, you must disambiguate for us. This<br></div><div>means that I'd have to write my example as<br></div><div><br></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> f (r.x</span><span style="font-family:menlo,consolas,monospace,sans-serif"><br></span></div><div><span style="font-family:menlo,consolas,monospace,sans-serif"> .y)</span><span style="font-family:menlo,consolas,monospace,sans-serif"><br></span></div><div><br></div><div>which still looks perfectly fine to me.<br></div><div><br></div><div>Eric<br></div><div><br></div><div>[1]: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-546645661" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-546645661</a><br></div><div>[2]: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-547606770" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-547606770</a><br></div><div><br></div><div>> Joachim floated the `(f r).x` idea recently and Richard supported him. <br></div><div>> I consulted the authors who said "Interestingly, the very first version <br></div><div>> of the prototype implemented exactly that. That behaviour surprised the <br></div><div>> heck out of everyone (including you) and we were quickly and <br></div><div>> overwhelmingly convinced that it was the wrong parse and updated the <br></div><div>> proposal accordingly." I had a long conversation with Richard, who (I <br></div><div>> think) finds both alternatives acceptable.<br></div><div>> <br></div><div>> I agree strongly with the authors; I think `(f r).x` would be horrible, <br></div><div>> and would vote against such a proposal. So, in the interests of making <br></div><div>> progress, I recommend that we adopt the `f (r.x)` parse. Talking to <br></div><div>> Richard I realise that a lot depends on your starting point:<br></div><div>> <br></div><div>> 1. I regard `M.N.x` and `r.x.y` as a single token, where `.` is <br></div><div>> punctuation. Space is always significant for dot; `M . x` is quite <br></div><div>> different to `M.x`. Another example is the unbounded enumeration `[Z <br></div><div>> ..]` where you must put the space; if you write `[Z..]` you'll get the <br></div><div>> dot-operator imported from module Z. <br></div><div>> From this point of view, Haskell's use of `(.)` as an infix operator <br></div><div>> for composition is an aberration. And parsing `f r.x` as `f (r.x)` is <br></div><div>> consistent with our parse of `f M.x`.<br></div><div>> <br></div><div>> 1. An alternative point of view is to regard `(.)` as a fully fledged <br></div><div>> operator, and all the stuff about qualified names, enumerations and so <br></div><div>> on, as a sad aberration. Under this point of view, record selection <br></div><div>> just makes the aberration worse.<br></div><div>> I realise that one reason I want the `f (r.x)` parse so strongly is my <br></div><div>> previously-implicit espousal of (A); perhaps making that explicit will <br></div><div>> help frame the conversation. I’m also very un-keen on making `r.x` <br></div><div>> illegal, which is another alternative in theory.<br></div><div>> <br></div><div>> TL;DR. Does anyone (who wants to accept the proposal in some form) <br></div><div>> seriously oppose the `f (r.x)` parse for `f r.x`? I hope that it'll be <br></div><div>> at least acceptable to everyone, and we can more on.<br></div><div>> <br></div><div>> Thanks<br></div><div>> <br></div><div>> Simon<br></div><div>> <br></div><div>> _______________________________________________<br></div><div>> ghc-steering-committee mailing list<br></div><div>> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br></div><div>> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br></div><div>><br></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>