Transitions

The transitions section closes out a state block and says where each incoming event sends the instance next.

state CLOSING
activity
transitions
    Door closed > CLOSED
    Passenger open > OPENING
    Door blocked > Count block
--

The grammar:

transitions = transition_header transition*
transition_header = "transitions" EOL*
transition = INDENT event_name (SP '>' SP state_name)? EOL*

An unindented transitions keyword opens the section, and each transition is an indented line naming the event, then >, then the destination state.

Note that the transitions section has no -- of its own. The unindented -- that follows is the block_end of the enclosing state block, so it closes the transitions and the state together.

Spacing

The grammar asks for exactly one space on each side of the >. Not zero, not two.

Events must be declared

Every event_name here has to appear in the model's Events section, and every state_name has to be a real state in this file. The grammar can't check either of those — both are just names to it — so a downstream module does the resolving. A transition to a misspelled state name parses perfectly well and fails later, which is how Regsitering floor call has sat undisturbed in this repository's older asl.xsm sample for years.

The transitions section is optional

Unlike the activity (see Activities), transitions may be left out entirely:

state CANNOT CLOSE
activity
    Take out of service -> /R4/Cabin
--

A state with no transitions is a final state — nothing gets the instance out of it. For a deletion state (see Deletion states) that's exactly right, since the instance ceases to exist. For any other state, an omitted transitions section is worth a second look: you may have modeled a dead end by accident.

Ignoring an event

That optional destination in the grammar — (SP '>' SP state_name)? — is not an accident. An event name on its own, with no > and no destination, means the event is accepted in this state and deliberately ignored:

transitions
    Passenger open
    Door closed > CLOSED

This is a real thing you want to be able to say. In a Shlaer-Mellor state model there's a difference between "this event cannot happen here" (leave it out of the transitions altogether, and its arrival is an error worth reporting) and "this event can happen here and the right response is to do nothing" (list it with no destination). Conflating the two is how you end up either silently swallowing real bugs or drowning in spurious can't-happen errors.

What the parser gives you

A list of Transition_a named tuples in the transitions field of StateBlock_a, each with an event and a to_state. An ignored event comes back with to_state=None. A state with no transitions section gets an empty list.