[ghc-steering-committee] Record syntax

[Simon Peyton Jones]

Friends
I'd like to move our record-syntax discussion forward.  Link to proposal discussion<https://github.com/ghc-proposals/ghc-proposals/pull/282>, and December GHC steering committee debates<https://mail.haskell.org/pipermail/ghc-steering-committee/2019-December/thread.html#1387>.
No-space arguments
I believe have agreed that
               f r.x
(with no spaces around the dot, and no parens around r.x) means
               f (r.x)
That is, treat it consistently with qualified names.  I asked everyone to express a view; Iavor, Eric, Arnaud, Joachim, and Richard all said it was at least acceptable; others expressed no view.  So let's take that as a decision, at least for now.
Naked selectors
Next question: how should we treat a "naked selector", namely .x where there is no space after the dot, but there is a space before.  I think there are three viable choices:

  1.  It's simply illegal.   This defers the choice;  perhaps later we will have more experience to go on.
  2.  It's a postfix operator, binding less tightly than function application, but more tightly than any infix operator.   So then (r .x) means r.x, and (r .x .y) means r.x.y.   But (f r .x) means (f r).x.

This choice naturally supports chaining (nice to have, but not essential).  We can write

f .map double

  .filter isEven

meaning (f.map double).filter isEven

  1.  It's a postfix operator, binding more tightly than function application, just as record update does.  So then (f r .x) means (f r.x), and (f r .x .y s .z) means (f r.x.y s.z).

This choice allows us to regard our decision about (f r.x) as what naturally happens if we parse it as three lexemes: f, r, and .x.  But it also breaks the "function application binds more tightly than anything else" rule, just as (f r {x=3}) sadly does already.

It does not permit chaining, at least not without stacked-up parens.
In all three cases we allow (.x), meaning (\r. r.x).   For (2) and (3) we can regard it as a "section", like infix operators only simpler because there is no argument.
I think this is the last major question we have to answer.
What are your views?   Personally I lean towards (2), but I could certainly live with (1).  I'm a bit reluctant to adopt (3).
Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200107/9a72e878/attachment.html>