Closed treeowl closed 3 years ago
This suggests at least two coercion operations:
forall a. Coercible (f a) (g a)
, then we can provide forall xs. Coercible (ARec f xs) (ARec g xs)
.(x,y)
in Zip xs ys
, Coercible (f x) (g y)
, then we can provide Coercible (ARec f xs) (ARec g ys)
.Wow, these are excellent changes! Are you still working on this branch, or are you happy with the improvements made thus far?
@acowley, just ironing out compatibility crud. As soon as CI passes, I'm good.
@acowley, this should be ready to go. Expect another ARec
PR shortly.
It looks like CI is working again. Would you prefer that I merge this PR first, or that one so that we can hopefully get CI to check this one?
@acowley, it looks like it's been checked just fine.
The
ARec
newtype constructor was exposed byData.Vinyl.ARec
, making it easy to break type safety. Add aData.Vinyl.ARec.Internal
module and makeData.Vinyl.ARec
export the type abstractly. Add a role annotation to preventcoerce
from breaking the abstraction.Hack around doctests failing to compile. I don't know the "right" way to do this, but something seems better than nothing.