RecordDotSyntax: please express a view

Simon Peyton Jones

9 Dec 2019 9 Dec '19

5:57 p.m.

Dear steering committee I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282 I recommend acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5634776... 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://github.com/ghc-proposals/ghc-proposals/pull/282 | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot- | 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://github.com/ghc-proposals/ghc-proposals#committee-process | 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 | http://www.joachim-breitner.de/ | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Show replies by date

Eric Seidel

9 Dec 9 Dec

9:56 p.m.

I'm very supportive of the proposal overall, I think it would be a major ergonomic improvement to the language. On the question of how to interpret `foo .lbl`, I'm still not entirely convinced that a bare `.lbl` should refer to the selector function. To me the alternative reading of `foo .lbl` being the same as `foo.lbl` is more natural. And I worry (without evidence to be fair) that the proposal's interpretation will be a new, common stumbling block for newcomers to the language. I believe I'm in the minority here, and I can certainly train myself to use the proposal's interpretation, so I won't stand in its way. But it would be really nice if the final implementation could provide a helpful suggestion to try `foo.lbl` instead if type-checking fails! On Mon, Dec 9, 2019, at 17:57, Simon Peyton Jones via ghc-steering-committee wrote:

...

Dear steering committee

I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282

I recommend acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5634776...

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://github.com/ghc-proposals/ghc-proposals/pull/282 | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot- | 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://github.com/ghc-proposals/ghc-proposals#committee-process | 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 | http://www.joachim-breitner.de/ | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

10 Dec 10 Dec

6:40 a.m.

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://github.com/ghc-proposals/ghc-proposals/pull/282

I recommend acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5634776...

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://github.com/ghc-proposals/ghc-proposals/pull/282 https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot- 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://github.com/ghc-proposals/ghc-proposals#committee-process 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 http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Simon Peyton Jones

7:47 a.m.

| 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

Richard Eisenberg

9:16 a.m.

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

Simon Peyton Jones

9:27 a.m.

| To be concrete, I propose this: Not concrete enough. I don't understand | prefix with a ( before the .: field selector | otherwise: field access What does (f a .b c .d e) mean? You may be arguing that naked `.x` is a *postfix operator*, rather like factorial when we write 5!. If so, it should have a precedence etc, and presumably binds less tightly than function application. So f a .b c .d e would presumably mean ((f a).b c).d e That might be OK. I don’t recall the discussion articulating it like this, but it seems defensible. Simon | -----Original Message----- | From: Richard Eisenberg | Sent: 10 December 2019 14:17 | To: Simon Peyton Jones | Cc: Joachim Breitner ; ghc-steering- | committee@haskell.org | Subject: 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 | bounces@haskell.org> 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 | bounces@haskell.org> | > | > > 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://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%7Cc4905b1dc7a4474 | 4c43b08d77d7b9d5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371158 | 42192614669&sdata=Xh0SopxeypTlM%2B31iuHJNQMRzNt2sTLGXbdmYjGu3CQ%3D | &reserved=0

Richard Eisenberg

9:33 a.m.

...

On Dec 10, 2019, at 2:27 PM, Simon Peyton Jones wrote:

| To be concrete, I propose this:

Not concrete enough. I don't understand

