* [x] DataKinds * [x] DefaultSignatures * [x] DerivingStrategies * [x] DisambiguateRecordFields * [x] ExplicitNamespaces * [x] GADTs with MonoLocalBinds * [ ] GADTs without MonoLocalBinds * [x] LambdaCase * [x] RoleAnnotations * [ ] TypeData * [x] TypeFamilies * [ ] BlockArguments (for BlockArguments, I just can't bring myself to care either way. Don't see this as a vote against: I simply have, in the most literal sense, no opinion) On Fri, 8 Dec 2023 at 19:03, Vladislav Zavialov wrote:

* [ ] DataKinds * [ ] DefaultSignatures * [x] DerivingStrategies * [x] DisambiguateRecordFields * [ ] ExplicitNamespaces * [x] GADTs with MonoLocalBinds * [x] GADTs without MonoLocalBinds * [x] LambdaCase * [ ] RoleAnnotations * [ ] TypeData * [ ] TypeFamilies * [x] BlockArguments

Vlad

On Fri, Dec 8, 2023 at 6:54 PM Joachim Breitner wrote:

...

Dear Committee,

there isn't much discussion, but maybe a silent consensus that we should go ahead with this?

So please cast your vote about each of the following extensions; simply by replying to this email and putting an x next to those extensions you think should be part of GHC2024.

* [ ] DataKinds * [ ] DefaultSignatures * [ ] DerivingStrategies * [ ] DisambiguateRecordFields * [ ] ExplicitNamespaces * [ ] GADTs with MonoLocalBinds * [ ] GADTs without MonoLocalBinds * [ ] LambdaCase * [ ] RoleAnnotations * [ ] TypeData * [ ] TypeFamilies * [ ] BlockArguments

As per the process (#372) the quorum for inclusion is _7 votes_ out of the 10 current committee members. So it takes only four “no”s to block an extension.

I’m putting GADTs in two both variants on the ballot. If “GADTs with MonoLocalBinds” makes it in, then its in, and only if not we look at “GADTs without MonoLocalBinds”. So it may make sense to vote in favor of both.

Ballot boxes are upen until Jan 8th, but it is probably better for everyone if votes are casted sooner. Maybe we can do it within a week?

Thanks, 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

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

Hi, Am Sonntag, dem 17.12.2023 um 21:24 +0000 schrieb Adam Gundry:

The proposal mentions ImpredicativeTypes, but it doesn't seem to appear on the ballot? (Personally I'm not in favour of including it, but was this an accidental omission?)

pure clerical error on my side, not sure how it happened. Sorry Arnaud (who proposed it). I guess it’s only fair to ask everyone to also cast a vote on ImpredicativeTypes. Sorry for the extra round-trip. Adam not in favor, I take. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

ImpredicativeTypes has been very successful, I think (i.e. few bug reports), and very non-disruptive (i.e even if it's on, code that doesn't use it goes on working). But still, I would give it a longer "outing" before having it on by default. So I'm mildly against. I'd put it on in the next iteration. But I don't feel strongly. Simon On Mon, 18 Dec 2023 at 08:09, Joachim Breitner wrote:

Hi,

Am Sonntag, dem 17.12.2023 um 21:24 +0000 schrieb Adam Gundry:

...

The proposal mentions ImpredicativeTypes, but it doesn't seem to appear on the ballot? (Personally I'm not in favour of including it, but was this an accidental omission?)

pure clerical error on my side, not sure how it happened. Sorry Arnaud (who proposed it).

I guess it’s only fair to ask everyone to also cast a vote on ImpredicativeTypes. Sorry for the extra round-trip.

Adam not in favor, I take.

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

Greetings from an old member! I am curious why folks are voting against BlockArguments? These days it and ImportQualifiedPost are the two extensions I turn on in pretty much any new project. Is the thinking that it it will be removed in the future? That would be very unfortunate, as I use it a lot, and the change would affect a lot of code. If not, are folks concerned about some sort of error it might cause? I see zero benefit in having to write BlockArguments in the extension field of my Cabal file, but it's also not that onerous, so not a big deal, just curious. Happy new year! Iavor On Wed, Jan 3, 2024, 03:21 Joachim Breitner wrote:

