MARTE — using $ in naming variables

This editing issue affects many chapters.

In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name.

Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning.
Examples are found in NFP (Fig 8.9) and many other chapters.

These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement.

In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples

There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call' expression, we use only the name. We really need to make difference between both because VSL parsers need to distinguish them.

a) Arguments to use 'let' as keyword in variable declarations:

The use of '$' is not 'conventional' to declare variables. Other keywords like 'let [variable-name]' would be more appropriate. It is recommended to use 'let ' for variable declaration because having a keyword for declaration is the more natural choice in most of languages.

b) Arguments to use '$' as part of the variable name in variable call expressions:

The absence of the symbol '$' in variable call expressions ("variable use") would make hard to make the distinction with other 'names' in VSL expressions, such as enumeration literals or PropertyCallExpression. The goal of this symbol in the former SPT profile was to identify easily a variable within an expression. With the current notation, the latter is not possible.
.
c) Arguments against a modification of variable notation

Some reasons would suggest avoiding such a modification:

• VSL has an essential difference with other conventional languages: VSL is intended to be used in 'properties values', where compact annotations should be privileged. Also, its use in Constraints tries to mark a difference with OCL, and it's that annotations should be shorter and easier to understand. Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language.

• The UML Time Observation notation works exactly like VSL variables. A symbol ('@' for time observation and '&' for duration observation) is used for declarations, and only the name (without the symbol) for expressions. Time observations could be considered as a sort of variables, but with a more specific semantics. So, having the notation of both VSL variables and Time Expression aligned is important for comprehensibility of Profile users.

-In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that the variables will be easily identified in a model, because they will include the '$' symbol.

• VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions.

d) Conclusions

The argument for using 'let' is more to follow conventional languages, and not pragmatic concerns. Also, the argument that the current mechanism confuses comprehensibility between variable declaration and variable call expression is not sustainable. VSL variable notation works exactly as UML TimeObservation works, and there were not reported any issue related to confusing language users.

For these reasons, we suggest to close this issue with no change.

Disposition: Closed, no change