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