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

Tue Dec 10 16:14:40 UTC 2019

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