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

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