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

Tue Dec 10 18:07:53 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.

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
> > > > >
> > > > > I recommend acceptance:
> > > > >
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691
> > > > >
> > > > > 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://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 at joachim-breitner.de
> > > > > >   http://www.joachim-breitner.de/
> > > > > >
> > > > > > _______________________________________________
> > > > > > ghc-steering-committee mailing list
> > > > > > ghc-steering-committee at haskell.org
> > > > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > > _______________________________________________
> > > > > ghc-steering-committee mailing list
> > > > > ghc-steering-committee at 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 at haskell.org
> > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191210/7c46329a/attachment-0001.html>