[ghc-steering-committee] GHC2024 voting

Moritz Angermann moritz.angermann at gmail.com
Thu Jan 4 10:53:13 UTC 2024


* [ ] 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 at 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 <iavor.diatchki at gmail.com>
> 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 <mail at joachim-breitner.de>
>> 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 at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240104/c9ea0ad4/attachment.html>


More information about the ghc-steering-committee mailing list