With introduction of null, it's better to allow short circuiting (lazy evaluation) for those boolean operators

[stevenylai]

I see the library now support null but perhaps it's better to also allow short circuiting for those boolean operator? Consider an example:

IF(v != NULL && v > 0, LOG(v), 0)

If v is set to null, we will get an exception saying null cannot be compared.

It seems that operators don't have the option to be lazy? So perhaps the workaround here is to introduce an AND function:

IF(AND(v != NULL, v > 0), LOG(v), 0)

[uklimaschewski]

I think this can be easily implemented in the expression evaluator here

      case INFIX_OPERATOR:
        result =
            token
                .getOperatorDefinition()
                .evaluate(
                    this,
                    token,
                    evaluateSubtree(startNode.getParameters().get(0)),
                    evaluateSubtree(startNode.getParameters().get(1)));
        break;

The operator type has to be checked. If it is a logical AND, then evaluate the first operand only.
Only, if the result is TRUE, evaluate also the second operand.

[uklimaschewski]

Similar logic can be implemented for the logical OR operator. If the first operand is TRUE, skip evaluating the second operand.

[stevenylai]

OK. I see. I think given that user can define custom operators, we can define an additional isLazy parameter in InfixOperator interface (assuming post/prefix operators do not need the same) and implement the lazy evaluation logic only for AND/OR operators. Documentation will also have to be updated.

I can also help to make the change if this sounds reasonable.

[uklimaschewski]

This is exactly what I had in mind. If there is no breaking changes, it could go to a 3.2.0 version.
Feel free to volunteer, I am always happy with people contributing. 🙂