Sequential execution

In most cases, it is possible to work out data dependencies by determining when data variables have been initialized and when they are accessed. If, however, a data variable is accessed more than once, it may be necessary indicate the access order. For example, consider this excerpt from an activity:

// BAD ACTIVITY, Don't do this!

cabin delay = cab.Estimate arrival time()
cabin delay = max( cabin delay, shortest delay )
Expect cabin( delay: cabin delay ) => UI

In the above partial activity it is unclear whether the Expect cabin bridge will send the original value or the adjusted value for cabin delay. If we drew this as a data flow diagram, we would add a control flow to ensure a correct sequence, as shown:

The highlighted control flow ensures that the bridge action does not execute until the max function action completes.

In Scrall we use indicate a sequencing control flow by means of a sequence token. A sequence token is named and then set by some action. One or more other actions can then require that token as input before proceeding. The action language is updated as shown:

// Now it is okay

cabin delay = cab.Estimate arrival time()
cabin delay = max( cabin delay, shortest delay ) <1>
<1> Expect cabin( delay: cabin delay ) => UI

In this above text we’ve defined a sequence token simply named 1 and then specified that it be set by the second assignment action. We’ve also specified that the same token is a required input for the bridge action.

A sequence token appears between angled <> brackets and can be named like any variable. So we could have called it <delay trimmed> instead.

If you want to specify that multiple actions require the same sequence token as input you can group them together as an action block using the {} brackets just as you would in an if-then-else structure. An action can set at most one sequence token by placing it to the right of the action.

An action, or set of actions, can be enabled by one or more sequence tokens. If there are multiple, they must all be enabled in order for the sequenced action to proceed. This is what you would expect if you saw an action on a data flow diagram with multiple incoming control flows.

Rather than use a sequence token in the above example, you could have done this:

// Better yet

cabin delay = max( cab.Estimate arrival time(), shortest delay )
Expect cabin( delay: cabin delay ) => UI

This is probably the better way in this example. In fact, you could compact everything into the bridge action and eliminate the temporary variable. The guideline is to use the simplest, easiest to read formulation for the given activity. Readability is always the primary goal.