| prefix with a ( before the .: field selector | otherwise: field access

What does (f a .b c .d e) mean?

According to my table, we have two prefix `.`s. These are field accesses. Just like the tight infix positioning of `.`. So, (f a .b c .d e) means the exact same thing as (f a.b c.d e), which is, presumably (f (a.b) (c.d) e). Perhaps that's not what we like. But it is simple and comes straight from my table. And it is not too bad for programmers: prefix `.` is *just like* tight infix `.`. The only exception is at the beginning of a section, where tight-infix does not make sense. Richard

Simon Peyton Jones

9:56 a.m.

According to my table, we have two prefix `.`s. These are field accesses. Just like the tight infix positioning of `.`. So, (f a .b c .d e) means the exact same thing as (f a.b c.d e), which is, presumably (f (a.b) (c.d) e). So `.x` behaves like a postfix operator with precedence tighter than function application. Indeed, personally, I don't like that! Also I realise that it might be good to write xs .map double .filter isEven .map square and that would indeed be what you could say with a postfix operator. It would parse as (((xs.map) double).filter isEven).map square Simon From: Richard Eisenberg Sent: 10 December 2019 14:33 To: Simon Peyton Jones Cc: Joachim Breitner ; ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] RecordDotSyntax: please express a view On Dec 10, 2019, at 2:27 PM, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: | To be concrete, I propose this: Not concrete enough. I don't understand | prefix with a ( before the .: field selector | otherwise: field access What does (f a .b c .d e) mean? According to my table, we have two prefix `.`s. These are field accesses. Just like the tight infix positioning of `.`. So, (f a .b c .d e) means the exact same thing as (f a.b c.d e), which is, presumably (f (a.b) (c.d) e). Perhaps that's not what we like. But it is simple and comes straight from my table. And it is not too bad for programmers: prefix `.` is *just like* tight infix `.`. The only exception is at the beginning of a section, where tight-infix does not make sense. Richard

Eric Seidel

10:27 p.m.

On Tue, Dec 10, 2019, at 09:27, Simon Peyton Jones via ghc-steering-committee wrote:

...

You may be arguing that naked `.x` is a *postfix operator*, rather like factorial when we write 5!.

I brought this up at some point during the discussion. Treating a bare `.x` as a postfix operator feels very natural to me, and then `(.x)` would be a natural way to refer to the operator itself. I'm not at all sure what the precedence of such an operator should be, however. When I see an example like

...

f a .b c .d e

I want to parse it (if at all) as

...

f (a .b) (c .d) e

rather than

...

((f a).b c).d e

However, when confronted with

...

xs .map double .filter isEven .map square

I instinctively want to flip the precedences and parse it as

...

(((xs.map) double).filter isEven).map square

What a difference some newlines (or is it the real names?) makes! Perhaps some more examples will be instructive. Another example that came up was deeply nested field accesses that don't fit onto a single line.

...

x.foo .bar .baz

This will be parsed as

...

((x.foo).bar).baz

regardless of precedence, as there is no function application. What if we add one?

...

f x.foo .bar .baz

If function application binds more tightly than field selection, this would parse as

...

((f x.foo).bar).baz

If you instead wanted

...

f (x.foo.bar.baz)

you could add parens

...

f (x.foo .bar .baz)

which still looks reasonable to me. So I think I would be happy with bare `.lbl` being a postfix operator that binds less tightly than function application.

Richard Eisenberg

11 Dec 11 Dec

4:11 a.m.

...

On Dec 11, 2019, at 3:27 AM, Eric Seidel wrote:

So I think I would be happy with bare `.lbl` being a postfix operator that binds less tightly than function application.

This means that `f x .bar` is `(f x) .bar` while `f x.bar` is `f (x.bar)`. A bit too subtle for me. Another alternative is to make `.foo` a postfix operator that does not associate with function application. That is, `f x .bar` would be a parse error. So we can write `x .foo .bar` to mean the same as `x.foo.bar`, but we don't have to commit to any strange parsing rules around `f a .b c .d e`. But I'm starting to lean toward just making bare `.foo` a syntax error and revisit this debate with more experience. Richard

Spiwack, Arnaud

12 Dec 12 Dec

4:04 a.m.

I'm having most trouble forming an opinion on this. Let me try to formulate my thoughts This proposal solves 1. A dot syntax for record selector 2. A nested record update syntax 3. Shared record field names This proposal doesn't address 4. Partial selection 5. Partial update This proposal breaks 6. Type-changing record update 7. Polymorphic (rank 2+) fields Does it balance out? 1. is nice, but honestly pretty trivial. The real reason for 1, though, is to enable 3. 2. is pretty cool. When you need nested update, not having syntax for it is pretty painful. It seems to be an oft repeated reason why Haskell records “suck”. That being said, how many languages don't have nested update, and of these do people complain about records “sucking”. As an example, Ocaml doesn't have nested updates, and Ocaml programmers don't complain about records. Still, pretty cool. 3. again a common complaint about Haskell records. In this respect this proposal can be seen as an improvement on what's already been done in -XDuplicateRecordFields (I don't have much of an experience with -XDuplicateRecordFields, but I believe it's an improvement); or a way to use -XNoFieldSelectors without resorting to lenses. To draw a comparison with Ocaml, again: shared record fields are a reasonably recent feature there too; it was welcome, but rather as fixing a minor inconvenience (programmers just namespaced their record fields). Maybe they are more pressing in Haskell because namespacing is less convenient. I'm not sure 4. is a rather unfortunate behaviour of Haskell's record semantic. It's not too hard to avoid its pitfalls, so it's ok 5. is more problematic. In fact, before this whole conversation started, if someone had asked me why people didn't like Haskell records, I would have told them about partial updates. So this leaves me a bit more dubious (though I also recognise that it is a hard problem to solve). 6/7. these are broken by this proposal in that the proposal removes syntax for those. In my very local experience, in record-heavy code, they are rather uncommon. So those programmers who would really like 2 and 3, are probably not the same who would be affected by this proposal. But this carries a risk: we seem to have taken the habit of being suspicious of fork-like extension. Don't 6 and 7 make this proposal fork-like? (note: 6 can probably be fixed later by adding type parameters to `HasField` (though the functional dependencies would become more subtle), I'm not sure we have any plan that would begin to address 7). I wrote all that, but it hasn't helped me make an opinion. Some people are very enthusiastic about this proposal, they probably deserve that we accept. It's definitely not a bad idea. We may want to be worried about the fork-like aspects; maybe they are not that bad though. As per syntax, Simon PJ's suggestions, on the github thread, sound pretty sensible to me. And I'm squarely in team (.foo) (section parentheses for usage as a function). Apologies if this message wasn't useful (it probably wasn't). I'll probably stay a neutral party for the rest of this process. On Wed, Dec 11, 2019 at 10:11 AM Richard Eisenberg wrote:

...

On Dec 11, 2019, at 3:27 AM, Eric Seidel wrote:

So I think I would be happy with bare `.lbl` being a postfix operator that binds less tightly than function application.

This means that `f x .bar` is `(f x) .bar` while `f x.bar` is `f (x.bar)`. A bit too subtle for me.

Another alternative is to make `.foo` a postfix operator that does not associate with function application. That is, `f x .bar` would be a parse error. So we can write `x .foo .bar` to mean the same as `x.foo.bar`, but we don't have to commit to any strange parsing rules around `f a .b c .d e`.

But I'm starting to lean toward just making bare `.foo` a syntax error and revisit this debate with more experience.

Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

4:14 a.m.

Hi, Am Donnerstag, den 12.12.2019, 10:04 +0100 schrieb Spiwack, Arnaud:

...

Apologies if this message wasn't useful (it probably wasn't). I'll probably stay a neutral party for the rest of this process.

I find it very useful. Especially as it reminds us that there is more to the proposal than the question about what a space left of the . means (which seems to suck in all the attention). Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Spiwack, Arnaud

4:19 a.m.

After I clicked “send”, and after some verification, I realised that there was a yet undocumented interaction with pattern synonyms. Namely, record-pattern-synonym update. I asked the author to document it in the proposal: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5649197... . On Thu, Dec 12, 2019 at 10:15 AM Joachim Breitner wrote:

...

Hi,

...
Apologies if this message wasn't useful (it probably wasn't). I'll

Am Donnerstag, den 12.12.2019, 10:04 +0100 schrieb Spiwack, Arnaud: probably stay a neutral party for the rest of this process.

I find it very useful. Especially as it reminds us that there is more to the proposal than the question about what a space left of the . means (which seems to suck in all the attention).

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

13 Dec 13 Dec

4:14 a.m.

Hi, unsurprisingly, Wadler’s law holds also within the committee. It looks like we have to accept that this one will not likely be solved by consensus (at least not “enthusiastic consensus”). But that is fine: The main point of the committee is to make _a_ decision, and we can vote and probably all live with the outcome. I’m not calling a vote yet (I’ll leave that to Simon when he feels that likely no new insights are going to emerge), but would like to outline the procedure. We could do a simple majority yes/no vote on the proposal as it stands. But I believe we can do better, by collecting all (reasonable) options that have been discussed, and doing a ranked voting. At the risk of secretarysplaining I’d like to point out that that voting tends to favor more widly acceptable outcomes: If 35% want .foo to be the selector, 30% want .foo to be a selection even with spaces on the left, and 25% are prefer to be conservative and forbid free- standing .foo for now, then it may be that that last option wins, as the most consensusable, wins. So if we do it this way, you should be able to express your genuine ranking preference, and not worry about strategic voting. So what options are on the table? I tried to find a small set of representative examples that explore all contentious corners of the design space, and came up with this: r.field f x.field y f x .field y f x (.field) y f x (.field y) I believe our reasonable options are (and there are many…) Reject: r.field = \a -> r (field a) f x.field y = \a -> f x (field y a) f x .field y = \a -> f x (field y a) f x (.field) y = f x (\a -> a . field) y f x (.field y) = f x (\a -> a . field y) OnlySelection: r.field = getField @"field" r f x.field y = f (x.field) y f x .field y -- NOT ALLOWED f x (.field) y -- NOPE f x (.field y) -- NAY SectionSelector: r.field = getField @"field" r f x.field y = f (x.field) y f x .field y -- VERBOTEN! f x (.field) y = f x (\r->r.field) y f x (.field y) -- BAD! PlainSelector: -- this is the proposal as it stands, I believe r.field = getField @"field" r f x.field y = f (x.field) y f x .field y = f x (\r->r.field) y f x (.field) y = f x (\r->r.field) y f x (.field y) = f x ((\r->r.field) y) = f x (field y) -- ! Ocaml: r.field = getField @"field" r f x.field y = f (x.field) y f x .field y = f (x.field) y f x (.field) y -- NOT ALLOWED f x (.field y) -- CAN’T DO THAT Ocaml+Section: r.field = getField @"field" r f x.field y = f (x.field) y f x .field y = f (x.field) y f x (.field) y = f (\r->r.field) y f x (.field y) -- NO NO NO JS: r.field = getField @"field" r f x.field y = ((f x).field) y f x .field y = ((f x).field) y f x (.field) y -- IMPOSSIBLE! f x (.field y) -- STOP IT PLEASE! JS+Section: r.field = getField @"field" r f x.field y = ((f x).field) y f x .field y = ((f x).field) y f x (.field) y = f x (\r->r.field) y f x (.field y) = f x (\r->(r.field) y) (Ocaml = . binds more tightly than function application to the left, JS = .foo has same precendence and associativity as function application.) In writing this I noticed that `f x (.field y)` hasn’t been given much discussion, and it seems to only really make sense in the JS-inspired variant where chaining becomes possible, and (.field y) is the “obvious” section syntax for the chaining use of .field. It should probably be prohibited in the variants that want (.field) to be parenthesized. Am I missing any reasonable point in the design space? Do I need to add more examples to the list of representative examples? I am not including the option to print a warning for misleading code (e.g. if `f x.field y = ((f x).field) y`), as that is a separate idea that applies to more than just records. But if people want to express, say, “JS, but only if we get such a warning”, we can add these variants to the ballot. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Richard Eisenberg

14 Dec 14 Dec

6:41 a.m.

Your very helpful delineation of the space assumes (.) = \ f g x -> f (g x) and then inlines. I actually think it would be clearer not to do this. I have taken your taxonomy and kept (.) abstract. Some examples also left (x.field) uninterpreted. I have expanded these to use getField. To be clear, this is *not* a reproposal or intended to make *any* change to Joachim's dichotomy. I am just restating it a way I understand better. Perhaps others will also find this to be clearer. Each individual committee member can use *either* my presentation or Joachim's. They (are intended to) have *the same* semantics. Reject: r.field = (.) r field f x.field y = (.) (f x) (field y) f x .field y = (.) (f x) (field y) f x (.field) y = f x (\a -> (.) a field) y f x (.field y) = f x (\a -> (.) a (field y)) OnlySelection: r.field = getField @"field" r f x.field y = f (getField @"field" x) y f x .field y -- NOT ALLOWED f x (.field) y -- NOPE f x (.field y) -- NAY SectionSelector: r.field = getField @"field" r f x.field y = f (getField @"field" x) y f x .field y -- VERBOTEN! f x (.field) y = f x (\r -> getField @"field" r) y f x (.field y) -- BAD! PlainSelector: -- this is the proposal as it stands, I believe r.field = getField @"field" r f x.field y = f (getField @"field" x) y f x .field y = f x (\r -> getField @"field" r) y f x (.field) y = f x (\r -> getField @"field" r) y f x (.field y) = f x ((\r -> getField @"field" r) y) = f x (getField @"field" y) -- ! Ocaml: r.field = getField @"field" r f x.field y = f (getField @"field" x) y f x .field y = f (getField @"field" x) y f x (.field) y -- NOT ALLOWED f x (.field y) -- CAN’T DO THAT Ocaml+Section: r.field = getField @"field" r f x.field y = f (getField @"field" x) y f x .field y = f (getField @"field" x) y f x (.field) y = f (\r -> getField @"field" r) y f x (.field y) -- NO NO NO JS: r.field = getField @"field" r f x.field y = (getField @"field" (f x)) y f x .field y = (getField @"field" (f x)) y f x (.field) y -- IMPOSSIBLE! f x (.field y) -- STOP IT PLEASE! JS+Section: r.field = getField @"field" r f x.field y = (getField @"field" (f x)) y f x .field y = (getField @"field" (f x)) y f x (.field) y = f x (\r -> getField @"field" r) y f x (.field y) = f x (\r -> (getField @"field" r) y) I hope this is helpful! Richard

Vitaly Bragilevsky

16 Dec 16 Dec

10:19 a.m.

Hi everyone, Joachim and Richard, thank you very much for creating this framework to think about this proposal. It is very helpful. As an educator, I'd vote for rejection. My reason is that the proposal introduces yet another style of programming in Haskell, in addition to traditional functional and lenses-like ones. I can easily imagine imitating object-oriented style with fields-functions and it will be too tempting to use it by those with OO-background (and this includes almost everyone these days given the trends in higher education). The proposal also limits ways to use function composition (especially in sections) which is another sad thing. I don't like all this happening to Haskell as a purely functional PL. Regards, Vitaly сб, 14 дек. 2019 г. в 14:42, Richard Eisenberg :

...

Your very helpful delineation of the space assumes (.) = \ f g x -> f (g x) and then inlines. I actually think it would be clearer not to do this. I have taken your taxonomy and kept (.) abstract. Some examples also left (x.field) uninterpreted. I have expanded these to use getField. To be clear, this is *not* a reproposal or intended to make *any* change to Joachim's dichotomy. I am just restating it a way I understand better. Perhaps others will also find this to be clearer. Each individual committee member can use *either* my presentation or Joachim's. They (are intended to) have *the same* semantics.

Reject: r.field = (.) r field f x.field y = (.) (f x) (field y) f x .field y = (.) (f x) (field y) f x (.field) y = f x (\a -> (.) a field) y f x (.field y) = f x (\a -> (.) a (field y))

OnlySelection: r.field = getField @"field" r f x.field y = f (getField @"field" x) y f x .field y -- NOT ALLOWED f x (.field) y -- NOPE f x (.field y) -- NAY

SectionSelector: r.field = getField @"field" r f x.field y = f (getField @"field" x) y f x .field y -- VERBOTEN! f x (.field) y = f x (\r -> getField @"field" r) y f x (.field y) -- BAD!

PlainSelector: -- this is the proposal as it stands, I believe r.field = getField @"field" r f x.field y = f (getField @"field" x) y f x .field y = f x (\r -> getField @"field" r) y f x (.field) y = f x (\r -> getField @"field" r) y f x (.field y) = f x ((\r -> getField @"field" r) y) = f x (getField @"field" y) -- !

Ocaml: r.field = getField @"field" r f x.field y = f (getField @"field" x) y f x .field y = f (getField @"field" x) y f x (.field) y -- NOT ALLOWED f x (.field y) -- CAN’T DO THAT

Ocaml+Section: r.field = getField @"field" r f x.field y = f (getField @"field" x) y f x .field y = f (getField @"field" x) y f x (.field) y = f (\r -> getField @"field" r) y f x (.field y) -- NO NO NO

JS: r.field = getField @"field" r f x.field y = (getField @"field" (f x)) y f x .field y = (getField @"field" (f x)) y f x (.field) y -- IMPOSSIBLE! f x (.field y) -- STOP IT PLEASE!

JS+Section: r.field = getField @"field" r f x.field y = (getField @"field" (f x)) y f x .field y = (getField @"field" (f x)) y f x (.field) y = f x (\r -> getField @"field" r) y f x (.field y) = f x (\r -> (getField @"field" r) y)

I hope this is helpful! Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Christopher Allen

10 Dec 10 Dec

9:54 a.m.

This proposal should be rejected. The contention over what whitespace around the dot operator should make it clear that even expert Haskellers aren't sure what to expect from this proposal in an intuitive way. We should wait until there's a more compelling benefit that would justify forking the syntax this dramatically. The proposal feels over-determined by present trends in lens libraries, but that's not something I have the energy to prosecute very far. I could imagine a less contentious way forward is possible but I think it's unlikely with the technical particulars at hand. I don't believe the enhanced type inference brought by RecordDotSyntax merits its inclusion given how it complicates the syntax and compatibility story. You can achieve the same with libraries now. That the existing extensions aren't as useful as they ought as compared with using a lens library is symptomatic of half-baked proposals being incorporated into GHC. We can wait until the juice is worth the squeeze and avoid an unforced error here. On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via ghc-steering-committee wrote:

...

Dear steering committee

I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282

I recommend acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5634776...

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://github.com/ghc-proposals/ghc-proposals/pull/282 | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot- | 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://github.com/ghc-proposals/ghc-proposals#committee-process | 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 | http://www.joachim-breitner.de/ | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com

Richard Eisenberg

10:25 a.m.

Thanks for your comments!

...

On Dec 10, 2019, at 2:54 PM, Christopher Allen wrote:

This proposal should be rejected.

The contention over what whitespace around the dot operator should make it clear that even expert Haskellers aren't sure what to expect from this proposal in an intuitive way.

Then there is an easy solution: just don't allow unparenthesized .foo -- that is, make it a parse error. I don't think there is any contention over what (.foo) should mean, and if plain .foo is a parse error, then there is no fork.

...

You can achieve the same with libraries now.

True -- but at significant cost, both in the effort to learn the (complex) libraries and in the need for Template Haskell, which cannot be used in cross-compilation, for example. I think the warm reception of this proposal suggests that, despite the library-based solution, something more is wanted.

...

That the existing extensions aren't as useful as they ought as compared with using a lens library is symptomatic of half-baked proposals being incorporated into GHC.

I'm curious which proposals you're thinking of here. The strangest one, I think, is DisambiguateRecordFields. That was added before the proposals process. I don't think it would have survived the current process -- at least, not in the form in which it has appeared. I would welcome exploring ways of removing it.

...

We can wait until the juice is worth the squeeze and avoid an unforced error here.

This is tempting. But I worry that this may be the best we get, and I think inaction is hurting us. Richard

...

On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via ghc-steering-committee wrote:

...
Dear steering committee

I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282

I recommend acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5634776...

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://github.com/ghc-proposals/ghc-proposals/pull/282 | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot- | 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://github.com/ghc-proposals/ghc-proposals#committee-process | 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 | http://www.joachim-breitner.de/ | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Eric Seidel

11:14 a.m.

I agree with Richard, I think it would be valuable to think of this as two separate proposals. 1. Introduce the dot syntax for projection and nested matching/update. Projection is written ‘foo.lbl’ (no white space allowed) and a bare .lbl is a syntax error. This piece seems largely uncontroversial. 2. Give a meaning to a bare ‘.lbl’. The controversy entirely surrounds what this form should mean. I think (1) is a perfectly good proposal on its own, so I’d much prefer us to accept (1) and defer a decision on (2) over rejecting the entire proposal. Sent from my iPhone

...

On Dec 10, 2019, at 10:26, Richard Eisenberg wrote:

Thanks for your comments!

...
On Dec 10, 2019, at 2:54 PM, Christopher Allen wrote:

This proposal should be rejected.

The contention over what whitespace around the dot operator should make it clear that even expert Haskellers aren't sure what to expect from this proposal in an intuitive way.

Then there is an easy solution: just don't allow unparenthesized .foo -- that is, make it a parse error. I don't think there is any contention over what (.foo) should mean, and if plain .foo is a parse error, then there is no fork.

...
You can achieve the same with libraries now.

True -- but at significant cost, both in the effort to learn the (complex) libraries and in the need for Template Haskell, which cannot be used in cross-compilation, for example. I think the warm reception of this proposal suggests that, despite the library-based solution, something more is wanted.

...
That the existing extensions aren't as useful as they ought as compared with using a lens library is symptomatic of half-baked proposals being incorporated into GHC.

I'm curious which proposals you're thinking of here. The strangest one, I think, is DisambiguateRecordFields. That was added before the proposals process. I don't think it would have survived the current process -- at least, not in the form in which it has appeared. I would welcome exploring ways of removing it.

...
We can wait until the juice is worth the squeeze and avoid an unforced error here.

This is tempting. But I worry that this may be the best we get, and I think inaction is hurting us.

Richard

...
...
On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via ghc-steering-committee wrote:

Dear steering committee

I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282

I recommend acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5634776...

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://github.com/ghc-proposals/ghc-proposals/pull/282 | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot- | 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://github.com/ghc-proposals/ghc-proposals#committee-process | 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 | http://www.joachim-breitner.de/ | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

11:25 a.m.

Hi, also, thinking about it, is (\x->x.foo) too bad? At least initially? Maybe people come up with a nice name for (\x->x.…) (similar to “happy monkey” for (:[]) ) then maybe they will warm up to it :-) Cheers, Joachim Am Dienstag, den 10.12.2019, 11:14 -0500 schrieb Eric Seidel:

...

I agree with Richard, I think it would be valuable to think of this as two separate proposals.

1. Introduce the dot syntax for projection and nested matching/update. Projection is written ‘foo.lbl’ (no white space allowed) and a bare .lbl is a syntax error. This piece seems largely uncontroversial.

2. Give a meaning to a bare ‘.lbl’. The controversy entirely surrounds what this form should mean.

I think (1) is a perfectly good proposal on its own, so I’d much prefer us to accept (1) and defer a decision on (2) over rejecting the entire proposal.

Sent from my iPhone

...
On Dec 10, 2019, at 10:26, Richard Eisenberg wrote:

Thanks for your comments!

...
On Dec 10, 2019, at 2:54 PM, Christopher Allen wrote:

This proposal should be rejected.

The contention over what whitespace around the dot operator should make it clear that even expert Haskellers aren't sure what to expect from this proposal in an intuitive way.

Then there is an easy solution: just don't allow unparenthesized .foo -- that is, make it a parse error. I don't think there is any contention over what (.foo) should mean, and if plain .foo is a parse error, then there is no fork.

...
You can achieve the same with libraries now.

True -- but at significant cost, both in the effort to learn the (complex) libraries and in the need for Template Haskell, which cannot be used in cross-compilation, for example. I think the warm reception of this proposal suggests that, despite the library-based solution, something more is wanted.

...
That the existing extensions aren't as useful as they ought as compared with using a lens library is symptomatic of half-baked proposals being incorporated into GHC.

I'm curious which proposals you're thinking of here. The strangest one, I think, is DisambiguateRecordFields. That was added before the proposals process. I don't think it would have survived the current process -- at least, not in the form in which it has appeared. I would welcome exploring ways of removing it.

...
We can wait until the juice is worth the squeeze and avoid an unforced error here.

This is tempting. But I worry that this may be the best we get, and I think inaction is hurting us.

Richard

...
...
On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via ghc-steering-committee wrote:

Dear steering committee

I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282

I recommend acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5634776...

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://github.com/ghc-proposals/ghc-proposals/pull/282 https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot- 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://github.com/ghc-proposals/ghc-proposals#committee-process 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 http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Iavor Diatchki

1:07 p.m.

Just wanted to chime in, that if we are to accept this, I also think that we should use the explicit section notation for selector functions. I don't think we should split this into multiple proposals, even though it introduces many features. In fact, for me, the most useful part of the proposal is the ability to do nested updates, which is quite orthogonal to using "dot" as a selector. On Tue, Dec 10, 2019 at 8:25 AM Joachim Breitner wrote:

...

Hi,

also, thinking about it, is (\x->x.foo) too bad? At least initially?

Maybe people come up with a nice name for (\x->x.…) (similar to “happy monkey” for (:[]) ) then maybe they will warm up to it :-)

