I like the motivation a lot, though, especially the point “The primary motivation behind the use of language editions is that they can succinctly inform GHC what kind of user it’s faced with, so GHC can behave accordingly.”
Personally, I have no issue with language extensions as they are — I feel confident in judging their benefit and cost.
However, from a conversation with @angerman , I gather is that this is not the case for everyone. I think that there are two points to distill:
-
Codified expert opinion on language extensions — In software projects that are developed by teams of Haskell programmers, not every team member is an expert in language design, and some team members can and will choose language extensions that bring no net benefit for the issues at hand (
AllowAmbiguousTypes*cough cough*). This is more of a skill question than a technical issue, but compiler suggestions are part of the conversation, and a language edition would codify expert opinion on language extensions in a way that the compiler can recite. -
Stability, transitively — For large codebases, compiler upgrades can be painful (“lack of stabililty”), and the main source of pain is not necessarily my own code, but the transitive dependencies that my team introduced. Demanding that transitive dependencies conform to a certain language edition can help avoid this kind of breakage — of course, at the obvious price of not being able to use that interesting dependencies, but it was always a trade-off.
I think that it’s important to realize that these points are not about the at-face-value and trade-offs of any particular extension (“technical”), but about the act of making an informed judgement about the utility of those extensions (“skill”). I think that this idea shows through the most in the Student2024 edition that you introduced @rae , but I think that it’s more general.
At least, as far the question of “are we addressing the wrong problem” goes, I can attest that the above happens in practice.