[ghc-steering-committee] Modification to record dot syntax propsal
Alejandro Serrano Mena
trupill at gmail.com
Fri Mar 5 17:35:22 UTC 2021
The plan looks fine to me.
Alejandro
El El vie, 5 mar 2021 a las 18:19, Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> escribió:
> 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.
> 2. 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.
> 3. 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.
> 4. 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.
> 5. 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/70d57eb4/attachment-0001.html>
More information about the ghc-steering-committee
mailing list