<!DOCTYPE html><html><head><title></title><style type="text/css">#qt p.qt-MsoNormal{margin-top:6pt;margin-right:0cm;margin-bottom:6pt;margin-left:0cm;font-size:11pt;font-family:Calibri, sans-serif;}
#qt p.qt-MsoListParagraph,#qt li.qt-MsoListParagraph{margin-top:6pt;margin-right:0cm;margin-bottom:6pt;margin-left:36pt;font-size:11pt;font-family:Calibri, sans-serif;}
#qt ol{margin-bottom:0cm;}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><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;" class="font"> f r.x<br></span></div><div><span style="font-family: menlo, consolas, monospace, sans-serif;" class="font"> .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;" class="font"> f (r.x<br></span></div><div><span style="font-family: menlo, consolas, monospace, sans-serif;" class="font"> ).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;" class="font"> f r.x<br></span></div><div><span style="font-family: menlo, consolas, monospace, sans-serif;" class="font"> .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;" class="font"> f ((r.x) -- (A)<br></span></div><div><span style="font-family: menlo, consolas, monospace, sans-serif;" class="font"> .y)<br></span></div><div><br></div><div>or<br></div><div><br></div><div><span style="font-family: menlo, consolas, monospace, sans-serif;" class="font"> (f (r.x)) -- (B)<br></span></div><div><span style="font-family: menlo, consolas, monospace, sans-serif;" class="font"> .y<br></span></div><div><br></div><div>or<br></div><div><br></div><div><span style="font-family: menlo, consolas, monospace, sans-serif;" class="font"> 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;" class="font"> f (r.x</span><span style="font-family: menlo, consolas, monospace, sans-serif;" class="font"><br></span></div><div><span style="font-family: menlo, consolas, monospace, sans-serif;" class="font"> .y)</span><span style="font-family: menlo, consolas, monospace, sans-serif;" class="font"><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]: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-546645661<br></div><div>[2]: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-547606770<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>> ghc-steering-committee@haskell.org<br></div><div>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br></div><div>><br></div></body></html>