In Shayan's implementation he has [1]
data ImplicitBndrs x thing
= IB
(XIB x thing)
thing
| NewImplicitBndrs
(XNewImplicitBndrs x thing)
type family XIB x thing
type family XNewImplicitBndrs x thing
type ForallXImplicitBndrs c x thing =
( c (XIB x thing)
, c (XNewImplicitBndrs x thing)
)
This gets used, in the same file as
type LSigType x = ImplicitBndrs x (LType x)
where `thing` is resolved to a specific type.
Because it is all in the same file, there is no problem making a
constraint on anything using LSigType, that mentions LHsType.
But in the approach I am taking[2], the type families are defined in
HsExtension, which is compiled early in the cycle, and imported by
HsTypes, HsBinds, HsDecl etc.
In order to derive a Data instance for anything using `LSigType x`, we
need to be able to specify that a Data instance exists for `LHsType x`.
So we can either do that directly in HsBinds, or try to add it to the existing
DataId constraint in HsExtension.
The first approach leads to a spread of the constraint throughout the AST,
which gets very messy.
The second approach requires being able to specify a
`forall thing. Data thing` constraint in HsExtension.
I tried an intermediate approach, introducing a constraint in HsDecls[3] to capture this,
but it eventually runs into needing it in the HsExpr.hs-boot file, which means I need
LHsType in that file.
Perhaps the simplest way forward is to get rid of the `thing` parameter completely,I hope this does not just confuse things even more.