Hi,
fine with acceptance. Having more fine grained extensions while we are
not 100% where the thing is going may pay off in the future, while
GHC2028 (rough guess) or Haskell2030 (who knows?) will alleviate the
pain of too fine-grained extensions.
Cheers,
Joachim
Am Dienstag, den 23.02.2021, 15:06 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
Friends
Please see this proposal #405 to split RecordDotSyntax into two extensions
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.
The main payload is:
Instead of RecordDotSyntax, have to independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.
I recommend acceptance of this proposal, but invite the committee’s view on one point (the final bullet below). Here is the thinking
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.
So we want another, less ambitious, extension to enable record-dot syntax itself, and its desugaring into getField; and similarly for record updates.
This patch to the proposal goes just a little further, by dis-aggregating into two independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.
An alternative, if the committee prefers, would be to have a single extension (say, OverloadedRecords).
Please express your opinion. This should not take us long. (Technical and clarification questions would be best done on the Githhub thread, as always.)
Simon
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
--
Joachim Breitner
mail@joachim-breitner.de http://www.joachim-breitner.de/_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.orghttps://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee