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

Mon Mar 1 22:03:51 UTC 2021

I agree with Arnaud about the motivation, as I expressed earlier. That said, I'm happy enough with the technical content of the "let's split the extensions", and so am happy to let this go forward. My sense is that, while we're all on the same train at the moment, different people are planning on disembarking at different stops (that is, heading for different final designs), which may cause trouble later.

As one data point, I was aware of the loss of type-changing update in the previous go-round, was disappointed about this, but felt that the proposal was good on balance. I would be sad if we renege on this point.

I do think we need to have a discussion on what the point of an extension is. Is an extension an optional feature? a way for users to express that they know what they're doing and can accept the consequences? a preview of features that will one day become on by default? I can perhaps guide that discussion, but not today. (Tomorrow is the ICFP deadline.) I do think there will be quite a range of views on this point, and these differences have cropped up on occasion.

Richard

> On Mar 1, 2021, at 12:51 PM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
> 
> I agree in principle that we can revisit decisions.   But we have to be aware that it is potentially very discouraging for proposal authors to
> propose something,
> have it extensively debated (including this very point), 
> have it accepted,
> implement it,
> and then be told that the committee has changed its mind.  That’s pretty bad from their point of view.
>  
> Still, Adam is working on a new SetField proposal, so perhaps that’s a figleaf.  I’ll consult them.
> 
> Simon
>  
>  
> From: Iavor Diatchki <iavor.diatchki at gmail.com> 
> Sent: 01 March 2021 17:23
> To: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee <ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal
>  
> Hello,
> 
>  
> 
> I think there is a strong motivation to *at least* split the extensions:  with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.
> 
>  
> 
> My preference would be to:
> 
>   1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this proposal)
> 
>   2. Treat the `.` notation part as accepted
> 
>   3. Require changes on the record update part, so that you don't have to choose between it and type changing record updates, which are quite useful, and I don't think we should aim for a Haskell without them.
> 
>  
> 
> I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
> 
>  
> 
> -Iavor
> 
>  
> 
>  
> 
>  
> 
> On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
> Simon, all,
> 
>  
> 
> After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.
> 
>  
> 
> The motivations provided by the modified Alternatives section is not much more helpful (at the risk of caricaturing a little, it basically reads: “we made two extensions rather than one because we can”). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).
> 
>  
> 
> My starting point is that:
> 
> - Additional extensions have a maintenance cost
> 
> - Additional extensions impose a cognitive burden on their use
> 
> - I expect that a new extension will break my code in the next few releases.
> 
>  
> 
> Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).
> 
>  
> 
> So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).
> 
>  
> 
> I appreciate that I'm in the minority here. Yet, I'm still unconvinced.
> 
>  
> 
> Best,
> 
> Arnaud
> 
>  
> 
> On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> 
> 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.
>  
> 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.
>  
> 
> 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 <mailto: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 <mailto:iavor.diatchki at gmail.com>>
> Cc: ghc-steering-committee <ghc-steering-committee at haskell.org <mailto: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.
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210301/52d3c918/attachment-0001.html>