I would love to see what we can consensually abolish. The existence of extra syntax and language features imposes a cost on whole ecosystem, not just GHC devs.
I would love the GHC Users Guide to be written assuming the language it’s describing is the most recent GHC202X. Then the extensions page can contain stuff like:
NoDeriveFunctor: disables the ability to derive Functor
I think that other thread has a slightly different topic. It mainly discusses the technical possibility of removing extensions and it explicitly states it isn’t meant for discussing specific extensions. In contrast, this thread asks about the benefits of removing extensions and asks for specific extensions that could be removed.
And I think we’re not flooded with new threads here on discourse, so I don’t mind having both these threads. But I could append all the comments in this thread to your earlier thread if you want.
Thanks, I agree this is a different topic, and I would like to come to more concrete and fruitful conclusions here.
I would love to see what we can consensually abolish. The existence of extra syntax and language features imposes a cost on whole ecosystem, not just GHC devs.
I hard agree with this.
Often Haskellers are wont to solve problems by adding features, but removing is a critical and fundamentally necessary part of an ecosystem.
The fact that GHC has never killed a feature seems to represent a short-term mindset that has doomed other languages to ridiculous feature manuals.
If we are going to deprecate language features, let’s make sure they have a at least 2 year deprecation warning phase. If 9.8 would come along deprecating some language features, and breaks code that worked fine in 9.6, we are on a sure way to kill haskell adoption.
In that case, they can’t be repackaged as plugins It would significantly regress GHC. On the other hand, if we make plugins properly compatible with cross compilers, then, yes this might be a good solution to make ghc more modular and lighter. I’m not sure how much of a performance impact it might have, and if we’d run into ordering issues (plugins x, needs to run before plugin y, …).
Ordering issues: start with the “lowest-hanging fruit” - plugins which can be used in any order…
Compatibility issue (with cross compilers): “low-hanging fruit” apparently all gone, so bring the chain-saw e.g. make the back-section (containing the code generator) into a standalone program which takes C-- as input.
…and also HBC: it had a standalone code generator in addition to the one in the primary executable, lmlcomp. For some reason, a different choice was made for GHC, and here we are.
I know some people use them, but I’d love to see TupleSections gone so that we could have (unambiguous) trailing commas for e.g. list syntax. It such an annoying syntactic wart that has led to the bizarre “leading comma” formatting workaround-but-not-really-a-workaround.
(I’d love to see just how necessary TupleSections really are compared to how many people could use trailing commas. I’d bet the ratio at least 100-to-1 in favor of trailing commas)
I’d be happy to see AlternativeLayoutRule gone, since it makes the lexer quite a bit more complex, while the extension itself is so obscure that it’s not even documented in the User’s Guide.
…and undoubtedly there will be disagreement about that list, as well as the other suggestions already here and elsewhere. All we can do is “hurry up and wait” e.g. for plugins to work everywhere, or “join in the fun”…
From my perspective the two features which incur large maintenance burden on my day-to-day work are safe haskell and backpack.
For each developer their list will be different, I mostly work on driver related code so regularly my work gets stalled on fixing an assumption or misimplementation in the backpack code. This does lead to frustration but also a low level of confidence that the backpack implementation is robust for serious use.