We come to the same conclusion though: explicitly enabled, on a per-module basis.
In that case, perhaps an example might be useful. Of course you can overdo it (pun intended) but especially for patterns like
I find it super useful. Same for writing lucid2, please look at how many $ you have to use, literally a fortune worth of syntactical noise!
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 Integer
s as a joke… but actually I kind of like the idea!
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?
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.
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
I’d use BlockArguments if after enabling it there was a tool (like hlint
) detecting redundant $
and telling me to remove them.
The do
and the \
are already the comma, no need to put two commata in a row.
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 …
Can we vote AGAINST (OverloadedStrings
for example) ?
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.)
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 #-}
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?
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 ???