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

Iavor Diatchki iavor.diatchki at gmail.com
Tue Dec 10 23:36:29 UTC 2019


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 <simonpj at microsoft.com>
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 <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>
> 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> wrote:
> > >
> > > Thanks for your comments!
> > >
> > > > On Dec 10, 2019, at 2:54 PM, Christopher Allen <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> 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>
> > > > > > On Behalf Of Joachim Breitner
> > > > > > Sent: 28 November 2019 10:11
> > > > > > To: ghc-steering-committee at haskell.org
> > > > > > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> > > > > > RecordDotSyntax, Shepherd: Simon PJ
> > > > > >
> > > > > > Dear Committee,
> > > > > >
> > > > > > this is your secretary speaking:
> > > > > >
> > > > > > RecordDotSyntax language extension proposal has been proposed by
> Neil
> > > > > > Mitchell and Shayne Fletcher
> > > > > > https://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
> > > > > >   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
> > > > > >
> 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
> > > > >
> 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
> > > >
> 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
> > >
> 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
> > 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
>   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
> 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/d88de122/attachment-0001.html>


More information about the ghc-steering-committee mailing list