The structure of the Matrix Language is basically that of an indented and semi-ordered hierarchical list. A simplified view of the language's high-level structure is shown below:
System:
...
Matrix::
...
Silo::
...
Realm:
...
Domain:
...
Entity:
...
State
...
CreationState:
...
DynamicState:
...
DeletionState:
...
CreationDataState::
...
DynamicDataState::
...
DeletionDataState::
...
This shows a representative selection of initial statements that all models must have. All statements work on similar principles. The statements are indented to show their scope (or region) in language terms and inclusion in model terms. For example, a system is composed of many matrixes; a matrix is composed of many silos; a silo is composed of many realms and so on.
If a state has actions it must perform when it entered then the corresponding action statements will appear under a StateAction statement. Matrix's organisation of its low-level action statements is after the StateAction statement is shown below:
...
CreateActive::
...
CreatePassive:
...
SelectionHead
...
SelectionTail
...
SelectionInit
...
SelectionLast
...
EntitySelection:
Selection
...
NullSelection
...
Traverse
Navigation
TraverseSelection
...
NullTraverseSelection
...
CaseSelection
WhenCase
...
WhenCaseSelection
...
NullCaseSelection
...
Some statements are optional and may be omited if the model aspects they define are simply not required. For example, if an entity has no state machine and therefore no states, the State statement is omitted.
Statements that exist on the same indentation level must be in a specified order when and if they appear.
A statement is considered to cover a region where that statement is in scope, indicated by the indentation level. Some statements have an associated subregion which specifies an unordered list and this is also indented. For example:
Type
BaseType
Integer
Index : 0 .. 5
Length : 0 .. 100
Here, the Integer statement has a data subregion declaring two integer types.
Directives are used in data subregions to indicate something to the Model Compiler that cannot ordinarily be done using the expected values for that field. For example, to indicate that a previously specified value for the upper limit for the type named Length should be used, the <<Last>> directive is specified:
Type
Subtype
IntegerSubtype
SubrangeInteger:Length
Valid_Length : 1 .. <<Last>>
This particular directive has the effect of making the maximum value for the subtype the same as that for the type it is based upon.
|