Happy new year everyone!

Am Freitag, dem 08.12.2023 um 18:54 +0100 schrieb Joachim Breitner:

...

Ballot boxes are upen until Jan 8th, but it is probably better for everyone if votes are casted sooner. Maybe we can do it within a week?

5 more days of voting, still waiting for the ballot from Moritz and Chris.

So far, we have DerivingStrategies, DisambiguateRecordFields, GADTs with MonoLocalBinds and LambdaCase are definitely in, and TypeData and BlockArguments are definitely out.

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

* [ ] DataKinds * [ ] DefaultSignatures * [x] DerivingStrategies * [x] DisambiguateRecordFields * [x] ExplicitNamespaces * [x] GADTs with MonoLocalBinds * [ ] GADTs without MonoLocalBinds * [x] LambdaCase * [ ] RoleAnnotations * [ ] TypeData * [ ] TypeFamilies * [ ] BlockArguments On Thu, 4 Jan 2024 at 5:19 AM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

I am curious why folks are voting against BlockArguments? These days it

...

and ImportQualifiedPost are the two extensions I turn on in pretty much any new project.

I'm not voting against.... I'm just not voting *for*! I find that f x do { blah } is hard to parse. You may say that the same is true of record update: g x y { f=3 } which was a bad mistake IMHO. But we are stuck with that one, and we don't have to add new ones.

It's just a matter of taste, I know, and I have no complaint about you using BlockArguments. But I didn't want to actively vote *for* adding it to GHC2024.

One thing that would change my mind is if 90%+ of the Haskell community always switched it in, as you do. But the poll only showed 43%; substantial but not overwhelming.

It is hardly a huge issue, but you asked, so I felt you deserved an explanation.

Simon

On Wed, 3 Jan 2024 at 16:48, Iavor Diatchki wrote:

...

Greetings from an old member!

I am curious why folks are voting against BlockArguments? These days it and ImportQualifiedPost are the two extensions I turn on in pretty much any new project.

Is the thinking that it it will be removed in the future? That would be very unfortunate, as I use it a lot, and the change would affect a lot of code. If not, are folks concerned about some sort of error it might cause?

I see zero benefit in having to write BlockArguments in the extension field of my Cabal file, but it's also not that onerous, so not a big deal, just curious.

Happy new year! Iavor

On Wed, Jan 3, 2024, 03:21 Joachim Breitner wrote:

...

Happy new year everyone!

Am Freitag, dem 08.12.2023 um 18:54 +0100 schrieb Joachim Breitner:

...

Ballot boxes are upen until Jan 8th, but it is probably better for everyone if votes are casted sooner. Maybe we can do it within a week?

5 more days of voting, still waiting for the ballot from Moritz and Chris.

So far, we have DerivingStrategies, DisambiguateRecordFields, GADTs with MonoLocalBinds and LambdaCase are definitely in, and TypeData and BlockArguments are definitely out.

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

I'm a huge fan of BlockArguments in limited doses. There are some good idioms with them, e.g. 1. bracket createResource destroyResource \resource -> do ... 2. when cond do ... 3. for elems \elem -> do ... Adding the `$` to those examples is just syntactic noise. It's quite clear what's going on without it. I know some people found ways to abuse BlockArguments, e.g. by prefixing each function argument with a `do`, and I'm not a fan of that. But with some sense of taste it's possible to put BlockArguments to good use. Vlad On Mon, Jan 8, 2024 at 5:54 PM Arnaud Spiwack wrote:

One thing that would change my mind is if 90%+ of the Haskell community

...

always switched it in, as you do. But the poll only showed 43%; substantial but not overwhelming.

Honestly, if we trust that ~45% of active Haskell programmers use BlockArgument, then I'd say it's a pretty convincing argument to include it. I'm absolutely not intent on using it (in fact, the mere existence of BlockArgument is a little baffling to me), but turning it on doesn't force me to use it. So if 50% of Haskellers care enough to actively turn on the extension, I think we can consider it a pretty compelling reason to have BlockArgument by default.

/Arnaud _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee