Rules for distributed control constructs

In earlier sections we sometimes referred informally to the ``active process group''. A concrete role of this group was as the default distribution target in distributed array constructors. We used the fact that the on construct establishes its parameter group as the active process group inside the body of the construct.

The other distributed control constructs, at and overall, also affect the active process group. If the current active group is p, executing the construct construct

    at(i = x [n]) {
      ...
    }

or

    overall(i = x for l : u : s) {
      ...
    }

will change the active group to p / i inside the bodies of the constructs.

Now the expression p / i is only well defined if the location i belongs to a range distributed over a dimension of p^5.1. So we infer that the control constructs given above can only appear at a point in the program where the dimension set of the active process group includes the process dimension over which x is distributed.

Note that the the dimension set of p / x [n] certainly does not include the process dimension associated with x--this follows directly from the nature of restriction operation. So one of the implications of the rule just given is that we should never expect to see exactly the two constructs above nested thus:

    at(i = x [n])
      overall(i = x for l : u : s) {     // error!
        ...
      }

This is just as well, because the outer construct already restricts control to a single coordinate value, and it surely doesn't make sense to try distributing control across all coordinates of the same process dimension inside that construct ^5.2.

Although it wasn't explicitly stated before, there is a similar restriction for the on construct. A precondition for appearance of the construct

    on(p) {
      ...
    }

is that the group p is contained in the group active in the immediately surrounding context.