[ghc-steering-committee] Record syntax
Simon Peyton Jones
simonpj at microsoft.com
Tue Jan 28 14:29:09 UTC 2020
| I hope we'll get a proposal that doesn't trip into so many gnarly problems
| and achieves more of what is expected of a modern record system. It's
| worth waiting.
That's a legitimate point of view, but we have been waiting -- for *precisely* this reason -- for well over a decade. Personally I think it's time to move.
I think voting is fine -- there are matters of judgement here. I'll think about what the questions are.
Simon
| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Christopher Allen
| Sent: 28 January 2020 14:18
| To: Cale Gibbard <cgibbard at gmail.com>
| Cc: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] Record syntax
|
| I'm still where I was before: we should reject this proposal. The
| exploding state space of how code using (.) should be parsed and the fact
| that there are this many dark corners make this a bad idea. It's not worth
| it.
|
| I hope we'll get a proposal that doesn't trip into so many gnarly problems
| and achieves more of what is expected of a modern record system. It's
| worth waiting.
|
| > On Jan 28, 2020, at 08:05, 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
| > _______________________________________________
| > 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
More information about the ghc-steering-committee
mailing list