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/