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:
Remove the need for Typeable in the GHC.Generics.Lens code, reverting to the use of the Generics Datatype class as appropriate.
Duplicate the reasoning from Data.Data.Lens that lets that code avoid traversing portions of the structure unnecessarily. Unlike Data.Data.Lens this can make more exacting judgments without having to "guess wrong" once first.
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. =(