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

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