[ghc-steering-committee] #380 GHC2021: Implications between extensions
eric at seidel.io
Mon Dec 7 20:45:36 UTC 2020
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:
> 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.
> Joachim Breitner
> mail at joachim-breitner.de
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
More information about the ghc-steering-committee