Soon we will have the  JFDI language which  will  allow us to have expressions. I would like to explore the idea of expressions in field constraints, to allow for easy reasoning over deep nested object models. This cannot be performant and will be very memory hungry - compared to a fast flat model - however in many situations the flexability this provides can be of great use and help write cleaner code, when the model cannot be flattened.

$p1 : Person( $petType: petType )
$p2 : Person( pet[$petType]["rover"].age == $p1.petType[$petType]["rover"].age )

When the tuple comes in and we have an expression on the right hand side of the evaulation we make a key from the expressionid and the tuple and add it to the map with evaulated expression result as the value. When facts come in they read the expression value from the map instead of evaluating it again. If the left hand side of the evaluation also has an expression we need to make a key of expressionid, fact and variable{FOOTNOTE DEF  } - this means when the tuple comes in and attempts to join with a fact it looks to see if the key already exists for that fact and reads its value, else it evaluates it and adds it to the map. If the evaluator is an == and we have literals (no variables) in the expressions, beyond the first $p1 right side variable, for the left and right hand side of the evaluator we can look to exploit this with indexing.

As an expression is evaulated it will need to register a listener for each nested instance where the expression is evaluated. That listener will reference the parent tuple or fact. When the instance is modified it will signal the listener for that node which will force the tuple or fact to be retracted and re-added to the node. This will force re-evaluation of tuple or fact. Life-cycle management will need to be involved so when the nested accessor is destroyed the listener will retract the related parent tuples or facts.

The reality of the most common use cases will be access collections:

Person(pets["dogs"]["rover"].age > 10 )

Michael says: Yes I agree very much so. This would be really quite useful. At the parser level we could probably differentiate between a flat constraint versus a generic JFDI expression.