<div dir="ltr"><div>I'm having most trouble forming an opinion on this.</div><div><br></div><div>Let me try to formulate my thoughts</div><div><br></div><div>This proposal solves</div><div><br></div><div>1. A dot syntax for record selector</div><div>2. A nested record update syntax</div><div>3. Shared record field names<br></div><div><br></div><div>This proposal doesn't address</div><div><br></div><div>4. Partial selection</div><div>5. Partial update</div><div><br></div><div>This proposal breaks</div><div><br></div><div>6. Type-changing record update</div><div>7. Polymorphic (rank 2+) fields</div><div><br></div><div>Does it balance out? <br></div><div><br></div><div>1. is nice, but honestly pretty trivial. The real reason for 1, though, is to enable 3.<br></div><div>2. is pretty cool. When you need nested update, not having syntax for it is pretty painful. It seems to be an oft repeated reason why Haskell records “suck”. That being said, how many languages don't have nested update, and of these do people complain about records “sucking”. As an example, Ocaml doesn't have nested updates, and Ocaml programmers don't complain about records. Still, pretty cool.</div><div>3. again a common complaint about Haskell records. In this respect this proposal can be seen as an improvement on what's already been done in -XDuplicateRecordFields (I don't have much of an experience with -XDuplicateRecordFields, but I believe it's an improvement); or a way to use -XNoFieldSelectors without resorting to lenses. To draw a comparison with Ocaml, again: shared record fields are a reasonably recent feature there too; it was welcome, but rather as fixing a minor inconvenience (programmers just namespaced their record fields). Maybe they are more pressing in Haskell because namespacing is less convenient. I'm not sure</div><div>4. is a rather unfortunate behaviour of Haskell's record semantic. It's not too hard to avoid its pitfalls, so it's ok</div><div>5. is more problematic. In fact, before this whole conversation started, if someone had asked me why people didn't like Haskell records, I would have told them about partial updates. So this leaves me a bit more dubious (though I also recognise that it is a hard problem to solve).</div><div>6/7. these are broken by this proposal in that the proposal removes syntax for those. In my very local experience, in record-heavy code, they are rather uncommon. So those programmers who would really like 2 and 3, are probably not the same who would be affected by this proposal. But this carries a risk: we seem to have taken the habit of being suspicious of fork-like extension. Don't 6 and 7 make this proposal fork-like? (note: 6 can probably be fixed later by adding type parameters to `HasField` (though the functional dependencies would become more subtle), I'm not sure we have any plan that would begin to address 7).</div><div><br></div><div>I wrote all that, but it hasn't helped me make an opinion. Some people are very enthusiastic about this proposal, they probably deserve that we accept. It's definitely not a bad idea. We may want to be worried about the fork-like aspects; maybe they are not that bad though.</div><div><br></div><div>As per syntax, Simon PJ's suggestions, on the github thread, sound pretty sensible to me. And I'm squarely in team (.foo) (section parentheses for usage as a function).</div><div><br></div><div>Apologies if this message wasn't useful (it probably wasn't). I'll probably stay a neutral party for the rest of this process.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 11, 2019 at 10:11 AM Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</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"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Dec 11, 2019, at 3:27 AM, Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:</div><br><div><span style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">So I think I would be happy with bare `.lbl` being a postfix operator that binds less tightly than function application.</span><br style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"></div></blockquote></div><br><div>This means that `f x .bar` is `(f x) .bar` while `f x.bar` is `f (x.bar)`. A bit too subtle for me.</div><div><br></div><div>Another alternative is to make `.foo` a postfix operator that does not associate with function application. That is, `f x .bar` would be a parse error. So we can write `x .foo .bar` to mean the same as `x.foo.bar`, but we don't have to commit to any strange parsing rules around `f a .b c .d e`.</div><div><br></div><div>But I'm starting to lean toward just making bare `.foo` a syntax error and revisit this debate with more experience.</div><div><br></div><div>Richard</div></div>_______________________________________________<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>