Open ndwarshuis opened 1 year ago
Sorry for taking so long to get to this
I'm a bit reluctant to merge this because (based on my cursory understanding of how this PR works), this is essentially implementing a form of unification (specifically gatherNestedVars
) as part of this TemplateHaskell
subroutine and I'm not sure I want to commit to maintaining a robust unification algorithm in order to support this feature.
Sorry for taking so long to get to this
no problem :)
I'm not sure I want to commit to maintaining a robust unification algorithm in order to support this feature.
I'm not sure what you mean by this. Can you please elaborate on "unification" and why it would be difficult to maintain long term?
This is a follow up to https://github.com/dhall-lang/dhall-haskell/pull/2506 for a complicated case I forgot to add.
In the case where an imported type uses another higher kinded type, the current algorithm will compare this inner type after its arguments have already been applied, in which case the search will fail.
Example:
Basic idea is to extend the nested type loop so that when matching a dhall type with an already-cached haskell type, it will store the type parameters for the outer haskell type constructor, gather the dhall types corresponding to the type parameters, recursively find the inner constructors for these nested dhall types, and finally apply the results to the outer type constructor.