[ghc-steering-committee] Modification to record dot syntax propsal

[Simon Peyton Jones]

Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.

There seem to be two motivations.


  1.  There really are two orthogonal extensions, one for r.x notation, and one for overloaded update.  Iavor likes the first but not the second.  Neil likes both.  Having separate extensions lets us experiment.



  1.  You suggest that changing the definition of RecordDotSyntax in a subsequent release, e.g. by subsequently making it imply NoFieldSelectors, would be fine. But it certainly imposes pain – some programs would stop compiling.  The approach offered by this proposal avoids that problem.

Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards.  It may not be pretty to divide things up so fine, but it’s not new.


If there are alternative suggestions, let’s hear them.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
Sent: 26 February 2021 22:33
To: Iavor Diatchki <iavor.diatchki at gmail.com>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal


I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.

This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.

Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.

I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210226/df2111f6/attachment-0001.html>