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

Simon Peyton Jones simonpj at microsoft.com
Thu Mar 4 15:34:46 UTC 2021 

Here's the text https://docs.google.com/document/d/1GbWAC8URaVRmj6Lkj1b10okNsVuUfO6U0qq-lrSpses/edit?usp=sharing

From: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
Sent: 04 March 2021 15:29
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Eric Seidel <eric at seidel.io>; ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal

As for my part, Simon and I had a call and he cleared up the situation for me. We came up with a piece of text that we will offer to the other to explain the motivation behind the split. I am now fine with the change.

On Thu, Mar 4, 2021 at 3:53 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
|  That being said, I don't see anything in the revised proposal about
|  the stability of OverloadedRecordUpdate. Are you saying that as part
|  of this revision, we'll explicitly accept OverloadedRecordDot and send
|  OverloadedRecordUpdate back for revision?

We *already* accepted both, as part of accepting the earlier RecordDotSyntax proposal.   But in this round, Iavor has pushed back against OverloadedRecordUpdate.  No one else has expressed a view on this point.

But rather than debate it at length I proposed to explicitly un-accept the OverloadedRecordUpdate part of the proposal.  It'll return as part of a new record-update proposal that Adam is working on.

In the meantime OverloadedRecordUpdate will be in GHC's codebase, and (assuming that's what the majority wants) documented in the user manual, with a prominent "may change" caveat.

Does that make it clear?

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org<mailto:bounces at haskell.org>> On Behalf Of Eric Seidel
|  Sent: 04 March 2021 14:38
|  To: 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 agree with Richard and Joachim that it should be documented in the
|  user guide. It's much better to document features with the expected
|  level of support than to let users stumble upon them and make their
|  own assumptions about stability.
|
|  That being said, I don't see anything in the revised proposal about
|  the stability of OverloadedRecordUpdate. Are you saying that as part
|  of this revision, we'll explicitly accept OverloadedRecordDot and send
|  OverloadedRecordUpdate back for revision?
|
|  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
|  committee wrote:
|  >
|  > Friends
|  >
|  >
|  >
|  > We've agree to accept my suggestion below.
|  >
|  >
|  >
|  > But there is one point at issue: should OverloadedRecordUpdate be
|  > documented in the user manual, albeit identified as a not-yet-
|  accepted
|  > feature?
|  >
|  >
|  >
|  >  * Richard positively wants it in the manual
|  >  * Iavor positively doesn't want it there.
|  >
|  >
|  > I don't mind either way.
|  >
|  >
|  >
|  > What do others think?  It's not a big deal, but we owe the authors a
|  > decision.  Answer by the end of the week please, and I'll make a
|  > shepherd decision based on the opinions I get.
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  >
|  >
|  > *From:* Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
|  > *Sent:* 02 March 2021 12:45
|  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
|  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
|  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
|  > syntax propsal
|  >
|  >
|  >
|  > 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<mailto: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<mailto:iavor.diatchki at gmail.com>>; Spiwack, Arnaud
|  > <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
|  > *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 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<mailto:iavor.diatchki at gmail.com>>
|  > *Sent:* 01 March 2021 17:23
|  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
|  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>;
|  > 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
|  >
|  >
|  >
|  > 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.
|  >
|  > >>
|  >
|  > >>  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<mailto: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<mailto:ghc-steering-committee at haskell.org>
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977282748%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mJwXqs%2FBs3qhnroUA%2FHLmBF8Y2hgNf8Ha65v%2BuWWotI%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&data=04%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977292739%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B7yr5Qa%2FcqrDvM6f0WeNaZt1ub3o%2Bj0SGjFeX2ASFXw%3D&reserved=0>%7C8abc00434aa94b7
|  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
|  55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9DGVl6oJc0%2BIQekuXf
|  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&reserved=0
|  >
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977302733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8851cSrXEPVuoeqJJlFtCM%2BVNJhT%2BhvPXfmTY9sm4mk%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&data=04%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977302733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=d1brPSssIphSkd1RwlnV%2Bj%2FotGv5Czxv1kYLkxBzUoE%3D&reserved=0>%7C8abc00434aa94b7
|  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
|  55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QZlV0RrRttaiDdrQNiRB
|  vUhS6il1DydPX5cyl%2BdILbI%3D&reserved=0
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto: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%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977312732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eqlY43l%2Bma8Vl3hQt6gqWmdUEkGF9xkCMbbBvcbK40w%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210304/6e90e462/attachment-0001.html>

More information about the ghc-steering-committee mailing list