Simon, I'm happy with letting you choose the syntax. You've got more stake in all this than any of us, and this is a conversation which can't end without someone having a final word. Let's give ourselves a deadline, after which whatever we've decided (for example by letting Simon choose :-) ) isn't up to debate anymore. Then we can go back to deciding on the specifics of the proposal. On Tue, Dec 17, 2019 at 2:58 AM Eric Seidel wrote:

On Mon, Dec 16, 2019, at 18:48, Simon Peyton Jones via ghc-steering-committee wrote:

...

Assuming that we want to accept some version, *I'd like to propose that we adopt the idea that `f r.x` means `f (r.x)`*, and not the record selection `(f r).x`

I would be content with either parse. The thing I found compelling about Joachim's suggestion was that it makes the syntax around `.` a bit less whitespace-sensitive.

My concerns have been mostly around the meaning of a bare `.x`, as in

f r.x .y

It seems like the committee is largely in agreement that a bare `.x` should not desugar to `\r -> r.x`. My reasoning is similar to what Chris Done[1] and Chris Smith[2] have articulated on the GitHub thread, namely that you should be able to split a deep record access across multiple lines without resorting to syntactic contortions like

f (r.x ).y

So, if we are all content with `f r.x` meaning `f (r.x)` and with a bare `.x` not desugaring to `\r -> r.x`, there's still a question of how to parse

f r.x .y

Does it parse as

f ((r.x) -- (A) .y)

or

(f (r.x)) -- (B) .y

or

ERROR -- (C)

(A) would mean that field access binds more tightly than function application. I think the result is intuitive, but the only precedent we have for binding tighter than function application is record syntax, which is widely criticized (including by myself).

(B) means the opposite, application binds more tightly than field access. I'm not sure how I feel about this. It seems prone to misinterpretation, but perhaps we can learn to adapt to it (ironically) the way we've adapted to record syntax.

(C) means that function application and field access don't associate. I believe Richard suggested this previously, and I think it's actually a pretty sensible solution. If you want to combine the two, you must disambiguate for us. This means that I'd have to write my example as

f (r.x .y)

which still looks perfectly fine to me.

Eric

[1]: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5466456... [2]: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5476067...

...

Joachim floated the `(f r).x` idea recently and Richard supported him. I consulted the authors who said "Interestingly, the very first version of the prototype implemented exactly that. That behaviour surprised the heck out of everyone (including you) and we were quickly and overwhelmingly convinced that it was the wrong parse and updated the proposal accordingly." I had a long conversation with Richard, who (I think) finds both alternatives acceptable.

I agree strongly with the authors; I think `(f r).x` would be horrible, and would vote against such a proposal. So, in the interests of making progress, I recommend that we adopt the `f (r.x)` parse. Talking to Richard I realise that a lot depends on your starting point:

1. I regard `M.N.x` and `r.x.y` as a single token, where `.` is punctuation. Space is always significant for dot; `M . x` is quite different to `M.x`. Another example is the unbounded enumeration `[Z ..]` where you must put the space; if you write `[Z..]` you'll get the dot-operator imported from module Z. From this point of view, Haskell's use of `(.)` as an infix operator for composition is an aberration. And parsing `f r.x` as `f (r.x)` is consistent with our parse of `f M.x`.

1. An alternative point of view is to regard `(.)` as a fully fledged operator, and all the stuff about qualified names, enumerations and so on, as a sad aberration. Under this point of view, record selection just makes the aberration worse. I realise that one reason I want the `f (r.x)` parse so strongly is my previously-implicit espousal of (A); perhaps making that explicit will help frame the conversation. I’m also very un-keen on making `r.x` illegal, which is another alternative in theory.

TL;DR. Does anyone (who wants to accept the proposal in some form) seriously oppose the `f (r.x)` parse for `f r.x`? I hope that it'll be at least acceptable to everyone, and we can more on.

Thanks

Simon

_______________________________________________ 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

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. 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

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

| 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

| In order to form a decision about `f r.x = f (r.x)` I also need to | know | whether I can, for example, align vertically (a very Haskelly desire) | without changing meaning: | | printf "%s %s" grandfather.first_name grandfather.last_name | printf "%s %s" mom .first_name mom .last_name | printf "%s %s" (kid!!0 ).first_name (kid!!0) .last_name If we choose (1) for naked selectors then the second and third are illegal because .x is illegal. If we choose (3) for naked selectors then you can do what you want, but with parens: | printf "%s %s" grandfather.first_name grandfather.last_name | printf "%s %s" (mom .first_name) (mom .last_name) | printf "%s %s" ((kid!!0 ).first_name) ((kid!!0) .last_name) The parens are only reqd if you want spaces. Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 17 December 2019 14:26 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Records again | | Hi, | | | Am Dienstag, den 17.12.2019, 11:46 +0000 schrieb Simon Peyton Jones | via | ghc-steering-committee: | > > 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. | | I don't think it can be answered separately. Maybe it can be seen as a | clearly separate question if one strongly believes that `r.f` is the | roughly the same thing as `M.f`. While I understand that view, I do | not | strongly believe in it, e.g. because we have `(complex expression).f` | and `r.f.g.h`, and this shows me that `e.f` is a more complex and less | atomic notion than a qualified name `M.f`. | | In order to form a decision about `f r.x = f (r.x)` I also need to | know | whether I can, for example, align vertically (a very Haskelly desire) | without changing meaning: | | printf "%s %s" grandfather.first_name grandfather.last_name | printf "%s %s" mom .first_name mom .last_name | printf "%s %s" (kid!!0 ).first_name (kid!!0) .last_name | | | (I am not saying that this is universally good style, but it is also | not completely unreasonable.) | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cada7e617f6 | 5f48d4bb0608d782fd24de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7121896074980463&sdata=QgmqcOorDYvxZZV%2Frwc1D1nI2fgi75cvA7yVRf5H1 | Ws%3D&reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cada7e617f65f48d | 4bb0608d782fd24de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371218 | 96074980463&sdata=kggIGRSDlzD%2FIX2zwO8mWL59ZzK9YzUNcnakt3Qt4EU%3D | &reserved=0

[continuation, hit sent too soon, sorry] Oh, and here is a nice way to justify the JS variant in a very functionally motivated way. Not sure if it is helpful, though, but it certainly is a cute angle… A record r with fields foo and bar can be thought of as a _function_ with domain {.foo, .bar} (and a dependent return type, but we are talking syntax, not types). With that point of view, the syntax r .foo _is_ simply function application. And we do not need _any_ custom mental parsing rules at all, and get f r.field y = ((f r).field) y f r .field y = ((f r).field) y and now of course you write f (r.x) or f (r .x) just like you would write f (g x) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/