[ghc-steering-committee] RecordDotSyntax: please express a view
Richard Eisenberg
rae at richarde.dev
Tue Dec 10 14:16:53 UTC 2019
I'm in support of this proposal.
I don't think it's fantastic. (In particular, I'm bothered about the lack of polymorphic update.) But it seems willfully disdainful of our users if we don't do *something*. This is the closest we've gotten to a solution here. Let's not turn down now. And perhaps with impredicativity, new doors will open up in the future.
As to the Great Whitespace Debate: I prefer requiring the parens for the selector section: (.foo). It makes this more like other sections. A related question (that seems unconsidered by the proposal) is: if we require parens for the section, what does a bare `.foo` mean? If we don't allow
> x.foo
> .bar
> .baz
then what do users do if they have long field names? Are we reduced to writing
> (x.foo.bar
> ).baz
? That's awful. I remember this coming up in the commentary, but I'm not quite sure how to search for it.
To be concrete, I propose this:
Position of . Meaning
-------- -------
tight infix with a conid before the .: module qualification
with anything else before the .: field access
suffix parse error
prefix with a ( before the .: field selector
otherwise: field access
loose infix normal, user-definable operator (defined to be composition in the Prelude)
Note that the lexer must tag the . with its position, and then parsing is easy to implement. Effectively, a prefix . slurps up all the preceding whitespace. No weird precedence rules necessary.
To be clear: I don't feel very strongly on this point, and I support the proposal with any discussed conclusion to the Great Whitespace Debate. Yet, as a committee member, I make my vote as I have written here.
Richard
> On Dec 10, 2019, at 12:47 PM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
> | About the contentious issue of (.foo) vs. .foo, I am squarely in the
> | (.foo) camp,
>
> Although I recommended allowing naked .foo, if there is a consensus on the committee for (.foo), with a naked .foo being illegal, then I'm quite willing to support that position too. After all, it just makes more programs illegal, we can always allow naked .foo later.
>
> I don't think anyone is proposing that
> f g .x h .y z
> means
> f (g.x) (h.y) z
> I would cordially dislike that, as I do the current record update syntax precedence rules.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-steering-committee <ghc-steering-committee-
> | bounces at haskell.org> On Behalf Of Joachim Breitner
> | Sent: 10 December 2019 11:41
> | To: ghc-steering-committee at haskell.org
> | Subject: Re: [ghc-steering-committee] RecordDotSyntax: please express
> | a view
> |
> | Hi,
> |
> | TL;DR: Support acceptance, preference for (.foo) over .foo.
> |
> | I guess many people are excited, so overall good to get this.
> |
> | I recently stopped using Haskell for something where readability was
> | the primary goal for lack of nested access and updates. So yay! :-)
> |
> | I am a bit unhappy about the “Higher-rank fields” problem. Not that I
> | use such field often, but it came up in the “Overloaded do” proposal.
> | Maybe accepting this will increase the chances of a getField variant
> | that works even in impredicative cases.
> |
> | I hope pattern matching will follow, but no need to have it in this
> | proposal.
> |
> |
> | About the contentious issue of (.foo) vs. .foo, I am squarely in the
> | (.foo) camp, for all the gut-feeling reasons given elsewhere in
> | abundance. My main reasons: feels like a syntactic section to me, and
> | less danger of wat effects for people coming from languages with the
> |
> | a.foo
> | .bar
> | .baz
> |
> | idiom…
> |
> |
> | I will not veto the current form, but Eric may be in less of a
> | minority
> | that he thinks.
> |
> |
> |
> | The precedence rule
> |
> | f a.b.c 10
> |
> | being
> |
> | f (a.b.c) 10
> |
> | makes sense when one comes from Ocaml or similar languages, or has
> | thought about record updates for a long time. There is a trace of a
> | feeling that this is un-Haskellish in the same way as
> |
> | f a { b = c } 10
> |
> | is. But at least we don't allow spaces around the dot, so it is
> | probably fine.
> |
> |
> | Cheers,
> | Joachim
> |
> |
> |
> |
> |
> |
> | Am Montag, den 09.12.2019, 22:57 +0000 schrieb Simon Peyton Jones via
> | ghc-steering-committee:
> | > Dear steering committee
> | >
> | > I'm the shepherd for the RecordDotSyntax proposal.
> | >
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> | ub.com%2Fghc-proposals%2Fghc-
> | proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C84
> | 3ae99c854745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> | 7C0%7C637115748567847774&sdata=gcW6OmpCccSbVaC5AmkFdJtrpwbdo1EIEy7
> | stuHOeq0%3D&reserved=0
> | >
> | > I recommend acceptance:
> | >
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> | ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282%23issuecomment-
> | 563477691&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
> | c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
> | 48567847774&sdata=9bwoFCaNRGH62hV7LvKvCPbiFXYQjAaSPgUKe6ttLtw%3D&a
> | mp;reserved=0
> | >
> | > Please reads the proposal, and as much of the discussion as you feel
> | able, and respond in the next week or two to indicate your views.
> | >
> | > Remember: ask technical questions on the Github discussion thread,
> | and use this mailing list for more evaluative discussion of judgement
> | or opinion.
> | >
> | > I'd love every member of the committee to express a view. This
> | proposal has attracted a lot of interest.
> | >
> | > Thanks
> | >
> | > Simon
> | >
> | > > -----Original Message-----
> | > > From: ghc-steering-committee <ghc-steering-committee-
> | bounces at haskell.org>
> | > > On Behalf Of Joachim Breitner
> | > > Sent: 28 November 2019 10:11
> | > > To: ghc-steering-committee at haskell.org
> | > > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> | > > RecordDotSyntax, Shepherd: Simon PJ
> | > >
> | > > Dear Committee,
> | > >
> | > > this is your secretary speaking:
> | > >
> | > > RecordDotSyntax language extension proposal has been proposed by
> | Neil
> | > > Mitchell and Shayne Fletcher
> | > >
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> | ub.com%2Fghc-proposals%2Fghc-
> | proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C84
> | 3ae99c854745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> | 7C0%7C637115748567847774&sdata=gcW6OmpCccSbVaC5AmkFdJtrpwbdo1EIEy7
> | stuHOeq0%3D&reserved=0
> | > >
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> | ub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-
> | &data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745dc9a3f08d7
> | 7d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157485678477
> | 74&sdata=Kno9%2Fitm3REWI6roXdLQ88tSpDA%2FeJvY8bb4XKKJI1g%3D&re
> | served=0
> | > > syntax/proposals/0000-record-dot-syntax.md
> | > >
> | > > This is going to be a tricky one. It is partly about whitespace,
> | so it
> | > > has attracted a _lot_ of community interest, by far the most so
> | far. To
> | > > navigate that ship, I propose Simon PJ as the shepherd, because he
> | is a
> | > > excellent moderator and community manager, and because he has the
> | > > necessary authority to hopefully get a verdict accepted.
> | > >
> | > > Please reach consensus as described in
> | > >
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> | ub.com%2Fghc-proposals%2Fghc-proposals%23committee-
> | process&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745dc9
> | a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115748
> | 567847774&sdata=0eXaTaxw81Z2szF2KGZ3qxbJgSgx3wQZUii8rr1XytM%3D&
> | ;reserved=0
> | > > I suggest you make a recommendation, in a new e-mail thread with
> | the
> | > > proposal number in the subject, about the decision, maybe point
> | out
> | > > debatable points, and assume that anyone who stays quiet agrees
> | with you.
> | > >
> | > > Thanks,
> | > > Joachim
> | > > --
> | > > Joachim Breitner
> | > > mail at joachim-breitner.de
> | > >
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
> | oachim-
> | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c85
> | 4745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> | 7115748567847774&sdata=aeTui1sCsvRGKFzUnyZHzKL%2FwBF0NLDGR%2BmJ5yT
> | UfrE%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
> | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
> | c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
> | 48567847774&sdata=hpyFheQhmtsGFHpKDn1US%2FIwi8OmgWdpk1IdT5v3YDo%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
> | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
> | c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
> | 48567847774&sdata=hpyFheQhmtsGFHpKDn1US%2FIwi8OmgWdpk1IdT5v3YDo%3D
> | &reserved=0
> | --
> | Joachim Breitner
> | mail at joachim-breitner.de
> |
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
> | oachim-
> | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c85
> | 4745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> | 7115748567857762&sdata=id%2Bw%2FzvZX%2FbgV%2FBovQ85ByF7KFdkU8NKtxU
> | eygGeYKU%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
> | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
> | c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
> | 48567857762&sdata=zUhQrs20IkgPfD4lBZIxTYQSBFVlIOP7itXhTTLut6A%3D&a
> | mp;reserved=0
> _______________________________________________
> 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