dhall-lang / dhall-haskell

Maintainable configuration files
https://dhall-lang.org/
BSD 3-Clause "New" or "Revised" License
908 stars 211 forks source link

add TH support for nested higher kinded types #2515

Open ndwarshuis opened 1 year ago

ndwarshuis commented 1 year ago

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:

let InnerS = \(x : Type) -> \(y : Type) -> { ifoo : x, ibar : y }

let InnerU = \(x : Type) -> \(y : Type) -> < Ifoo : x | Ibar : y >

let Outer =
      \(i : Type) ->
      \(j : Type) ->
        { ofoo : InnerS i Text, obar : InnerU j Text }

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.

Gabriella439 commented 7 months 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.

ndwarshuis commented 7 months ago

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?