MARTE — Annex B: how VSL constructs shall be typed and evaluated

Subject: Annex B doesn't clearly define how VSL constructs shall be typed and evaluated Details: Our problem: it seems to be missing some information in the current VSL specification that explains how language constructs shall be typed and evaluated. We had a look at other standard programming languages (ANSI C, Java) to see how such information is defined. In the ANSI C language reference, every section introducing a language element is organised with the same structure: a subsection that introduces the syntax, a subsection defining the constraints (including type constraints) and finally a subsection regarding the semantics (other type constraints plus explanations regarding the evaluation). For instance, we can have a look at an extract that introduces the function calls: > 6.5.2.2 Function calls > > Syntax > > primary-expression: > identifier > constant > string-literal > ( expression ) > > > Constraints > 1 The expression that denotes the called function shall have type pointer to function > returning void or returning an object type other than an array type. > > 2 If the expression that denotes the called function has a type that includes a prototype, the > number of arguments shall agree with the number of parameters. Each argument shall > have a type such that its value may be assigned to an object with the unqualified version > of the type of its corresponding parameter. > > Semantics > 3 A postfix expression followed by parentheses () containing a possibly empty, commaseparated > list of expressions is a function call. The postfix expression denotes the called > function. The list of expressions specifies the arguments to the function. > > 5 If the expression that denotes the called function has type pointer to function returning an > object type, the function call expression has the same type as that object type, and has the > value determined as specified in 6.8.6.4. Otherwise, the function call has type void. If > an attempt is made to modify the result of a function call or to access it after the next > sequence point, the behavior is undefined. In VSL, we have a definition of the abstract syntax (the meta-model) and the concrete syntax (the BNF) in the Annex B and we have a detailed description of the domain classes (abstract syntax elements) in the Annex F. It seems that the current "constraint" and "semantics" sections of the metaclass descriptions miss some detailed information on the way constructs shall be typed and evaluated. The information does not seem to be systematic and homogeneous. Examples: > F.13.6 ConditionalExpression (from Expressions) > Generalizations > • Expression (from Expressions) on page 560 > Associations > • conditionExpr: VSL::ValueSpecification [1] Boolean expression to be evaluated. > • ifTrueExpr: VSL::ValueSpecification [1] result expression if conditionExpr is evaluated to True. > • ifFalseExpr: VSL::ValueSpecification [1] result expression if conditionExpr is evaluated to false. > Semantics > Conditional Expressions define "if-then-else" statements, which can be used inside an expression. The result of evaluating > this expression will be the result of => Here it is not stated that the consequence (ifTrueExpr) and the alternative (ifFalseExpr) shall have the same type or that the type of such an expression if a boolean. OR > F.13.8 DurationExpression (from TimeExpressions) > Generalizations > • TimeExpression (from TimeExpressions) on page 567 > Semantics > DurationExpression is a time expression that denotes a duration value. => Again, here it may miss more detailed information on the type of the expression. This is the kind of information we missed when implementing the VSL editor and which we need to figure out by ourselves. Sometimes it's obvious but it happens to be definitely tricky. That's why we think that it would be beneficial for MARTE and VSL to complete the Annex F to add this information. In that context, we propose that: 1) every VSL domain class in Annex F shall provide information about its type. 2) if the type cannot be directly known, there shall be an explanation on how it can be computed (this is the case of all the subclasses of Expression and TimeExpression). 3) if information about the evaluation / execution semantics is provided then it shall be distinguished from the type information (because this is something really different). All this information would complete either the "constraint" and/or "semantics" section of Annex F.

VSL complements MARTE for improving the UML data type system and the
specification of expressions. The approach to define VSL was to balance both its
precision and its level of formality in order to provide a very compact specification
but still well-formed. MARTE Beta 1 and 2 have provided a good basis to develop
a couple of tools supporting VSL parsing and type checking. There are, however,
some aspects that need to be improved in the VSL specification to avoid
ambiguity in tool implementations. Some of the ambiguity problems were
described in the summary of this issue, but we can organize them more formally
in the following categories:
a) Some of the production rules are syntactically ambiguous because they are
based on the UML model to which the VSL expression is attached (e.g., does a
data type exist or not). This means that disambiguating rules have to be defined
for those rules.
b) In order to semantically evaluate VSL expressions, we need to define the type
of each expression or value specification. The mapping of expressions to (data)
types can be easily identified in many cases, but there are other cases that this
requires making it explicit. Moreover, there are some expressions that cannot be
evaluated to any existing data type defined in MARTE. For example, duration
expressions have not a type counterpart in the library of MARTE primitive types. To solve item (a), we will add a section of “Disambiguating Rules” for each
production rule. In addition, one of the suggestions proposed in the summary of
this issue is to add a special section for a semantics description. It must be
noted, however, that VSL is described in two main parts: abstract syntax and
concrete syntax. The semantics of VSL construct is described in plain English as
a part of the abstract syntax. More particularly, the semantics of VSL model
elements is described in Annex F, section F.13. However, the mapping of
abstract syntax constructs to concrete syntax constructs is not explicit. In this
resolution, we propose to add this mapping by identifying the abstract syntax
counterpart of each production rule explicitly in the concrete syntax section.
To solve item (b), we will complete all the required primitive types and describe
the types to which VSL expressions should be evaluated. For those expressions
that cannot be directly mapped to a concrete type, we will provide rules to help
evaluating them.
In addition, we will add some clarifications to help VSL implementers to use this
specification. The goal is that at the end of all processing every tool
implementation should be able to produce the same well-formed instance of
abstract syntax tree.