New scoping rules
For the new version of GBOML, the addition of arrays #9/dicts #10 leads to new problems relative to scoping. For example:
#NODE Parent
array <- {Child1.v, Child2.v};
#NODE Child1
#VARIABLES
external: v;
#NODE Child2
#VARIABLES
external: v;
#CONSTRAINTS
sum(x for x in array) == 0;
Should be forbidden as it breaks the rule that #constraints can only be made on variables from the node.
Yet, we should authorize to write array <- {Child1.v, Child2.v};
as it is correct in other contexts:
#NODE Parent
array <- {Child1.v, Child2.v};
#NODE Child1
#VARIABLES
external: v;
#NODE Child2
#VARIABLES
external: v;
#HYPEREDGE e
#CONSTRAINTS
sum(x for x in Parent.array) == 0;
Here is a proposal to make everything work.
The rule
- Variables can only be used in node-constraints if they are owned by this node.
- Variables can only be used in hyperedge-constraints if they are owned by siblings of this hyperedge.
Types of scoping
There are two types of scoping:
-
parentScope(A)
: the scope that a (grand-)*child has from its parentA
.-
parentScope(A)
contains all the parameters from A.
-
-
childScope(A)
: the scope that a direct parent has from its childA
.-
childScope(A)
contains all the external variables of A -
childScope(A)
may contain some parameters, explictly shared (via theshared
keyword)
-
When an expression is created, such as
#NODE
array <- {Child1, Child2, Parent, Child2.v};
The references of the nodes are actually replaced with their scope:
array <- {childScope(Child1), childScope(Child2), parentScope(Parent), childScope(Child2).v};
Variable usage in constraints
See The Rule. Accessibility is checked when creating the matrix.