If an axiom calls an auxiliary, then the generated Java code will have a compile error. Consider the following Xsemantics snippet:
auxiliary {
exampleAuxiliary(Object obj): Object
}
judgments {
exampleJudgement ||- Object obj : output Object
}
auxiliary exampleAuxiliary(Object obj) {
obj
}
axiom ExampleAxiom
G ||- Object obj : exampleAuxiliary(obj)
This produces the following Java method for the axiom:
private Object _applyRuleExampleAxiom_1(final RuleEnvironment G, final Object obj) throws RuleFailedException {
Object _exampleAuxiliary = this.exampleAuxiliaryInternal(_trace_, obj);
return _exampleAuxiliary;
}
The generated Java has the error: _trace_ cannot be resolved to a variable.
The problem is that _trace_ is not defined for methods generated from axioms, yet the auxiliary method expects a RuleApplicationTrace to be passed to it. If it doesn't make sense to call an auxiliary from an axiom, then there should be a validation error on the Xsemantics file. If it does make sense, then _trace_ should also be generated for axiom methods.
If an axiom calls an auxiliary, then the generated Java code will have a compile error. Consider the following Xsemantics snippet:
This produces the following Java method for the axiom:
The generated Java has the error:
_trace_ cannot be resolved to a variable.The problem is that
_trace_is not defined for methods generated from axioms, yet the auxiliary method expects aRuleApplicationTraceto be passed to it. If it doesn't make sense to call an auxiliary from an axiom, then there should be a validation error on the Xsemantics file. If it does make sense, then_trace_should also be generated for axiom methods.