Stop Directly Constructing Policy AST

[JeremyRubin]

The Policy AST is not intended to be directly constructed. Switch to our own custom AST, or a macro language, strings, or something else to ensure that all the properties of miniscript are correctly checked.

[ProofOfKeags]

Should we go after our own CBC Policy construct that we "compile" to the policy FE language and parse it with actual policy?

I'm not yet sure if a CBC Policy AST is possible. I can look into this.

[JeremyRubin]

a CBC subset of policy isn't easy given how timelocks are implemented, so I think it's out of scope.

[JeremyRubin]

cc @apoelstra I think a more succinct explanation of why the "just do it as strings" approach for using Policy v.s. working with the AST directly is that it makes it really difficult to programmatically construct the policy fragments. i.e., in my compiler passes I do some manipulations on the AST that requires inspecting them or generating them programmatically. writing a bunch of custom string concatenating code would be sad. not sure if i expressed that well before, but one example is we have a function that generates different threshold groups that become available at different times which is a function of input parameters. string templating that would be meh.

so i think regardless of if we do strings when we pass to policy, we want some kind of PolicyBuilder enum that we can use to emit policy / build it up programmatically.

[apoelstra]

Sure, we'll explore this.

[ProofOfKeags]

Alternatively, understanding the "gaps" in where you can create a structurally well-typed Policy expression in the AST that isn't valid semantically would at least help us craft a Policy builder ourselves. I anticipate that the work to understand those gaps is not too much less than actually having an API for it though. If it is that could be a very helpful intermediate step.