GHC2024 committee deliberation

newer
Please review #624: Linear lets,...

Joachim Breitner

6 Nov 2023 6 Nov '23

4:10 a.m.

Dear Committee, I’d like to get the committe involvement in GHC2024 started. The current proposal is at https://github.com/ghc-proposals/ghc-proposals/pull/613 https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposal... At the moment, six changes relative to CHC2021 are proposed by committee and by community members. See the proposal for rationales. My goal is to have a decision in time for 9.10. I suggest we use November to deliberate the proposals and maybe add more changes to the list, and then vote in early December. We’ll put each change separately on the ballot. I know that there are ongoing discussions that could arguably affect how we want the next GHC20xx to look like, in particular the just opened #620, and I anticipate a desire to postpone GHC2024 until that has been decided. But I recall that we postponed GHC2023 for (among other reasons) for the same reason, and I wouldn’t be surprised that if in a year we have yet another unresolved question that seems worth waiting for. If this pattern reminds you of the GHC release process before we introduced the regular cadence, then maybe you’ll agree that if we want a predictable and reasonable frequent stream of language editions, we have to avoid such delays when feasible. So please let us know what you think of the proposed changes, what other changes you want to see, or if you have qualms about the process. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Show replies by date

Arnaud Spiwack

6 Nov 6 Nov

9:20 a.m.

I've just pushed a bunch of extra proposed extensions (then I saw that you changed the label, and then I went and found your email). It's already more than 6. In the thread, there's also a proposal for BlockArgument that has yet to be added to the proposal. maybe you’ll agree that

...

if we want a predictable and reasonable frequent stream of language editions, we have to avoid such delays when feasible.

I, for one, favour a regular cadence, too. On Mon, 6 Nov 2023 at 10:10, Joachim Breitner wrote:

...

Dear Committee,

I’d like to get the committe involvement in GHC2024 started. The current proposal is at https://github.com/ghc-proposals/ghc-proposals/pull/613

https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposal...

At the moment, six changes relative to CHC2021 are proposed by committee and by community members. See the proposal for rationales.

My goal is to have a decision in time for 9.10. I suggest we use November to deliberate the proposals and maybe add more changes to the list, and then vote in early December. We’ll put each change separately on the ballot.

I know that there are ongoing discussions that could arguably affect how we want the next GHC20xx to look like, in particular the just opened #620, and I anticipate a desire to postpone GHC2024 until that has been decided. But I recall that we postponed GHC2023 for (among other reasons) for the same reason, and I wouldn’t be surprised that if in a year we have yet another unresolved question that seems worth waiting for. If this pattern reminds you of the GHC release process before we introduced the regular cadence, then maybe you’ll agree that if we want a predictable and reasonable frequent stream of language editions, we have to avoid such delays when feasible.

So please let us know what you think of the proposed changes, what other changes you want to see, or if you have qualms about the process.

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

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Joachim Breitner

21 Nov 21 Nov

12:18 p.m.

Hi, thanks for pushing more and well-justified proposals. Allow me to collect my thoughts on the individual additions proposed at https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposal... (generally, I’m guess I'm an inclusionist here) * DataKinds and TypeData Leaning towards yes for DataKinds, unsure for TypeData, and will bow in if this turns out to be contentious. It feels like a step in the right direction, but I am not a heavy user. * DerivingStrategies Being more explicit seems to be useful, e.g. with documentation, and it certainly doesn’t hurt. In favor. * DisambiguateRecordFields Small quality-of-life improvement, so sure, why not. In favor, unless I am missing something (peeks at Adam’s exam paper to copy the answer) * ExplicitNamespaces Again, being explicit is good, and it solves this oddity with language implications not being consistent with language editions (TypeOperators implies ExplicitNamespaces, but only the former is in gHC2021). In favor. * GADTs To me, they are just a normal part of what Haskell is these days. Let’s declare them so. * MonoLocalBinds Not an expert, but people say it’s simpler and needed to stay sane with GADTs. Yes, sometimes annoying (local parser helper etc.), but in those cases an explicit type signature is probably nice as well. Leaning towards yes. * ImpredicativeTypes Trusting Arnaud here, so sure. * LambdaCase In favor. I have seen code bases making good use of it, and it fits Haskell with it’s tendency to favor the point-free style. Happy to include (including the n-ary \cases variant). * RoleAnnotations Yes! It’s just something you need to build proper abstractions these days * TypeFamilies If we add GADTs (and MonoLocalBinds), I wouldn’t mind type families as well. I follow the argument that _if_ there is going to be a breaking change to their design in the future (evaluation order or something), it probably needs to be in a separate extension, given the amount of code out there already, and thus GHC2024 will continue to work. I hope. (It’s a bit optimistic for type-level stuff, which is not local to one module). Hmm, guess I ended up saying yes to all, but with varying levels of confidence. I trust the collective wisdom of the committee will find the right selection in the end. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Simon Peyton Jones

4:06 p.m.

...

* MonoLocalBinds

Not an expert, but people say it’s simpler and needed to stay sane with GADTs. Yes, sometimes annoying (local parser helper etc.), but in those cases an explicit type signature is probably nice as well. Leaning towards yes.

I agree. But I have been increasingly realising that really the extension should be called PolyLocalBinds, and MonoLocalBinds should be a synonym for NoPolyLocalBinds. Reason: extensions generally allow more programs, not fewer. PolyLocalBinds does that -- at the expense of less predictable type inference. To get predictable type inference with GADTs we switch PolyLocalBinds off. You may think this is just moving the deck chairs around, but I think this renaming is a more consistent story. Simon On Tue, 21 Nov 2023 at 17:18, Joachim Breitner wrote:

...

Hi,

thanks for pushing more and well-justified proposals.

Allow me to collect my thoughts on the individual additions proposed at

https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposal... (generally, I’m guess I'm an inclusionist here)

* DataKinds and TypeData

Leaning towards yes for DataKinds, unsure for TypeData, and will bow in if this turns out to be contentious. It feels like a step in the right direction, but I am not a heavy user.

* DerivingStrategies

Being more explicit seems to be useful, e.g. with documentation, and it certainly doesn’t hurt. In favor.

* DisambiguateRecordFields

Small quality-of-life improvement, so sure, why not. In favor, unless I am missing something (peeks at Adam’s exam paper to copy the answer)

* ExplicitNamespaces

Again, being explicit is good, and it solves this oddity with language implications not being consistent with language editions (TypeOperators implies ExplicitNamespaces, but only the former is in gHC2021). In favor.

* GADTs

To me, they are just a normal part of what Haskell is these days. Let’s declare them so.

* MonoLocalBinds

Not an expert, but people say it’s simpler and needed to stay sane with GADTs. Yes, sometimes annoying (local parser helper etc.), but in those cases an explicit type signature is probably nice as well. Leaning towards yes.

* ImpredicativeTypes

Trusting Arnaud here, so sure.

* LambdaCase

In favor. I have seen code bases making good use of it, and it fits Haskell with it’s tendency to favor the point-free style. Happy to include (including the n-ary \cases variant).

* RoleAnnotations

Yes! It’s just something you need to build proper abstractions these days

* TypeFamilies

If we add GADTs (and MonoLocalBinds), I wouldn’t mind type families as well. I follow the argument that _if_ there is going to be a breaking change to their design in the future (evaluation order or something), it probably needs to be in a separate extension, given the amount of code out there already, and thus GHC2024 will continue to work. I hope. (It’s a bit optimistic for type-level stuff, which is not local to one module).

Hmm, guess I ended up saying yes to all, but with varying levels of confidence. I trust the collective wisdom of the committee will find the right selection in the end.

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

Joachim Breitner

4:11 p.m.

Hi, Am Dienstag, dem 21.11.2023 um 21:06 +0000 schrieb Simon Peyton Jones:

...

I agree. But I have been increasingly realising that really the extension should be called PolyLocalBinds, and MonoLocalBinds should be a synonym for NoPolyLocalBinds.

Reason: extensions generally allow more programs, not fewer. PolyLocalBinds does that -- at the expense of less predictable type inference. To get predictable type inference with GADTs we switch PolyLocalBinds off.

You may think this is just moving the deck chairs around, but I think this renaming is a more consistent story.

I am a big fan of nicely arranged seating on deck. So if we think it’s useful, I think we can add this to GHC2024 as NoPolyLocalBinds, retrofit PolyLocalBinds into the previous editions, and make the (No)MonoLocalBinds flags just aliases. I can add this as a rider to the GHC2024 vote. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Arnaud Spiwack

22 Nov 22 Nov

2:36 a.m.

Joachim: you didn't opine on default type signatures. By the way, is it you kicking off the deliberation? On Tue, 21 Nov 2023 at 22:11, Joachim Breitner wrote:

...

Hi,

Am Dienstag, dem 21.11.2023 um 21:06 +0000 schrieb Simon Peyton Jones:

...
I agree. But I have been increasingly realising that really the extension should be called PolyLocalBinds, and MonoLocalBinds should be a synonym for NoPolyLocalBinds.

Reason: extensions generally allow more programs, not fewer. PolyLocalBinds does that -- at the expense of less predictable type inference. To get predictable type inference with GADTs we switch PolyLocalBinds off.

You may think this is just moving the deck chairs around, but I think this renaming is a more consistent story.

I am a big fan of nicely arranged seating on deck. So if we think it’s useful, I think we can add this to GHC2024 as NoPolyLocalBinds, retrofit PolyLocalBinds into the previous editions, and make the (No)MonoLocalBinds flags just aliases. I can add this as a rider to the GHC2024 vote.

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

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Joachim Breitner

4:41 a.m.

Hi, Am Mittwoch, dem 22.11.2023 um 08:36 +0100 schrieb Arnaud Spiwack:

...

Joachim: you didn't opine on default type signatures.

ups, scrolled past it. My gut feeling about that extension is that it feels relatively ad-hoc and specialized. Just look at the long list of “Detailed requirements for default type signatures” that go along with it! I’m hesitant to put into the curriculum of “contemporary Haskell”. We’ll see.

...

By the way, is it you kicking off the deliberation?

I tried to kick it off already with the email from Nov 6, but yes, I am also writing my thoughts to stir more discussion. I hope we can start voting in two weeks. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Arnaud Spiwack

8:47 a.m.

We're currently proposing the inclusion of 12 extensions. Someone also proposed BlockArguments in the thread, but it hasn't found a champion to add it to the proposal (I won't be this champion, I find myself quite unable to argue for or against it). This'd bring us to 59 of the ~130 extensions. Almost halfway there! (considering that some are deprecated or mere aliases, it's actually rather better than it looks). Maybe I should add QualifiedDo, too. I like QualifiedDo, and I don't envision any change to it. Any thoughts on this one? On Wed, 22 Nov 2023 at 10:41, Joachim Breitner wrote:

...

Hi,

Am Mittwoch, dem 22.11.2023 um 08:36 +0100 schrieb Arnaud Spiwack:

...
Joachim: you didn't opine on default type signatures.

ups, scrolled past it.

My gut feeling about that extension is that it feels relatively ad-hoc and specialized. Just look at the long list of “Detailed requirements for default type signatures” that go along with it! I’m hesitant to put into the curriculum of “contemporary Haskell”. We’ll see.

...
By the way, is it you kicking off the deliberation?

I tried to kick it off already with the email from Nov 6, but yes, I am also writing my thoughts to stir more discussion. I hope we can start voting in two weeks.

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

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Joachim Breitner

9:42 a.m.

Hi, Am Mittwoch, dem 22.11.2023 um 14:47 +0100 schrieb Arnaud Spiwack:

...

Someone also proposed BlockArguments in the thread, but it hasn't found a champion to add it to the proposal (I won't be this champion, I find myself quite unable to argue for or against it).

actually, I like that one, and just put it on the tally. Having worked with languages that already have it (lean) I appreciate its de-noising effect on syntax.

...

This'd bring us to 59 of the ~130 extensions. Almost halfway there! (considering that some are deprecated or mere aliases, it's actually rather better than it looks).

Now is there a way to `git rebase -i` our collective minds so that instead of 59 extensions, we have 4 language editions? :)

...

Maybe I should add QualifiedDo, too. I like QualifiedDo, and I don't envision any change to it. Any thoughts on this one?

Feels a bit too new to me, I haven’t seen it in action enough (but I also haven’t been looking). Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Joachim Breitner

3:25 p.m.

Hi, it was brought to my attention that the proposal that introduced GHC20xx actually laid out a specific process to decide about the next GHC20xx: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-gh... This includes “secretary tallies usage on Hackage” and “secretary runs a public poll”, and also wants to do all these things on _all_ extensions, instead on focusing on those that least someone nominates, and requires every committee member to independently propose a set of extensions. I’m not sure to what extend we should tie ourselves to a process we imagined three years ago. But if anyone things we should do one of these things, we can. I guess I could at least do a simple poll on discourse with the currently proposed extensions. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Joachim Breitner

4:11 p.m.

Am Mittwoch, dem 22.11.2023 um 21:25 +0100 schrieb Joachim Breitner:

...

I guess I could at least do a simple poll on discourse with the currently proposed extensions.

Now at https://discourse.haskell.org/t/ghc2024-community-input/8168. Not perfect (e.g. number of options on Discourse are limited), but it’s something. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Joachim Breitner

30 Nov 30 Nov

1:30 p.m.

Hi all, Am Mittwoch, dem 22.11.2023 um 22:11 +0100 schrieb Joachim Breitner:

...

Am Mittwoch, dem 22.11.2023 um 21:25 +0100 schrieb Joachim Breitner:

...
I guess I could at least do a simple poll on discourse with the currently proposed extensions.

Now at https://discourse.haskell.org/t/ghc2024-community-input/8168. Not perfect (e.g. number of options on Discourse are limited), but it’s something.

after a week, we got 137 people to vote. This is of course not representative of our full target audience, but still useful input. For example, I didn’t expect LambdaCase to be that popular (84%). Other interesting bits: * DerivingVia is the most popular extension that we do _not_ have on the ballot for 2024, with 62%. I think it's reasonable, I woudn’t mind maturing it a for another edition cycle or so; there was talk about improving error messages. * Lots of discussion about BlockArguments, but mostly along the lines of “I use it (in Haskell or other languages), it’s great” vs. “It don’t use it, it looks weird to me.”. My hypothesis is that it is no harder to get used to than application-by-juxtaposition or $ or other keywords, so I’m still in favor. Anyways, have a look if you are curious, and take it into account in your voting if I want. So where do we stand? Does everyone in the committee have the information they need to cast a vote? Should we just go ahead with voting, or would some committee members maybe share an assessment of the currently proposed extensions at https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposal... to help people decide? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Simon Peyton Jones

4 Dec 4 Dec

7:40 a.m.

...

So where do we stand?

- I'm happy for us to define GHC2024 now. - I do not feel strongly about the exact list of extensions... for me this is very user-driven. - The votes were interesting. I would also love to see stats on extension usage, derived from trawling Hackage. I'm sure this has been done, probably many times. Do we have data? - Several features were suggested that got more votes than the ones currently in the GHC2024 proposal. Why exclude them from our committee voting? E.g. RecordWildCards seems popular. - Some extensions come down to taste. Personally I don't like `BlockaArguments` but clearly quite a lot of people do. So I don't really object. - Other extensions are "big": MonoLocalBinds and TypeFamilies in particular. I'm OK with including them> - I would argue (mildly) against DefaultSignatures. It's a mature and stable extension, but a pretty tricky, speicalised and ad-hoc one. Data from usage in Hackage might affect my opinion! Simon On Thu, 30 Nov 2023 at 18:30, Joachim Breitner wrote:

...

Hi all,

Am Mittwoch, dem 22.11.2023 um 22:11 +0100 schrieb Joachim Breitner:

...
Am Mittwoch, dem 22.11.2023 um 21:25 +0100 schrieb Joachim Breitner:

...
I guess I could at least do a simple poll on discourse with the currently proposed extensions.

Now at https://discourse.haskell.org/t/ghc2024-community-input/8168. Not perfect (e.g. number of options on Discourse are limited), but it’s something.

after a week, we got 137 people to vote. This is of course not representative of our full target audience, but still useful input. For example, I didn’t expect LambdaCase to be that popular (84%). Other interesting bits:

* DerivingVia is the most popular extension that we do _not_ have on the ballot for 2024, with 62%. I think it's reasonable, I woudn’t mind maturing it a for another edition cycle or so; there was talk about improving error messages.

* Lots of discussion about BlockArguments, but mostly along the lines of “I use it (in Haskell or other languages), it’s great” vs. “It don’t use it, it looks weird to me.”. My hypothesis is that it is no harder to get used to than application-by-juxtaposition or $ or other keywords, so I’m still in favor.

Anyways, have a look if you are curious, and take it into account in your voting if I want.

So where do we stand? Does everyone in the committee have the information they need to cast a vote? Should we just go ahead with voting, or would some committee members maybe share an assessment of the currently proposed extensions at

https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposal... to help people decide?

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

Joachim Breitner

8:24 a.m.

Hi, Am Montag, dem 04.12.2023 um 12:40 +0000 schrieb Simon Peyton Jones:

...

* I'm happy for us to define GHC2024 now.

Yay :-)

...

* The votes were interesting. I would also love to see stats on extension usage, derived from trawling Hackage. I'm sure this has been done, probably many times. Do we have data?

Not at the moment. Any volunteers to gather them?

...

* Several features were suggested that got more votes than the ones currently in the GHC2024 proposal. Why exclude them from our committee voting? E.g. RecordWildCards seems popular.

Nobody actively nominated them as part of https://github.com/ghc-proposals/ghc-proposals/pull/613 I guess you get different result is you ask in what place “please actively nominate what you want to see” and in another, more crowded place “here is a long list of option, just tick what you like”. In the concrete case of RecordWildCards there are also strongly held believes against it (it violates the LSP). Maybe that’s why nobody nominated it. (I personally like to use it occasionally, but that’s the reason why _I_ wouldn’t push for it.) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Joachim Breitner

8:26 a.m.

Hi, Am Montag, dem 04.12.2023 um 14:24 +0100 schrieb Joachim Breitner:

...

In the concrete case of RecordWildCards there are also strongly held believes against it (it violates the LSP). Maybe that’s why nobody nominated it.

or maybe not, it doesn't really need the type system, does it? But very close in spirit – you cannot determine the binding structure from just looking at a single module. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Arnaud Spiwack

9:57 a.m.

On this topic, I really like NamedFieldPuns, what do we think about it? I sometimes feel I'm the only person in the world using them (borrowing from Ocaml where they're pretty common). But, on the other hand, I really like them. On Mon, 4 Dec 2023 at 14:26, Joachim Breitner wrote:

...

Hi,

Am Montag, dem 04.12.2023 um 14:24 +0100 schrieb Joachim Breitner:

...
In the concrete case of RecordWildCards there are also strongly held believes against it (it violates the LSP). Maybe that’s why nobody nominated it.

or maybe not, it doesn't really need the type system, does it? But very close in spirit – you cannot determine the binding structure from just looking at a single module.

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

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Joachim Breitner

10:30 a.m.

Hi, Am Montag, dem 04.12.2023 um 15:57 +0100 schrieb Arnaud Spiwack:

...

On this topic, I really like NamedFieldPuns, what do we think about it? I sometimes feel I'm the only person in the world using them (borrowing from Ocaml where they're pretty common). But, on the other hand, I really like them.

same here. My impression is that they have become common place in a few languages now, and there is no reason not to have them in Haskell as well. THB, if this was a pubquiz I’d have lost a point by guessing that it’s already part of GHC2021. Ah, no, I do win the points: They are in GHC2021 according to https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/control.html#... Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Arnaud Spiwack

10:40 a.m.

Good. You win the pub quiz, I lose. But it's the sweetest kind of defeat. On Mon, 4 Dec 2023 at 16:30, Joachim Breitner wrote:

...

Hi,

Am Montag, dem 04.12.2023 um 15:57 +0100 schrieb Arnaud Spiwack:

...
On this topic, I really like NamedFieldPuns, what do we think about it? I sometimes feel I'm the only person in the world using them (borrowing from Ocaml where they're pretty common). But, on the other hand, I really like them.

same here. My impression is that they have become common place in a few languages now, and there is no reason not to have them in Haskell as well.

THB, if this was a pubquiz I’d have lost a point by guessing that it’s already part of GHC2021.

Ah, no, I do win the points: They are in GHC2021 according to

https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/control.html#...

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Chris Dornan

22 Nov 22 Nov

11:33 p.m.

Joachim, Gathering some data might be a good idea, provided the secretary is banned from doing this! (I mean it is really, really bad idea to load up the secretary with these kinds of activities.) I am not in favour of polling. We collect that kind of data in the survey -- can we not use that? Advertising the ghc-proposal issue in the usual places should be sufficient. Otherwise I fear we would be inviting problems and poor decisions. Chris

...

On 22 Nov 2023, at 20:25, Joachim Breitner wrote:

Hi,

it was brought to my attention that the proposal that introduced GHC20xx actually laid out a specific process to decide about the next GHC20xx: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-gh...

This includes “secretary tallies usage on Hackage” and “secretary runs a public poll”, and also wants to do all these things on _all_ extensions, instead on focusing on those that least someone nominates, and requires every committee member to independently propose a set of extensions.

I’m not sure to what extend we should tie ourselves to a process we imagined three years ago. But if anyone things we should do one of these things, we can.

I guess I could at least do a simple poll on discourse with the currently proposed extensions.

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

Joachim Breitner

23 Nov 23 Nov

2:54 a.m.

Hi, Am Donnerstag, dem 23.11.2023 um 04:33 +0000 schrieb Chris Dornan:

...

I am not in favour of polling. We collect that kind of data in the survey -- can we not use that?

unfortunately it seems the survey hasn’t happened for a while. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

533

Age (days ago)

561

Last active (days ago)

List overview

Download

19 comments

4 participants

participants (4)

Arnaud Spiwack
Chris Dornan
Joachim Breitner
Simon Peyton Jones

GHC2024 committee deliberation

tags

participants (4)