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

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

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