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

Tue Dec 10 16:25:00 UTC 2019

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/