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

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 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 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-5634776...

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 | 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://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@joachim-breitner.de | http://www.joachim-breitner.de/ | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee