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

Iavor Diatchki iavor.diatchki at gmail.com
Wed Mar 3 16:12:51 UTC 2021 

I don't really know what it means for an extension to
"experimental"---aren't they all?

I'd rather not have the Update part advertised in the manual, as I do think
it's design should be reconsidered---tools are not going to trip on it, as
no one should be using it, for all practical purposes it is not there.

I am fine with leaving it in the source code of GHC, as I expect that
eventually we'll come up with a suitable design, and expect that large
parts of the implementation would be the same, so I see no reason to make
the authors remove their code, only to have to add it again later.

-Iavor

On Wed, Mar 3, 2021 at 8:05 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> In terms of actual official GHC Steering Committee business, this proposal
> is really just about changing the name of the extension from
> -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will simply
> fall short of the entire proposal. Is that accurate?
>
>
>
> Not quite.
>
>    - It replaces RecordDotSyntax with two separate extensions,
>    OverloadedRecordDot and OverloadedRecordUpdate.
>    - The second, OverloadedRecordUpdate would be advertised as
>    experimental and subject to change. (I’m totally happy with having it in
>    the user manual if that’s what everyone is happy with.)
>    - If you switch on experimental OverloadedRecordUpdate, you get the
>    whole proposal, with no falling short. But the committee has expressed some
>    second thoughts about update, hence advertising it as experimental.
>
> OK?  Only Richard, Iavor, Joachim, Arnaud have said anything on this
> thread.   I’m taking silence as assent … yell by the end of today if you
> are unhappy.  I’d like to communicate with the authors.
>
>
>
> Simon
>
>
>
> *From:* Richard Eisenberg <rae at richarde.dev>
> *Sent:* 02 March 2021 16:46
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
> I don't love having a feature that's completely unmentioned in the manual
> -- too much of a root to trip over. (For example, tooling may run into
> -XOverloadedRecordUpdate, but now has no official place to look to see what
> it is.) I'd be fine with a short section in the manual describing that an
> experimental -XOverloadedRecordUpdate extension exists, is subject to
> change, and is meant to roughly implement some part of some proposal. This
> can be done in just a few sentences, with a link to the proposal, but just
> being silent seems unhelpful to users.
>
>
>
> With that small tweak, I'm quite happy to agree with the proposal here.
>
>
>
> In terms of actual official GHC Steering Committee business, this proposal
> is really just about changing the name of the extension from
> -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will simply
> fall short of the entire proposal. Is that accurate?
>
>
>
> Richard
>
>
>
> On Mar 2, 2021, at 7:45 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
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccf65595be24d42cab2ca08d8dd9ab96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637503003928846093%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3goska4aw00W0GxIvfDOj3JCdEaQ0CB8Zowb1u5RbMo%3D&reserved=0>
>
>
> _______________________________________________
> 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/20210303/84e7e123/attachment-0001.html>

More information about the ghc-steering-committee mailing list