Certain statements may have annotations that effect the execution of the statement. An annotation has the form of an identifier preceded by a “@” character. Note that the identifiers for annotations are not reserved words, but only a limited set of predefined annotation identifiers can be used (see Table 9 -6).
A set of annotations for a statement are listed on one or more lines preceding the statement. Each of these lines has a similar form to an end-of-line lexical comment (see Subclause 7.4). This syntax reflects the fact that an annotation is essentially a directive used in the mapping of the annotated statement, not an executable construct in its own right. An annotation may place restrictions on the allowed form of the statement being annotated, but that statement is still always legal even if the annotation is removed.
Examples
//@isolated
{
temperature = temperatureSensor.read();
pressure = pressureSensor.read();
ActuateControl(temperature, pressure);
}
Syntax
AnnotatedStatement(s: Statement)
= "//@" Annotation(s.annotation) { "@" Annotation(s.annotation) }
[ "//" { InputCharacter } ] LineTerminator
Statement(s)
Annotation(a: Annotation)
= Identifier(a.identifier)
[ "(" Name(a.argument) { "," Name(a.argument) ")" ]
Figure 9 43 Abstract Syntax of Annotations
Cross References
-
LineTerminator see Subclause 7.1
-
InputCharacter see Subclause 7.1
-
Identifier see Subclause 7.5
-
Statement see Subclause 9.1
NOTE. The lexical element LineTerminator is used as a syntactic non-terminal element in the production for AnnotatedStatement above and must not be ignored as white space in this case (see also Subclause 7.3). Even though the initial “//@” token has a form similar to the start of an end-of-line comment (see Subclause 7.4), annotations must specifically follow the syntax shown above. However, a list of annotations may be followed by a “//”, the characters after which are ignored, giving the same effect as having an end-of-line comment at the end of the annotation line.
Semantics
Annotations
Even though syntactically any statement may be annotated, specific annotations may only be used with the specific statements to which they apply. Table 9 -6 lists all allowable annotations and the statements to which they apply. The effect of an annotation is described in the subclause for the statement to which the annotation applies, except for the @islolated annotation, which applies to all statements and is described below.
Table 9 6 Allowable Annotations
Annotation
|
Applicable Statement
|
Allows Arguments?
|
isolated
|
Any statement other than an empty statement or break.
|
No
|
determined
|
if (see Subclause 9.8)
switch (see Subclause 9.9)
|
No
|
assured
|
if (see Subclause 9.8)
switch (see Subclause 9.9)
|
No
|
parallel
|
block (see Subclause 9.3)
|
No
|
for (see Subclause 9.12)
|
Yes
|
Since the syntax allows an annotated statement to itself be annotated, annotations may be spread across multiple lines preceding a single “base” statement. For the purposes of determining applicability, per Table 9 -6, of a further annotation of an annotated statement, the annotated statement is to be considered to be of the same kind as its base statement. However, no annotation may be applied more than once to the same base statement.
Arguments
The syntax for annotations allows for an optional list of names to be given as arguments of the annotation. Currently, only the @parallel annotation on a for statement allows such argument (see Subclause 9.12 for rules related to names used as such arguments).
Isolation
The annotation @isolated may be used with any statement other than the empty or break statements, indicating that the statement is executed in isolation. That is, during the execution of the statement, no object accessed as part of the execution of the statement or as the result of a synchronous invocation from the statement may be modified by any action that is not executed as part of the statement or as the result of a synchronous invocation from the statement.
The semantics of isolation is discussed in Subclause 8.6.4.1 of the fUML specification.
NOTE. The unary operator $ can also be used to denote isolation at the expression level (see Subclause 8.5.6).
Other annotations are discussed with the description of the statements to which they apply.
9.3In-line Statements
An in-line statement allows code in a language other than Alf to be inserted in-line as an Alf statement. The actual interpretation and execution of such inline code is implementation dependent. Typically, such code would be passed directly to a target implementation platform, but the details are not defined in the Alf standard. While syntactically a statement, an in-line statement has a form similar to an in-line lexical comment, to indicate that the in-line code is not included in normal Alf language processing.
The language used for the in-line code is identified by a name. There is no standard list of language names, but the following names are recommended to promote potential interoperability for commonly embedded language fragments.
Example
/*@inline('C++') // Native code
*data = this;
controller->initiate();
*/
Syntax
InLineStatement(s: InLineStatement)
= InLineHeader(s) CommentText(s.code) "*/"
InLineHeader(s: InLineStatement)
= "/*@" "inline" "(" Name(s.language) ")"
[ "//" { InputCharacter } ] LineTerminator
Figure 9 44 Abstract Syntax of In-Line Statements
Cross References
-
LineTerminator see Subclause 7.1
-
InputCharacter see Subclause 7.1
-
CommentText see Subclause 7.4.1
-
Name see Subclause 7.5
NOTE. The lexical element LineTerminator is used as a syntactic non-terminal element in the production for InLineHeader above and must not be ignored as white space in this case (see also Subclause 7.3). Even though the initial “/*@” token has a form similar to the start of an in-line comment (see Subclause 7.4), an in-line statement header must specifically follow the syntax shown above. However, the inline annotation may be followed by a “//”, the characters after which are ignored to the end of line, giving the same effect as having an end-of-line comment on the header line. Comments may also be used in the body code of an in-line statement, as allowed by the specific language in which that code is written. However, since the comment delimiter “*/” is used to end an in-line statement, comment syntax using this delimeter cannot be used within the in-line statement.
Semantics
The execution semantics for an in-line statement are implementation specific.
Any relationship of code within an in-line statement to named elements outside of the in-line statement is also implementation specific.
Share with your friends: |