Re: [ghc-steering-committee] RecordDotSyntax: please express a view

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 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 On Behalf Of Joachim Breitner | Sent: 10 December 2019 11:41 | To: ghc-steering-committee@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 | > > On Behalf Of Joachim Breitner | > > Sent: 28 November 2019 10:11 | > > To: ghc-steering-committee@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@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@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@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@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee