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

1. Variables can only be used in node-constraints if they are owned by this node.
2. 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:

1. parentScope(A): the scope that a (grand-)*child has from its parent A.
   • parentScope(A) contains all the parameters from A.
2. childScope(A): the scope that a direct parent has from its child A.
   • childScope(A) contains all the external variables of A
   • childScope(A) may contain some parameters, explictly shared (via the shared 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.