As per Jordan's suggestion in #4, I've added a note about GHC 8.8. I'm
probably not going to change the code until then, simply because it
makes things a bit uglier.
Although we technically only "need" `Functor f` and `GConstruct` will in
turn imply `Applicative f`, it would be nice for the benefit of users if
it were clear in the signature that `Applicative` were required.
Turns out, as @kcsongor suspected, we can use generic-lens directly by
exposing a generic rep for our HKD type. All the tests work fine, two
documentation updates. I'm very pleased!
All we do is expose the internal rep "as" the generic rep. I need to do
a bit of experimentation, but this _might_ actually make the generic
lenses here redundant...
For many of the instances, we use a transformation to and from a nested
tuple shape. For example, we can have an instance of `Eq` for any HKD by
converting it to nested tuples and using _that_ instance.
@pacak notes that, while this is fine in principal, not exposing it
means that we can't write functions on top of various internals that are
suitably polymorphic because we can't add this class as a constraint.
This commit exposes this class, and frees us all.
Previously, the constraint for `baddDicts` got lost in the machinery,
and would be ambiguous in the `K1` instance. This commit copies the
Barbies default implementation almost verbatim, and seems to fix the
issue.
I think I must have left in some dodgy code... weird. Anyway, this
commit means that you don't have to satisfy some arbitrary `Arbitrary`
constraints to use an HKD as a monoid.
With this function, we can construct HKD structures for non-monoidal
types, without jumping through many weird hoops as we go. I'll push a
release soon!
Before Hackage, we should probably pick some actual library versions to
depend on. This commit does that, and removes the lens dependency, which
should make installation much faster.
Quite a giant refactor:
- The partial type has been generalised to `HKD f` for some
parameter-wrapping functor `f`.
- The internals of `field` and `position` are now handled by
`generic-lens`. It doesn't work yet, though.
A la generic lens, we dimap either side of the glens and ravel the whole
thing at the end. This might even optimise better, though I should
check. Still some weird issues with the predicate, but we'll get to that
shortly.
Why get a dog and bark yourself? This commit uses the generic-lens
internal functions to create the lenses, which means the error messages
will be substantially better.
