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

[Richard Eisenberg]

> On Dec 12, 2019, at 9:44 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> 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)

I have now read (most of) the comments posted in the last 24 hours on the GitHub trail. And it's changing my view of all this.

I'm now more in favor of (B).

To me, the clearest argument for this is that it is true already. That is, if I write `f x.y` in code today, it means `(f x) . y`. Of course, we're changing the meaning of `.`. But it doesn't mean we have to change the parsing. And somehow, no one complains about it today. (Well, that's not true -- beginners complain. They get used to it.)

I would also like to propose

(C). Syntax error.

That is, a tight-infix use of `.` does not associate with a function application on its left. A prefix occurrence of `.` would: `f x .y` would be `(f x) .y`.

We could also just make this a warning.

Somehow, this all reminds me a bit of the precedence of the * prefix operator and field selection in C/C++. In these languages, *foo.bar.baz means *(foo.bar.baz), which I've always found surprising. More often, we want (*foo).bar.baz. And indeed to satisfy their users, they came up with a totally new operator: foo->bar is precisely (*foo).bar. My point here is that we are not alone in grappling with this issue, and that "field access is always the highest-precedence operator" is not always a good idea.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191212/33d48ede/attachment.html>