[ghc-steering-committee] Record syntax

Tue Jan 28 14:21:10 UTC 2020

Okay, found the proposal at
https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/proposals/0000-record-dot-syntax.md

My main question is whether this is really an improvement over just
defining an infix operator for carrying out this operation. I can
foresee having to untangle someone's code which was written with lots
of weird polymorphic naked field selectors at 3am under a deadline,
and not being very happy about this. Do we actually *want* people to
write code like the expression we're trying to disambiguate here? Is
it really too much to ask that they write f (getField @x) g (getField
@y) h (getField @z) or f (getField @x) (g (getField @y)) (h (getField
@z)) as appropriate to their situation?

On Tue, 28 Jan 2020 at 09:04, Cale Gibbard <cgibbard at gmail.com> wrote:
>
> Hey guys, I'm new here, what is this weird dot nonsense? :D
>
> Can we perhaps avoid overloading (.) further? Function composition is
> really important, and I was already upset at the lack of visual
> clarity by the time it was used for qualifying modules...
>
> On Tue, 28 Jan 2020 at 08:58, Eric Seidel <eric at seidel.io> wrote:
> >
> > I agree with Joachim that we should have a formal vote on this point. It's contentious, as syntax always seems to be, so it would be good to get everyone's opinion on record, even if that opinion is just "2 and 3 both seem reasonable to me".
> >
> > But, before we vote, it occurs to me that we have three new committee members (welcome!) who might have comments or questions. Alejandro, Cale, and Tom, have you been following the discussion so far, or do you need a summary? I wouldn't blame you, it's been dragging on for a very long time..
> >
> > On Tue, Jan 28, 2020, at 07:12, Joachim Breitner wrote:
> > > I know I know. It matters for what are the names of variables. My
> > > mental parser first looks what are the names (and handles module
> > > prefixes), and then the expression parser runs. At least in my head.
> > >
> > > And module prefixes are not arbitrary expressions (yet…), but the `r`
> > > can be an arbitrary complex expression!
> > >
> > >    f (foo bar // baz).r
> > >
> > > vs
> > >
> > >    f (foo bar // baz) .r
> > >
> > > would be different under your proposal, but the same under mine.
> > >
> > > But none of this is new to anyone here… why not just vote and get a decision?
> > >
> > > Cheers,
> > > Joachim
> > >
> > >
> > > Am 28. Januar 2020 12:58:34 MEZ schrieb Simon Peyton Jones
> > > <simonpj at microsoft.com>:
> > > >|  With function application, no space or space is irrelevant:
> > > >|
> > > >|    f r"" = f r "" ≠ f (r "") = f (r "")
> > > >
> > > >But that is not so
> > > >
> > > >     f r x  ≠   f rx
> > > >     f M.x  ≠   f M x
> > > >
> > > >White space (or its absence) matters.
> > > >
> > > >Simon
> > > >
> > > >|  -----Original Message-----
> > > >|  From: ghc-steering-committee
> > > ><ghc-steering-committee-bounces at haskell.org>
> > > >|  On Behalf Of Joachim Breitner
> > > >|  Sent: 28 January 2020 11:55
> > > >|  To: ghc-steering-committee at haskell.org
> > > >|  Subject: Re: [ghc-steering-committee] Record syntax
> > > >|
> > > >|  Hi,
> > > >|
> > > >|  > Consider  (f .x g .y h .z)
> > > >|  >
> > > >|  > (2) says this means ((((f .x) g) .y) h) .z), so that it
> > > >parenthesises
> > > >|  > exactly like function application.
> > > >|  >
> > > >|  > (3) says it means (((f .x) (g .y)) (h .z)) which, while
> > > >unambiguous,
> > > >|  > I dislike cordially.
> > > >|  >
> > > >|  > I propose to adopt (2).
> > > >|
> > > >|  I agree that “exactly like function application” is a great, simple
> > > >|  universal way of explaining the parsing.
> > > >|
> > > >|  But I can't stop pointing out that this is inconsistent if we insist
> > > >|  that `f r.x = f (r.x)`.
> > > >|
> > > >|  With function application, no space or space is irrelevant:
> > > >|
> > > >|    f r"" = f r "" ≠ f (r "") = f (r "")
> > > >|
> > > >|  You propose
> > > >|
> > > >|    f r.x ≠ f r .x = f (r .x) = f (r .x)
> > > >|
> > > >|  while I am still attached to
> > > >|
> > > >|    f r.x = f r .x ≠ f (r .x) = f (r .x)
> > > >|
> > > >|  I know that this will disappoint a few who want their code to look
> > > >like
> > > >|  it does in some other languages (many object oriented langauges,
> > > >|  Ocaml), and who do not want to put in the extra parentheses. But in
> > > >|  this case I am leaning towards the elegance of _really_ saying
> > > >“exactly
> > > >|  like function application”, not only syntactically, but also morally
> > > >(a
> > > >|  record is a function on a finite set of field names.)
> > > >|  I find this very justifiable for a functional programming language.
> > > >|
> > > >|  And I find it very un-haskelly that going from a space to no space
> > > >|  between expressions makes a difference (I believe Simon Marlow
> > > >shared
> > > >|  this reservation.)
> > > >|
> > > >|
> > > >|  If we do insist on “binds more tightly if no space”, then I am
> > > >actually
> > > >|  in favor of “also binds more tightly if there is a space”, i.e. (3)
> > > >|  above, to avoid the whitespace-sensitivity.
> > > >|
> > > >|
> > > >|  So if it comes to a vote, I think these three options cover all
> > > >|  opinions so far?
> > > >|
> > > >|   * f r .x = (f r).x; f r.x = f (r.x)     -- Simon’s (2)
> > > >|   * f r .x = (f r).x; f r.x = (f r).x)    -- My take on it
> > > >|   * f r .x = f (r.x); f r.x = f (r.x)     -- Simon’s (3)
> > > >|
> > > >|  Anything else?
> > > >|
> > > >|
> > > >|  If we vote, I hope we don't get too many abstinations. Nobody will
> > > >be
> > > >|  personally offended if you vote “against” them (I hope), but
> > > >whatever
> > > >|  outcome we have better have weight, and is supported by a high
> > > >turnout.
> > > >|
> > > >|
> > > >|  And I think we should just vote; we keep rephrasing the same
> > > >arguments
> > > >|  with different words.
> > > >|
> > > >|  Cheers,
> > > >|  Joachim
> > > >|
> > > >|  --
> > > >|  Joachim Breitner
> > > >|    mail at joachim-breitner.de
> > > >|
> > > >|
> > > >https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
> > > >|  im-
> > > >|
> > > >breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e
> > > >|
> > > >1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933
> > > >|
> > > >72311824&sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D&
> > > >|  reserved=0
> > > >|
> > > >|
> > > >|  _______________________________________________
> > > >|  ghc-steering-committee mailing list
> > > >|  ghc-steering-committee at haskell.org
> > > >|
> > > >https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
> > > >|  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > > >|
> > > >committee&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694
> > > >|
> > > >a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311
> > > >|
> > > >824&sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%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
> > >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee