<div dir="ltr">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.<div><br></div><div>I don't think we should split this into multiple proposals, even though it introduces many features.</div><div><br></div><div>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.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 10, 2019 at 8:25 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
also, thinking about it, is (\x->x.foo) too bad? At least initially?<br>
<br>
Maybe people come up with a nice name for (\x->x.…)  (similar to “happy<br>
monkey” for (:[]) ) then maybe they will warm up to it :-)<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
Am Dienstag, den 10.12.2019, 11:14 -0500 schrieb Eric Seidel:<br>
> I agree with Richard, I think it would be valuable to think of this<br>
> as two separate proposals. <br>
> <br>
> 1. Introduce the dot syntax for projection and nested<br>
> matching/update. Projection is written ‘foo.lbl’ (no white space<br>
> allowed) and a bare .lbl is a syntax error. This piece seems largely<br>
> uncontroversial. <br>
> <br>
> 2. Give a meaning to a bare ‘.lbl’. The controversy entirely<br>
> surrounds what this form should mean. <br>
> <br>
> I think (1) is a perfectly good proposal on its own, so I’d much<br>
> prefer us to accept (1) and defer a decision on (2) over rejecting<br>
> the entire proposal. <br>
> <br>
> Sent from my iPhone<br>
> <br>
> > On Dec 10, 2019, at 10:26, Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>> wrote:<br>
> > <br>
> > Thanks for your comments!<br>
> > <br>
> > > On Dec 10, 2019, at 2:54 PM, Christopher Allen <<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</a>> wrote:<br>
> > > <br>
> > > This proposal should be rejected.<br>
> > > <br>
> > > The contention over what whitespace around the dot operator should<br>
> > > make it clear that even expert Haskellers aren't sure what to expect<br>
> > > from this proposal in an intuitive way.<br>
> > <br>
> > 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.<br>
> > <br>
> > > You can achieve the same with<br>
> > > libraries now.<br>
> > <br>
> > 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.<br>
> > <br>
> > > That the existing extensions aren't as useful as they<br>
> > > ought as compared with using a lens library is symptomatic of<br>
> > > half-baked proposals being incorporated into GHC.<br>
> > <br>
> > 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.<br>
> > <br>
> > > We can wait until the juice is worth the squeeze and avoid an unforced<br>
> > > error here.<br>
> > <br>
> > This is tempting. But I worry that this may be the best we get, and I think inaction is hurting us.<br>
> > <br>
> > Richard<br>
> > <br>
> > > > On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via<br>
> > > > ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>> wrote:<br>
> > > > <br>
> > > > Dear steering committee<br>
> > > > <br>
> > > > I'm the shepherd for the RecordDotSyntax proposal.<br>
> > > > <a href="https://github.com/ghc-proposals/ghc-proposals/pull/282" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/282</a><br>
> > > > <br>
> > > > I recommend acceptance:<br>
> > > > <a href="https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691</a><br>
> > > > <br>
> > > > 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.<br>
> > > > <br>
> > > > Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion.<br>
> > > > <br>
> > > > I'd love every member of the committee to express a view.  This proposal has attracted a lot of interest.<br>
> > > > <br>
> > > > Thanks<br>
> > > > <br>
> > > > Simon<br>
> > > > <br>
> > > > > -----Original Message-----<br>
> > > > > From: ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>><br>
> > > > > On Behalf Of Joachim Breitner<br>
> > > > > Sent: 28 November 2019 10:11<br>
> > > > > To: <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > > > > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:<br>
> > > > > RecordDotSyntax, Shepherd: Simon PJ<br>
> > > > > <br>
> > > > > Dear Committee,<br>
> > > > > <br>
> > > > > this is your secretary speaking:<br>
> > > > > <br>
> > > > > RecordDotSyntax language extension proposal has been proposed by Neil<br>
> > > > > Mitchell and Shayne Fletcher<br>
> > > > > <a href="https://github.com/ghc-proposals/ghc-proposals/pull/282" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/282</a><br>
> > > > > <a href="https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-" rel="noreferrer" target="_blank">https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-</a><br>
> > > > > syntax/proposals/0000-record-dot-syntax.md<br>
> > > > > <br>
> > > > > This is going to be a tricky one. It is partly about whitespace, so it<br>
> > > > > has attracted a _lot_ of community interest, by far the most so far. To<br>
> > > > > navigate that ship, I propose Simon PJ as the shepherd, because he is a<br>
> > > > > excellent moderator and community manager, and because he has the<br>
> > > > > necessary authority to hopefully get a verdict accepted.<br>
> > > > > <br>
> > > > > Please reach consensus as described in<br>
> > > > > <a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br>
> > > > > I suggest you make a recommendation, in a new e-mail thread with the<br>
> > > > > proposal number in the subject, about the decision, maybe point out<br>
> > > > > debatable points, and assume that anyone who stays quiet agrees with you.<br>
> > > > > <br>
> > > > > Thanks,<br>
> > > > > Joachim<br>
> > > > > --<br>
> > > > > Joachim Breitner<br>
> > > > >   <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> > > > >   <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
> > > > > <br>
> > > > > _______________________________________________<br>
> > > > > ghc-steering-committee mailing list<br>
> > > > > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > > > > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> > > > _______________________________________________<br>
> > > > ghc-steering-committee mailing list<br>
> > > > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > > > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> > > <br>
> > > <br>
> > > -- <br>
> > > Chris Allen<br>
> > > Currently working on <a href="http://haskellbook.com" rel="noreferrer" target="_blank">http://haskellbook.com</a><br>
> > > _______________________________________________<br>
> > > ghc-steering-committee mailing list<br>
> > > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> > <br>
> > _______________________________________________<br>
> > ghc-steering-committee mailing list<br>
> > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> <br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>