The simulation language contains four types of statement, sequences of which form the bodies of transitions. Statements are imperative, and are the only part of the language which may have side-effects. Statements take only well typed inputs, but have no return type.
Statements in sequences inside transition bodies are separated by semi-colons and are executed in program order (i.e. the order in which they appear in the simulation description). Their side-effects occur in program order as well, so a reply statement followed by an emit statement will produce a different sequence of messages on D-Bus than if the emit statement was listed first.
The most common type of statement, assignments may be used in all types of transition. They assign the value of the expression on their right-hand side to the variable (or structure of variables) on their left-hand side.
object->PropertyName = "new value"
(Variable1, Variable2) = ([1u, 2u], [3u, 4u])
Assignment to structures is only permitted if all of the leaves/atomic values in the structure are variables. None of them may be other values, such as string literals.
Signal emissions may be used in all types of transition, and have the side-effect of emitting a D-Bus signal. They take a signal name and a tuple of parameters for the signal. The signal must be defined on an interface implemented by the containing object.
emit SignalName ("parameter1", 5u, ["list", "of", "things"])Method call replies may only be used in method-triggered transitions. They take a tuple of output parameters from the method and have the side-effect of returning that tuple to the client over D-Bus as a method reply message. The type of the parameter tuple must match the method's definition in the set of interfaces implemented by the containing object.
reply ("out parameter1", 42u, {
"dict" : <5u>,
"of" : <true>,
"variants" : <"value">,
})As with method call replies, method call errors may only be used in method-triggered transitions. They take the name of an error and have the side-effect of throwing that error to the client over D-Bus as a method reply message. No restrictions are placed on the error name past those given in the D-Bus specification.
throw ErrorName