GHC.Generics offers a bunch of data types which have valid instances of various type classes in base, such as Functor. There's no good reason not to have these instances, so they should be added.
Trac metadata
Trac field
Value
Version
7.8.2
Type
FeatureRequest
TypeOfFailure
OtherFailure
Priority
normal
Resolution
Unresolved
Component
libraries/base
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
ekmett, hvr
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
The missing Functor/Foldable/Traversable instances for these have bitten me before and the instances are entirely determined by their laws / convention.
There are a few other instances that make sense uniformly:
e.g. U1, Par1, Rec1, and (:*:), and M1 can also be made instances of Applicative, Monad, MonadZip in a completely unambiguous way determined by the laws just by lifting them from their parts.
(:.:) admits an unambiguous Applicative, but not the others.
It might also make sense to look into making the types in there instances of Generic / Generic1 for bootstrapping purposes, and they are currently missing Typeable and Data instances as well.
The instances probably have to live out mostly where the typeclasses come from rather than in the module itself to avoid cycles, but otherwise I don't see any headaches, and they are entirely determined by the definitions of the classes involved, so there is no bikeshedding opportunity.
dreixelassigned to @trac-dreixel and unassigned @trac-ocharles
assigned to @trac-dreixel and unassigned @trac-ocharles
I have a branch that adds almost all the above mentioned type clasess at https://github.com/ocharles/ghc/tree/generics-instances. I didn't do Data, mostly because I ran out of steam - if people feel strongly about that I can come back and add it.
hvr - as mentioned on Github, I was somewhat intending to squash this down into a single commit when I'm done. If you'd like, I could simply omit whitespace changes from this. My editor does it for me, so I sometimes forget it is happening :)
Alright, I've responded to some comments and added more instances. Could people please have another look? I wrote out Data instances, but I have never actually used Data.Data, so I may have got that wrong. Is it possible to write Data instances for (:+:) and friends? My initial attempt was no, but I may have missed something. Latest code is at https://github.com/ocharles/ghc/tree/generics-instances (as before).
I'm not following the details here, but if the core-libraries commmitte are happy please turn it into one comment and change to 'patch' status so that Austin can merge it. Thanks!
I've had a look at this, and all seems fine to me. One caveat however:
instance (Data p, Data (f p), Typeable c, Typeable i, Typeable f) => Data (M1 i c f p) where
This Typeable c constraint will require changing the generation of Generic instances in GHC, because these cs are compiler-generated empty datatypes, which currently do not derive Typeable.
Simon: what's the best way to do this? We need Typeable instances for the stuff generated by mkBindsMetaD in TcGenGenerics.
Well I suppose you'd need to derive Typeable for these generated data types.
Mind you, IIRC now that we have DataKinds I think the Generics stuff could be done much more neatly, dramatically reducing the number of generated data types.
This is all code you wrote, Pedro, isn't it? So you are definitely free to improve it!
Mind you, IIRC now that we have DataKinds I think the Generics stuff could be done much more neatly, dramatically reducing the number of generated data types.
This is all code you wrote, Pedro, isn't it? So you are definitely free to improve it!
Sure. All I'm worried about is backwards-compatibility, and the lack of #6024 (closed) doesn't help.
I'd be interested in helping tidy up the stuff in GHC.Generics to use data kinds, btw. So dreixel, if that's something that you think is somewhat obvious and wouldn't mind me doing it - just let me know!
Ok folks, I've squashed this down to just two commits now - one with instances and one with whitespace changes. I think we may be all ready to go, and we can derive typeable in a separate commit. It does mean that without that the Data instances are fairly useless.
Sounds good to me. Please leave the ticket open; it might still take me a few weeks to implementing the changes in GHC, but I think that's not a problem.
Sorry for the delay; it's still in my to do list. His changes can be merged, though; perhaps it's best to do that earlier rather than later, to avoid conflicts. But please keep the ticket open; I'll close it once I make sure that the datatypes generated when deriving Generic have Typeable instances.
Just a heads-up: I want to implement the changes described in the following wiki page, which would mean there are no longer internally generated datatypes for which we then need Typeable instances:
So then we'd just be piggybacking on typeability of Symbols (and instances for MetaCons/MetaData) to get the Typeable instance for things like M1 i c p?
I have vague recollections of Richard mentioning that having every Symbol/Nat be Typeable. I don't recall what came of it though. Do we have that now in HEAD?
What can we do to make sure this makes it in for 7.10? Perhaps it would make sense to split out the Data and Typeable changes so the other instances can be merged independently.
#9766 (closed), which had been blocking this for a while, has been fixed, so there's nothing holding this back at the moment. ocharles, would you be willing to rebase your work on top of master?
You'll need to make some changes to work with the latest GHC:
Typeable instances are now derived automatically for everything, so you can remove those.
Arity has been removed from GHC.Generics
GHC.Generics has added some new datatypes:
FixityI was added as a type-level counterpart to Fixity (this probably doesn't need any instances)
A new data family (URec) was added to support Generic(1) instances for unboxed types. The data instances could probably use Functor, Foldable, and Traversable instances (I think those would be well-kinded, but I'd have to check.)
I checked, and it turns out that derived Traversable instances for URec won't kind-check at the moment. This isn't a fundamental limitation of Traversable, however. I've opened #11174 (closed) regarding this issue.