Closed MangoIV closed 3 months ago
Well, you have to put a limit somewhere. Ok, why 30? But also, why 64 specifically? Normal GHC has instances (such as Eq
and also GHC's Generic
) for tuples only up to size 15, if I remember correctly.
In principle, it would be easy to add more instances. However, these instances add quite a bit of compile time (the
Instances
module is already problematic in that respect. And large types are massively slower due to the unfortunate quadratic code size problem in Core.
So I'm wondering if it wouldn't be better if you define these instances in your code if you really need them, because if we add them to the library, the compile time hit will be impacting all users.
I'd also be interested to learn more about the library though. Is it specifically using large tuples and then generics-sop
? If so, why not use NP
directly, or perhaps something like large-records
?
But also, why 64 specifically
afaiu that’s the biggest Tuple that we get from ghc-prim
these instances add quite a bit of compile time
that is true, it’s the case for us as well, increase in compile time is quite substantial
I'd also be interested to learn more about the library though
the library makes the very questionable choice of allowing only tuples of different sizes as input. This is already a problem because as already noted the maximum size is 64. As I said, I understand that this should probably fixed instead in the library but I wanted to ask wrt the instances anyway.
So I guess the conclusion is:
thank you for answering!
We are using
generics-sop
with fairly large tuple types because a library wants us to do so. While I acknowledge that it might be the better option to fix the library, I would nonetheless be interested in understanding why instances 31 through 64 are missing.Thank you so much in advance!