GHC backward compatibility policy / support for GHC 7.6

[sjakobi]

Issues with supporting GHC 7.6 (the currently oldest supported version) have recently come up in

• 8700f2a#r36749989 (as a part of Add forM #592)
• WIP: NonEmptySet and NonEmptyMap #616 (comment)

That made me wonder whether support for 7.6 could be dropped? Are there any guidelines for how long containers wants to support old GHC versions?

I believe some packages look at the GHC versions in the current Debian stable or oldstable, which are 8.4 and 8.0 respectively.

[treeowl]

There is no policy that I know of. Last I looked, it appeared that the next time we gain anything significant is when we drop 7.8 and stop having to worry about pre-AMP stuff. A few people really do like to use recent containers versions with elderly GHC ones, but the utility certainly does trail off over time. There will be at least one particularly conservative Haskeller who complains bitterly when we drop 7.8, because he hates what happened with Foldable/Traversable. Aside from him, the main folks to worry about are GHC devs who like to try out random code on compilers going back a good ways to see how compile-time and run-time performance has looked historically. But they may not be looking as far back as 7.8 anymore. The easiest thing is to do nothing, until the maintenance burden imposed by the backwards compatibility actually starts to feel oppressive. But feel free to make a case, preferably coming up with a rough lower bound on the amount of cruft we'll be able to remove by dropping 7.8.

[sjakobi]

On master, I count

$ git grep "if __GLASGOW_HASKELL__ >= 708" | wc -l
35

To get rid of all this CPP, we only need to drop support for 7.6 (not 7.8 – you had little off-by-one error there @treeowl).

I think we should do this. This would also remove a hurdle for contributors, as seen in #592 and #616.

What do you say @treeowl?

[sjakobi]

Oops, sorry, AMP was indeed implemented in GHC 7.10 / base 4.8:

$ git grep "MIN_VERSION_base(4,8,0)" | wc -l
62

But as the count for the if __GLASGOW_HASKELL__ >= 708 condition shows, we'd already gain a lot by dropping support for 7.6.

[sjakobi]

$ git grep "if __GLASGOW_HASKELL__ >= 708" | wc -l
35

There's even a bit more CPP that we could get rid of by dropping 7.6:

$ git grep -E "GLASGOW_HASKELL__ .+ 707" | wc -l
3
$ git grep "MIN_VERSION_base(4,7,0)" | wc -l
3

[fumieval]

👍 to the idea. I'd prefer not to add CPP pragmas whenever working on a library.

[sjakobi]

Let's do this and drop support for GHC 7.6. Would you be interested in preparing a PR, @fumieval?

[fumieval]

Sure, I created #728

[sjakobi]

I'm under the impression that a lot of libraries are dropping support for GHC < 8.0 these days. For example haskell/bytestring#265. Would anyone mind if we'd do the same in containers?

[treeowl]

That's best discussed publicly, methinks.

[sjakobi]

That's best discussed publicly, methinks.

Anyone with a GitHub account can comment here?! Do you want me to invite comments on the libraries mailing list?

[treeowl]

Sorry, I was half asleep. In the past, I've solicited feedback on both the libraries list and haskell-cafe.

…

On Mon, Feb 22, 2021, 8:50 AM Simon Jakobi ***@***.***> wrote: That's best discussed publicly, methinks. Anyone with a GitHub account can comment here?! Do you want me to invite comments on the libraries mailing list? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#699 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOOF7KXTTH2BGPEUJB2TZTTAJOI3ANCNFSM4KFPIBQA> .

[meooow25]

GHC 7.6 was dropped in #812