Top level organization of execution
Here is an illustration of the top level of the Scrall grammar in which we break down a model Activity into its primary units of execution such as execution units, statements, blocks, sequence tokens and so forth.
A populated Activity in the metamodel is probably best visualized as a flat data flow diagram. That said, the textual specification of the components of Activity content in just about any action language rely on some degree of indentation and nesting. The one dimensional nature of text inevitably leads us to hierarchical patterns.
Un-nesting, then, is a pervasive theme as we sift through our parsed action language to populate the corresponding metamodel elements.
Here is the top level of our parse tree with Leon's peg grammar graphical notation annotated:
An activity corresponds to the metamodel definition of a state, method, or synchronous (external entity) operation Activity. It may be empty, as is sometimes the case when you define a State where an instance simply waits, or it may consist of multiple execution_units, each corresponding to a set of computations. We use the term 'computation' to refer loosely to any processing that occurs in an Activity. Non-state Activities may return a value such a Method or a Synchronous Operation on an External Entity. If so, an output_flow may be specified which itself may define some computation in order to produce the value.
Throughout this discussion we will be using a mix of Scrall grammar and metamodel terms. All Metamodel concepts that have been formalized as metamodel classes such as Activity, State, Method, etc will be in initial caps as they are throughout the metamodel documentation. Scrall language elements such as activity, execution_unit, scalar_expression and such will always be in lowercase. Just because two names are the same such as activity and Activity, don't assume they mean exactly the same thing. When in doubt, consult the relevant portions of the metamodel wiki and the scrall grammar itself.
An execution_unit is either an output_flow or a set of Scrall statements followed by an optional sequence_token.
As the name suggests, an output_flow flows a value out of a Method or Synchronous Operation Activity. Only these Activities can yield a value during execution. You can think of it like a programming language return statement. A State Activity cannot contain an output_flow, but this is not a rule enforced by the parser. We do enforce it in the course of model population, however.
The output value is determined by a scalar_expr which is a bit of misnomer as it can output a single Scalar, Table, or Instance Flow. A better name for it might simply be ‘expr’ which we can consider later.
An statement_set represents a bundle of computation that can execute either immediately (upon activity invocation) or when certain conditions are met. There are two kinds of statement_sets.
An sequenced_statement_set is either a single statement or a block of execution_units. Either of these terms may be preceded by sequence_tokens and thus represent processing dependent on a set of Sequence Flows.
For each sequence_token, if any, we will populate a Sequence Flow input to certain Actions populated from each statement. Only those Actions that are not dependent on any Data Flow will receive a Sequence Flow input as these are what we consider to be initial Actions. That is, Actions that kick off a flow of computation.
See Parsing sequenced statement sets for more details on this process.
A sequence_token represents some named condition that we consider to be enabled when the set of statements has completed execution.
A single sequence_token that follows a statement_set is enabled when all of those statements complete execution.
A set of sequence_tokens preceding a set of statements in a sequenced_statement_set establish an enabling condition. Each of these sequence_tokens must be enabled before the sequenced_statement_set may begin execution.
Certain statements define internal blocks as part of their pattern. A decision statement, for example, specifies a true and an optional false result. Here the statement or block of statements is enabled by some condition defined in the statement type such as if true / if false as opposed to input tokens which are meaningless in this context. Consequently, enabling sequence tokens are not relevant (or permitted) in front of a component_statement_set.
That said, either type of statement_set may enable a single sequence_token.
A Scrall statement is one of several pre-defined patterns that populate a set of Actions and Flows within an Activity. Each such pattern is defined in the statement breakdown.
A block is a set of statements enclosed in {} brackets. Any block may optionally be followed by a single sequence_token to indicate a condition that is set when all of the statements inside the block that were executable, given whatever conditional logic applies inside that block (decisions, switches, etc).