We come to the same conclusion though: explicitly enabled, on a per-module basis. 
2 Likes
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 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
Maintaining haskell programs - #76 by ocharles still works
1 Like
The do and the \ are already the comma, no need to put two commata in a row.
6 Likes
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 }
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
You could do
{-# LANGUAGE GHC2024 #-}
{-# LANGUAGE NoOverloadedStrings #-}
2 Likes
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
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
I strongly suspect this comes down to the lack of a third option on the poll. It’s not a particularly well-known extension, so more of the 69% are likely to be "don’t care"s than actual "no"s.
2 Likes
I shared this thought initially, but my fervent hope is that GHC20XX will not be de facto “append-only”. That is, I don’t see the harm in adding TypeFamilies now if they are subsequently removed if/when we get real promoted functions a la DependentTypes (to be clear, I am mostly indifferent on if TypeFamilies get in).
IMO @Ericson2314 is right to highlight the tension between goals (unified default language) and implementation (language extension zoo). The fact that each extension is ostensibly independent puts an enormous burden on design and implementation.
5 Likes
Yeah a big test for me is — can we get rid of TypeFamilies and ScopedTypeVariables later, once we have better alternatives?
3 Likes
Hmm? That seems at odds with what you say over here. Or perhaps “learners” is not the same as “beginners”(?)
Then where is “the Haskell for beginners” you talk about? H2010 is not it. AFAICT GHC top brass have just stopped caring how newbies could possibly scale the dizzying heights to get in to the GHC fortress. Could I suggest there be a much smaller set of extensions GHCNursery that Introductory texts could talk about, and would not keep moving about? (I call it Hugs – stable since 2006.)
(As I’ve just said over there on Github …) I don’t see the point in these repeated discussions of GHC20xx content. Everybody’s going to end up disappointed – probably by both their favourite extension getting excluded and their most-hated extension getting included. So everybody’s code will end up adding/subtracting some extensions.
If you’re going to individually mangle some extensions, you might as well mangle them all. (It’s only newbies we need protect from mangling-effects.) H2010 is certainly inadequate, but at least it’s a known evil – as in we all know it.
Unfortunately, Discourse requires …, so there is no space for a “None” option
I vote for “None”. Indeed I vote to take out ScopedTypeVariables.
ScopedTypeVariablesbreaks GHC’s usual rule that explicitforallis optional and doesn’t affect semantics. [from the ! in the docos]
It’s ghastly! How was it ever allowed in to GHC? I hate it so much I put in a Proposal to severely prune its behaviour, and GHC’s over-enthusiasm for suggesting it in error messages. Proposal accepted. I vote for that in GHC2024, and I suggest GHC2024 isn’t released until it’s included.
3 Likes