compile needs a sanity check for variables typos, etc.

[zramsay]

if there's a typo in a parameter name then instead of a warning or a failure during the compile, the resultant pdf will have that variable left blank. This is easy-ish to spot in a 10 page contract but in a longer one with many more params a typo might be hard to catch.

I know it's no easy task to generate the params file from the template buuut presumably it would be easier to check that all variables in the template are correctly exposed/defined in the params.dhall

[shonfeder]

Dhall gives this for free if you specify the type for your params.

[shonfeder]

Oh nevermind -- I see the point here: this will ensure that a params file satisfies some specified structure, but that doesn't ensure that the reference to the params in the markdown file is correct! I agree this would be very useful.

[zramsay]

say the template.md looks like:

Name or whatever
{{date.start}}
{{date.end}}
{{date.signde}}
{{variable.not_defined}}

^ notice typo date.signde

and the params.dhall looks like:

let Date : Type =
    { start : Text
    , end : Text
    , signed : Text
    }

let date : Date =
    { start = "01/01/2021"
    , end = "01/03/2021"
    , signed = "20/01/2021"
    }

in { date = date }

In this scenario, it's a user oversight (1. a typo and 2. forgetting to define the {{variable.not_defined}} in the params.dhall)
The problem is this: there will be no indication of this oversight during compile. At the most it should fail, at the least it should provide a warning. The same problem exists in the other direction (e.g, typo in the params.dhall or a defined variable that didn't get included in markdown).

Current behaviour is to simply leave the {{date.signde}} and {{variable.not_defined}} blank which makes detecting any user error in this regard somewhat tedious. A helpful best practice is bolding all the variables in the markdown so a blank one shows up as **** but this is not ideal nor reliable.