Re: [ghc-steering-committee] Records again

That's a very good point---I guess I tend to do this too, but I had never really thought about the underlying rule. Thanks! On Wed, Dec 18, 2019 at 6:28 AM Simon Marlow wrote:

On Tue, 17 Dec 2019 at 11:10, Richard Eisenberg wrote:

...

On Dec 17, 2019, at 10:32 AM, Joachim Breitner wrote:

I would find it bad, though, if we have

f r.x.y = f (r.x.y)

but disallow or give completely different meaning (as in the bare .y variants) to

f r.x .y

Just to repeat one of Simon's arguments he used against me yesterday: How do you feel about `f x_y` vs `f x _y`? We have no trouble accepting that whitespace is significant there. If we accept that `.` is part of the construction of a token, then this is all very natural. Somehow, we read `_` this way. If we view `.` as something else, then it's much harder.

The counter-argument to this is that "x" and "_y" are lexemes of the same class (varid) but "." and "y" are not. A principle I like to use when designing syntax is that whitespace should be necessary only for separating lexemes of the same class, otherwise it should be optional.

(as an interesting exercise see if you can find places where this is violated in the Haskell 2010 lexical syntax. And then see if you can find the (many more) places it's violated in GHC's lexical syntax).

Cheers Simon

I'm in the "view as something else" camp, but the argument above made me

...

realize that I didn't have to revise the whole way I parse Haskell in order to understand the new syntax -- I just have to reclassify the lexical category of `.`.

In the end, I don't feel strongly about this all. And (for me) the authors' comments that `f r.x = (f r).x` is abhorrent carries weight.

Richard _______________________________________________ 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