[ghc-steering-committee] Records again

[Iavor Diatchki]

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 <marlowsd at gmail.com> wrote:

>
> 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
>>
> _______________________________________________
> 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/0fbfca09/attachment.html>