Deprecating Language Features

#1

Recently there’s been a discussion around deprecating SafeHaskell, and this year deep subsumption was semi-deprecated.

I am curious whether the myriad features that Haskell has incur a noticeable maintenance burden on Haskell?

Personally, I’d be willing to forgo some less-used features if it would improve GHC devs’ lives.

Full list of extensions

I am starting this thread because I am interested:

  1. How much maintenance burden is incurred by the pick-and-mix style language extension set
  2. Whether any extensions are right for the chop

Perhaps also there are non-extension features that are not great on the cost-benefit curve.

6 Likes
OverloadedStringDefault proposal
Seeking feedback on language editions proposal
Language, library, and compiler stability (moved from GHC 9.6 Migration guide)
#2

My list of extensions that I have never used and probably never will:

I also think NegativeLiterals can be removed in favor of LexicalNegation.

6 Likes
#3

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.

7 Likes
#4
4 Likes
#5

I totally forgot about that :sweat_smile:

I think it’s still a valuable to have. But let me know if I should delete @jaror

1 Like
#6

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

4 Likes
#7

Haha, I had also forgotten that.

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.

1 Like
#8

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.

1 Like
#9

Dumb question for this thread: how many of these extensions/features could be repackaged as plugins?

1 Like
#11

Do plugins work with cross compilers?

1 Like
#12

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.

4 Likes
#13

…I’m going to say “no”:

…confirmed:

1 Like
#14

In that case, they can’t be repackaged as plugins :frowning_face: 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, …).

1 Like
#15

  • 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.

1 Like
#16

This is pretty close to what @csabahruska actually does.

Multi-target GHC might be workable middle ground as well. Getting plugins to work with cross compilers is actually something we should fix.

So, I’d rather advocate for:

  • fix plugin defects today
  • consider moving extensions into plugins.
  • build plugins on demand (even for novel extensions).
1 Like
#17

…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.

1 Like
#18

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)

3 Likes
#19

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.

9 Likes
#20

AlternativeLayoutRule isn’t alone:

…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”…

2 Likes
#21

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.

16 Likes
Pre-GHC-Proposal: Instantiate backpack signatures when importing