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

[Richard Eisenberg]

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 <mail at joachim-breitner.de> 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-564465807
> 
> 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 at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee