For people who don’t like OverloadedStrings… how do you feel about numeric literals being overloaded by default? I was going to suggest that we add NoOverloadedNumbers which would make literals always be Integers as a joke… but actually I kind of like the idea!
9 Likes
Probably getting off-topic here, so maybe we spin this out into a separate thread, but - how much have you tried to use BlockArguments in anger? Like others, I find it indispensable and don’t really have any recollection of it being confusing/giving me weird syntax errors/etc. It’s always felt perfectly natural from the get-go. I’m curious if the syntactically baffling bit comes from having trialed it and having a poor experience by the end, or just comes from purely reading code?
12 Likes
I haven’t used it myself. I’ve just read code that uses it and it looks so alien that I feel discouraged from it. I also don’t find using $ inconvenient at all. I’ve changed my mind on plenty of things before though. This may become one of them.
3 Likes
I think the best explanation for BlockArguments's aversion is that it feels like someone is writting a very long text without commas. In this analogy $ is the comma, in case I wasn’t very clear 
2 Likes
I’d use BlockArguments if after enabling it there was a tool (like hlint) detecting redundant $ and telling me to remove them.
2 Likes
The do and the \ are already the comma, no need to put two commata in a row.
6 Likes
Just to clarify, does DisambiguateRecordFields works now or not ? Last time I tried to do something like
data A = A { x :: Int }
data B = B { x :: Int }
a = A 3
a' = a { x = 2 }
Wouldn’t work.
It won’t do type dependent name resolution, i.e. it only works if you use the constructor directly:
data A = A { x :: Int }
data B = B { x :: Int }
a = A { x = 2 }
even if I do a { x = 2 } :: A ? (or something ?)
In that case I don’t see the point of having it.
What about MultiWayIf, surely it is as inoffensive as ,let’s lambdaCase and Co …
7 Likes
Can we vote AGAINST (OverloadedStrings for example) ?
3 Likes
As long as you don’t want to vote against everything, you vote against by not checking a box 
At least that’s how I interpret the results. (Yes, maybe it would be more precise to also have “don’t care” and “don’t know”. But to get a Stimmungsbild this should be enough I hope.)
4 Likes
I voted yes for the option I like and no for the one I don’t have an opinion.
However I want to be able to vote against OverloadedString because it breaks exisiting code heavily.
This mean I have to turn the full GHC2024 off all together (and not benefit from all the option I voted for).
You could do
{-# LANGUAGE GHC2024 #-}
{-# LANGUAGE NoOverloadedStrings #-}
2 Likes
I didn’t think of that 
but this is because IMHO ultimately extensions which have been integrated into HaskellXX should be just part of the language with no way to disable them. If everybody agree that for example LambdaCase is good and harmless (people don’t have to use it after all) what is the point of having a NoLambdaCase extension ?
Does it alleviate your worries that OverloadedStrings is currently not on the ballot and so far I haven’t seen anyone nominate it?
2 Likes
Well it is on your list of option to vote for. I assumed that if enough people voted for it, you might press to include it. Otherwise what was a point of including it ???
1 Like
Considering that removing extensions is not an option, and that this vote is done in context of GHC2021, I think it’s worrying that ExplicitNamespaces currently only has gotten a vote from only 31% of participants. I would encourage those that didn’t vote for it to re-read the Why add ExplicitNamespaces? section in the GHC2024 and elaborate on their choice. It really doesn’t make sense to me. I hope that the committee will disregard the popular opinion in this instance. Do you really think it makes sense to have TypeOperators without ExplicitNamesapces @hasufell?
4 Likes
to put the numbers in perspective. If I just include the ones on the ballot, they all get 80%, then what does that mean? If we see that a representative samples of extensions not on the ballot all get 80% as well, then that tells a different story than if all others get 20%.
2 Likes