[ghc-steering-committee] Record dot notation

[Cale Gibbard]

1 > 2 > 3 > 4

I don't really understand the need for this syntax sugar. It seems to
optimise already-short expressions by a constant factor in a way that
makes their meaning harder to grasp. Think about how much effort
people have spent trying to understand what .x ought to mean and how
it should be parsed here, and multiply that by all the users of the
language who are actually going to have to deal with occurrences of it
and wonder what's going on.

The period character is already too overloaded in Haskell's syntax
imo, and I don't really see why we should need it when there are
plenty of reasonable other options for expressing these programs,
including the option of no further syntax sugar at all. The fact that
other languages use that syntax isn't really an argument that it's
right for Haskell, which is very different from those languages in
countless other ways already.


On Fri, 7 Feb 2020 at 17:37, Joachim Breitner <mail at joachim-breitner.de> wrote:
>
> Hello,
>
> Am Freitag, den 07.02.2020, 17:13 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
> > Here are the alternatives I propose we vote on.  The first order of
> > business is to check that they are all clear; and that I haven't omitted
> > a worthy alternative.  Here they are:
> >
> > 1. Reject the proposal
> >
> > 2. Naked .x is illegal
> >
> > 3. Naked .x is a postfix operator, binding exactly
> >    like application:  f r .x   means (f r).x
> >
> > 4. Naked .x is a postfix operator, binding more tightly
> >    than application: f r .x   means   f (r.x)
> >
> > Under all of (2,3,4) I think we are content that
> >   - (f r.x) means  (f (r.x))
> >   - (.x)    means  (\r -> r.x)
> >
> > By "naked .x" I mean "not preceded by an identifier (e.g.
> > r.x),
> > or an open paren (e.g. (.x)), or a close paren (e.g. (f 3).x)
>
>
> What about other non-whitespace? I assume these would also not be
> naked?
>
>   "hi".x
>   [1,2,3].x
>   Foo{a = 3}.x
>   (☃).x
>
> What about?
>
>   f{-comment-}x
>
> I really would prefer a design where all these questions do not even
> need to be asked…
>
> > Let's just check everyone is happy with these alternatives.  Then we can
> > vote by putting in rank order, and Joachim can run his STV algorithm.
>
> As I said repeatedly: I am _not_ content that
>
>    (f r.x) means  (f (r.x))
>
> as (in combination with 3, but not with 4) it introduces whitespace
> sensitivity between expressions, which I would like to avoid.
>
> 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.)
>
> NB: We don’t need a variant of 4, because under rule 4, we don't need
> to special-case “.x without whitespace before”. Variant 4 simply makes
> .x behave like {x=1}, if I am not mistaken.
>
> Luckily, Condorcet voting (not actually STV) allows us to add “odd”
> options without affecting the result of the rest. If I am the only one
> who leans towards not introducing whitespace sensitivity, this my
> insisting on this being on the ballot is harmless noise.
>
> (I wonder why we do not use the exhaustive design space overview in my
> mail from Fri, 13 Dec 2019 10:14:22 +0100, where I already suggested to
> vote. But I guess variants 1-5 above suffice, if nobody is asking for
> any of the other three; two of them forbid (.x), which nobody seems to
> advocate for. And with option 3 or 5 one kinda has to answer the
> question if (.x y) should be allowed… maybe not worth the distraction.)
>
>
>
> 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.
>
>
> 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/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee