[ghc-steering-committee] Record dot notation

Wed Feb 12 14:53:45 UTC 2020

Don’t forget option (6): like (5) but treat r.x as a lexeme.

I find it hard to justify a language in which
               f M.x     means      f (M.x)
but         f m.x     means      (f m).x

especially when the “.” means, in both cases, “take the x component of the thing on the left”.

So here I’m leaning even harder on the connection with qualified names: let’s simply be consistent with that.

I’m quite content to follow (5) on the meaning of
               f (g 3).x
That is, it means the same as (f (g 3)   .x), namely  (f (g 3)).x

But I’m very keen on maintaining consistency with qualified names when the thing on the LHS is a token (or dotted chain thereof.)

Does anyone else have an alternative beyond 1-6 that they want to put forward?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 12 February 2020 11:21
To: Richard Eisenberg <rae at richarde.dev>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] Record dot notation

On Mon, 10 Feb 2020 at 14:15, Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:
Upon careful consideration, I think the whitespace concerns here are somewhat ill-founded.

First, please see https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst#proposed-change-specification<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0229-whitespace-bang-patterns.rst%23proposed-change-specification&data=02%7C01%7Csimonpj%40microsoft.com%7Ca979afde4a764f748da908d7afadb9b9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637171032991836904&sdata=6m9YqnH08xdPoivBg86r1RGKhpewqTDPHtNbYt5518U%3D&reserved=0>, where (among other points), a careful description of "loose infix" vs "prefix" vs "suffix" vs "tight infix" is discussed. Here is a set of examples:

a ! b   -- a loose infix occurrence

a!b     -- a tight infix occurrence

a !b    -- a prefix occurrence

a! b    -- a suffix occurrence
Yes and I was not very keen on that proposal (my concerns are on the discussion thread).

This distinction is *not* just made by example, but that proposal (which has been accepted) defines these precisely. So, the comments on this thread about what counts as a naked selector are addressed: a naked selector is one where the dot is a prefix occurrence.

Other whitespace-wariness comes from worrying about the distinction between prefix and tight infix occurrences. That is, should we differentiate between the interpretation of `f r.x` and `f r .x`. Yet in all versions of any of this, we differentiate between loose infix and the others. Thus there is *always* whitespace-sensitivity around dot. Note that this is true, as Simon PJ pointed out, regardless of this proposal, where a tight-infix usage of a dot with a capitalized identifier on the left is taken as a module qualification. In all of its versions, this proposal *increases* the whitespace sensitivity, by further distinguishing between prefix occurrences of dot and other usages.

Let's compare options 3 and 5 with this analysis then:

Option 3:
loose-infix: whatever (.) is in scope
tight-infix:
  - if left-hand is a capitalized identifier: module qualification
  - otherwise: record selection, binding tighter than function application
prefix: postfix record selection, binding like function application
suffix: presumably, whatever (.) is in scope

Option 5:
loose-infix: whatever (.) is in scope
tight-infix:
 - if left-hand is a capitalized identifier: module qualification
 - otherwise: postfix record selection, binding like function application
prefix: postfix record selection, binding like function application
suffix: presumably, whatever (.) is in scope

That's a good summary - but note that under Option 5 tight-infix and prefix are the same, modulo the qualified-identifier case, and this is the key difference. What I wanted to avoid was having to use the language of tight-infix vs. prefix AT ALL in understanding how record selection syntax works, and (5) achieves that whereas (3) doesn't.

Under option 5 we get one new lexeme:
   .<varid>
and everything else can be handled at the context-free grammar level. This is a nice minimal addition to the language. We don't have to invoke the mess that is proposal #229, which was forced upon us because BangPatterns and TypeApplications made the handling of (!) and (@) so complicated. If we don't have to do the same to (.), I believe we should take the opportunity to avoid it.

Cheers
Simon

My point here is that option (5) is no more or less whitespace sensitive than option (3). Both need the same cases to figure what the period character in your code means. I think this is why Simon PJ has keyed this part of the debate to module qualification: that existing feature (not under debate) essentially breaks the symmetry here, meaning that we have more room to work with without breaking symmetry further.

My vote is thus:

3 > 5 > 2 > 4 > 1

Other points of motivation:
- Despite my argument above, I see the merit in (5). I just think that an argument "we don't want dot to be whitespace-sensitive" isn't really effective.
- I want to accept this proposal. We're not going to get another go at this.
- I really don't like the way record-update binds, and (4) reminds me too much of that.

Richard

On Feb 10, 2020, at 9:58 AM, Simon Marlow <marlowsd at gmail.com<mailto:marlowsd at gmail.com>> wrote:

On Fri, 7 Feb 2020 at 22:37, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:

I really would prefer a design where all these questions do not even
need to be asked…

Me too. Also what about (.x) vs. ( .x), are those the same?

So I think to have the full picture, we need the following option as
well on the ballot:

 5. .x is a postfix operator, binding exactly like application,
    whether it is naked or not.
    (This is option 3, but without the whitespace-sensitivity.)

[...]

Anyways, now for my opinion: Assuming no more options are added, my
ranking will be

  5 > 4 > 2 > 1 > 3

This puts first the two variants where .x behaves like an existing
language feature (either like function application or like record
updates), has no whitespace sensitivity, and follows existing languages
precedence (JS and OCaml, resp.).
Then the compromise solution that simply forbids putting spaces before
.x (so at least the program doesn't change semantics silently).
I dislike variant 3, which adds a _new_ special rule, and where adding
a single space can change the meaning of the program, so I rank that
last.

I'm also against whitespace-sensitivity and I lean towards this ordering too.
But I'm going with:

5 > 2 > 1 > 4 > 3

Rationale: (5) seems the easiest to explain and has the fewest special cases, yet covers the use-cases we're interested in. Beyond that I want to be conservative because I find it hard to predict the ramifications of the more-complex alternatives 4/3, so I've put 2/1 ahead of those. I've made my peace with the current record selection syntax binding more tightly than application, and indeed I often rely on it to avoid a $, so I'm OK with 4 over 3.

Cheers
Simon

Cheers,
Joachim

PS, because its on my mind, and just for fun:

Under variant 3, both foo1 and foo2 typecheck, they do quite different
things (well, one loops).

  data Stream a = Stream { val :: a, next :: Stream a }

  foo1 f s = Stream (s.val) (foo1 (fmap f s).next)
  foo2 f s = Stream (s.val) (foo2 (fmap f s) .next)

--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca979afde4a764f748da908d7afadb9b9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637171032991836904&sdata=6W2WqiJ6t%2FNknHjToU62bZBs%2BvqXwgOjvGcdFOzouVY%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<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%7Ca979afde4a764f748da908d7afadb9b9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637171032991846862&sdata=1nmXgAluEp76Pl%2Busq9%2BxpMG8NvdQqlKv2ByTSHUDW8%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<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%7Ca979afde4a764f748da908d7afadb9b9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637171032991846862&sdata=1nmXgAluEp76Pl%2Busq9%2BxpMG8NvdQqlKv2ByTSHUDW8%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200212/8f27f2a4/attachment-0001.html>