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

[Iavor Diatchki]

That seems reasonable to me.

On Tue, Mar 2, 2021 at 4:46 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Friends
>
>
>
> Having consulted the authors, I propose that we do this:
>
>
>
>    - Proceed with OverloadedRecordDot for 9.2, exactly as in the original
>    proposal except for the extension name.
>    - Record update will remain exactly as now, in 9.2; that is, drawing
>    back from the original proposal.
>    - There may be some *code* in 9.2 that allows overloaded record
>    update, protected by OverloadedRecordUpdate, but not in the user manual,
>    and not treated as an accepted proposal.   I don’t think we should ask the
>    authors to remove it, and it will allow experimentation.
>    - Adam is leading on a revised record-update proposal. This will cover
>       - the tradeoffs between type-changing and non-type-changing update
>       - what the current record-update syntax stands for, and/or any new
>       syntax
>
>
>
> Is that acceptable to everyone?
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Peyton Jones via ghc-steering-committee
> *Sent:* 01 March 2021 17:51
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud <
> arnaud.spiwack at tweag.io>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
> 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>
> 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>
> 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.
>
>
>
>    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.
>
> _______________________________________________
> 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/20210302/1cf2be62/attachment-0001.html>