GHC.Generics.Lens should expose uniplate, template, and biplate analogues, not just tinplate.
Right now GHC.Generics.Lens is fairly crippled compared to Data.Data.Lens.
It would be informative to:
We should also add upon and whatver uponTheDeep variant to GHC.Generics.Lens when we get the chance.
Sounds like good ideas for sake of completeness, but I'm wondering if there are any benefits to supporting Generic in lens at all? Generic is great for implementing generically derivable type classes, but maybe Data is simply better suited for the kind of generic programming lens does? Any downsides to the Data/Typeable constraints as opposed to Generic? Both are derivable with GHC anyways ...
GHC.Generics has a better story for dealing with changing types and can deal, potentially, with polymorphic recursion in ways Data cannot.
In theory more static information could be available to the hit-map compiler in Data.Data.Lens in the GHC.Generics version as well, which might enable it to out-perform its competitor -- but I'm not holding my breath.
Up until now to deal with polymorphic recursion in Data I've had to use my own syb-extras package. Sadly, I was unable to interest the maintainer of syb in adding Data1. =(
"Fixed" in 4e01a13
Might still be worth looking into at some point because GHC.Generics could be faster than Data.Data, see ndmitchell/uniplate#11 (comment)
Not every use of Data is appropriate for use with GHC.Generics. The speed up isn't magical and relies on things being able to be determined at compile time.