8.6.4. Actually computing the current context
The execution machine must compute the value of the current context. This is trivial in many cases, as expressions are quite often applied to contexts. However, in a do (or notify or action) things can get difficult if they hold for role state. Remember that the expressions in the body of such a do will be applied to a role instance.
Isn’t the current context just the context of that role instance? That may be the case, but it is not so if the object- or subject state is for a calculated role. The current context should be the lexical context, i.e. the context that one can verify, in the source code, to contain the do expression somewhere in its body. But the origin
that the expression function is applied to, may be a role in an entirely different context. That is the usefulness of calculated roles!
Let’s consider the case of object state. The state specification will have a RoleIdentification that represents the origin
. Consider the case of an ImplicitRole: the RoleIdentification contains a context type that represents the current context, and a Step that represents the expression that computes the role from that context.
To find the context from the role, we just have to reverse the expression. This we can do; we have machinery to invert QueryFunctionDescriptions (for triggering state changes and query updates, for example). So we compute a QueryFunctionDescription for the Step with respect to the current context type, and reverse it.
The execution machine uses that inverted function to compute the context from the role instance that changes state.