<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">
<blockquote dir="auto" class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>I'm not voting against.... I'm just not voting *for*!  I find that </div><div style="margin-left:40px">f x do { blah }</div>is hard to parse.  You may say that the same is true of record update:<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px">g x y { f=3 } <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">which was a bad mistake IMHO. But we are stuck with that one, and we don't have to add new ones.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
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.  </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">It is hardly a huge issue, but you asked, so I felt you deserved an explanation.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br>

</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 3 Jan 2024 at 16:48, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com">iavor.diatchki@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Greetings from an old member!<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Happy new year! </div><div dir="auto">Iavor</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 3, 2024, 03:21 Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" rel="noreferrer noreferrer" target="_blank">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Happy new year everyone!<br>
<br>
Am Freitag, dem 08.12.2023 um 18:54 +0100 schrieb Joachim Breitner:<br>
> Ballot boxes are upen until Jan 8th, but it is probably better for<br>
> everyone if votes are casted sooner. Maybe we can do it within a week?<br>
<br>
5 more days of voting, still waiting for the ballot from Moritz and<br>
Chris.<br>
<br>
So far, we have DerivingStrategies, DisambiguateRecordFields, GADTs<br>
with MonoLocalBinds and LambdaCase are definitely in, and TypeData and<br>
BlockArguments are definitely out.<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" rel="noreferrer noreferrer noreferrer" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" rel="noreferrer noreferrer noreferrer" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>