<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">I've posted on GitHub (<a href="https://github.com/ghc-proposals/ghc-proposals/pull/405#issuecomment-784515926" class="">https://github.com/ghc-proposals/ghc-proposals/pull/405#issuecomment-784515926</a>). I'm unconvinced by this motivation, unfortunately.</div><div class=""><br class=""></div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 23, 2021, at 11:35 AM, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class=""><br class="">fine with acceptance. Having more fine grained extensions while we are<br class="">not 100% where the thing is going may pay off in the future, while<br class="">GHC2028 (rough guess) or Haskell2030 (who knows?) will alleviate the<br class="">pain of too fine-grained extensions.<br class=""><br class="">Cheers,<br class="">Joachim<br class=""><br class="">Am Dienstag, den 23.02.2021, 15:06 +0000 schrieb Simon Peyton Jones via<br class="">ghc-steering-committee:<br class=""><blockquote type="cite" class="">Friends<br class="">Please see this proposal #405 to split RecordDotSyntax into two extensions<br class="">It is a small modification of #282 on record dot syntax. The top comment gives links to the versions of the proposal before and after the change.<br class="">The main payload is:<br class="">Instead of RecordDotSyntax, have to independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.<br class="">I recommend acceptance of this proposal, but invite the committee’s view on one point (the final bullet below). Here is the thinking<br class="">RecordDotSyntax is the extension that we will eventually want programmers to user. It will probably ultimately imply NoFieldSelectors. But we aren’t quite ready make that choice yet. So we don’t want to specify exactly what RecordDotSyntax does yet.<br class="">So we want another, less ambitious, extension to enable record-dot syntax itself, and its desugaring into getField; and similarly for record updates.<br class="">This patch to the proposal goes just a little further, by dis-aggregating into two independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.<br class="">An alternative, if the committee prefers, would be to have a single extension (say, OverloadedRecords).<br class="">Please express your opinion. This should not take us long. (Technical and clarification questions would be best done on the Githhub thread, as always.)<br class="">Simon<br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></blockquote>-- <br class="">Joachim Breitner<br class=""> <a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a><br class=""> <a href="http://www.joachim-breitner.de/" class="">http://www.joachim-breitner.de/</a><br class=""><br class=""><br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></div></blockquote></div><br class=""></div></body></html>