On 27/04/2023 15:11, Eric Seidel wrote:
I can't speak for Simon, but I felt similarly about Extensions vs Warnings. What you're saying here is not quite what I had in mind. For me it's more like
• Remove (say) MultiParamTypeClasses as an extension • Accept programs that use MultiParamTypeClasses unconditionally • If you want to disallow MPTCs, you can disable them with `-Wmulti-param-type-classes -Werror`
In other words, MPTCs are simply part of the language now. Not a second class citizen that must be opted into with an Extension or by *disabling* a Warning. We leave an escape hatch in the form of an opt-in warning for those who would rather not use MPTCs, much like other aspects of the language the may be controversial.
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`? If the issue is implementation complexity, then I don't see how changing one flag to another really helps that; to fundamentally simplify the implementation you have to eliminate the ability to disable the feature altogether. (And I would argue that the way to keep the implementation simple is to design language features that are orthogonal, rather than having one big monolithic language that can't be decomposed...) If it's a conceptual/documentation issue, could we instead rewrite the user's guide so that it assumes GHC2021 as a baseline, and presents multi-parameter type classes as a feature of "GHC Haskell" (with a side note that they can be disabled with NoMultiParamTypeClasses)? I'm sure I'm missing something... :-) Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England