I instinctively read it as `(f (r.x))`, but I also like the conceptual simplicity of always treating `.x` as a postfix operator. And I'm not as bothered by having to write `f (r.x)`. I think I would be quite happy with Richard's suggestion (C), `f r.x` is a syntax error, please add parentheses either way. --- I'm also somewhat skeptical of the method-chaining arguments. xs.map (+1) .filter even will not type check in any case, as [] has no `map` or `filter` fields. Yes you could add "virtual" fields to sorta kinda make things work (it seems like there are a number of caveats), but this feels like an abuse of the HasField machinery to me. And I find it quite unlikely that doing so would unlock the dot-based autocompletion reliably. On Thu, Dec 12, 2019, at 04:44, Simon Peyton Jones via ghc-steering-committee wrote:
A question for the committee.
What does f r.x mean, where there is no white space on either side of the dot?
A. The proposal says it means (f (r.x)) B. Joachim wants it to mean ((f r).x)
In trying to guide the discussion to a conclusion I proposed to fix on (A). I don't think it was controversial in the public discussion, it's compatible with qualified names, and forcing `f (r.x)` looks horribly clumsy to me.
Partly it's a question of whether your starting point is (a) "." is fundamentally an operator, albeit with some special extra rules, or (b) R.x, r.x, and .x are new syntactic forms, unrelated to the infix operator (.) I'm definitely thinking of it in the latter way.
I don't really want to re-open this question, and I'm not sure if the authors of the proposal could live with (B). However, if the committee wants to reopen the question, then that is what we should do. Can you express a view on this narrow question?
Simon _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee