Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "VIATRA2/Examples/VTCL/TypeChecking"

< VIATRA2‎ | Examples‎ | VTCL
(Typed variables within ASM rules)
(Overview: Type checking)
Line 39: Line 39:
 
=== Error messages ===
 
=== Error messages ===
  
The following error messages are issued by the type checker
+
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''
 
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term
 
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term
 
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term
 
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term

Revision as of 10:20, 25 May 2009

Overview: Type checking

Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification.

As the main extension of the language, one can add type information to

  • all variables defined locally with the let rule
  • a parameter of an ASM rule, graph pattern or graph transformation rule
  • for the parameters and return values of ASM functions

Then the VIATRA2 parser checks if these variables are used in a type conformant way.

Typed variables within ASM rules

In ASM rules, types can be assigned to variables within the let rule with the following syntax VarName : TypeConst = InitValue. Here the type constant TypeConst should be a valid element of the model space, which can be resolved at compile time.

The following example demonstrates two typical type errors identified by the typechecker.

machine typechecking_errors {
  rule main() = 
  let X : datatypes.Integer = 0, 
      // Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String'	
      Y : datatypes.Integer = "oops0"
  in
    seq {
          // Type error: operation '*' undefined for types ('Integer', 'String') 
 	  update X = X * "oops1";
          // Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'
 	  update X = X + "oops2";
          // This is correct
 	  update X = X + 3;	  
    }
}

Typed variables in ASM functions

Typed variables in graph patterns

Error messages

The following error messages are issued by the type checker. Note that currently, these messages are classified as warnings!

  • Operator '-' is undefined for the argument type ('datatypes.String'): issued when checking an ASM term
  • Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String'): issued when checking an ASM term
  • The type 'uml2.metamodel.Classifier' of actual parameter is not compatible with the type 'uml2.metamodel.Class' of symbolic parameter 'C'. See the definition of 'myPattern' : issued when calling a graph pattern using the find construct
  • The type 'uml2.metamodel.Classifier' of variable reference is not compatible with the type 'uml2.metamodel.Class' of its definition.: issued in ASM rules or in the body of graph patterns
  • Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' : issued in case of an update rule
  • Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' : issued when initializing an ASM function

--Varro.mit.bme.hu 11:02, 25 May 2009 (UTC)

Back to the top