Cheers, Joachim

...
I agree with Richard, I think it would be valuable to think of this as two separate proposals.

1. Introduce the dot syntax for projection and nested matching/update. Projection is written ‘foo.lbl’ (no white space allowed) and a bare .lbl is a syntax error. This piece seems largely uncontroversial.

2. Give a meaning to a bare ‘.lbl’. The controversy entirely surrounds what this form should mean.

I think (1) is a perfectly good proposal on its own, so I’d much prefer us to accept (1) and defer a decision on (2) over rejecting the entire proposal.

Sent from my iPhone

...
On Dec 10, 2019, at 10:26, Richard Eisenberg wrote:

Thanks for your comments!

...
On Dec 10, 2019, at 2:54 PM, Christopher Allen wrote:

This proposal should be rejected.

The contention over what whitespace around the dot operator should make it clear that even expert Haskellers aren't sure what to expect from this proposal in an intuitive way.

Then there is an easy solution: just don't allow unparenthesized .foo -- that is, make it a parse error. I don't think there is any contention over what (.foo) should mean, and if plain .foo is a parse error, then

...
...
...
You can achieve the same with libraries now.

True -- but at significant cost, both in the effort to learn the

(complex) libraries and in the need for Template Haskell, which cannot be used in cross-compilation, for example. I think the warm reception of this

...
...
...
That the existing extensions aren't as useful as they ought as compared with using a lens library is symptomatic of half-baked proposals being incorporated into GHC.

I'm curious which proposals you're thinking of here. The strangest

one, I think, is DisambiguateRecordFields. That was added before the

...
...
...
We can wait until the juice is worth the squeeze and avoid an

unforced

...
...
error here.

This is tempting. But I worry that this may be the best we get, and I

...
...
Richard

...
...
On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via ghc-steering-committee wrote:

Dear steering committee

I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282

I recommend acceptance:

https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5634776...

...
...
...
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

...
...
...
...
Thanks

Simon

...
-----Original Message----- From: ghc-steering-committee <

ghc-steering-committee-bounces@haskell.org>

...
...
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://github.com/ghc-proposals/ghc-proposals/pull/282

https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-

...
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://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with

Am Dienstag, den 10.12.2019, 11:14 -0500 schrieb Eric Seidel: there is no fork. proposal suggests that, despite the library-based solution, something more is wanted. proposals process. I don't think it would have survived the current process -- at least, not in the form in which it has appeared. I would welcome exploring ways of removing it. think inaction is hurting us. proposal has attracted a lot of interest. 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 http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

5:25 p.m.

Just wanted to chime in, that if we are to accept this, I also think that we should use the explicit section notation for selector functions. To be clear, you prefer that (.foo) is the selector function, and .foo (sans parens) is illegal? Or do you have something else in mind for .foo? Simon From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 10 December 2019 18:08 To: Joachim Breitner Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] RecordDotSyntax: please express a view Just wanted to chime in, that if we are to accept this, I also think that we should use the explicit section notation for selector functions. I don't think we should split this into multiple proposals, even though it introduces many features. In fact, for me, the most useful part of the proposal is the ability to do nested updates, which is quite orthogonal to using "dot" as a selector. On Tue, Dec 10, 2019 at 8:25 AM Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Hi, also, thinking about it, is (\x->x.foo) too bad? At least initially? Maybe people come up with a nice name for (\x->x.…) (similar to “happy monkey” for (:[]) ) then maybe they will warm up to it :-) Cheers, Joachim Am Dienstag, den 10.12.2019, 11:14 -0500 schrieb Eric Seidel:

...

I agree with Richard, I think it would be valuable to think of this as two separate proposals.

1. Introduce the dot syntax for projection and nested matching/update. Projection is written ‘foo.lbl’ (no white space allowed) and a bare .lbl is a syntax error. This piece seems largely uncontroversial.

2. Give a meaning to a bare ‘.lbl’. The controversy entirely surrounds what this form should mean.

I think (1) is a perfectly good proposal on its own, so I’d much prefer us to accept (1) and defer a decision on (2) over rejecting the entire proposal.

Sent from my iPhone

...
On Dec 10, 2019, at 10:26, Richard Eisenberg mailto:rae@richarde.dev> wrote:

Thanks for your comments!

...
On Dec 10, 2019, at 2:54 PM, Christopher Allen mailto:cma@bitemyapp.com> wrote:

This proposal should be rejected.

The contention over what whitespace around the dot operator should make it clear that even expert Haskellers aren't sure what to expect from this proposal in an intuitive way.

Then there is an easy solution: just don't allow unparenthesized .foo -- that is, make it a parse error. I don't think there is any contention over what (.foo) should mean, and if plain .foo is a parse error, then there is no fork.

...
You can achieve the same with libraries now.

True -- but at significant cost, both in the effort to learn the (complex) libraries and in the need for Template Haskell, which cannot be used in cross-compilation, for example. I think the warm reception of this proposal suggests that, despite the library-based solution, something more is wanted.

...
That the existing extensions aren't as useful as they ought as compared with using a lens library is symptomatic of half-baked proposals being incorporated into GHC.

I'm curious which proposals you're thinking of here. The strangest one, I think, is DisambiguateRecordFields. That was added before the proposals process. I don't think it would have survived the current process -- at least, not in the form in which it has appeared. I would welcome exploring ways of removing it.

...
We can wait until the juice is worth the squeeze and avoid an unforced error here.

This is tempting. But I worry that this may be the best we get, and I think inaction is hurting us.

Richard

...
...
On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote:

Dear steering committee

I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021935354&sdata=YMrBWZyrnmy%2FcJ2e5x3TAmvTo7DQamaxZu5IQzkRPS8%3D&reserved=0

I recommend acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5634776...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282%23issuecomment-563477691&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021935354&sdata=MLMWuA10JgKqndNIg2gufvvsuMxtKLTiOzHZOBScsLc%3D&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 mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Joachim Breitner Sent: 28 November 2019 10:11 To: ghc-steering-committee@haskell.orgmailto: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://github.com/ghc-proposals/ghc-proposals/pull/282 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021945348&sdata=seXtl%2FufSwR3Yx6O1KdRNTL9jn9Gdh378Dh69czXORo%3D&reserved=0 https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021955345&sdata=zc73B6VSW9yzhUlwPU7vcTVb115ZSMoOE%2FDa0APlDhE%3D&reserved=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://github.com/ghc-proposals/ghc-proposals#committee-process https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021955345&sdata=SrIQa28Rtyx7evKGUK850hI8banF7HDEiMZ%2FJjShEC4%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.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021965332&sdata=n195w9oPoKziOv7zBQ6KpPoi3NRwXYe%2BbzSxl%2FUlo1Q%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021975327&sdata=2GxTlecHJQEngX7dEd7RXbqU%2FcOud%2BuuqacsrPTdkZE%3D&reserved=0

ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021975327&sdata=2GxTlecHJQEngX7dEd7RXbqU%2FcOud%2BuuqacsrPTdkZE%3D&reserved=0

-- Chris Allen Currently working on http://haskellbook.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021985324&sdata=6LiqHhWXBwozb2Tsdmu0XF93XzNrCUf3tZEqHGa%2BqjQ%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021985324&sdata=j9JRF42QBPvEWM4ZF0quDoPFRr1TgCN2GPBXgWNKMa8%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021995336&sdata=ask0ZPCDBtLB6XkE3BeeFuTE2%2Be0QOcgkifDpNDhC7E%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022005321&sdata=Z898U%2B2wyaLpqEoSwQ8RBjgxiGkQfSoiCPL2Ftki2OE%3D&reserved=0 -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022005321&sdata=Xnqi8KguWWaNazTwElo1qfddKAyEAJR9n1UmPZ3rqk8%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022015315&sdata=qJuM%2FqqR3gFjlHh2u00murQ3Xf64n9vactZht19lDSI%3D&reserved=0

Iavor Diatchki

6:36 p.m.

I am not really sure what to do with `.foo` on its own. Probably simplest to just make it into a syntax error. On Tue, Dec 10, 2019 at 2:25 PM Simon Peyton Jones wrote:

...

Just wanted to chime in, that if we are to accept this, I also think that we should use the explicit section notation for selector functions.

To be clear, you prefer that (.foo) is the selector function, and .foo (sans parens) is illegal? Or do you have something else in mind for .foo?

Simon

*From:* ghc-steering-committee *On Behalf Of *Iavor Diatchki *Sent:* 10 December 2019 18:08 *To:* Joachim Breitner *Cc:* ghc-steering-committee *Subject:* Re: [ghc-steering-committee] RecordDotSyntax: please express a view

Just wanted to chime in, that if we are to accept this, I also think that we should use the explicit section notation for selector functions.

I don't think we should split this into multiple proposals, even though it introduces many features.

In fact, for me, the most useful part of the proposal is the ability to do nested updates, which is quite orthogonal to using "dot" as a selector.

On Tue, Dec 10, 2019 at 8:25 AM Joachim Breitner wrote:

Hi,

also, thinking about it, is (\x->x.foo) too bad? At least initially?

Maybe people come up with a nice name for (\x->x.…) (similar to “happy monkey” for (:[]) ) then maybe they will warm up to it :-)

Cheers, Joachim

...
I agree with Richard, I think it would be valuable to think of this as two separate proposals.

1. Introduce the dot syntax for projection and nested matching/update. Projection is written ‘foo.lbl’ (no white space allowed) and a bare .lbl is a syntax error. This piece seems largely uncontroversial.

2. Give a meaning to a bare ‘.lbl’. The controversy entirely surrounds what this form should mean.

I think (1) is a perfectly good proposal on its own, so I’d much prefer us to accept (1) and defer a decision on (2) over rejecting the entire proposal.

