[ghc-steering-committee] Records again

[Simon Marlow]

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
<ghc-steering-committee at haskell.org> 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 <ghc-steering-committee-bounces at haskell.org
> >
> | On Behalf Of Joachim Breitner
> | Sent: 17 December 2019 10:33
> | To: ghc-steering-committee at 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 at joachim-breitner.de
> |   http://www.joachim-breitner.de/
> |
> | _______________________________________________
> | ghc-steering-committee mailing list
> | ghc-steering-committee at haskell.org
> | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191219/9589f7ed/attachment-0001.html>