[ghc-steering-committee] GHC2023

[Chris Dornan]

> I’m still fairly convinced that we are doing the community a service if
> we take the idea of GHC20xx editions as a continuous and predictable
> stream of improvements serious.

Very well put -- count me in. I think the anxiety around us generating more things that the community has to think about is understandable, but other than that there isn't a great deal of substance to the objections, but I think the idea of a steady stream of refinement around what we think should be in 'modern base Haskell' is a strong and important one, and a steady effort of refinement is I am sure going to lead to a better and more rational result than periodic bun fights to determine what is going into the next decade of 'modern base Haskell'.

So I vote yes to continuing to think about what we want in ghc2023.

Thanks again Joachim for (again) keeping us on track.

Chris

> On 8 Jan 2023, at 10:35, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Mittwoch, dem 23.11.2022 um 17:51 +0100 schrieb Joachim Breitner:
>> encouraged by Arnaud reports about Rust editions, and also in light of
>> the ExplicitNamespaces “bug” in GHC2021, I’m now starting a proposal to
>> define GHC2023. 
>> 
>> Please see
>> https://github.com/ghc-proposals/ghc-proposals/pull/559
>> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst
>> 
>> The proposal text succinctly tries to alleviate worries that this is
>> “too soon”, and gives motivation for the nominated extensions.
>> 
>> At the moment it suggest to add ExplicitNamespaces and LambdaCase
>> 
>> I invite all committee members to 
>> * nominate more extensions to add
>> * bring arguments in favor of an extension
>> * bring arguments against an extension
>> 
>> You can either add them directly (via suggested edits) to the proposal
>> text, or write them here and I’ll paraphrase them into that document,
>> to try to summarize the discussion well.
>> 
>> Once that phase seems concluded, I’ll invite you to vote. Not sure yet
>> how precisely, but we’ll vote in a way that one can also express that
>> no GHC2023 should happen.
> 
> I have not seen much engagement from the committee on this PR, and I
> sense a certain reluctance to have another GHC20xx this year. But I
> don’t want us to deviate from the original accepted plan just because
> of implicit assumptions, nor get bogged down by the more fundamental
> (and important!) discussion about the role of extensions in general.
> 
> So let’s bring this to a vote – if the camp that prefers even rarer
> releases is in the majority, the vote will show that. 
> 
> I’m still fairly convinced that we are doing the community a service if
> we take the idea of GHC20xx editions as a continuous and predictable
> stream of improvements serious. Even if the delta is kinda small.
> Actually, I should say: _Especially_ if the delta is kinda small! This
> takes the anxiety out of “anew GHC20xx has been released”, just like
> the now bi-yearly GHC releases ideally don’t scare anyone anymore, as
> it helps us get used to and gain practice with the process.
> 
> So let’s collect possibly more nominations and otherwise discuss with
> the community on the PR for two more weeks (until roughly Sun, Jan 22).
> If you’d like to get an extension on the ballot, or expand the
> rationale for an extension, simply edit 
> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst <https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst>
> 
> Then I will ask a for a vote. The ballot will roughly look like this:
> 
>  For each of the following extension, should it become part of
>  GHC2023? Please annotate with “strong yes”, “weak yes” or “no”.
> 
>  GotoStatement
>  SemanticComments
>  ImplementationByChatGTP
> 
> We’ll have GHC2023 if _at leas one_ extension has a majority of “strong
> yes” vote, and it will contain those extensions that have a majority of
> “yes” votes.
> 
> This allows you to distinguish between “worth having GHC2023 for” from
> “not worth having GHC2023 for, but good enough to include if we have
> GHC2023 anyways”. For example if you think there shouldn’t be a
> GHC2023, you just never vote “strong yes”, but you can still have a say
> what should be in it if it happens, by voting “weak yes” or “no”.
> 
> 
> Cheers,
> Joachim
> 
> 
> 
> 
> 
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>  http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://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/20230108/b5be47ea/attachment-0001.html>