Issue 11878: Annex B: how VSL constructs shall be typed and evaluated (marte-ftf) Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com) Nature: Revision Severity: Significant Summary: 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. Resolution: 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. Revised Text: see ptc/2009-05-12 pages 139 - 150 Actions taken: December 21, 2007: received issue October 16, 2009: closed issue Discussion: Resolution: This requires a lot of work. We agree that this is a real issue. This relates a fundamental problem of VSL which is to define what is part of the language and is defined in libraries. This requires to define a mechanism to formalize datatype operation semantics at library level. This also requires to revise if we need a primitive type for Time-related values. We should also try to align to OCL, which already define a chapter for the semantics and expression evaluation. This should be defined with a careful work. So we propose to defer this issue. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 21 Dec 2007 14:50:49 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Sébastien Demathieu Company: Thales mailFrom: sebastien.demathieu@thalesgroup.com Notification: Yes Specification: UML profile for MARTE Section: Annex B FormalNumber: 07-08-04 Version: Beta 1 RevisionDate: 08/2007 Page: 383 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Description 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.