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!
@acowley How it is better than 3-ghc-majors policy?
@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".
@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.
@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 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 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.