When I first picked up Haskell professionally, I was told “we don’t write f.g, we write f . g, because when someone manages to add the record syntax, the former will be record selection”. So I’ve always considered f.g to be forbidden syntax. Morally a syntax error, if you will, that the parser accidentally didn’t catch. So, while it is true that *today* f r.x parses as (f r).x (that is, (B)). I see no objection for (A), which does make more visual sense to me. On Thu, Dec 12, 2019 at 10:49 AM Simon Marlow wrote:

Definitely (A).

On Thu, 12 Dec 2019 at 09: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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

My first reaction was "surely (A)". After reading Joachim's argument, my answer is now "(A)", but without the "surely". Yes, I see your (Joachim's) point here. But I worry that moving away from (A) optimizes the less common case of long field names / chaining over the more common case of passing a field value as a function argument. As for laying out long names, we always have

f.foo & (.bar) & (.baz)

Not fantastic, but also not terrible. (Recall that (&) = flip ($).) The chaining examples (which look like x.f1(biz, baz).f2(wurble).f3() in Java) seem less likely in Haskell. Richard

On Dec 12, 2019, at 10:23 AM, Joachim Breitner wrote:

Hi,

Am Donnerstag, den 12.12.2019, 09:44 +0000 schrieb Simon Peyton Jones.

...

f r.x A. The proposal says it means (f (r.x)) B. Joachim wants it to mean ((f r).x)

to give credit where credit is due, this wasn’t my idea:

I came to that conclusion after reading Eric’s mail on this list (from Tue, 10 Dec 2019 22:27:57 -0500) and Chris Done’s nice summary and digestion of Eric’s mail as posted in https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5644658...

I expect the ability to freely add whitespace on (at least) one side of a dot, without changing the meaning, is also advantageous to be able to lay out code nicely.

It seems we gain a lot (e.g. chaining with argument) if we let go of of the desire to not have to parenthesize non-atomic arguments (in `f (r.x) (s.x)`), which we otherwise _always_ do in Haskell (as in `f (x!!5) (y!!5)`).

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Donnerstag, den 12.12.2019, 12:30 +0000 schrieb Richard Eisenberg:

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.

such a warning was actually also proposed in the monster GitHub thread: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5645975... as -Wproximity, which could warn about any misleading spacing, so not only `f x.y` (whether this is a record access or function composition), but also `x * y+z` etc. Sounds very nice! Probably orthogonal to this proposal, but maybe a way to make people worry less about the confusion that `f x.y` may bring? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/