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

Thu Mar 4 09:22:16 UTC 2021

I'm really the only one pushing back here. And since time is sort of of the
essence, in this particular, I suppose that we can accept.

Still, as I said in the Github thread, I would really appreciate a more
fleshed out motivation to be documented in the proposal (in the
alternatives subsection where the authors compare one vs two extensions). A
proposal is for design documentation, and here, the design decision can
only be found in a Github thread. It would be much better if the proposal
document reflected this thread.

On Thu, Mar 4, 2021 at 2:18 AM Eric Seidel <eric at seidel.io> wrote:

> I explicitly assent to accepting this revision. I agree with Arnaud and
> Richard that the motivation feels lacking, but we have enough precedent for
> fine-grained extensions that I feel comfortable with this as an
> implementation strategy.
>
> On Wed, Mar 3, 2021, at 11:04, Simon Peyton Jones via
> ghc-steering-committee 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
> >
> _______________________________________________
> 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/20210304/fdbbc3e0/attachment-0001.html>