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

Alejandro Serrano Mena trupill at gmail.com
Fri Mar 5 17:45:36 UTC 2021


I haven’t talked too much because I did not follow the original discussion
in depth. However, a change of what record syntax can do seems undesirable
to me, too; and I think just the “getter” part is an improvements over the
current status quo. So I am happy with Simon’s wording of the situation.

Alejandro

El El vie, 5 mar 2021 a las 18:36, Richard Eisenberg <rae at richarde.dev>
escribió:

> I have one disagreement with what Simon says below:
>
>
>    1. However, the loss of type-changing updates is a real concern, so
>    the committee want to express doubt about the OverloadedRecordUpdate part,
>    even though we previously accepted it.   Sorry about that.  It’s a change
>    in our stance.
>
>
> I don't see this result from this thread. Instead, I see that one member
> of the committee has expressed doubt about this. This is a valid concern
> and one that we could continue to discuss, but I don't feel comfortable
> stating that the "committee" expresses doubt. If there are others on the
> committee who share similar doubts and want to un-accept part of the
> original proposal, please speak up -- I may have misread the room.
> Otherwise, I don't think this point accurately represents the discussion we
> have had here.
>
> I'm happy with the other points.
>
> Thanks,
> Richard
>
> On Mar 5, 2021, at 12:19 PM, Simon Peyton Jones via ghc-steering-committee
> <ghc-steering-committee at haskell.org> wrote:
>
> So, why the hurry to add this to GHC now, when we know from experience how
> painful it is to remove things, once they are out in the wild?
> I thought had agreed the following:
>
>    1. We accept the proposal.
>
>
>    1. It’s fine for the authors to continue with the implementation.  If
>    OverloadedRecordUpdate in GHC’s code base, it should be documented in the
>    user manual.  They should signal in that documentation that this part of
>    the design may well change in the future, so it would be inadvisable to
>    start using it for long-lived libraries.
>    2. Arnaud wanted clarification in Alternatives, section 7.7.   To
>    avoid confusion about what “clarify” means, Arnaud and I drafted this
>    <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1GbWAC8URaVRmj6Lkj1b10okNsVuUfO6U0qq-lrSpses%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C2f00be7cdc504b92fcc708d8df229562%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504686911684988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bWQMb8whuhbQamUYbMReDvrCEjhJtX1oG2tQZcCwE6k%3D&reserved=0>.
>    They have already adopted this wording.
>    3. We’ll look forward to a new record-update proposal soon, which Adam
>    is working on.
>
> I think this is fine.   We discussed the original proposal for months, and
> this modification draws back on that accepted proposal, and so should be
> even easier to agree.
>
> Please yell now (today) if you really think this is a mistake.  I have
> checked with the authors and this is acceptable to them.  I think if we say
> no, we want to back to the drawing board for the entire design they’ll just
> give up, and with some justification.
>
> OK?
>
> Simon
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org
> > *On Behalf Of *Iavor Diatchki
> *Sent:* 05 March 2021 16:03
> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>; ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
> I find that this committee is having less and less technical discussion on
> concrete issues, and there is a lot of talk of process, rules, and
> definitions, that I do not find useful.
>
>
>
> It is extremely difficult to anticipate all aspects of a design without
> implementing it and using it for a while, so I completely disagree that we
> should not revisit accepted proposals.
>
>
>
> While "experimental" extensions are totally fine in my book, I really do
> think we should avoid intentionally introducing things that we know now are
> likely to change.   The overloaded records update is such an extension: it
> changes a useful, standardized, and in my experience, not uncommonly used
> feature, into a less general version (in one dimension, anyway).
> Furthermore, we are aware that there is already work by Adam to address
> this, so the extension will likely change (or perhaps we are going to have
> yet another record related extension).
>
>
>
> So, why the hurry to add this to GHC now, when we know from experience how
> painful it is to remove things, once they are out in the wild?
>
> On Fri, Mar 5, 2021, 02:50 Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> Iavor,
>
>
>
> I concur with Simon and Eric. Accepting a proposal is a promise that the
> proposal will not be debated on the design front in the future. That is,
> when the implementation comes up it is out of scope to discuss design.
> That's the deal. GHC proposals are a process. The goal of this process is
> to foster participation of the wider community to the evolution of GHC, by
> reducing stress and uncertainty, and focusing productivity. This is why
> changing the design of an accepted proposal requires another proposal,
> submitted to the same level of scrutiny as the original proposal. Even, and
> in particular, by members of the steering committee.
>
>
>
> In this particular case, the authors have agreed to the change, and this
> is something that we feel is important enough to press forward quickly. So
> in the interest of everybody's time, I suggest that we move on. But,
> generally, the point stands.
>
>
>
> /Arnaud
>
>
>
> On Thu, Mar 4, 2021 at 8:45 PM Eric Seidel <eric at seidel.io> wrote:
>
> I agree it’s more important to get things right than to look good, but we
> should aim to do both of course. As Simon mentioned earlier, this will
> erode the community’s confidence if it happens too often. So I’m ok with
> reversing our decision on this point (happily it sounds like there’s
> already work underway on an improved design), but I think we should reflect
> on why we didn’t have this discussion back when we were discussing the
> original proposal.
>
> Sent from my iPhone
>
>
>
> On Mar 4, 2021, at 14:04, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
>
> 
>
> Bad look or not, it seems better to me to change our mind than accept
> something "to save face" :)     It seems hard to imagine that I am the only
> one here who uses type changing updates in records.  How are other members
> of the committee reconciling this change?   Are you planning to change your
> code to use record wild cards as Neil suggested---this seems a lot worse
> than the status quo? Or is the plan the plan to just fork the language and
> use the pragma to disambiguate?
>
>
>
> I don't mind if the extension is in GHC's code, but I think that if we add
> it to the GHC manual, people will use it, and it will be a much bigger deal
> to change later.
>
>
>
> On Thu, Mar 4, 2021 at 9:59 AM Eric Seidel <eric at seidel.io> wrote:
>
> Yes that clears up the current situation. And from the current email chain
> it looks like the authors are aware of the plan to send record updates back
> for revision? I'd just want to make sure that the updated proposal reflects
> that split on which parts have been accepted.
>
> For what it's worth, I do recall the loss of type-changing update being
> part of the original proposal and thought the proposal was still good on
> balance. The tradeoffs were definitely discussed in the giant Github
> thread, I don't recall if we discussed that aspect here though..
> Regardless, I think it's a bad look for us to walk back a decision on
> account of not having read the proposal closely enough!
>
> On Thu, Mar 4, 2021, at 09:53, Simon Peyton Jones 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> On Behalf Of Eric Seidel
> > |  Sent: 04 March 2021 14:38
> > |  To: 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>
> > |  > *Sent:* 02 March 2021 12:45
> > |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > |  > *Cc:* Simon Peyton Jones <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> *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://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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335600745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s8rfn2SfP1OFefRGDsd%2FmqTI%2FLu3z7qMkFNhZBlZDbc%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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335610744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0iayJnlnpm5mchQpMmPgRY5bw2t%2FSrHkYmfnXamfgjQ%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
> > |
> 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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335620741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ba9awmAYQ%2BPEtLYOlw2Mu8irB%2FGwmvv2OM30ofAMCmA%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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335620741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BikTVk4HLF4Gey%2BgOoWnbhGKbYhUADxIfZNAzEBtFp8%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
> 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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%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
> <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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%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/20210305/46eec740/attachment-0001.html>


More information about the ghc-steering-committee mailing list