[ghc-steering-committee] GHC2023

[Simon Peyton Jones]

Adding Tom Ellis (thank you Jakob).

Simon

On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> Another year has passed, and if we are serious with the idea that
>> GHC20xx is a continuous thing, we should probably start defining
>> GHC2023 – even if it is just a small delta.
>>
>
> Indeed, we originally said we'd review GHC20xx annually, but I think we
> might want to consult the community to see if that is too often.  There has
> been an interesting thread
> <https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell
> Discourse.
>
> The HF Stability Working Group discussed this on Monday, and I think Tom
> Ellis (a member of the SWG) is willing to lead a consultation.  I think
> that would be great -- we have no axe to grind here, and I think we'll be
> delighted to do whatever makes the maximal number of people happy.
>
> Tom (cc'd) will write with more info shortly.  Sound OK?
>
> Simon
>
> On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi Committee,
>>
>> when we defined the process for GHC20xx, as written in
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
>> we wrote
>>
>>    Likely, the first iteration of this process will be vastly different
>>    from the following ones: The first one is expected to add a large
>>    number of uncontroversial extensions; so the next iteration will
>>    likely only make a smaller, but more controversial change.
>>
>>    Therefore, this proposal does not commit to a fixed cadence.
>>    Instead, 6 months after the first release of a version of GHC that
>>    supports a GHC20xx set, we evaluate the outcome, the process, and
>>    the perceived need of a next release. At that time we will refine
>>    the processes, if needed, and set a cadence.
>>
>> The first version of GHC that supported GHC2021 was 9.2, released in
>> October 2022.
>>
>> Last fall we said that not enough time has passed to do such an
>> evaluation, and we skipped defining GHC2022.
>>
>> Another year has passed, and if we are serious with the idea that
>> GHC20xx is a continuous thing, we should probably start defining
>> GHC2023 – even if it is just a small delta. This e-mail tries to
>> kickstart that process.
>>
>>
>> Last time we did a relative elaborate thing where we voted on
>> essentially _every_ extension. I think that made sense for the first
>> iteration, where we had to winddow down the likely extensions. But now
>> we have a base line (GHC2021), and are asked to find a suitable delta,
>> and I’d go for a nomination-based approach: Committee members can
>> propose adding (or removing, in theory) specific extensions, and then
>> we vote only on those. Does that sound reasonable?
>>
>> Does anyone have any insight from the real world? Has GHC2021 helped
>> our users? And if not, why not?
>>
>> What kind of hard data would you like to see, if any?
>>
>> (I’m a bit wary of spending too much time writing scripts to scrape
>> hackage, for example to see which extensions people tend to enable _in
>> addition_ to GHC2021, only to see that libraries on hackage are
>> understandably slow to use default-language: GHC2021, as that’s not
>> great for backward compat for now. But I am also not sure where to look
>> for good data…)
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> 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/20221101/e57dbe6d/attachment.html>