[ghc-steering-committee] Records again

Joachim Breitner mail at joachim-breitner.de
Tue Dec 17 10:32:30 UTC 2019


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 at joachim-breitner.de
  http://www.joachim-breitner.de/



More information about the ghc-steering-committee mailing list