Sent from my iPhone

...
On Dec 10, 2019, at 10:26, Richard Eisenberg wrote:

Thanks for your comments!

...
On Dec 10, 2019, at 2:54 PM, Christopher Allen wrote:

This proposal should be rejected.

The contention over what whitespace around the dot operator should make it clear that even expert Haskellers aren't sure what to expect from this proposal in an intuitive way.

Then there is an easy solution: just don't allow unparenthesized .foo -- that is, make it a parse error. I don't think there is any contention over what (.foo) should mean, and if plain .foo is a parse error, then

...
...
...
You can achieve the same with libraries now.

True -- but at significant cost, both in the effort to learn the

(complex) libraries and in the need for Template Haskell, which cannot be used in cross-compilation, for example. I think the warm reception of this

...
...
...
That the existing extensions aren't as useful as they ought as compared with using a lens library is symptomatic of half-baked proposals being incorporated into GHC.

I'm curious which proposals you're thinking of here. The strangest

one, I think, is DisambiguateRecordFields. That was added before the

...
...
...
We can wait until the juice is worth the squeeze and avoid an

unforced

...
...
error here.

This is tempting. But I worry that this may be the best we get, and I

...
...
Richard

...
...
On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via ghc-steering-committee wrote:

Dear steering committee

I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021935354&sdata=YMrBWZyrnmy%2FcJ2e5x3TAmvTo7DQamaxZu5IQzkRPS8%3D&reserved=0

...
...
...
I recommend acceptance:

https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5634776... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282%23issuecomment-563477691&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021935354&sdata=MLMWuA10JgKqndNIg2gufvvsuMxtKLTiOzHZOBScsLc%3D&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

...
...
...
...
Thanks

Simon

...
-----Original Message----- From: ghc-steering-committee <

ghc-steering-committee-bounces@haskell.org>

...
...
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://github.com/ghc-proposals/ghc-proposals/pull/282 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021945348&sdata=seXtl%2FufSwR3Yx6O1KdRNTL9jn9Gdh378Dh69czXORo%3D&reserved=0

https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot- https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021955345&sdata=zc73B6VSW9yzhUlwPU7vcTVb115ZSMoOE%2FDa0APlDhE%3D&reserved=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://github.com/ghc-proposals/ghc-proposals#committee-process https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021955345&sdata=SrIQa28Rtyx7evKGUK850hI8banF7HDEiMZ%2FJjShEC4%3D&reserved=0 I suggest you make a recommendation, in a new e-mail thread with

Am Dienstag, den 10.12.2019, 11:14 -0500 schrieb Eric Seidel: there is no fork. proposal suggests that, despite the library-based solution, something more is wanted. proposals process. I don't think it would have survived the current process -- at least, not in the form in which it has appeared. I would welcome exploring ways of removing it. think inaction is hurting us. proposal has attracted a lot of interest. 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 http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021965332&sdata=n195w9oPoKziOv7zBQ6KpPoi3NRwXYe%2BbzSxl%2FUlo1Q%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021975327&sdata=2GxTlecHJQEngX7dEd7RXbqU%2FcOud%2BuuqacsrPTdkZE%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021975327&sdata=2GxTlecHJQEngX7dEd7RXbqU%2FcOud%2BuuqacsrPTdkZE%3D&reserved=0

-- Chris Allen Currently working on http://haskellbook.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021985324&sdata=6LiqHhWXBwozb2Tsdmu0XF93XzNrCUf3tZEqHGa%2BqjQ%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021985324&sdata=j9JRF42QBPvEWM4ZF0quDoPFRr1TgCN2GPBXgWNKMa8%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021995336&sdata=ask0ZPCDBtLB6XkE3BeeFuTE2%2Be0QOcgkifDpNDhC7E%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022005321&sdata=Z898U%2B2wyaLpqEoSwQ8RBjgxiGkQfSoiCPL2Ftki2OE%3D&reserved=0 -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022005321&sdata=Xnqi8KguWWaNazTwElo1qfddKAyEAJR9n1UmPZ3rqk8%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022015315&sdata=qJuM%2FqqR3gFjlHh2u00murQ3Xf64n9vactZht19lDSI%3D&reserved=0

Simon Marlow

12 Dec 12 Dec

3:40 a.m.

I'm not a huge fan of this proposal mostly due to the confusion it introduces between "a . b" and "a.b". However we already decided we didn't care too much about that when we introduced qualified names, so I think that ship has sailed. (In fact I'd rather like us to pick a different symbol for function composition, heretical a suggestion as that may be, given that we've effectively deprecated the significance . as function composition by introducing two more meanings for it). So to be clear, I am weakly in favour of acceptance. I would much prefer (.foo) to .foo for the standalone selector syntax, though. Cheers Simon On Mon, 9 Dec 2019 at 22:58, Simon Peyton Jones via ghc-steering-committee < ghc-steering-committee@haskell.org> wrote:

...

Dear steering committee

I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282

I recommend acceptance:

https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-5634776...

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://github.com/ghc-proposals/ghc-proposals/pull/282 | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot- | 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://github.com/ghc-proposals/ghc-proposals#committee-process | 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 | http://www.joachim-breitner.de/ | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

1982

Age (days ago)

1989

Last active (days ago)

List overview

Download

23 comments

9 participants

participants (9)

Christopher Allen
Eric Seidel
Iavor Diatchki
Joachim Breitner
Richard Eisenberg
Simon Marlow
Simon Peyton Jones
Spiwack, Arnaud
Vitaly Bragilevsky

RecordDotSyntax: please express a view

tags

participants (9)