Generically derive Read1/Show1 in Data.Functor.Classes.Generic

[RyanGlScott]

We already have Eq1/Ord1, but Read1/Show1 are the awkward grimy cases.

I'd be willing to do this, provided I can answer these two questions:

1. Do we want to mirror deriving Show's ability to generate specialized Show functions for certain unlifted types? (e.g., data CharHash = CharHash Char# deriving Show is legal.) GHC generics didn't get the ability to work over unlifted types until GHC 8.0. The generic-deriving library allows us to backport this to earlier GHCs, but it requires incurring a dependency.

2. Do we want to generate the exact same Show code on a GHC version-by-GHC version basis, or do we always want to generate what the latest GHC does? For instance, with this code:

   data Weird = Weird { weird :: Int } deriving Show

   Then showsPrec 11 (Weird 0) "" displays as "(Weird {weird = 0})" on GHC 7.10 and earlier, but as "Weird {weird = 0}" on GHC 8.0 and later.

   • [ ] Read1
   • [ ] Show1

[RyanGlScott]

It just hit me that in regards to question 1, we can't use generic-deriving, since it's not in the Haskell Platform (yet?). So we'll just have to settle for only handling unlifted types with GHC 8.0+ in #21.

[ekmett]

Re: generic-deriving and the platform, I'm less concerned. transformers-compat isn't "in the platform" either after all.

[ekmett]

As for item 2, I'm pretty flexible. If we show the latest and greatest version of things it is easier to maintain, if we maintain character for character compatibility with with Show it is a easier for folks to mix and match.

[RyanGlScott]

Re: generic-deriving and the platform, I'm less concerned. transformers-compat isn't "in the platform" either after all.

It isn't?

As for item 2, I'm pretty flexible. If we show the latest and greatest version of things it is easier to maintain, if we maintain character for character compatibility with with Show it is a easier for folks to mix and match.

Luckily, there's not a whole lot you have to do at the moment to get character-per-character compatibility with Show—it just amounts to a single CPP check.

[ekmett]

Hah. I guess someone added it.

[ekmett]

If we incurred the dependency on generic-deriving conditional on using an older version of GHC then the platform isn't a concern, as the platform would be unaffected.

[RyanGlScott]

If we incurred the dependency on generic-deriving conditional on using an older version of GHC then the platform isn't a concern, as the platform would be unaffected.

That sounds reasonable. There probably won't be any more Platform releases that use GHC 7.10, will there? In this context, "an older version of GHC" includes GHC 7.10 (since the generic support for unlifted types will be added in 8.0), but as long as the next platform release uses 8.0, it won't be a problem.

[ekmett]

The worst case scenario is that they have to expand the platform to include generic-deriving if they don't ship with 8.0, which isn't really a "sky is falling" scenario.

[RyanGlScott]

Re item (2), I could add versions of Data.Functor.Classes.Generic's functions that take an Options argument controlling whether you get complete backwards compatibility or the latest GHC's behavior (with the former being the default).

[ekmett]

sounds good to me

[RyanGlScott]

OK, I've updated #22 to include the above changes.

[RyanGlScott]

Hm, the scope of the changes made to derived Show instances might not be quite as drastic as I originally thought, since there's talk of reverting the parentheses-related changes made in GHC HEAD. It'd still be okay to have an Options argument, though, since there will be changes made to the output of unboxed arguments.

[RyanGlScott]

Trac #2530's changes have been reverted, so I updated #22 accordingly. The only thing that the Options configure now is the Show behavior for unlifted types.