From arnaud.spiwack at tweag.io Thu May 2 06:56:51 2024 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Thu, 2 May 2024 08:56:51 +0200 Subject: [ghc-steering-committee] Proposal #631: Set program exit code by main return type, recommendation: accept something In-Reply-To: References: Message-ID: With the change of definition for 4, I'm leaving the votes open until tomorrow (Friday). I'll tally the vote Friday European afternoon (I want to post a decision on Github before the end of the week, because I'm off all week next week). On Tue, 30 Apr 2024 at 14:38, Arnaud Spiwack wrote: > Moritz, > > No worries. Take good care of yourself. > > On Tue, 30 Apr 2024 at 14:37, Moritz Angermann > wrote: > >> Dear friends, >> >> I ask to abstain from this vote, as I’m experiencing some medical issues, >> which require my full attention right now. >> >> Thank you! >> >> Best, >> Moritz >> >> On Tue, 30 Apr 2024 at 8:20 PM, Arnaud Spiwack >> wrote: >> >>> On Mon, 29 Apr 2024 at 17:58, Simon Peyton Jones < >>> simon.peytonjones at gmail.com> wrote: >>> >>>> Actually I didn't say anything about warnings when suggesting (4). If >>>> we adopted (4) *we'd surely want a warning like (2) when main returns >>>> a type other than (), Void, or ExitCode*. So I'm going to vote on >>>> that basis >>>> >>> >>> Argl! My misunderstanding, sorry. >>> >>> Would anyone change their vote if we change 4 to: -XNoWombat: 00WWWN / >>> -XWombat 00IWWN]? I believe Malte will. Anyone else? >>> >>> (For 3a, I did specify that -XWombat gives errors on types which aren't >>> instances of ExitStatus) >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io. > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu May 2 13:05:07 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 2 May 2024 14:05:07 +0100 Subject: [ghc-steering-committee] Please review #641: Wildcard binders in type declarations In-Reply-To: <9833566f-e73a-40fd-9a13-0b2e645b59a9@well-typed.com> References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com> <9833566f-e73a-40fd-9a13-0b2e645b59a9@well-typed.com> Message-ID: > > 1. If the proposed amendment is rejected, we /still/ have to change > template-haskell to implement 425 in its current form. The specification > allows invisible wildcards `@_`, which can't be represented in > template-haskell at the moment. So I'd like to ask voting members to take > that into consideration: this is not an "unforced change" because there is > a change coming either way. Are you sure? We could, if we chose, just (continue to) not support "_" in TH. People generating TH code can always use a fresh variable instead. I'm still leaning towards "do nothing"; and if we don't want that, then "do the minimum" (ie the non-recursive form). We have so much complexity already, I don't want to add more. Simon PS sorry to be slow on this On Mon, 22 Apr 2024 at 21:26, Adam Gundry wrote: > I find Vlad's argument convincing: if we are already adding support for > @_ then at the very least it's worth adding _ at the same time, and it > seems to involve no more breakage or implementation cost than #425 > unamended. So I vote to accept. > > I'm on the fence as to whether to prefer the recursive version (more > general and consistent with term syntax) or the non-recursive version > (since it is simpler, and in practice the more general forms seem > unlikely to be useful). > > Adam > > > On 19/04/2024 17:17, Vladislav Zavialov wrote: > > That's exactly right. We are not choosing between change / no change, we > > are choosing between three possible changes: > > > > 1. Current proposal: only add support for @_ > > 2. Amendment sans recursion (if revised): add support for @_, @(_ :: k), > > _, and (_ :: k) > > 3. Amendment with recursion: add support for arbitrary combinations > > of @, _, ::, and ( ... ) > > > > It's going to be breaking in all three scenarios, unless we come up with > > a compatibility layer using pattern synonyms as Adam suggests (I have > > not investigated the feasibility of that). > > > > Vlad > > > > On Fri, Apr 19, 2024 at 5:59 PM Malte Ott > > wrote: > > > > Thanks for the input Vlad. Regarding the breaking change to TH: > > Do I understand you correctly that the required changes from 425 > > have not landed > > in 9.10 and therefor accepting this proposal will not create anymore > > breakage, > > even between 9.10 and 9.12? > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > 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: From vlad.z.4096 at gmail.com Thu May 2 13:34:53 2024 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Thu, 2 May 2024 15:34:53 +0200 Subject: [ghc-steering-committee] Please review #641: Wildcard binders in type declarations In-Reply-To: References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com> <9833566f-e73a-40fd-9a13-0b2e645b59a9@well-typed.com> Message-ID: > We could, if we chose, just (continue to) not support "_" in TH. Do you mean supporting the feature in GHC but not in TH? E.g. if the programmer uses a TH quotation [d| type T @_ = ... |], the generated AST would actually be equivalent to [d| type T @_w1 = ... |] where _w1 is a fresh name? I think it'd be mostly fine, though it would be a lossy conversion, so if the user attempts to preprocess the TH AST before splicing it, they might be surprised to find that their wildcard is no longer a wildcard. In other words, the TH AST is not only produced but also sometimes consumed by user-written code, so I err on the side of representing things exactly rather than via an encoding. I'm not thrilled about taking such shortcuts because they tend to bite back later, but yes, it could work. > I'm still leaning towards "do nothing" By "do nothing" do you mean not implementing @_ which is already in the proposal? This would correspond to "do nothing" in implementation terms, but that'd be a conscious deviation from the spec. The intellectually honest thing to do in that case would be to update the spec to reflect this choice. So the proposal is no good in its current form: it is rather inconsistent to have @_ but not _. We need an amendment, but the question is which amendment: to add syntax or to remove it. Maybe your counterproposal is to remove @_ from the proposal? That would bring the spec in sync with the current impl. Vlad On Thu, May 2, 2024 at 3:05 PM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > 1. If the proposed amendment is rejected, we /still/ have to change >> template-haskell to implement 425 in its current form. The specification >> allows invisible wildcards `@_`, which can't be represented in >> template-haskell at the moment. So I'd like to ask voting members to take >> that into consideration: this is not an "unforced change" because there is >> a change coming either way. > > > Are you sure? We could, if we chose, just (continue to) not support "_" > in TH. People generating TH code can always use a fresh variable instead. > > I'm still leaning towards "do nothing"; and if we don't want that, then > "do the minimum" (ie the non-recursive form). We have so much complexity > already, I don't want to add more. > > Simon > > PS sorry to be slow on this > > > On Mon, 22 Apr 2024 at 21:26, Adam Gundry wrote: > >> I find Vlad's argument convincing: if we are already adding support for >> @_ then at the very least it's worth adding _ at the same time, and it >> seems to involve no more breakage or implementation cost than #425 >> unamended. So I vote to accept. >> >> I'm on the fence as to whether to prefer the recursive version (more >> general and consistent with term syntax) or the non-recursive version >> (since it is simpler, and in practice the more general forms seem >> unlikely to be useful). >> >> Adam >> >> >> On 19/04/2024 17:17, Vladislav Zavialov wrote: >> > That's exactly right. We are not choosing between change / no change, >> we >> > are choosing between three possible changes: >> > >> > 1. Current proposal: only add support for @_ >> > 2. Amendment sans recursion (if revised): add support for @_, @(_ :: >> k), >> > _, and (_ :: k) >> > 3. Amendment with recursion: add support for arbitrary combinations >> > of @, _, ::, and ( ... ) >> > >> > It's going to be breaking in all three scenarios, unless we come up >> with >> > a compatibility layer using pattern synonyms as Adam suggests (I have >> > not investigated the feasibility of that). >> > >> > Vlad >> > >> > On Fri, Apr 19, 2024 at 5:59 PM Malte Ott > > > wrote: >> > >> > Thanks for the input Vlad. Regarding the breaking change to TH: >> > Do I understand you correctly that the required changes from 425 >> > have not landed >> > in 9.10 and therefor accepting this proposal will not create anymore >> > breakage, >> > even between 9.10 and 9.12? >> >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, https://www.well-typed.com/ >> >> Registered in England & Wales, OC335890 >> 27 Old Gloucester Street, London WC1N 3AX, England >> >> _______________________________________________ >> 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: From simon.peytonjones at gmail.com Thu May 2 17:16:11 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 2 May 2024 18:16:11 +0100 Subject: [ghc-steering-committee] Please review #641: Wildcard binders in type declarations In-Reply-To: References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com> <9833566f-e73a-40fd-9a13-0b2e645b59a9@well-typed.com> Message-ID: By "do nothing" do you mean not implementing @_ which is already in the proposal? Sorry to be ambiguous. I mean that the GHC Steering Committee does nothing -- i.e. leaves the spec as-is. So then it still has to be implemented. So the proposal is no good in its current form: it is rather inconsistent to have @_ but not _. Ah, I had not realised that. Thanks for pointing it out. I have responded on the discussion thread (this committee thread is too easily lost/missed.) Simon On Thu, 2 May 2024 at 14:35, Vladislav Zavialov wrote: > > We could, if we chose, just (continue to) not support "_" in TH. > > Do you mean supporting the feature in GHC but not in TH? E.g. if the > programmer uses a TH quotation [d| type T @_ = ... |], the generated AST > would actually be equivalent to [d| type T @_w1 = ... |] where _w1 is a > fresh name? I think it'd be mostly fine, though it would be a lossy > conversion, so if the user attempts to preprocess the TH AST before > splicing it, they might be surprised to find that their wildcard is no > longer a wildcard. In other words, the TH AST is not only produced but also > sometimes consumed by user-written code, so I err on the side of > representing things exactly rather than via an encoding. > > I'm not thrilled about taking such shortcuts because they tend to bite > back later, but yes, it could work. > > > I'm still leaning towards "do nothing" > > By "do nothing" do you mean not implementing @_ which is already in the > proposal? This would correspond to "do nothing" in implementation terms, > but that'd be a conscious deviation from the spec. The intellectually > honest thing to do in that case would be to update the spec to reflect this > choice. So the proposal is no good in its current form: it is rather > inconsistent to have @_ but not _. We need an amendment, but the question > is which amendment: to add syntax or to remove it. Maybe your > counterproposal is to remove @_ from the proposal? That would bring the > spec in sync with the current impl. > > Vlad > > On Thu, May 2, 2024 at 3:05 PM Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> 1. If the proposed amendment is rejected, we /still/ have to change >>> template-haskell to implement 425 in its current form. The specification >>> allows invisible wildcards `@_`, which can't be represented in >>> template-haskell at the moment. So I'd like to ask voting members to take >>> that into consideration: this is not an "unforced change" because there is >>> a change coming either way. >> >> >> Are you sure? We could, if we chose, just (continue to) not support "_" >> in TH. People generating TH code can always use a fresh variable instead. >> >> I'm still leaning towards "do nothing"; and if we don't want that, then >> "do the minimum" (ie the non-recursive form). We have so much complexity >> already, I don't want to add more. >> >> Simon >> >> PS sorry to be slow on this >> >> >> On Mon, 22 Apr 2024 at 21:26, Adam Gundry wrote: >> >>> I find Vlad's argument convincing: if we are already adding support for >>> @_ then at the very least it's worth adding _ at the same time, and it >>> seems to involve no more breakage or implementation cost than #425 >>> unamended. So I vote to accept. >>> >>> I'm on the fence as to whether to prefer the recursive version (more >>> general and consistent with term syntax) or the non-recursive version >>> (since it is simpler, and in practice the more general forms seem >>> unlikely to be useful). >>> >>> Adam >>> >>> >>> On 19/04/2024 17:17, Vladislav Zavialov wrote: >>> > That's exactly right. We are not choosing between change / no change, >>> we >>> > are choosing between three possible changes: >>> > >>> > 1. Current proposal: only add support for @_ >>> > 2. Amendment sans recursion (if revised): add support for @_, @(_ :: >>> k), >>> > _, and (_ :: k) >>> > 3. Amendment with recursion: add support for arbitrary combinations >>> > of @, _, ::, and ( ... ) >>> > >>> > It's going to be breaking in all three scenarios, unless we come up >>> with >>> > a compatibility layer using pattern synonyms as Adam suggests (I have >>> > not investigated the feasibility of that). >>> > >>> > Vlad >>> > >>> > On Fri, Apr 19, 2024 at 5:59 PM Malte Ott >> > > wrote: >>> > >>> > Thanks for the input Vlad. Regarding the breaking change to TH: >>> > Do I understand you correctly that the required changes from 425 >>> > have not landed >>> > in 9.10 and therefor accepting this proposal will not create >>> anymore >>> > breakage, >>> > even between 9.10 and 9.12? >>> >>> >>> -- >>> Adam Gundry, Haskell Consultant >>> Well-Typed LLP, https://www.well-typed.com/ >>> >>> Registered in England & Wales, OC335890 >>> 27 Old Gloucester Street, London WC1N 3AX, England >>> >>> _______________________________________________ >>> 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: From arnaud.spiwack at tweag.io Fri May 3 13:29:20 2024 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Fri, 3 May 2024 15:29:20 +0200 Subject: [ghc-steering-committee] Proposal #631: Set program exit code by main return type, recommendation: accept something In-Reply-To: References: Message-ID: As it turns out. 3a wins in the votes as currently laid out. But changing Malte's vote to 4 first makes 4 the winner. Since it's my understanding that if warnings are added Malte prefers 4. I'll ask Shea to modify his proposal to 4. On Thu, 2 May 2024 at 08:56, Arnaud Spiwack wrote: > With the change of definition for 4, I'm leaving the votes open until > tomorrow (Friday). I'll tally the vote Friday European afternoon (I want to > post a decision on Github before the end of the week, because I'm off all > week next week). > > On Tue, 30 Apr 2024 at 14:38, Arnaud Spiwack > wrote: > >> Moritz, >> >> No worries. Take good care of yourself. >> >> On Tue, 30 Apr 2024 at 14:37, Moritz Angermann < >> moritz.angermann at gmail.com> wrote: >> >>> Dear friends, >>> >>> I ask to abstain from this vote, as I’m experiencing some medical >>> issues, which require my full attention right now. >>> >>> Thank you! >>> >>> Best, >>> Moritz >>> >>> On Tue, 30 Apr 2024 at 8:20 PM, Arnaud Spiwack >>> wrote: >>> >>>> On Mon, 29 Apr 2024 at 17:58, Simon Peyton Jones < >>>> simon.peytonjones at gmail.com> wrote: >>>> >>>>> Actually I didn't say anything about warnings when suggesting (4). If >>>>> we adopted (4) *we'd surely want a warning like (2) when main returns >>>>> a type other than (), Void, or ExitCode*. So I'm going to vote on >>>>> that basis >>>>> >>>> >>>> Argl! My misunderstanding, sorry. >>>> >>>> Would anyone change their vote if we change 4 to: -XNoWombat: 00WWWN / >>>> -XWombat 00IWWN]? I believe Malte will. Anyone else? >>>> >>>> (For 3a, I did specify that -XWombat gives errors on types which aren't >>>> instances of ExitStatus) >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>> >> >> -- >> Arnaud Spiwack >> Director, Research at https://moduscreate.com and https://tweag.io. >> > > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io. > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From malte.ott at maralorn.de Fri May 3 13:36:29 2024 From: malte.ott at maralorn.de (Malte Ott) Date: Fri, 3 May 2024 15:36:29 +0200 Subject: [ghc-steering-committee] Proposal #631: Set program exit code by main return type, recommendation: accept something In-Reply-To: References: Message-ID: <4m7yuxjfdqht3pjapeeaxswwpw2o62b6o2xw46v3kkfhwqgr2n@hera.m-0.eu> I agree with this plan of action, althougn I have no strong opinion about 3a vs. 4. On 2024-05-03 15:29, Arnaud Spiwack wrote: > As it turns out. 3a wins in the votes as currently laid out. But changing > Malte's vote to 4 first makes 4 the winner. Since it's my understanding > that if warnings are added Malte prefers 4. I'll ask Shea to modify his > proposal to 4. > > On Thu, 2 May 2024 at 08:56, Arnaud Spiwack wrote: > > > With the change of definition for 4, I'm leaving the votes open until > > tomorrow (Friday). I'll tally the vote Friday European afternoon (I want to > > post a decision on Github before the end of the week, because I'm off all > > week next week). > > > > On Tue, 30 Apr 2024 at 14:38, Arnaud Spiwack > > wrote: > > > >> Moritz, > >> > >> No worries. Take good care of yourself. > >> > >> On Tue, 30 Apr 2024 at 14:37, Moritz Angermann < > >> moritz.angermann at gmail.com> wrote: > >> > >>> Dear friends, > >>> > >>> I ask to abstain from this vote, as I’m experiencing some medical > >>> issues, which require my full attention right now. > >>> > >>> Thank you! > >>> > >>> Best, > >>> Moritz > >>> > >>> On Tue, 30 Apr 2024 at 8:20 PM, Arnaud Spiwack > >>> wrote: > >>> > >>>> On Mon, 29 Apr 2024 at 17:58, Simon Peyton Jones < > >>>> simon.peytonjones at gmail.com> wrote: > >>>> > >>>>> Actually I didn't say anything about warnings when suggesting (4). If > >>>>> we adopted (4) *we'd surely want a warning like (2) when main returns > >>>>> a type other than (), Void, or ExitCode*. So I'm going to vote on > >>>>> that basis > >>>>> > >>>> > >>>> Argl! My misunderstanding, sorry. > >>>> > >>>> Would anyone change their vote if we change 4 to: -XNoWombat: 00WWWN / > >>>> -XWombat 00IWWN]? I believe Malte will. Anyone else? > >>>> > >>>> (For 3a, I did specify that -XWombat gives errors on types which aren't > >>>> instances of ExitStatus) > >>>> _______________________________________________ > >>>> ghc-steering-committee mailing list > >>>> ghc-steering-committee at haskell.org > >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > >>>> > >>> > >> > >> -- > >> Arnaud Spiwack > >> Director, Research at https://moduscreate.com and https://tweag.io. > >> > > > > > > -- > > Arnaud Spiwack > > Director, Research at https://moduscreate.com and https://tweag.io. > > > > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From simon.peytonjones at gmail.com Fri May 3 21:06:14 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 3 May 2024 22:06:14 +0100 Subject: [ghc-steering-committee] Please review #641: Wildcard binders in type declarations In-Reply-To: References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com> Message-ID: Dear Steering Committee Vlad proposes to amend proposal #425 > to > permit more wildcard binder forms in type declarations: > > https://github.com/ghc-proposals/ghc-proposals/pull/641 > You may find it easiest to look at the rich diff We have since exchanged some email, and I invite you to look at my latest post on the ticket, namely: https://github.com/ghc-proposals/ghc-proposals/pull/641#issuecomment-2091099038 In the light of these exchanges I'd like to modify my previous recommendation of "reject/park". I now propose: - Add wildcards to *all* binders in type declarations, not just @_. - Allow kind annotations for wildcards These changes just fill out the design of #425 in two obvious ways. In particular: data T1 @_ = MkT1 -- Allowed by #425 data T2 @(_::Nat) = MkT2 -- Not currently allowed by #425 data T3 _ = MkT3 -- Not currently allowed by #425 data T4 (_ :: Nat) = MkT4 -- Not currently allowed by #425 HoweverI propose that we reject - Do all this recursively - Make changes to Template Haskell There is no obvious user need for data T2 @((k::Nat)::Nat) = MkT2 New recursive structures just add (modest but palpable) complexity to the specification and to the implementation. It is a cost without (so far as I can see) a user need or tangible benefit. As to Template Haskell, neither #425 nor the above enhancement forces us to make a change to TH. Currently binders in TH data type declarations cannot have wildcards. There is no pressing reason to introduce them: one can always use a type variable instead. And our General Rules ask us to avoid making breaking changes without a strong reason to do so. Perhaps we might enhance TH as part of a subsequent, bigger upheaval of TH syntax. But not now. None of this is a terribly big deal. Unless anyone objects strenuously I propose to make this our decision and move on. It's always possible to do more later if there is a user need. If you want to object to this proposal, please do so by the end of Weds 8th May. Thanks! Simon Simon On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Dear Steering Committee > > Vlad proposes to amend proposal #425 > to > permit more wildcard binder forms in type declarations: > https://github.com/ghc-proposals/ghc-proposals/pull/641 > > You may find it easiest to look at the rich diff > > . > > This is a pretty small generalisation which would allow > > data T (( (a :: k1) :: k2)) = ... > > in which the binder has multiple kind signatures and redundant parens. > The change is *not driven by user need*, but rather solely by *uniformity*: > these same forms are permitted in function definitions: > > f :: forall (a :: k). blah > f @(((a::k1)::k2))) = ... > > is permitted. > > It imposes a change on Template Haskell syntax too. > > The implementation becomes a bit more complicated; more recursive data > types, etc. Nothing hard, but more. > > It's not a big deal either way. Very few people expressed a view on > GitHub. My personal view is that the modest (albeit non-zero) gain does > not justify the definite (albeit modest) pain. I would leave this until > someone actually wants it. > > Vlad argues for future-proofing, but my experience is that an eye to the > future is sensible when you are making changes anyway; but making unforced > changes solely for the future risks incurring pain now that, when the > future comes, turns out to have been a poor investment. We may have > correctly anticipated, or we may not. > > So my recommendation is to park this until we get a real user demand. > > It's a perfectly sensible proposal, but adopting it is a judgement call. > I'll leave a week for committee responses, and then we can just vote. > > Simon > > On Thu, 21 Mar 2024 at 08:07, Adam Gundry wrote: > >> Dear Committee, >> >> Vlad proposes to amend proposal #425 to permit more wildcard binder >> forms in type declarations: >> >> https://github.com/ghc-proposals/ghc-proposals/pull/641 >> >> I'd like to nominate Simon PJ as the shepherd. >> >> Please guide us to a conclusion as outlined in >> https://github.com/ghc-proposals/ghc-proposals#committee-process >> >> Cheers, >> >> Adam >> >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, https://www.well-typed.com/ >> >> Registered in England & Wales, OC335890 >> 27 Old Gloucester Street, London WC1N 3AX, England >> _______________________________________________ >> 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: From mpg at mpg.is Fri May 3 23:44:46 2024 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Sat, 4 May 2024 01:44:46 +0200 Subject: [ghc-steering-committee] Please review #641: Wildcard binders in type declarations In-Reply-To: References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com> Message-ID: This looks cleaner. No objections here. On Fri, 3 May 2024 at 23:06, Simon Peyton Jones wrote: > Dear Steering Committee > > Vlad proposes to amend proposal #425 >> to >> permit more wildcard binder forms in type declarations: >> >> https://github.com/ghc-proposals/ghc-proposals/pull/641 >> > You may find it easiest to look at the rich diff > > > > We have since exchanged some email, and I invite you to look at my latest > post on the ticket, namely: > > https://github.com/ghc-proposals/ghc-proposals/pull/641#issuecomment-2091099038 > > In the light of these exchanges I'd like to modify my previous > recommendation of "reject/park". I now propose: > > - Add wildcards to *all* binders in type declarations, not just @_. > - Allow kind annotations for wildcards > > These changes just fill out the design of #425 in two obvious ways. In > particular: > > data T1 @_ = MkT1 -- Allowed by #425 > data T2 @(_::Nat) = MkT2 -- Not currently allowed by #425 > data T3 _ = MkT3 -- Not currently allowed by #425 > data T4 (_ :: Nat) = MkT4 -- Not currently allowed by #425 > > HoweverI propose that we reject > > - Do all this recursively > - Make changes to Template Haskell > > There is no obvious user need for > data T2 @((k::Nat)::Nat) = MkT2 > New recursive structures just add (modest but palpable) complexity to the > specification and to the implementation. It is a cost without (so far as I > can see) a user need or tangible benefit. > > As to Template Haskell, neither #425 nor the above enhancement forces us > to make a change to TH. Currently binders in TH data type declarations > cannot have wildcards. There is no pressing reason to introduce them: one > can always use a type variable instead. And our General Rules ask us to > avoid making breaking changes without a strong reason to do so. > > Perhaps we might enhance TH as part of a subsequent, bigger upheaval of TH > syntax. But not now. > > None of this is a terribly big deal. Unless anyone objects strenuously I > propose to make this our decision and move on. It's always possible to do > more later if there is a user need. > > If you want to object to this proposal, please do so by the end of Weds > 8th May. Thanks! > > Simon > > Simon > > On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> Dear Steering Committee >> >> Vlad proposes to amend proposal #425 >> to >> permit more wildcard binder forms in type declarations: >> https://github.com/ghc-proposals/ghc-proposals/pull/641 >> >> You may find it easiest to look at the rich diff >> >> . >> >> This is a pretty small generalisation which would allow >> >> data T (( (a :: k1) :: k2)) = ... >> >> in which the binder has multiple kind signatures and redundant parens. >> The change is *not driven by user need*, but rather solely by >> *uniformity*: these same forms are permitted in function definitions: >> >> f :: forall (a :: k). blah >> f @(((a::k1)::k2))) = ... >> >> is permitted. >> >> It imposes a change on Template Haskell syntax too. >> >> The implementation becomes a bit more complicated; more recursive data >> types, etc. Nothing hard, but more. >> >> It's not a big deal either way. Very few people expressed a view on >> GitHub. My personal view is that the modest (albeit non-zero) gain does >> not justify the definite (albeit modest) pain. I would leave this until >> someone actually wants it. >> >> Vlad argues for future-proofing, but my experience is that an eye to the >> future is sensible when you are making changes anyway; but making unforced >> changes solely for the future risks incurring pain now that, when the >> future comes, turns out to have been a poor investment. We may have >> correctly anticipated, or we may not. >> >> So my recommendation is to park this until we get a real user demand. >> >> It's a perfectly sensible proposal, but adopting it is a judgement call. >> I'll leave a week for committee responses, and then we can just vote. >> >> Simon >> >> On Thu, 21 Mar 2024 at 08:07, Adam Gundry wrote: >> >>> Dear Committee, >>> >>> Vlad proposes to amend proposal #425 to permit more wildcard binder >>> forms in type declarations: >>> >>> https://github.com/ghc-proposals/ghc-proposals/pull/641 >>> >>> I'd like to nominate Simon PJ as the shepherd. >>> >>> Please guide us to a conclusion as outlined in >>> https://github.com/ghc-proposals/ghc-proposals#committee-process >>> >>> Cheers, >>> >>> Adam >>> >>> >>> -- >>> Adam Gundry, Haskell Consultant >>> Well-Typed LLP, https://www.well-typed.com/ >>> >>> Registered in England & Wales, OC335890 >>> 27 Old Gloucester Street, London WC1N 3AX, England >>> _______________________________________________ >>> 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 > -- -- Matthías Páll Gissurarson -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Sat May 4 04:17:06 2024 From: chris at chrisdornan.com (Chris Dornan) Date: Sat, 4 May 2024 05:17:06 +0100 Subject: [ghc-steering-committee] Please review #641: Wildcard binders in type declarations In-Reply-To: References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com> Message-ID: <56CF77AA-A8C2-4C2E-870F-70C67F73D983@chrisdornan.com> Thanks Simon, This makes complete sense. I agree with you on minimising unnecessary TH churn and avoiding unnecessary complexity. Chris > On 3 May 2024, at 22:06, Simon Peyton Jones wrote: > > Dear Steering Committee > >> Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations: >> >> https://github.com/ghc-proposals/ghc-proposals/pull/641 > You may find it easiest to look at the rich diff > > We have since exchanged some email, and I invite you to look at my latest post on the ticket, namely: > https://github.com/ghc-proposals/ghc-proposals/pull/641#issuecomment-2091099038 > > In the light of these exchanges I'd like to modify my previous recommendation of "reject/park". I now propose: > Add wildcards to all binders in type declarations, not just @_. > Allow kind annotations for wildcards > These changes just fill out the design of #425 in two obvious ways. In particular: > data T1 @_ = MkT1 -- Allowed by #425 > data T2 @(_::Nat) = MkT2 -- Not currently allowed by #425 > data T3 _ = MkT3 -- Not currently allowed by #425 > data T4 (_ :: Nat) = MkT4 -- Not currently allowed by #425 > HoweverI propose that we reject > Do all this recursively > Make changes to Template Haskell > There is no obvious user need for > data T2 @((k::Nat)::Nat) = MkT2 > New recursive structures just add (modest but palpable) complexity to the specification and to the implementation. It is a cost without (so far as I can see) a user need or tangible benefit. > > As to Template Haskell, neither #425 nor the above enhancement forces us to make a change to TH. Currently binders in TH data type declarations cannot have wildcards. There is no pressing reason to introduce them: one can always use a type variable instead. And our General Rules ask us to avoid making breaking changes without a strong reason to do so. > > Perhaps we might enhance TH as part of a subsequent, bigger upheaval of TH syntax. But not now. > > None of this is a terribly big deal. Unless anyone objects strenuously I propose to make this our decision and move on. It's always possible to do more later if there is a user need. > > If you want to object to this proposal, please do so by the end of Weds 8th May. Thanks! > > Simon > > Simon > > On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones > wrote: >> Dear Steering Committee >> >> Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations: >> https://github.com/ghc-proposals/ghc-proposals/pull/641 >> >> You may find it easiest to look at the rich diff . >> >> This is a pretty small generalisation which would allow >> >> data T (( (a :: k1) :: k2)) = ... >> >> in which the binder has multiple kind signatures and redundant parens. The change is not driven by user need, but rather solely by uniformity: these same forms are permitted in function definitions: >> >> f :: forall (a :: k). blah >> f @(((a::k1)::k2))) = ... >> >> is permitted. >> >> It imposes a change on Template Haskell syntax too. >> >> The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more. >> >> It's not a big deal either way. Very few people expressed a view on GitHub. My personal view is that the modest (albeit non-zero) gain does not justify the definite (albeit modest) pain. I would leave this until someone actually wants it. >> >> Vlad argues for future-proofing, but my experience is that an eye to the future is sensible when you are making changes anyway; but making unforced changes solely for the future risks incurring pain now that, when the future comes, turns out to have been a poor investment. We may have correctly anticipated, or we may not. >> >> So my recommendation is to park this until we get a real user demand. >> >> It's a perfectly sensible proposal, but adopting it is a judgement call. I'll leave a week for committee responses, and then we can just vote. >> >> Simon >> >> On Thu, 21 Mar 2024 at 08:07, Adam Gundry > wrote: >>> Dear Committee, >>> >>> Vlad proposes to amend proposal #425 to permit more wildcard binder >>> forms in type declarations: >>> >>> https://github.com/ghc-proposals/ghc-proposals/pull/641 >>> >>> I'd like to nominate Simon PJ as the shepherd. >>> >>> Please guide us to a conclusion as outlined in >>> https://github.com/ghc-proposals/ghc-proposals#committee-process >>> >>> Cheers, >>> >>> Adam >>> >>> >>> -- >>> Adam Gundry, Haskell Consultant >>> Well-Typed LLP, https://www.well-typed.com/ >>> >>> Registered in England & Wales, OC335890 >>> 27 Old Gloucester Street, London WC1N 3AX, England >>> _______________________________________________ >>> 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: From arnaud.spiwack at tweag.io Mon May 13 12:49:05 2024 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Mon, 13 May 2024 14:49:05 +0200 Subject: [ghc-steering-committee] Please review #641: Wildcard binders in type declarations In-Reply-To: <56CF77AA-A8C2-4C2E-870F-70C67F73D983@chrisdornan.com> References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com> <56CF77AA-A8C2-4C2E-870F-70C67F73D983@chrisdornan.com> Message-ID: Sounds good to me. On Sat, 4 May 2024 at 06:17, Chris Dornan wrote: > Thanks Simon, > > This makes complete sense. I agree with you on minimising unnecessary TH > churn and avoiding unnecessary complexity. > > Chris > > On 3 May 2024, at 22:06, Simon Peyton Jones > wrote: > > Dear Steering Committee > > Vlad proposes to amend proposal #425 >> to >> permit more wildcard binder forms in type declarations: >> >> https://github.com/ghc-proposals/ghc-proposals/pull/641 >> > You may find it easiest to look at the rich diff > > > > We have since exchanged some email, and I invite you to look at my latest > post on the ticket, namely: > > https://github.com/ghc-proposals/ghc-proposals/pull/641#issuecomment-2091099038 > > In the light of these exchanges I'd like to modify my previous > recommendation of "reject/park". I now propose: > > - Add wildcards to *all* binders in type declarations, not just @_. > - Allow kind annotations for wildcards > > These changes just fill out the design of #425 in two obvious ways. In > particular: > > data T1 @_ = MkT1 -- Allowed by #425 > data T2 @(_::Nat) = MkT2 -- Not currently allowed by #425 > data T3 _ = MkT3 -- Not currently allowed by #425 > data T4 (_ :: Nat) = MkT4 -- Not currently allowed by #425 > > HoweverI propose that we reject > > - Do all this recursively > - Make changes to Template Haskell > > There is no obvious user need for > data T2 @((k::Nat)::Nat) = MkT2 > New recursive structures just add (modest but palpable) complexity to the > specification and to the implementation. It is a cost without (so far as I > can see) a user need or tangible benefit. > > As to Template Haskell, neither #425 nor the above enhancement forces us > to make a change to TH. Currently binders in TH data type declarations > cannot have wildcards. There is no pressing reason to introduce them: one > can always use a type variable instead. And our General Rules ask us to > avoid making breaking changes without a strong reason to do so. > > Perhaps we might enhance TH as part of a subsequent, bigger upheaval of TH > syntax. But not now. > > None of this is a terribly big deal. Unless anyone objects strenuously I > propose to make this our decision and move on. It's always possible to do > more later if there is a user need. > > If you want to object to this proposal, please do so by the end of Weds > 8th May. Thanks! > > Simon > > Simon > > On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> Dear Steering Committee >> >> Vlad proposes to amend proposal #425 >> to >> permit more wildcard binder forms in type declarations: >> https://github.com/ghc-proposals/ghc-proposals/pull/641 >> >> You may find it easiest to look at the rich diff >> >> . >> >> This is a pretty small generalisation which would allow >> >> data T (( (a :: k1) :: k2)) = ... >> >> in which the binder has multiple kind signatures and redundant parens. >> The change is *not driven by user need*, but rather solely by >> *uniformity*: these same forms are permitted in function definitions: >> >> f :: forall (a :: k). blah >> f @(((a::k1)::k2))) = ... >> >> is permitted. >> >> It imposes a change on Template Haskell syntax too. >> >> The implementation becomes a bit more complicated; more recursive data >> types, etc. Nothing hard, but more. >> >> It's not a big deal either way. Very few people expressed a view on >> GitHub. My personal view is that the modest (albeit non-zero) gain does >> not justify the definite (albeit modest) pain. I would leave this until >> someone actually wants it. >> >> Vlad argues for future-proofing, but my experience is that an eye to the >> future is sensible when you are making changes anyway; but making unforced >> changes solely for the future risks incurring pain now that, when the >> future comes, turns out to have been a poor investment. We may have >> correctly anticipated, or we may not. >> >> So my recommendation is to park this until we get a real user demand. >> >> It's a perfectly sensible proposal, but adopting it is a judgement call. >> I'll leave a week for committee responses, and then we can just vote. >> >> Simon >> >> On Thu, 21 Mar 2024 at 08:07, Adam Gundry wrote: >> >>> Dear Committee, >>> >>> Vlad proposes to amend proposal #425 to permit more wildcard binder >>> forms in type declarations: >>> >>> https://github.com/ghc-proposals/ghc-proposals/pull/641 >>> >>> I'd like to nominate Simon PJ as the shepherd. >>> >>> Please guide us to a conclusion as outlined in >>> https://github.com/ghc-proposals/ghc-proposals#committee-process >>> >>> Cheers, >>> >>> Adam >>> >>> >>> -- >>> Adam Gundry, Haskell Consultant >>> Well-Typed LLP, https://www.well-typed.com/ >>> >>> Registered in England & Wales, OC335890 >>> 27 Old Gloucester Street, London WC1N 3AX, England >>> _______________________________________________ >>> 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 > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Wed May 15 14:25:53 2024 From: adam at well-typed.com (Adam Gundry) Date: Wed, 15 May 2024 15:25:53 +0100 Subject: [ghc-steering-committee] Welcome to new members Message-ID: Dear all, Following the recent nomination round, the committee is delighted to welcome Sebastian Graf, Jakob Brünker and Erik de Castro Lopo as new members. Thank you for your willingness to volunteer. I will add your details to the GitHub repo, and you are encouraged to contribute to the discussion of any of the proposals under committee review. We would also like to record our thanks to those who applied in this round but were not selected. It was unusually competitive, so we were unfortunately not in a position to accept everyone, but your continued involvement in the proposals process is very welcome, and there will no doubt be future opportunities to join the committee. Best wishes, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From jakob.bruenker at gmail.com Wed May 15 15:02:46 2024 From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=) Date: Wed, 15 May 2024 17:02:46 +0200 Subject: [ghc-steering-committee] Welcome to new members In-Reply-To: References: Message-ID: Thank you Adam! I look forward to working together with everyone. Is there an easy way to see the proposals that are under review? The link on the main repo page "List of proposals waiting for committee decision" currently doesn't show any results. Cheers, Jakob On Wed, May 15, 2024 at 4:25 PM Adam Gundry wrote: > Dear all, > > Following the recent nomination round, the committee is delighted to > welcome Sebastian Graf, Jakob Brünker and Erik de Castro Lopo as new > members. Thank you for your willingness to volunteer. I will add your > details to the GitHub repo, and you are encouraged to contribute to the > discussion of any of the proposals under committee review. > > We would also like to record our thanks to those who applied in this > round but were not selected. It was unusually competitive, so we were > unfortunately not in a position to accept everyone, but your continued > involvement in the proposals process is very welcome, and there will no > doubt be future opportunities to join the committee. > > Best wishes, > > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Wed May 15 15:10:54 2024 From: adam at well-typed.com (Adam Gundry) Date: Wed, 15 May 2024 16:10:54 +0100 Subject: [ghc-steering-committee] Welcome to new members In-Reply-To: References: Message-ID: <44835b36-0688-40ce-8914-432c08902a34@well-typed.com> Actually, it turns out that there currently *are* no proposals under review or pending shepherd recommendation! I should have checked before sending my email. So I guess you are encouraged to write or revise some more proposals instead. :-) In case you're not aware, there's also a summary spreadsheet here, which also shows nothing to review (now that I've updated it): https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit#gid=0. I'll grant you edit permissions shortly. Cheers, Adam On 15/05/2024 16:02, Jakob Brünker wrote: > Thank you Adam! I look forward to working together with everyone. > > Is there an easy way to see the proposals that are under review? The > link on the main repo page "List of proposals waiting for committee > decision" currently doesn't show any results. > > Cheers, > Jakob > > On Wed, May 15, 2024 at 4:25 PM Adam Gundry > wrote: > > Dear all, > > Following the recent nomination round, the committee is delighted to > welcome Sebastian Graf, Jakob Brünker and Erik de Castro Lopo as new > members. Thank you for your willingness to volunteer. I will add your > details to the GitHub repo, and you are encouraged to contribute to the > discussion of any of the proposals under committee review. > > We would also like to record our thanks to those who applied in this > round but were not selected. It was unusually competitive, so we were > unfortunately not in a position to accept everyone, but your continued > involvement in the proposals process is very welcome, and there will no > doubt be future opportunities to join the committee. > > Best wishes, > > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From simon.peytonjones at gmail.com Thu May 16 08:27:20 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 16 May 2024 09:27:20 +0100 Subject: [ghc-steering-committee] Proposal #601: extension lifecycle Message-ID: Dear GHC Steering Committee Trevis Elser has submitted GHC Proposal #601 to us for consideration. (It was originally drafted by David Christiansen, but Trevis took it over.) It proposes that that we classify extensions into four categories: - Stable - Experimental - Deprecated - Legacy It does not say which extensions are in which category (that's #635, still to come); it simply establishes the categories. *I strongly urge you to accept the proposal*. We have been using this language informally for years, and it's good to nail it down more precisely. There is plenty of discussion on the PR, but it's all about the specifics (e.g. do we want both Deprecated and Legacy; answer, yes). There seems to be a strong consensus around the principle. I don't expect this to be controversial. Please (everyone) can you respond within a week, by *end of day on Thursday 23 May. *Can you - Reply by email - Update the spreadsheet with your vote Thanks! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu May 16 08:44:21 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 16 May 2024 09:44:21 +0100 Subject: [ghc-steering-committee] Welcome to new members In-Reply-To: <44835b36-0688-40ce-8914-432c08902a34@well-typed.com> References: <44835b36-0688-40ce-8914-432c08902a34@well-typed.com> Message-ID: Actually, it turns out that there currently *are* no proposals under review or pending shepherd recommendation! I should have checked before There is one now, as you'll have seen. But this situation is a bit unusual. We have had up to eight in play recently but we made a determined (and successful) effort to get them decided. Authors deserve a reasonably prompt response. We have an *obligation *to attend to proposals that are submitted to the committee, but an *invitation *to contribute to those under development . Early feedback to authors is valuable. E.g. Gergo is actively working on this one. Simon On Wed, 15 May 2024 at 16:11, Adam Gundry wrote: > Actually, it turns out that there currently *are* no proposals under > review or pending shepherd recommendation! I should have checked before > sending my email. So I guess you are encouraged to write or revise some > more proposals instead. :-) > > In case you're not aware, there's also a summary spreadsheet here, which > also shows nothing to review (now that I've updated it): > > https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit#gid=0. > > I'll grant you edit permissions shortly. > > Cheers, > > Adam > > > On 15/05/2024 16:02, Jakob Brünker wrote: > > Thank you Adam! I look forward to working together with everyone. > > > > Is there an easy way to see the proposals that are under review? The > > link on the main repo page "List of proposals waiting for committee > > decision" currently doesn't show any results. > > > > Cheers, > > Jakob > > > > On Wed, May 15, 2024 at 4:25 PM Adam Gundry > > wrote: > > > > Dear all, > > > > Following the recent nomination round, the committee is delighted to > > welcome Sebastian Graf, Jakob Brünker and Erik de Castro Lopo as new > > members. Thank you for your willingness to volunteer. I will add your > > details to the GitHub repo, and you are encouraged to contribute to > the > > discussion of any of the proposals under committee review. > > > > We would also like to record our thanks to those who applied in this > > round but were not selected. It was unusually competitive, so we were > > unfortunately not in a position to accept everyone, but your > continued > > involvement in the proposals process is very welcome, and there will > no > > doubt be future opportunities to join the committee. > > > > Best wishes, > > > > Adam > > > > > > -- > > Adam Gundry, Haskell Consultant > > Well-Typed LLP, https://www.well-typed.com/ > > > > > > Registered in England & Wales, OC335890 > > 27 Old Gloucester Street, London WC1N 3AX, England > > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > 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: From adam at well-typed.com Thu May 16 09:08:29 2024 From: adam at well-typed.com (Adam Gundry) Date: Thu, 16 May 2024 10:08:29 +0100 Subject: [ghc-steering-committee] Proposal #601: extension lifecycle In-Reply-To: References: Message-ID: <2b073bd4-56a4-42ed-a2ed-9b5b862ff6bb@well-typed.com> I'm in favour. (And I'm willing to work on the necessary follow-up proposal to apply the categorisation to specific extensions.) Cheers, Adam On 16/05/2024 09:27, Simon Peyton Jones wrote: > Dear GHC Steering Committee > > Trevis Elser has submitted GHC Proposal #601 > to us for > consideration.  (It was originally drafted by David Christiansen, but > Trevis took it over.) > > It proposes that that we classify extensions into four categories: > > * Stable > * Experimental > * Deprecated > * Legacy > > It does not say which extensions are in which category (that's #635, > still to come); it simply establishes the categories. > > *I strongly urge you to accept the proposal*. We have been using this > language informally for years, and it's good to nail it down more precisely. > > There is plenty of discussion on the PR, but it's all about the > specifics (e.g. do we want both Deprecated and Legacy; answer, yes). > There seems to be a strong consensus around the principle. > > I don't expect this to be controversial. Please (everyone) can you > respond within a week, by *end of day on Thursday 23 May. *Can you > > * Reply by email > * Update the spreadsheet > with your vote > > Thanks! > > Simon -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From eric at seidel.io Thu May 16 12:03:48 2024 From: eric at seidel.io (Eric Seidel) Date: Thu, 16 May 2024 08:03:48 -0400 Subject: [ghc-steering-committee] Proposal #601: extension lifecycle In-Reply-To: <2b073bd4-56a4-42ed-a2ed-9b5b862ff6bb@well-typed.com> References: <2b073bd4-56a4-42ed-a2ed-9b5b862ff6bb@well-typed.com> Message-ID: <5C735D80-42FD-40AE-AC0D-7D7029D9D697@seidel.io> I support this proposal. Sent from my iPhone > On May 16, 2024, at 05:08, Adam Gundry wrote: > > I'm in favour. (And I'm willing to work on the necessary follow-up proposal to apply the categorisation to specific extensions.) > > Cheers, > > Adam > > >> On 16/05/2024 09:27, Simon Peyton Jones wrote: >> Dear GHC Steering Committee >> Trevis Elser has submitted GHC Proposal #601 to us for consideration. (It was originally drafted by David Christiansen, but Trevis took it over.) >> It proposes that that we classify extensions into four categories: >> * Stable >> * Experimental >> * Deprecated >> * Legacy >> It does not say which extensions are in which category (that's #635, still to come); it simply establishes the categories. >> *I strongly urge you to accept the proposal*. We have been using this language informally for years, and it's good to nail it down more precisely. >> There is plenty of discussion on the PR, but it's all about the specifics (e.g. do we want both Deprecated and Legacy; answer, yes). There seems to be a strong consensus around the principle. >> I don't expect this to be controversial. Please (everyone) can you respond within a week, by *end of day on Thursday 23 May. *Can you >> * Reply by email >> * Update the spreadsheet >> with your vote >> Thanks! >> Simon > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From moritz.angermann at gmail.com Thu May 16 12:36:11 2024 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Thu, 16 May 2024 20:36:11 +0800 Subject: [ghc-steering-committee] Proposal #601: extension lifecycle In-Reply-To: <5C735D80-42FD-40AE-AC0D-7D7029D9D697@seidel.io> References: <2b073bd4-56a4-42ed-a2ed-9b5b862ff6bb@well-typed.com> <5C735D80-42FD-40AE-AC0D-7D7029D9D697@seidel.io> Message-ID: I am in support of this proposal. I do not believe that beating this any further will result in any meaningful improvement. As I’ve learned in other discussions the word Experimental means different things to different people. The proposal does call out some extensions as experimental, but does not list LT although to me it’s one of the most prominent examples. In any case having some guiding flow around extensions is a step in the right direction in my opinion. Best, Moritz On Thu, 16 May 2024 at 8:04 PM, Eric Seidel wrote: > I support this proposal. > > Sent from my iPhone > > > On May 16, 2024, at 05:08, Adam Gundry wrote: > > > > I'm in favour. (And I'm willing to work on the necessary follow-up > proposal to apply the categorisation to specific extensions.) > > > > Cheers, > > > > Adam > > > > > >> On 16/05/2024 09:27, Simon Peyton Jones wrote: > >> Dear GHC Steering Committee > >> Trevis Elser has submitted GHC Proposal #601 < > https://github.com/ghc-proposals/ghc-proposals/pull/601>to us for > consideration. (It was originally drafted by David Christiansen, but > Trevis took it over.) > >> It proposes that that we classify extensions into four categories: > >> * Stable > >> * Experimental > >> * Deprecated > >> * Legacy > >> It does not say which extensions are in which category (that's #635, > still to come); it simply establishes the categories. > >> *I strongly urge you to accept the proposal*. We have been using this > language informally for years, and it's good to nail it down more precisely. > >> There is plenty of discussion on the PR, but it's all about the > specifics (e.g. do we want both Deprecated and Legacy; answer, yes). There > seems to be a strong consensus around the principle. > >> I don't expect this to be controversial. Please (everyone) can you > respond within a week, by *end of day on Thursday 23 May. *Can you > >> * Reply by email > >> * Update the spreadsheet > >> < > https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>with > your vote > >> Thanks! > >> Simon > > > > -- > > Adam Gundry, Haskell Consultant > > Well-Typed LLP, https://www.well-typed.com/ > > > > Registered in England & Wales, OC335890 > > 27 Old Gloucester Street, London WC1N 3AX, England > > > > _______________________________________________ > > 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: From simon.peytonjones at gmail.com Thu May 16 12:43:19 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 16 May 2024 13:43:19 +0100 Subject: [ghc-steering-committee] Proposal #601: extension lifecycle In-Reply-To: References: <2b073bd4-56a4-42ed-a2ed-9b5b862ff6bb@well-typed.com> <5C735D80-42FD-40AE-AC0D-7D7029D9D697@seidel.io> Message-ID: The proposal does call out some extensions as experimental, but does not list LT although to me it’s one of the most prominent examples It specifically says that any extensions mentioned are examples only. A separate proposal is for deciding which extension is in which category. So this proposal does not, in itself, do any categorisation whatsoever. Simon On Thu, 16 May 2024 at 13:36, Moritz Angermann wrote: > I am in support of this proposal. I do not believe that beating this any > further will result in any meaningful improvement. As I’ve learned in other > discussions the word Experimental means different things to different > people. The proposal does call out some extensions as experimental, but > does not list LT although to me it’s one of the most prominent examples. > > In any case having some guiding flow around extensions is a step in the > right direction in my opinion. > > Best, > Moritz > > On Thu, 16 May 2024 at 8:04 PM, Eric Seidel wrote: > >> I support this proposal. >> >> Sent from my iPhone >> >> > On May 16, 2024, at 05:08, Adam Gundry wrote: >> > >> > I'm in favour. (And I'm willing to work on the necessary follow-up >> proposal to apply the categorisation to specific extensions.) >> > >> > Cheers, >> > >> > Adam >> > >> > >> >> On 16/05/2024 09:27, Simon Peyton Jones wrote: >> >> Dear GHC Steering Committee >> >> Trevis Elser has submitted GHC Proposal #601 < >> https://github.com/ghc-proposals/ghc-proposals/pull/601>to us for >> consideration. (It was originally drafted by David Christiansen, but >> Trevis took it over.) >> >> It proposes that that we classify extensions into four categories: >> >> * Stable >> >> * Experimental >> >> * Deprecated >> >> * Legacy >> >> It does not say which extensions are in which category (that's #635, >> still to come); it simply establishes the categories. >> >> *I strongly urge you to accept the proposal*. We have been using this >> language informally for years, and it's good to nail it down more precisely. >> >> There is plenty of discussion on the PR, but it's all about the >> specifics (e.g. do we want both Deprecated and Legacy; answer, yes). There >> seems to be a strong consensus around the principle. >> >> I don't expect this to be controversial. Please (everyone) can you >> respond within a week, by *end of day on Thursday 23 May. *Can you >> >> * Reply by email >> >> * Update the spreadsheet >> >> < >> https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>with >> your vote >> >> Thanks! >> >> Simon >> > >> > -- >> > Adam Gundry, Haskell Consultant >> > Well-Typed LLP, https://www.well-typed.com/ >> > >> > Registered in England & Wales, OC335890 >> > 27 Old Gloucester Street, London WC1N 3AX, England >> > >> > _______________________________________________ >> > 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 >> > _______________________________________________ > 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: From arnaud.spiwack at tweag.io Fri May 17 07:09:29 2024 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Fri, 17 May 2024 09:09:29 +0200 Subject: [ghc-steering-committee] Proposal #601: extension lifecycle In-Reply-To: References: <2b073bd4-56a4-42ed-a2ed-9b5b862ff6bb@well-typed.com> <5C735D80-42FD-40AE-AC0D-7D7029D9D697@seidel.io> Message-ID: Good for me. On Thu, 16 May 2024 at 14:43, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > The proposal does call out some extensions as experimental, but does not > list LT although to me it’s one of the most prominent examples > > It specifically says that any extensions mentioned are examples only. A separate > proposal is > for deciding which extension is in which category. > > So this proposal does not, in itself, do any categorisation whatsoever. > > Simon > > On Thu, 16 May 2024 at 13:36, Moritz Angermann > wrote: > >> I am in support of this proposal. I do not believe that beating this any >> further will result in any meaningful improvement. As I’ve learned in other >> discussions the word Experimental means different things to different >> people. The proposal does call out some extensions as experimental, but >> does not list LT although to me it’s one of the most prominent examples. >> >> In any case having some guiding flow around extensions is a step in the >> right direction in my opinion. >> >> Best, >> Moritz >> >> On Thu, 16 May 2024 at 8:04 PM, Eric Seidel wrote: >> >>> I support this proposal. >>> >>> Sent from my iPhone >>> >>> > On May 16, 2024, at 05:08, Adam Gundry wrote: >>> > >>> > I'm in favour. (And I'm willing to work on the necessary follow-up >>> proposal to apply the categorisation to specific extensions.) >>> > >>> > Cheers, >>> > >>> > Adam >>> > >>> > >>> >> On 16/05/2024 09:27, Simon Peyton Jones wrote: >>> >> Dear GHC Steering Committee >>> >> Trevis Elser has submitted GHC Proposal #601 < >>> https://github.com/ghc-proposals/ghc-proposals/pull/601>to us for >>> consideration. (It was originally drafted by David Christiansen, but >>> Trevis took it over.) >>> >> It proposes that that we classify extensions into four categories: >>> >> * Stable >>> >> * Experimental >>> >> * Deprecated >>> >> * Legacy >>> >> It does not say which extensions are in which category (that's #635, >>> still to come); it simply establishes the categories. >>> >> *I strongly urge you to accept the proposal*. We have been using this >>> language informally for years, and it's good to nail it down more precisely. >>> >> There is plenty of discussion on the PR, but it's all about the >>> specifics (e.g. do we want both Deprecated and Legacy; answer, yes). There >>> seems to be a strong consensus around the principle. >>> >> I don't expect this to be controversial. Please (everyone) can you >>> respond within a week, by *end of day on Thursday 23 May. *Can you >>> >> * Reply by email >>> >> * Update the spreadsheet >>> >> < >>> https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>with >>> your vote >>> >> Thanks! >>> >> Simon >>> > >>> > -- >>> > Adam Gundry, Haskell Consultant >>> > Well-Typed LLP, https://www.well-typed.com/ >>> > >>> > Registered in England & Wales, OC335890 >>> > 27 Old Gloucester Street, London WC1N 3AX, England >>> > >>> > _______________________________________________ >>> > 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 >>> >> _______________________________________________ >> 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 > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpg at mpg.is Fri May 17 08:43:09 2024 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Fri, 17 May 2024 10:43:09 +0200 Subject: [ghc-steering-committee] Proposal #601: extension lifecycle In-Reply-To: References: <2b073bd4-56a4-42ed-a2ed-9b5b862ff6bb@well-typed.com> <5C735D80-42FD-40AE-AC0D-7D7029D9D697@seidel.io> Message-ID: I'm in favor On Fri, 17 May 2024 at 09:09, Arnaud Spiwack wrote: > Good for me. > > On Thu, 16 May 2024 at 14:43, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> The proposal does call out some extensions as experimental, but does not >> list LT although to me it’s one of the most prominent examples >> >> It specifically says that any extensions mentioned are examples only. A separate >> proposal is >> for deciding which extension is in which category. >> >> So this proposal does not, in itself, do any categorisation whatsoever. >> >> Simon >> >> On Thu, 16 May 2024 at 13:36, Moritz Angermann < >> moritz.angermann at gmail.com> wrote: >> >>> I am in support of this proposal. I do not believe that beating this any >>> further will result in any meaningful improvement. As I’ve learned in other >>> discussions the word Experimental means different things to different >>> people. The proposal does call out some extensions as experimental, but >>> does not list LT although to me it’s one of the most prominent examples. >>> >>> In any case having some guiding flow around extensions is a step in the >>> right direction in my opinion. >>> >>> Best, >>> Moritz >>> >>> On Thu, 16 May 2024 at 8:04 PM, Eric Seidel wrote: >>> >>>> I support this proposal. >>>> >>>> Sent from my iPhone >>>> >>>> > On May 16, 2024, at 05:08, Adam Gundry wrote: >>>> > >>>> > I'm in favour. (And I'm willing to work on the necessary follow-up >>>> proposal to apply the categorisation to specific extensions.) >>>> > >>>> > Cheers, >>>> > >>>> > Adam >>>> > >>>> > >>>> >> On 16/05/2024 09:27, Simon Peyton Jones wrote: >>>> >> Dear GHC Steering Committee >>>> >> Trevis Elser has submitted GHC Proposal #601 < >>>> https://github.com/ghc-proposals/ghc-proposals/pull/601>to us for >>>> consideration. (It was originally drafted by David Christiansen, but >>>> Trevis took it over.) >>>> >> It proposes that that we classify extensions into four categories: >>>> >> * Stable >>>> >> * Experimental >>>> >> * Deprecated >>>> >> * Legacy >>>> >> It does not say which extensions are in which category (that's #635, >>>> still to come); it simply establishes the categories. >>>> >> *I strongly urge you to accept the proposal*. We have been using >>>> this language informally for years, and it's good to nail it down more >>>> precisely. >>>> >> There is plenty of discussion on the PR, but it's all about the >>>> specifics (e.g. do we want both Deprecated and Legacy; answer, yes). There >>>> seems to be a strong consensus around the principle. >>>> >> I don't expect this to be controversial. Please (everyone) can you >>>> respond within a week, by *end of day on Thursday 23 May. *Can you >>>> >> * Reply by email >>>> >> * Update the spreadsheet >>>> >> < >>>> https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>with >>>> your vote >>>> >> Thanks! >>>> >> Simon >>>> > >>>> > -- >>>> > Adam Gundry, Haskell Consultant >>>> > Well-Typed LLP, https://www.well-typed.com/ >>>> > >>>> > Registered in England & Wales, OC335890 >>>> > 27 Old Gloucester Street, London WC1N 3AX, England >>>> > >>>> > _______________________________________________ >>>> > 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 >>>> >>> _______________________________________________ >>> 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 >> > > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- -- Matthías Páll Gissurarson -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob.bruenker at gmail.com Fri May 17 18:07:16 2024 From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=) Date: Fri, 17 May 2024 20:07:16 +0200 Subject: [ghc-steering-committee] Proposal #601: extension lifecycle In-Reply-To: References: <2b073bd4-56a4-42ed-a2ed-9b5b862ff6bb@well-typed.com> <5C735D80-42FD-40AE-AC0D-7D7029D9D697@seidel.io> Message-ID: I left a couple of clarifying questions on github, but I'm in support. On Fri, May 17, 2024 at 10:43 AM Matthías Páll Gissurarson wrote: > I'm in favor > > On Fri, 17 May 2024 at 09:09, Arnaud Spiwack > wrote: > >> Good for me. >> >> On Thu, 16 May 2024 at 14:43, Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> >>> The proposal does call out some extensions as experimental, but does not >>> list LT although to me it’s one of the most prominent examples >>> >>> It specifically says that any extensions mentioned are examples only. A separate >>> proposal >>> is for >>> deciding which extension is in which category. >>> >>> So this proposal does not, in itself, do any categorisation whatsoever. >>> >>> Simon >>> >>> On Thu, 16 May 2024 at 13:36, Moritz Angermann < >>> moritz.angermann at gmail.com> wrote: >>> >>>> I am in support of this proposal. I do not believe that beating this >>>> any further will result in any meaningful improvement. As I’ve learned in >>>> other discussions the word Experimental means different things to different >>>> people. The proposal does call out some extensions as experimental, but >>>> does not list LT although to me it’s one of the most prominent examples. >>>> >>>> In any case having some guiding flow around extensions is a step in the >>>> right direction in my opinion. >>>> >>>> Best, >>>> Moritz >>>> >>>> On Thu, 16 May 2024 at 8:04 PM, Eric Seidel wrote: >>>> >>>>> I support this proposal. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> > On May 16, 2024, at 05:08, Adam Gundry wrote: >>>>> > >>>>> > I'm in favour. (And I'm willing to work on the necessary follow-up >>>>> proposal to apply the categorisation to specific extensions.) >>>>> > >>>>> > Cheers, >>>>> > >>>>> > Adam >>>>> > >>>>> > >>>>> >> On 16/05/2024 09:27, Simon Peyton Jones wrote: >>>>> >> Dear GHC Steering Committee >>>>> >> Trevis Elser has submitted GHC Proposal #601 < >>>>> https://github.com/ghc-proposals/ghc-proposals/pull/601>to us for >>>>> consideration. (It was originally drafted by David Christiansen, but >>>>> Trevis took it over.) >>>>> >> It proposes that that we classify extensions into four categories: >>>>> >> * Stable >>>>> >> * Experimental >>>>> >> * Deprecated >>>>> >> * Legacy >>>>> >> It does not say which extensions are in which category (that's >>>>> #635, still to come); it simply establishes the categories. >>>>> >> *I strongly urge you to accept the proposal*. We have been using >>>>> this language informally for years, and it's good to nail it down more >>>>> precisely. >>>>> >> There is plenty of discussion on the PR, but it's all about the >>>>> specifics (e.g. do we want both Deprecated and Legacy; answer, yes). There >>>>> seems to be a strong consensus around the principle. >>>>> >> I don't expect this to be controversial. Please (everyone) can you >>>>> respond within a week, by *end of day on Thursday 23 May. *Can you >>>>> >> * Reply by email >>>>> >> * Update the spreadsheet >>>>> >> < >>>>> https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>with >>>>> your vote >>>>> >> Thanks! >>>>> >> Simon >>>>> > >>>>> > -- >>>>> > Adam Gundry, Haskell Consultant >>>>> > Well-Typed LLP, https://www.well-typed.com/ >>>>> > >>>>> > Registered in England & Wales, OC335890 >>>>> > 27 Old Gloucester Street, London WC1N 3AX, England >>>>> > >>>>> > _______________________________________________ >>>>> > 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 >>>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> -- >> Arnaud Spiwack >> Director, Research at https://moduscreate.com and https://tweag.io. >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > > > -- > -- Matthías Páll Gissurarson > _______________________________________________ > 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: From adam at well-typed.com Fri May 24 17:15:50 2024 From: adam at well-typed.com (Adam Gundry) Date: Fri, 24 May 2024 18:15:50 +0100 Subject: [ghc-steering-committee] Please review #267: Class method headers Message-ID: Dear Committee, Vlad proposes to allow class variable binders on the left of :: in class method signatures: https://github.com/ghc-proposals/ghc-proposals/pull/267 https://github.com/int-index/ghc-proposals/blob/class-method-headers/proposals/0000-class-method-headers.rst I'd like to nominate Jakob as the shepherd (welcome Jakob!). Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From simon.peytonjones at gmail.com Mon May 27 09:08:16 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 27 May 2024 10:08:16 +0100 Subject: [ghc-steering-committee] Proposal #601: extension lifecycle In-Reply-To: References: Message-ID: Dear Simon, Sebastian, Chris, Erik I don't think you have responded to my email below, not updated the spreadsheet . Any particular reason? I don't want to accept the proposal if there are any strenuous objections. In the case of Erik and Sebastian it's possible that you have not been added correctly to the GHC Steering Committee mailing list, so I'm including your email addresses in the to: field Thanks Simon On Thu, 16 May 2024 at 09:27, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Dear GHC Steering Committee > > Trevis Elser has submitted GHC Proposal #601 > to us for > consideration. (It was originally drafted by David Christiansen, but > Trevis took it over.) > > It proposes that that we classify extensions into four categories: > > - Stable > - Experimental > - Deprecated > - Legacy > > It does not say which extensions are in which category (that's #635, still > to come); it simply establishes the categories. > > *I strongly urge you to accept the proposal*. We have been using this > language informally for years, and it's good to nail it down more precisely. > > There is plenty of discussion on the PR, but it's all about the specifics > (e.g. do we want both Deprecated and Legacy; answer, yes). There seems to > be a strong consensus around the principle. > > I don't expect this to be controversial. Please (everyone) can you respond > within a week, by *end of day on Thursday 23 May. *Can you > > - Reply by email > - Update the spreadsheet > with > your vote > > Thanks! > > Simon > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Mon May 27 12:47:42 2024 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 27 May 2024 12:47:42 +0000 Subject: [ghc-steering-committee] Proposal #601: extension lifecycle In-Reply-To: References: Message-ID: Hi Simon, (Indeed, I only registered an account for the mailing list without subscribing. Let's see if I receive this mail now.) I voted Accept as well. Cheers, Sebastian ------ Originalnachricht ------ Von "Simon Peyton Jones" An "ghc-steering-committee" ; "Erik de Castro Lopo" ; "Sebastian Graf" Datum 27.05.2024 11:08:16 Betreff Re: Proposal #601: extension lifecycle >Dear Simon, Sebastian, Chris, Erik > >I don't think you have responded to my email below, not updated the >spreadsheet >. > Any particular reason? I don't want to accept the proposal if there >are any strenuous objections. > >In the case of Erik and Sebastian it's possible that you have not been >added correctly to the GHC Steering Committee mailing list, so I'm >including your email addresses in the to: field > >Thanks > >Simon > >On Thu, 16 May 2024 at 09:27, Simon Peyton Jones > wrote: >>Dear GHC Steering Committee >> >>Trevis Elser has submitted GHC Proposal #601 >>to us for >>consideration. (It was originally drafted by David Christiansen, but >>Trevis took it over.) >> >>It proposes that that we classify extensions into four categories: >>Stable >>Experimental >>Deprecated >>Legacy >>It does not say which extensions are in which category (that's #635, >>still to come); it simply establishes the categories. >> >>I strongly urge you to accept the proposal. We have been using this >>language informally for years, and it's good to nail it down more >>precisely. >> >>There is plenty of discussion on the PR, but it's all about the >>specifics (e.g. do we want both Deprecated and Legacy; answer, yes). >>There seems to be a strong consensus around the principle. >> >>I don't expect this to be controversial. Please (everyone) can you >>respond within a week, by end of day on Thursday 23 May. Can you >>Reply by email >>Update the spreadsheet >>with >>your vote >>Thanks! >> >>Simon >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: