Re: [ghc-steering-committee] Records again

The treatment of ".x" as a postfix operator that binds more tightly than function application seems like a reasonable position to me. It accounts for f r.x => f (r.x) and also means that we can split a chain of record selectors over multiple lines. It does diverge from qualified name syntax, but I think that was already the case since we intend that the left-hand side of a record selection is an expression, not an identifier - in fact it would be an aexp in terms of the Haskell grammar. So the new lexeme is the ".varid" record selector and we're only discussing what happens at the context-free grammar level. Cheers Simon On Tue, 17 Dec 2019 at 11:46, Simon Peyton Jones via ghc-steering-committee wrote:

| I.e. I will support `f r.x = f (r.x)`, if I can still add space before the | .x.

That gets into a separate question, the "naked selector" question. There we have the following viable alternatives

(1) .x is illegal (2) .x means (\r. r.x) (3) .x is a postfix operator

Certainly (3) would all you to write r .x .y meaning r.x.y or f (r .x .y) meaning f (r.x.y)

But I was trying to close the discussion of (f r.x) before opening the discussion about 1/2/3 for naked selectors.

Simon

-----Original Message----- | From: ghc-steering-committee

...

| On Behalf Of Joachim Breitner | Sent: 17 December 2019 10:33 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Records again | | Hi, | | Eric nicely summarizes my thoughts | | I am a happy user of | | f r.x .y = f (r.x.y) | | in Ocaml, and I agree that it is not an absolutely horrible choice, and | will likely vote it over Reject. | | | 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 | | (where the space could still be a newline). Record accessors can possibly | be deeply nested, so it should be possible to nicely wrap or vertically | align the code. This indicates that postfix .x should parse similar to | postfix `{x=1}` (what a nice coincidence that both relate to records). | | So while I fully understand the analogy to module qualifiers, this aspect | already makes them different. | | | In the end I am a big fan of the fundamental rule of mentally parsing | Haskell code, namely “function composition binds most tightly and | associates to the left”. | Yes, there are exceptions (qualified names, record updates). | And yes, variant “JS” and “JS+Section” are still a slight exception to that | rule (as there record accessors associate with function application). | | So maybe my current thinking is | | JS+Section > JS > Ocaml+Section > Ocaml > SectionSelector | > Reject > OnlySelection > PlainSelector | | | I.e. I will support `f r.x = f (r.x)`, if I can still add space before the | .x. | | I am not yet completely decided what to think of disallowing `f r .x`. | | | | Oh, and here is a nice way to justify the JS variants functionally. Not | sure if it is helpful… A record r with fields foo and bar can be thought of | as a _function_ with domain {.foo, .bar}. In that point of view, the | syntax | f .foo | | | | | Cheers, | Joachim | -- | Joachim Breitner | mail@joachim-breitner.de | http://www.joachim-breitner.de/ | | _______________________________________________ | 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