That's an interesting point. The docs don't say NullaryTypeClasses is implied by MultiParamTypeClasses, they say it has been supplanted.
Nullary (no parameter) type classes are enabled with MultiParamTypeClasses; historically, they were enabled with the (now deprecated) NullaryTypeClasses.
As a result I thought it would be odd to vote for both extensions, and voted yes on MultiParamTypeClasses and no on NullaryTypeClasses. On Mon, Dec 7, 2020, at 15:36, Joachim Breitner wrote:
Hi
Am Montag, den 07.12.2020, 21:16 +0100 schrieb Alejandro Serrano Mena:
- What should we do with those which are superseded? I voted ‘yes’ to NullaryTypeClasses because it’s implied by MultiParamTypeClasses. I don’t think we’ll end up in a situation in which the former is accepted but not the latter, but it’s worth mentioning.
my understanding is that implications will hold. So if we vote MultiParamTypeClasses in, but not NullaryTypeClasses explicitly then NullaryTypeClasses would still be active. Just as if you enabled -XMultiParamTypeClasses. Often, nothing else is technically possible.
In fact, it makes sense to vote MultiParamTypeClasses: yes NullaryTypeClasses: no to express “I want MultiParamTypeClasses, but if that does not make it in, then NullaryTypeClasses isn't worth going in on its own”.
In general, whatever set we end up with will still be under common sense scrutiny.
I have briefly considered digging up the list of implications, and somehow including it in my updates (“the following extensions would be enabled by way of implication”). Maybe I’ll do that, we’ll see.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee