[ghc-steering-committee] RecordDotSyntax: please express a view
Simon Peyton Jones
simonpj at microsoft.com
Tue Dec 10 22:25:18 UTC 2019
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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 10 December 2019 18:08
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
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 <mail at joachim-breitner.de<mailto:mail at 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 <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:
> >
> > Thanks for your comments!
> >
> > > On Dec 10, 2019, at 2:54 PM, Christopher Allen <cma at bitemyapp.com<mailto:cma at 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 <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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-563477691<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 <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>>
> > > > > On Behalf Of Joachim Breitner
> > > > > Sent: 28 November 2019 10:11
> > > > > To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> > > > > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> > > > > RecordDotSyntax, Shepherd: Simon PJ
> > > > >
> > > > > Dear Committee,
> > > > >
> > > > > this is your secretary speaking:
> > > > >
> > > > > RecordDotSyntax language extension proposal has been proposed by Neil
> > > > > Mitchell and Shayne Fletcher
> > > > > https://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 at joachim-breitner.de<mailto:mail at 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 at haskell.org<mailto:ghc-steering-committee at 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 at haskell.org<mailto:ghc-steering-committee at 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 at haskell.org<mailto:ghc-steering-committee at 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 at haskell.org<mailto:ghc-steering-committee at 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 at haskell.org<mailto:ghc-steering-committee at 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 at joachim-breitner.de<mailto:mail at 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 at haskell.org<mailto:ghc-steering-committee at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191210/0814b2c9/attachment-0001.html>
More information about the ghc-steering-committee
mailing list