This `HKD` is a better fit for `Rel8` than `higgledy`'s `HKD`. In a very literal sense, this `HKD` is now a `Rel8able` (i.e., `Context -> Type`), whereas `higgledy`'s is `(Type -> Type) -> Type`. This meant we had to use hacks like `HKD a (Compose Aggregate Expr)` to get a `HKD` into the `Aggregate` context (and similarly for `Insert`). Now we can just do `HKD a Aggregate` and `HKD a Insert` like any other `Rel8able`.
Like `higgledy`'s, our `HKD` is compatible with `generic-lens`.
One feature we have that `higgledy` doesn't is the ability to support sum types. You can make a `HKD` out of an arbitrary algebraic data type (whose fields are `DBType`s).
What's still missing is constructor/deconstructor machinery, but that's nearly finished, and the underlying machinery will also be used by the `ADT` `Rel8able`.
There is actually nothing specific to `reify` in the `Generic` version of these operations, they're actually just a specific instance of a much more general `gmap` operation. This now lives in `Rel8.Generic.Map`.
Previously these were implemented with `unsafeCoerce`, which was mostly correct, but was incorrect for certain instances of `HList`. With this change, `deriving Rel8able` will now fail to type check in those instances.
This builds upon the `Rel8.Generic.Record` machinery introduced in the previous commit. It means that we can use generic implementations of the `Table`, `EqTable`, `OrdTable` and `ToExprs` for all tuple types, rendering `HPair`, `HTrio`, `HQuartet` and `HQuintet` unnecessary (this commit removes them).
The is implemented using new machinery in `Rel8.Generic.Record`, which transforms the generic representation of any type to be as if that type was a record. Numeric labels are assigned to anonymous field selectors like `_1`, `_2`, `_3` and so on.
Previous it was `((Type -> Type) -> Type) -> Constraint`. The problem is this clashes with things like `HKD` from `higgledy`. We can use GADTs and PolyKinds hacks to get around this while mostly retaining the same API. The only major difference is we use `Result` in places where we used `Identity` before.
Now that the Field type family only needs a Necessity and a Type, we don't need to "parse" the Type to find the Necessity, we can instead just make it so that Column creates a Required field, and repurpose the name Default to be a type family that creates an Optional field.
The previous "parsing" approach was brittle sometimes, particularly in the case of polymorphism.
