I wish #Haskell had as well thought out an edition system as #Rust. https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md
I think it would handle things like replacing `*` with `Type` quite nicely, for example. There would still be the question of the scope of the standard library, for which I’m unaware of an approach that makes everyone happy all the time, but keeping old code cleanly usable is so, so important, particularly for smaller communities!
@dpwiz Neither is a slam dunk, that’s for sure. What I really want to avoid is compiling some old code with a new compiler and having to manually address new errors that bring nothing of benefit to the old code. The RFC says, “Most code with warnings on edition N should, after running rustfix, compile on edition N+1 and have the same behavior.” It’s a soft goal, but the impression one gets is that the priority is on minimizing churn.
@dpwiz Also, I’m not trying to throw stones here. I was way more in the camp of gradual fixing when I had more time for Haskell maintenance. The simplified subsumption changes that hit with GHC 9 really turned me around. I had compilation errors all over, and the needed code changes were clunky.
@acowley So, this is -Wcompat? (=
To sum up, we have:
- Stackage LTS, pinning GHC major and a set of cross-compatible packages.
- -Wcompat for advance warnings.
- -XGHC2021 for baseline language features
- GHC proposal system to announce, plan ahead, and coordinate features.
What do we miss other than formal blessing that such-and-such GHC/LTS heralds a new "epoch"?
ghc/8.10.7 and its associated lts-18 appear to be something just like that.
And soon 9.6.x will come, that'll cement in GHC2021, text-2, etc etc
@dpwiz We’re missing a `ghcfix` tool that migrates code. But look at the simplified subsumption debate from last year to see differing attitudes about breakage. GHC devs felt that breaking 13% of library code (which seems to have been an undercount due to a mistaken heuristic), and an unknown amount of application code (which matters because libraries could compile without error while applications might not) was tolerable without any automated migration.
@dpwiz To be clear, all those things you’re mentioning are good, and I don’t think Rust’s approach is perfect. I wanted to take the opportunity to express my appreciation that the Rust approach very explicitly takes as its mission to minimize churn.
@dpwiz It’s similar, no doubt! I think I just get such good vibes from things like, “To be crystal clear: Rust compilers must support all extant editions, and a crate dependency graph may involve several different editions simultaneously. Thus, editions do not split the ecosystem nor do they break existing code.”
@acowley So, those are our stackage LTS snapshots? 
@dpwiz I don’t think LTS snapshots are the same as “Rust compilers must support all extant editions,” but I do really appreciate what LTS snapshots attempt to offer. It needs a lot of work if you want to contemplate patching an old release without the explicit help of a package author, and I don’t know if we have the work force available for that kind of thing in the community.
@acowley If anything, it would be python 2/3 and scala 2/3, regularly.
Maybe I just prefer gradual fixing instead of "patch tues-years".