We could perhaps have reusable, named expressions:
expression triangle_inequality(A as java.lang.Integer, B as java.lang.Integer, C as java.lang.Integer) {
A < B+C &&
B < A+C &&
C < A+B
} // type inferred as boolean -- or should we make the return type explicit?
Then use them in check expressions (later in evals) directly:
check triangle_inequality(X,Y,Z);
Perhaps it would be also possible to use them as sub-expressions:
only one evaluator class has to be generated for it
if pure functional / side effect-free property has to be proven / asserted using annotations / whatever (see #96), you only have to do it once
if the expression is very complex, you do not have to expand it within the pattern code, making the .eiq tidier, even if you use it only once
you can include such an expression in a query library! #193
in fact, you can generate its evaluator code for the library, and then you can match interpretative queries using this expression with precompiled evaluation (i.e. the stuff that is slow in interpretative mode)!
Priority: low, we do not have user requests for this yet.
We could perhaps have reusable, named expressions:
Then use them in check expressions (later in evals) directly:
Perhaps it would be also possible to use them as sub-expressions:
The advantages I foresee:
Priority: low, we do not have user requests for this yet.