[ghc-steering-committee] Record dot notation

Wed Feb 12 16:43:52 UTC 2020

On Wed, 12 Feb 2020 at 14:53, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> 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
>

Yes OK, I think that's reasonable. (I hadn't digested your earlier message
proposing this properly, but I went back and re-read it just now.)

I can imagine explaining that to someone - there's a straightforward
lexical syntax, and the context-free grammar is similar to the rules for
function application.

Joachim what do you think?

Cheers
Simon

>
>
> 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> 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> wrote:
>
>
>
> On Fri, 7 Feb 2020 at 22:37, Joachim Breitner <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
>   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
> 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
> 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/f882839d/attachment-0001.html>