I welcome warmly the wish to whittle away the overwhelming worries over compatibility issues between warnings and errors, extension sets, options, and flags.
On compatibility, I’m still unsure of what to make of this as a library author. I would not want my choice of using
Stable to limit my imports to those libraries also compiled with
Stable, especially if its “Experimentality” is well-encapsulated by its API. I think bundles are a step in the right direction here, because while I fear that a full edition-based compilation pipeline is too restrictive, they sit at the sweet spot where a little goes a long way, in terms of conveying to the user (and maintainer!) what kind of Haskell-magic they’re allowed to perform. Some might call it overkill to call for a strict-edition-bundle-allow-list compiler pass through the entire ecosystem from their own cabal file, and I would agree, but such a tool could still be useful for directing eager maintainers upstream to help the community avoid bitrot. I cower in despair when I recompile Yesod on a new GHC and the dependency tree spits out pages of warnings from before the Semigroup-Monoid proposal. I think it’ll also reduce the amount of
CPP people have to write, too.
I do hope to try out the
Complete bundle someday soon. I think it will be difficult not to get carried away playing fill-in-the-blank with the language server.
You made no mention of GHC targeting WebAssembly. As I understand it currently requires a custom build, but as GHC grows its capabilities in these areas, I think we should also aim to capture this dimension of its behaviour.
I’m thrilled that you share the opinion that the
Safe infrastructure has decayed beyond the point of rehabilitation. When I started using Haskell in 2015 I could already see its bones. Occasionally revising a
Stable language edition and providing support with a wider range of compiler versions allows us to make stronger promises about build integrity while also blessing us with a sturdy foundation for other compiler improvements (e.g. the RTS).
As for which module gets to be the
Prelude… I still think that should be a part of the cabal file, maybe under an
implicit-imports: header. The only thing we can put there are modules we know about from the
build-depends:. That also lets us kill off