[ghc-steering-committee] Language Extension Policy – Round 2

[Eric Seidel]

On Thu, Apr 27, 2023, at 11:40, Adam Gundry wrote:
> Here's what I don't quite understand: MultiParamTypeClasses is already 
> part of GHC2021 and thus enabled by default (unless the program is 
> specifying e.g. Haskell2010 as the default-language). Given that, why is 
> it worthwhile to go through the churn of replacing 
> `-XNoMultiParamTypeClasses` with `-Werror=multi-param-type-classes`?

It may not be, but that's not the question we're trying to answer right now, at least not as I understood it. Arnaud asked us whether these are valid use cases for extensions. That's a "what should be" question. My answer is that restricting to a subset of the language should be done via warnings or linters, rather than via extensions. That's not the current pattern in GHC, but it's what I would do if we were starting over.

Once we've established "what should be", we can then discuss "what to do about it", i.e. should we undertake a large refactoring of GHC to migrate all of these extensions to warnings? We might decide that it's worthwhile because of some reduction in code complexity. Or we might decide that it's not worthwhile because of the churn it would cause. But either way we have learned something about language design that can guide future decisions.