Open Lysxia opened 7 years ago
Yeah, this is a good idea.
Actually the generic implementations would subsume the pXX
adaptors. I guess there is also a way to write the pTXX
generically. With sufficient inlining it should also be possible to maintain the same performance as Template Haskell. I'll see whether I can make this work.
That would be good. I don't care about pTXX
. We can get rid of them. I don't think anyone uses them.
I found that genericAdaptor
can already be optimized as much as what one might write by hand, with sufficient inlining. I'll put the benchmarks I made in a PR.
I'm wondering then whether it's fine to just get rid of pXX
adaptors as well. The main concern is that it actually does not provide a 100% replacement for pXX
, because Generic
is only derived in base
up to tuples of length 7. Are pXX
used in other places outside product-profunctors
?
The template haskell scripts that are currently in use to implement Default
instances and adaptors depend on pXX
but can probably be rewritten not to, if we are to keep those at all. Are we?
genericAdaptor can already be optimized as much as what one might write by hand
Nice!
Generic is only derived in base up to tuples of length 7
Any idea why?
It's pretty nasty to use tuples of length greater than 7 anyway so we can probably get rid of these.
The template haskell scripts that are currently in use to implement Default instances and adaptors depend on pXX but can probably be rewritten not to, if we are to keep those at all. Are we?
The TH is a big hack and could be written much better. I'd like to replace it with Generic
stuff ideally, but we need a migration plan.
Beyond the fact that large tuples are smelly, it seems they also blow up compilation time and space usage. especially in combination with generics. I found this relevant GHC issue where they made the decision of stopping at 7.
That's a bit worrying because people will want to use these product-profunctor generics with Opaleye with records approaching 100 fields in size ...
These lines make the documentation look pretty bad.
A simple fix is to move them into their own module, which can be reexported by the main one. I think it would be even better to let the user import that separate module themselves because the short names pollute the namespace a bit.