Closed Lysxia closed 6 years ago
OK... and why do you expect that output? :)
I think perhaps you're trying to silently appeal to how a derived Show
instance would behave in the same scenario, but keep in mind that GShow
is not the same class as Show
. Indeed, we make no guarantees about output of GShow
at all—it, like every other G
-prefixed class in this library, is simply a toy example to demonstrate how one can use GHC.Generics
. GShow
is not intended to be a drop-in replacement for Show
(and indeed, it can't be by virtue of being a different class).
To put it another way—we could change this behavior, but I don't see what it would buy us here. I think what you want is a GHC.Generics
–based implementation of show
, not the GShow
class.
Since generic-deriving is a toy example, I understand that this isn't really a problem, so feel free to just close this.
In fact, I was considering forking generic-deriving to work with the actual classes in base. Such a fork would have more reason to match GHC's derived instances. Eventually I changed my mind, but I thought this discrepancy would at least be worth pointing out, as I expected gshow
to mirror show
and produce a valid Haskell expression, at least for some simple class of types.
Indeed, I think having a library which provides generic implementations of standard type classes would be a good idea. For various reasons, generic-deriving
probably won't ever be that library, one reason being that generic-deriving
has an extremely minimal dependency footprint, so backporting generic implementations of things like Semigroup
would be tricky, since Semigroup
has only been in base
since 4.9.
In any case, I'll opt to close this. Thank you for the bug report!
Expected output: