[ghc-steering-committee] Records again

Simon Marlow marlowsd at gmail.com
Wed Dec 18 14:28:05 UTC 2019


On Tue, 17 Dec 2019 at 11:10, Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Dec 17, 2019, at 10:32 AM, Joachim Breitner <mail at joachim-breitner.de>
> 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191218/b00897c0/attachment.html>


More information about the ghc-steering-committee mailing list