Dear Ghc-Steering-Committee, Here's an email from Tom Ellis about the GHC20xx thread. Please do read it. (Who, if anyone, is the moderator of the ghc-steering-committee mailing list?) Simon ---------- Forwarded message --------- From: Tom Ellis <tom-2019@jaguarpaw.co.uk> Date: Tue, 8 Nov 2022 at 08:04 Subject: Re: [ghc-steering-committee] GHC2023 To: Simon Peyton Jones <simon.peytonjones@gmail.com> Hello Simon, I sent this to the steering committee mailing list on Saturday but received an email in response saying it was "being held until the list moderator can review it for approval". Perhaps no moderator has had the chance to review it yet, as it hasn't yet appeared on the mailing list archive https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/thre... Perhaps you would be kind enough to forward it to the list for me directly. Thanks, Tom Thanks Simon. On reflection, I'm not particularly motivated to consult the community because the concerns I have impinge most strongly on members of the community who are distant from where a consultation could easily reach, and on non-but-potential-members of the community who are getting a false impression from afar. I will content myself with elaborating on my concerns and then leaving it to the steering committee to take them into account if they see fit. To set the scene, everything I write below is presented from the point of view of someone who wishes Haskell usage to increase and believes that we can't increase Haskell usage by appealing to people who are already comfortable with the way the Haskell ecosystem currently works: we've already got most of those people. For the ten years that I have been in the community, Haskell has had a (false) reputation, to outsiders, as a fragmented language with multiple mysterious things called "language extensions" each of which fractures the language in an incompatible way. "It's impossible to learn Haskell because there are so many incompatible Haskells" they say. It may be hard to believe that this perception exists: as users of GHC we know that there are very few extensions that introduce any incompatibility with others; extensions typically just remove unneccesary restrictions. But, for those of you who don't spend far-too-much of your time on discussion fora such as Hacker News and Reddit, I can guarantee to you that this objection to Haskell comes up *a lot*. Haskell also has, to both insiders and outsiders, a (true) reputation for being an unstable moving target. "It's impossible to learn or use Haskell because the language and libraries keep changing", they say. This one is easier to believe. GHC2021 is a wonderful way of dealing with all of the first and part of the second objection! I can now respond to complaints of language fragmentation and language instability by simply saying "Turn on GHC2021 and be happy". This is great news! (GHC2021 doesn't deal with instability in libraries of course, but I'm pleased that there are many people making efforts in that area too.) I am concerned that GHC2023 would weaken the power of my rejoinder "Turn on GHC2021 and be happy". Now I am at risk of the responses "But why not GHC2023?", "Haskell introduced a new, incompatible language just two years after standardising on GHC2021", "I just spent my precious time learning GHC2021, now I have to spend time learning GHC2023.". Sure, these responses are based on misunderstandings of the technical details. But perceptions really, really matter! If we want a large increase in Haskell usage then we have to take perceptions into account. We can't substantially increase Haskell usage any more by appealing just to our techncial excellence. If we choose to prioritise business-as-usual, that is, the incorporation of highly technically excellent features on a regular basis, with no thought to the costs, then the consequence will be Haskellers-as-usual: people who value that kind of thing in spite of the costs. We already have most of those people. We can't increase Haskell adoption that way. If we choose to change tack then we have the chance of changing the types of people we pick up as new Haskellers, from among those who would never otherwise have considered the language. To put it pithily, Joachim writes in a sibling thread "The point of the GHC20xx series is to get (proven, useful, uncontroversial) goodies into the hands of our users". Are members of the Haskell community, and indeed non-but-potential-members, screaming out for new "goodies"? Or are they screaming out for a brief respite from the unforgiving churn of the Haskell ecosystem, both real and not-real-but-perceived. My experience of the last ten years tells me it's the latter. To be clear, I personally am very much looking forward to more highly technically excellent features, including the exciting ongoing work on dependent types, WASM, GHCJS, and so on. It's one of the aspects of the community that really inspires and excites me! I personally can tolerate the churn. But I don't want those things at the *cost* of continuing to push away potential new users who are currently peering over the fence, discouraged because they can't tolerate the churn that they see, real or perceived. Now, with my stability hat on, looking from the point of view of process design, it's actually *better* for changes to happen in small increments, so maybe having GHC20xx every year is actually *better* than every five years. I don't wish to advocate for one choice or another. Rather I wish to advocate for the point of view that: Technical excellence matters. Stability and the perception of stability matter too. Tom On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <simon.peytonjones@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@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-gh...
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…)
Hi Tom, thanks for your input! If I may (inadequadly) summarize what I read is that we should take into account stability and not just technical stability (your code doesn’t have to change as you upgrade your code), but also _perceived_ stability (there is GHC2021 and GH2023 and that’s confused). I agree that this is imporant, and worth thinking more about. In particular: How do other languages treat this? In one of my newsfeeds I recently read
Version 1.65.0 of the Rust language has been released. Improvements include generic associated types, a new let...else statement, and the ability to break from labeled blocks
and also
Version 3.10.0 of the Python language has been released. There are a lot of significant changes in this release, including the much- discussed structural pattern-matching feature.
so these (popular, non-scary) languages certainly don’t freeze their language, and do extend the language repeatedly. Why are they not preceived as unstable as Haskell is? (Here I am really talking about _perceived_ instability, not real instability in the sense of _breaking_ changes – the above extensions are AFAIK not breaking, and many of our Haskell extensions are not breaking.) It is because we have the concept of a language extension in the first place! And, on top of that, now the concept of the current version of GHC Haskell. If we didn’t have that in the first place, and no Haskell standard, it’d just be the case that GHC-9.2 happens to be the first version where you can, say, derive Functor, and that’s it. My idea of GHC20xx is that it brings us closer to the Rust or Python model: Unless you tell GHC you want something else, you get the latest stable (in the sense of proven, not in the sense of unchanging) set of language features. And if you want something else (e.g. opt-out of new extensions, or try out experimental ones), you have to explicitly ask for it (e.g. pin the language version with -XGHC2021, or enable -XFancyTypes). A bit like using Rust nightly, just less hassle… So if you don’t actively do something, you get the same experience as in rust or python … and at this point I wonder why this experience is perceived as different as in these languages? (Again, I am focusing here on non-breaking, additive extensions. How to handle breaking changes is yet another discussion, of course, and one where peeking at Python or Rust is not always showing us the best way to do it.) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
To chime in with data from other communities, in Rust there is a concept of Edition [1]. They are, likewise, labelled by years. In your project file (Cargo.toml), you write something like `edition = '2021'`. This fixes a set of features. It is sold and perceived as a backward compatibility mechanism. If I set my edition, later Rust compilers will not break my code. If I want to benefit from new features which are backward incompatible, I will need to change the edition, and risk breakage then. There appears to be a new edition in Rust every 3 years. Which seems like a reasonable pace to me. [1]: https://doc.rust-lang.org/edition-guide/index.html On Tue, 8 Nov 2022 at 12:48, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi Tom,
thanks for your input! If I may (inadequadly) summarize what I read is that we should take into account stability and not just technical stability (your code doesn’t have to change as you upgrade your code), but also _perceived_ stability (there is GHC2021 and GH2023 and that’s confused).
I agree that this is imporant, and worth thinking more about.
In particular: How do other languages treat this? In one of my newsfeeds I recently read
Version 1.65.0 of the Rust language has been released. Improvements include generic associated types, a new let...else statement, and the ability to break from labeled blocks
and also
Version 3.10.0 of the Python language has been released. There are a lot of significant changes in this release, including the much- discussed structural pattern-matching feature.
so these (popular, non-scary) languages certainly don’t freeze their language, and do extend the language repeatedly. Why are they not preceived as unstable as Haskell is?
(Here I am really talking about _perceived_ instability, not real instability in the sense of _breaking_ changes – the above extensions are AFAIK not breaking, and many of our Haskell extensions are not breaking.)
It is because we have the concept of a language extension in the first place! And, on top of that, now the concept of the current version of GHC Haskell. If we didn’t have that in the first place, and no Haskell standard, it’d just be the case that GHC-9.2 happens to be the first version where you can, say, derive Functor, and that’s it.
My idea of GHC20xx is that it brings us closer to the Rust or Python model: Unless you tell GHC you want something else, you get the latest stable (in the sense of proven, not in the sense of unchanging) set of language features.
And if you want something else (e.g. opt-out of new extensions, or try out experimental ones), you have to explicitly ask for it (e.g. pin the language version with -XGHC2021, or enable -XFancyTypes). A bit like using Rust nightly, just less hassle…
So if you don’t actively do something, you get the same experience as in rust or python … and at this point I wonder why this experience is perceived as different as in these languages?
(Again, I am focusing here on non-breaking, additive extensions. How to handle breaking changes is yet another discussion, of course, and one where peeking at Python or Rust is not always showing us the best way to do it.)
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Thanks for that! Do I also have to bump the edition if I want to get my hands on new non-breaking features (e.g. new syntax that simply wasn't legal before)? 10.11.2022 10:19:06 Arnaud Spiwack <arnaud.spiwack@tweag.io>:
To chime in with data from other communities, in Rust there is a concept of Edition [1]. They are, likewise, labelled by years.
In your project file (Cargo.toml), you write something like `edition = '2021'`.
This fixes a set of features. It is sold and perceived as a backward compatibility mechanism. If I set my edition, later Rust compilers will not break my code. If I want to benefit from new features which are backward incompatible, I will need to change the edition, and risk breakage then.
There appears to be a new edition in Rust every 3 years. Which seems like a reasonable pace to me.
[1]: https://doc.rust-lang.org/edition-guide/index.html
On Tue, 8 Nov 2022 at 12:48, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi Tom,
thanks for your input! If I may (inadequadly) summarize what I read is that we should take into account stability and not just technical stability (your code doesn’t have to change as you upgrade your code), but also _perceived_ stability (there is GHC2021 and GH2023 and that’s confused).
I agree that this is imporant, and worth thinking more about.
In particular: How do other languages treat this? In one of my newsfeeds I recently read
Version 1.65.0 of the Rust language has been released. Improvements include generic associated types, a new let...else statement, and the ability to break from labeled blocks
and also
Version 3.10.0 of the Python language has been released. There are a lot of significant changes in this release, including the much- discussed structural pattern-matching feature.
so these (popular, non-scary) languages certainly don’t freeze their language, and do extend the language repeatedly. Why are they not preceived as unstable as Haskell is?
(Here I am really talking about _perceived_ instability, not real instability in the sense of _breaking_ changes – the above extensions are AFAIK not breaking, and many of our Haskell extensions are not breaking.)
It is because we have the concept of a language extension in the first place! And, on top of that, now the concept of the current version of GHC Haskell. If we didn’t have that in the first place, and no Haskell standard, it’d just be the case that GHC-9.2 happens to be the first version where you can, say, derive Functor, and that’s it.
My idea of GHC20xx is that it brings us closer to the Rust or Python model: Unless you tell GHC you want something else, you get the latest stable (in the sense of proven, not in the sense of unchanging) set of language features.
And if you want something else (e.g. opt-out of new extensions, or try out experimental ones), you have to explicitly ask for it (e.g. pin the language version with -XGHC2021, or enable -XFancyTypes). A bit like using Rust nightly, just less hassle…
So if you don’t actively do something, you get the same experience as in rust or python … and at this point I wonder why this experience is perceived as different as in these languages?
(Again, I am focusing here on non-breaking, additive extensions. How to handle breaking changes is yet another discussion, of course, and one where peeking at Python or Rust is not always showing us the best way to do it.)
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Do I also have to bump the edition if I want to get my hands on new non-breaking features (e.g. new syntax that simply wasn't legal before)?
Not that I know of. Rust has something kind of akin to extensions that they call unstable features. You can turn some of them on if you want to live on the edge (by adding a flag inside a file, e.g. `#![feature(box_syntax)]`). You have no guarantee of stability for them, they may even get removed in the next version of the compiler. (there was a time where unstable features were, in addition, only available in nightly builds I don't know if it's still the case). These unstable features get rolled in the compiler pretty quickly. And I believe that if they are backward compatible, they can get rolled in between editions (I'm not super practiced with Rust, so I don't pay a lot of attention to these details). I don't think that all the features have to be gated by a feature flag at some point. A strict improvement of the borrow checker would probably just be part of the next release. I should say that, anecdotally, editions have been pointed out to me as a reason why Rust is more stable than Haskell. /Arnaud
Hi, 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/proposal... 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. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
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/proposal...
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/proposal... 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@joachim-breitner.de http://www.joachim-breitner.de/
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@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/proposal...
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/proposal... <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@joachim-breitner.de <mailto:mail@joachim-breitner.de> http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
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.
Well, it will if that's what we vote on, but you are suggesting For each of the following extension, should it become part of
GHC2023? Please annotate with “strong yes”, “weak yes” or “no”.
I rather think we should *first *decide on GHC20xx cadence. Our advertised cadence is advertised as annual, but my instinct is that's too frequent. I'd just every 3 yrs, which appears to match Rust. Can we vote on that first? Simon On Sun, 8 Jan 2023 at 19:33, Chris Dornan <chris@chrisdornan.com> wrote:
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@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/proposal...
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/proposal...
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@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Hi, Am Dienstag, dem 10.01.2023 um 10:06 +0000 schrieb Simon Peyton Jones:
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.
Well, it will if that's what we vote on, but you are suggesting … Can we vote on that first?
That’s part of the vote – just don’t say “strong yes” for any option if you think it’s too early. “Strong yes” means “I think there should be a GHC2023 because of extension X”. If a majority votes at most “weak yes” to every extension, then there will be no GHC2023. I find a separate vote “should we have GHC2023” is not that meaningful if it would be equal to GHC2021 anyways (assuming no extenion gets then voted in) so it seems prudent to ask “Is there even any extension that warrants having GHC2023.”
I'd just every 3 yrs, which appears to match Rust.
I think the comparision is misleading. Rust bundles _breaking_ changes every 3 years. Nonbreaking, purely additive, syntax guarded, features come out continuously. If we follow their model, we can have GHC20xx yearly (or more often!), as long as we hold back _breaking_ changes to a three-yearly cadence. (Which seems quite a reasonably policy.) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
That’s part of the vote – just don’t say “strong yes” for any option if you think it’s too early. “Strong yes” means “I think there should be a GHC2023 because of extension X”.
It seems a very funny way to do it. I'd prefer to ask "what cadence do we want" and then move on to discuss features individually. At the moment I might think "yes, extension X belongs in the next GHC20xx", so do I vote yes or no for X? What do other members of the committee think about cadence? RSVP! You are a member! Simon On Tue, 10 Jan 2023 at 10:13, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,
Am Dienstag, dem 10.01.2023 um 10:06 +0000 schrieb Simon Peyton Jones:
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.
Well, it will if that's what we vote on, but you are suggesting … Can we vote on that first?
That’s part of the vote – just don’t say “strong yes” for any option if you think it’s too early. “Strong yes” means “I think there should be a GHC2023 because of extension X”. If a majority votes at most “weak yes” to every extension, then there will be no GHC2023.
I find a separate vote “should we have GHC2023” is not that meaningful if it would be equal to GHC2021 anyways (assuming no extenion gets then voted in) so it seems prudent to ask “Is there even any extension that warrants having GHC2023.”
I'd just every 3 yrs, which appears to match Rust.
I think the comparision is misleading. Rust bundles _breaking_ changes every 3 years. Nonbreaking, purely additive, syntax guarded, features come out continuously. If we follow their model, we can have GHC20xx yearly (or more often!), as long as we hold back _breaking_ changes to a three-yearly cadence. (Which seems quite a reasonably policy.)
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
Hi, Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
It seems a very funny way to do it. I'd prefer to ask "what cadence do we want" and then move on to discuss features individually. At the moment I might think "yes, extension X belongs in the next GHC20xx", so do I vote yes or no for X?
Ah, I see the confusion. The question is _not_ about “the next GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The answer may well be “no extension is pressing enough to make a release now”. A year ago we concluded to
don’t work on defining GHC2022, and the next update will be GHC2023 (or later).
and now we have to decide if it’s going to be GHC2023 or later. Maybe what I want to say is that by deciding whether we have GHC2023 or not, we are (implicitly) setting a precedence for what could become a regular cadence, should we not change our minds in the following years.
What do other members of the committee think about cadence? RSVP! You are a member!
I’m also curious :-) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
Empirically, I don't feel quite ready to make a call for GHC2023. So I think that I'd favour a 3-year cadence. On Tue, 10 Jan 2023 at 11:44, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,
Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
It seems a very funny way to do it. I'd prefer to ask "what cadence do we want" and then move on to discuss features individually. At the moment I might think "yes, extension X belongs in the next GHC20xx", so do I vote yes or no for X?
Ah, I see the confusion. The question is _not_ about “the next GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The answer may well be “no extension is pressing enough to make a release now”.
A year ago we concluded to
don’t work on defining GHC2022, and the next update will be GHC2023 (or later).
and now we have to decide if it’s going to be GHC2023 or later.
Maybe what I want to say is that by deciding whether we have GHC2023 or not, we are (implicitly) setting a precedence for what could become a regular cadence, should we not change our minds in the following years.
What do other members of the committee think about cadence? RSVP! You are a member!
I’m also curious :-)
Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
I'd personally rather spend our collective energies on landing the thoughts in our "Policy on Language Extensions" document. That is, work out any remaining points of disagreement and then move the document into the repo. In particular, if we end up in a place where we're content to add new syntax-guarded features without a new extension flag, that will, in turn, inform the GHC2023 idea. I don't have the bandwidth to both work on GHC's type-checker (as I'm doing weekly, as Simon and I coordinate) and push such a thing through. Though if no one else wants to land that document, I think it's worth my slowing down type-checker work for a few weeks to do so. So any other volunteers here? Sorry to redirect us from the immediate task at hand -- GHC2023 -- but one of my principles is that it's best to work out principles (i.e. our policy on extensions) before specifics. Richard
On Jan 11, 2023, at 4:29 AM, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Empirically, I don't feel quite ready to make a call for GHC2023. So I think that I'd favour a 3-year cadence.
On Tue, 10 Jan 2023 at 11:44, Joachim Breitner <mail@joachim-breitner.de <mailto:mail@joachim-breitner.de>> wrote: Hi,
Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
It seems a very funny way to do it. I'd prefer to ask "what cadence do we want" and then move on to discuss features individually. At the moment I might think "yes, extension X belongs in the next GHC20xx", so do I vote yes or no for X?
Ah, I see the confusion. The question is _not_ about “the next GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The answer may well be “no extension is pressing enough to make a release now”.
A year ago we concluded to
don’t work on defining GHC2022, and the next update will be GHC2023 (or later).
and now we have to decide if it’s going to be GHC2023 or later.
Maybe what I want to say is that by deciding whether we have GHC2023 or not, we are (implicitly) setting a precedence for what could become a regular cadence, should we not change our minds in the following years.
What do other members of the committee think about cadence? RSVP! You are a member!
I’m also curious :-)
Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de <mailto:mail@joachim-breitner.de> http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
I was just perusing the doc and after a flurry of activity it seems to be stalled in various places. I doubt we'll make more progress without someone actively driving it to a conclusion - several of the threads just end up in minor differences of opinion and nobody feels enough ownership to resolve them with edits directly. Meanwhile, the comments on the doc are getting a bit unwieldy to work with. Still, I think it has been super useful so far - in particular the idea of using the warning system instead of turning off extensions is a really nice simplification. I personally have sporadic time to work on this but probably not enough to satisfactorily drive it. Richard, I'd be very happy if you wanted to take this on; alternatively we can continue via email as best we can. I think we should next 1. Resolve the categorisation (Richard's in section 2 vs. mine in 2.2) 2. Resolve the strategy (Simon's sec 3 vs. Joachim's sec 4) Cheers Simon On Wed, 11 Jan 2023 at 13:28, Richard Eisenberg <lists@richarde.dev> wrote:
I'd personally rather spend our collective energies on landing the thoughts in our "Policy on Language Extensions" document. That is, work out any remaining points of disagreement and then move the document into the repo. In particular, if we end up in a place where we're content to add new syntax-guarded features without a new extension flag, that will, in turn, inform the GHC2023 idea.
I don't have the bandwidth to both work on GHC's type-checker (as I'm doing weekly, as Simon and I coordinate) and push such a thing through. Though if no one else wants to land that document, I think it's worth my slowing down type-checker work for a few weeks to do so. So any other volunteers here? Sorry to redirect us from the immediate task at hand -- GHC2023 -- but one of my principles is that it's best to work out principles (i.e. our policy on extensions) before specifics.
Richard
On Jan 11, 2023, at 4:29 AM, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Empirically, I don't feel quite ready to make a call for GHC2023. So I think that I'd favour a 3-year cadence.
On Tue, 10 Jan 2023 at 11:44, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,
Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
It seems a very funny way to do it. I'd prefer to ask "what cadence do we want" and then move on to discuss features individually. At the moment I might think "yes, extension X belongs in the next GHC20xx", so do I vote yes or no for X?
Ah, I see the confusion. The question is _not_ about “the next GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The answer may well be “no extension is pressing enough to make a release now”.
A year ago we concluded to
don’t work on defining GHC2022, and the next update will be GHC2023 (or later).
and now we have to decide if it’s going to be GHC2023 or later.
Maybe what I want to say is that by deciding whether we have GHC2023 or not, we are (implicitly) setting a precedence for what could become a regular cadence, should we not change our minds in the following years.
What do other members of the committee think about cadence? RSVP! You are a member!
I’m also curious :-)
Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Just to check: you are talking about this doc: Policy on language extensions <https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/edit?usp=sharing> I agree that it would be sensible to sort this doc first. Arnaud might be another possible driving force to getting it done? Simon On Wed, 11 Jan 2023 at 14:55, Simon Marlow <marlowsd@gmail.com> wrote:
I was just perusing the doc and after a flurry of activity it seems to be stalled in various places. I doubt we'll make more progress without someone actively driving it to a conclusion - several of the threads just end up in minor differences of opinion and nobody feels enough ownership to resolve them with edits directly. Meanwhile, the comments on the doc are getting a bit unwieldy to work with.
Still, I think it has been super useful so far - in particular the idea of using the warning system instead of turning off extensions is a really nice simplification.
I personally have sporadic time to work on this but probably not enough to satisfactorily drive it. Richard, I'd be very happy if you wanted to take this on; alternatively we can continue via email as best we can.
I think we should next 1. Resolve the categorisation (Richard's in section 2 vs. mine in 2.2) 2. Resolve the strategy (Simon's sec 3 vs. Joachim's sec 4)
Cheers Simon
On Wed, 11 Jan 2023 at 13:28, Richard Eisenberg <lists@richarde.dev> wrote:
I'd personally rather spend our collective energies on landing the thoughts in our "Policy on Language Extensions" document. That is, work out any remaining points of disagreement and then move the document into the repo. In particular, if we end up in a place where we're content to add new syntax-guarded features without a new extension flag, that will, in turn, inform the GHC2023 idea.
I don't have the bandwidth to both work on GHC's type-checker (as I'm doing weekly, as Simon and I coordinate) and push such a thing through. Though if no one else wants to land that document, I think it's worth my slowing down type-checker work for a few weeks to do so. So any other volunteers here? Sorry to redirect us from the immediate task at hand -- GHC2023 -- but one of my principles is that it's best to work out principles (i.e. our policy on extensions) before specifics.
Richard
On Jan 11, 2023, at 4:29 AM, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Empirically, I don't feel quite ready to make a call for GHC2023. So I think that I'd favour a 3-year cadence.
On Tue, 10 Jan 2023 at 11:44, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,
Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
It seems a very funny way to do it. I'd prefer to ask "what cadence do we want" and then move on to discuss features individually. At the moment I might think "yes, extension X belongs in the next GHC20xx", so do I vote yes or no for X?
Ah, I see the confusion. The question is _not_ about “the next GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The answer may well be “no extension is pressing enough to make a release now”.
A year ago we concluded to
don’t work on defining GHC2022, and the next update will be GHC2023 (or later).
and now we have to decide if it’s going to be GHC2023 or later.
Maybe what I want to say is that by deciding whether we have GHC2023 or not, we are (implicitly) setting a precedence for what could become a regular cadence, should we not change our minds in the following years.
What do other members of the committee think about cadence? RSVP! You are a member!
I’m also curious :-)
Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
On Thu, 12 Jan 2023 at 09:23, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Just to check: you are talking about this doc: Policy on language extensions <https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/edit?usp=sharing>
Yes
I agree that it would be sensible to sort this doc first.
Arnaud might be another possible driving force to getting it done?
Simon
On Wed, 11 Jan 2023 at 14:55, Simon Marlow <marlowsd@gmail.com> wrote:
I was just perusing the doc and after a flurry of activity it seems to be stalled in various places. I doubt we'll make more progress without someone actively driving it to a conclusion - several of the threads just end up in minor differences of opinion and nobody feels enough ownership to resolve them with edits directly. Meanwhile, the comments on the doc are getting a bit unwieldy to work with.
Still, I think it has been super useful so far - in particular the idea of using the warning system instead of turning off extensions is a really nice simplification.
I personally have sporadic time to work on this but probably not enough to satisfactorily drive it. Richard, I'd be very happy if you wanted to take this on; alternatively we can continue via email as best we can.
I think we should next 1. Resolve the categorisation (Richard's in section 2 vs. mine in 2.2) 2. Resolve the strategy (Simon's sec 3 vs. Joachim's sec 4)
Cheers Simon
On Wed, 11 Jan 2023 at 13:28, Richard Eisenberg <lists@richarde.dev> wrote:
I'd personally rather spend our collective energies on landing the thoughts in our "Policy on Language Extensions" document. That is, work out any remaining points of disagreement and then move the document into the repo. In particular, if we end up in a place where we're content to add new syntax-guarded features without a new extension flag, that will, in turn, inform the GHC2023 idea.
I don't have the bandwidth to both work on GHC's type-checker (as I'm doing weekly, as Simon and I coordinate) and push such a thing through. Though if no one else wants to land that document, I think it's worth my slowing down type-checker work for a few weeks to do so. So any other volunteers here? Sorry to redirect us from the immediate task at hand -- GHC2023 -- but one of my principles is that it's best to work out principles (i.e. our policy on extensions) before specifics.
Richard
On Jan 11, 2023, at 4:29 AM, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Empirically, I don't feel quite ready to make a call for GHC2023. So I think that I'd favour a 3-year cadence.
On Tue, 10 Jan 2023 at 11:44, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,
Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
It seems a very funny way to do it. I'd prefer to ask "what cadence do we want" and then move on to discuss features individually. At the moment I might think "yes, extension X belongs in the next GHC20xx", so do I vote yes or no for X?
Ah, I see the confusion. The question is _not_ about “the next GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The answer may well be “no extension is pressing enough to make a release now”.
A year ago we concluded to
don’t work on defining GHC2022, and the next update will be GHC2023 (or later).
and now we have to decide if it’s going to be GHC2023 or later.
Maybe what I want to say is that by deciding whether we have GHC2023 or not, we are (implicitly) setting a precedence for what could become a regular cadence, should we not change our minds in the following years.
What do other members of the committee think about cadence? RSVP! You are a member!
I’m also curious :-)
Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Arnaud might be another possible driving force to getting it done?
I can if you need me to. If you ask me to take the lead on this, I'll need a bit of time to come up with a good way of driving consensus. It seems to be a rather tricky subject :-) .
Thank you Arnaud! Simon On Fri, 20 Jan 2023 at 08:14, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Arnaud might be another possible driving force to getting it done?
I can if you need me to. If you ask me to take the lead on this, I'll need a bit of time to come up with a good way of driving consensus. It seems to be a rather tricky subject :-) .
On Nov 8, 2022, at 4:07 AM, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
(Who, if anyone, is the moderator of the ghc-steering-committee mailing list?)
I am. But perhaps it would be good to add a second moderator as well. Workload is very low -- maybe 1-2 requests per month, 90% of which are spam. I am happy to continue in this role, but there may be delays in delivery. Richard
Hi, feel free to add me. The command line tool listadmin makes dealing with such small very efficient. Cheers, Joachim Am Freitag, dem 11.11.2022 um 20:37 +0000 schrieb Richard Eisenberg:
On Nov 8, 2022, at 4:07 AM, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
(Who, if anyone, is the moderator of the ghc-steering-committee mailing list?)
I am. But perhaps it would be good to add a second moderator as well. Workload is very low -- maybe 1-2 requests per month, 90% of which are spam. I am happy to continue in this role, but there may be delays in delivery.
Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
Done. Thanks!
On Nov 12, 2022, at 4:04 AM, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,
feel free to add me. The command line tool listadmin makes dealing with such small very efficient.
Cheers, Joachim
Am Freitag, dem 11.11.2022 um 20:37 +0000 schrieb Richard Eisenberg:
On Nov 8, 2022, at 4:07 AM, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
(Who, if anyone, is the moderator of the ghc-steering-committee mailing list?)
I am. But perhaps it would be good to add a second moderator as well. Workload is very low -- maybe 1-2 requests per month, 90% of which are spam. I am happy to continue in this role, but there may be delays in delivery.
Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
participants (6)
-
Arnaud Spiwack -
Chris Dornan -
Joachim Breitner -
Richard Eisenberg -
Simon Marlow -
Simon Peyton Jones