You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A query is a list of rule definitions, binding a plan to a name. Each of these plans can invoke other sources of data by name. If the sequence of rules only reference previously bound names, then we do not need any recursion, and can just implement each rule in order. That is how the code currently works.
More generally, we can have some non-standard behavior if:
A rule references itself,
A rule references a name bound later in the query.
A rule references a bound name that is rebound later in the query.
In these cases, and perhaps others I haven't thought of, we might prefer the semantics of a query to be the fixed point of repeated application of its rules, in order. This is a strict generalization of just requiring an acyclic "depends on" relation among the rules.
It seems natural to construct the "depends on" relation and find the strongly connected components. Each of these can be independently rendered as an iterative scope, with iterate::Variable types used for collections that must develop recursively. For re-bound names, the initial value of the variable should be the initial collection, and the recursive definition then overwrites this.
The text was updated successfully, but these errors were encountered:
A query is a list of rule definitions, binding a plan to a name. Each of these plans can invoke other sources of data by name. If the sequence of rules only reference previously bound names, then we do not need any recursion, and can just implement each rule in order. That is how the code currently works.
More generally, we can have some non-standard behavior if:
In these cases, and perhaps others I haven't thought of, we might prefer the semantics of a query to be the fixed point of repeated application of its rules, in order. This is a strict generalization of just requiring an acyclic "depends on" relation among the rules.
It seems natural to construct the "depends on" relation and find the strongly connected components. Each of these can be independently rendered as an iterative scope, with
iterate::Variable
types used for collections that must develop recursively. For re-bound names, the initial value of the variable should be the initial collection, and the recursive definition then overwrites this.The text was updated successfully, but these errors were encountered: