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
f { myRecord | myField = newValue } -- or
f { MkRecord | myField = newValue } -- data constructor version
I find record syntax so awkward I never use it. Can I vote for GHC2024 to include NoTraditionalRecordSyntax and NoFieldSelectors?
1 Like
Absolutely! A benefit of language editions is that we can make breaking changes like that in a way that doesn’t tie updating the language used to updating the GHC version (which you may be forced to). At least for module-local extensions like AcopedTypeVariables.
3 Likes
…and as I vaguely recall, the early implementations in GHC were very finicky (according to one of the “dual Simons”, I think) - someone else more knowledgable than me can inform us if that has now improved.
For me, the fact that functional dependencies made the Haskell type system Turing-complete was one reason to avoid it. Another was seeing some of the “poor-man’s Prolog” that it (ahem) “inspired”. So I find it somewhat contradictory to see people that seem to implicitly promote functional dependencies then also claim to speak on behalf of learners or beginners i.e. those new to Haskell.
Moreover, wasn’t the problems associated with functional dependencies ultimately one of the reasons for the interest in bringing dependant types to Haskell, via detours through associated types, type families and others? (or is that a mangled recollection on my part?)
1 Like
I’d say the implementation in GHC today is unacceptably dodgy (especially the interaction with Flexible/Overlapping Instances). It could be fixed up if as much effort went in to FunDeps as in to Type Families. (And don’t TFs also make the type system Turing-Complete? Or does the way it leaves unresolved instances just hanging make for some special variety of Undecidability?) “Could be”? Has been.
If that’s a dig at me: I wouldn’t propose FunDeps in their current form for beginners; but neither would I propose TFs. I don’t see that Dependent Types would be any easier for beginners. When learners progress a little way further, they’re going to need some type-manipulating behaviour. GHC20xx isn’t particularly aimed at beginners/learners, it appears. So hmm dunno.
I very much despise (though maybe that word’s a bit too harsh) the do “as a comma”.
To me (even with syntax highlighting) it just feels like another argument in the list:
myFunc a b =
doSomething otherVal a do theRest with b
andThen some indentedSection
This is just a string of text, compare:
myFunc a b =
doSomething otherVal a $ do theRest with b
andThen some indentedSection
Now I know it’s often done with a dangling do, but it still just feels like an argument to the preceding function, instead of a clear (non-text) separation of “text sections” (which are functions and their arguments)
At least, this is my reason to not like BlockArguments. That and I remember seeing/reading something about weird indenting interactions that make me not want to use it. (in some edge cases, I believe)
4 Likes
I assume you don’t have the same difficulty with:
myFunc a b =
if doSomething otherVal a then theRest with b
else some more
If not, do you have a guess as to why keywords then and do trigger different brain circuits?
3 Likes
Can we also assume you, @rhendric, don’t have any difficulty with:
myFunc a b = if
doSomething otherVal a then theRest with b
else some more
But if you do, could you guess why different circuits in your brain are being activated?
When looking at that code, my process appears to be to single out then and else as keywords that divide up the remainder of the body of the function, and then to object that then does not appear to be preceded by an if clause. So, uh, yeah, I guess that’s not having difficulty? I don’t know what point you’re trying to make.
I do hate putting the then after the if's expression, in fact.
I prefer using guards whenever possible, and IF I have to use an if-then-else, I want the then on the next line
myFunc a b =
if doSomething otherVal a
then theRest with b
else some more
But doing that with do-blocks is kind of weird since I’m used to the dangling do (and annoying because it introduces 3 space indenting) :
myFunc a b =
doSomething otherVal a
do theRest with b
andThen some indentedSection
2 Likes
The point is context.
Before do was allowed to drift wander float, it also preceded monadic expressions. This was something you just got acquainted with (i.e. it may very have activated the same brain circuit which recognises other “leading keywords” like module , import, export, data, newtype, let and case).
So to then see do now being used in this other way is anomalous, much like this probably is:
anotherFunc a b c d fee fi fo fum =
checkThat d fee if fo fum doSomething otherVal a c then theRest with b fi
else some more
…if not for you, then perhaps someone who’s begun to learn to use Haskell.
People have explained here the downsides of including OverloadedStrings. Are there any downsides to RecordWildCards?
1 Like
It makes large codebases unreadable.
4 Likes
It introduces symbols into scope that can not be traced back to where they come into scope without already knowing the fields of the data type they come from.
I.e. someone reading code that uses RecordWildCards will have a harder time figuring out which values in scope come from the record wild card and which come from global imports, for example.
7 Likes