How to access the ast.Tree after compile?

[polds]

Is there a way to access the *ast.Tree produced by running expr.Compile? I saw that recently the tree was removed from *vm.Program so is not directly accessible. It seems like I could recreate the tree if I copy over the compilation step logic:

https://github.com/expr-lang/expr/blob/master/expr.go#L176-L199

Reason is I have a need to compile sets of expressions and would like to walk the tree to attempt and detect expression collisions (ie one expression asserts that a value is true and another asserts that it's false).

Is it possible to access the tree, or is there another way I could possibly reliably do this level of collision detection?

[antonmedv]

Is there a way to access the *ast.Tree

One way is to use parser directly:

import "github.com/expr-lang/expr/parser"

...

	tree, err := parser.Parse(input)
	if err != nil {
		return nil, err
	}

But if operator overloads or patchers is needed - we can add some method, like expr.CompileWithTree or I can bring back program.Tree. What do you think?

Is it possible to access the tree, or is there another way I could possibly reliably do this level of collision detection?

This is actually a very cool thing. Could you show some examples what you think of?

[polds]

So fairly contrived example but not totally unrealistic. We're building an engine that evaluates many "rules" against the same very complex data structures, each rule is executed in it's own Parse / Compile phase and the rules can contain many logic gates basically like "generally speaking this data structure should have these values, except under these circumstances then we expect an entirely different value."

And when I say many, it could potentially be in the hundreds or thousands of rules.

In that example we do want to generally assert that values should be a specific value, but would also like the ability (in a different execution of a rule) assert that a specific value is a different one. We would want for our compilation step that compiles all the rules to be able to detect that these rules (which again are run as separate run contexts) conflict as they both touch providers.*.val and error for the user before submitting the rule, as a build time step, and avoid a situation where the rules are processed and we get explicitly contradictory responses.

Rectifying the issue is a separate issue we're still figuring out, but it'd probably turn into the globally scoped rule providing a not statement for the exceptional field. But the important thing for now is a way where we can detect these collisions. So our thoughts were walking OpCodes or the AST Tree and producing trees where we can quickly find rules that collide.

I unfortunately don't have any code to show for it as we're still in the implementation / investigation phase.