[ghc-steering-committee] Precedence of r.x

[Eric Seidel]

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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>