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