You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the Generic instance of Rec is oblivious of the functor wrapping the fields. This means the Generic instance it provides cannot be equivalent to that of an equivalent Haskell record.
@acowley If you'd like, maybe you'd want to upstream my GenRec newtype into vinyl. But as such it's kinda limited. It only supports Rec with the ElField functor. (And ARec, but simply through a brute-force conversion to Rec to reuse the instance for Rec, although it's possible GHC is smart enough to optimize away the whole conversion, I didn't check).
Maybe SRec could be given an instance too.
Also, any functor should work, as long as you "insert" it in the Generic representation of each field. (I never really checked how Generics behave with HKDs à la barbies)
But the instance of Rep I derive can work for basically any Generic-based library (it works with Aeson too for instance), as it only uses M1, (:*:) and K1. Maybe the same could be done for CoRec, but given a lot of Generic-based libs don't like sum types or hack around them, it's less useful anyway IMHO.
Currently, the Generic instance of
Rec
is oblivious of the functor wrapping the fields. This means the Generic instance it provides cannot be equivalent to that of an equivalent Haskell record.Would there be a way to have:
that ensures the Generic instances for Person1 and Person2 can be used instead of one another?
The text was updated successfully, but these errors were encountered: