https://wiki.eclipse.org/api.php?action=feedcontributions&user=Varro.mit.bme.hu&feedformat=atomEclipsepedia - User contributions [en]2024-03-28T14:10:21ZUser contributionsMediaWiki 1.26.4https://wiki.eclipse.org/index.php?title=VIATRA/Addon/Surrogate_Queries&diff=384305VIATRA/Addon/Surrogate Queries2015-05-20T16:49:21Z<p>Daniel.varro.gmail.com: Some clarifications and improvements for the use of English.</p>
<hr />
<div>= Surrogate queries for derived features =<br />
<br />
Query-based features capture the definition of [[EMFIncQuery/UserDocumentation/Query_Based_Features#Well-behaving_structural_feature|well-behaving]] derived features of Ecore models by queries, and allow the use of such derived features in the body of other queries. But when an Ecore model is not allowed to be modified, you could not use derived features in query bodies in the past. EMF-IncQuery 1.0.0 introduces '''surrogate queries''' for derived features, where a derived feature used in a query is replaced by a subpattern call during query execution time (runtime).<br />
<br />
== Usage ==<br />
<br />
<source lang="java"><br />
@Surrogate<br />
pattern superClass(self : Classifier, super : Classifer) {<br />
Classifier.generalization(self, generalization);<br />
Generalization.general(generalization, classifier);<br />
}<br />
</source><br />
<br />
In order to create a surrogate query, simply add a @Surrogate annotation for a pattern and the generator will take care of defining the correct extension points. When the query plug-in is included in the host, the EMF-IncQuery runtime will automatically replace path expressions including the feature with a subpattern call. In addition, if the plug-in is available in the host or target platform, the warning for a derived feature usage will be different (instead of warning about not representable feature, it will include the fully qualified name of the surrogate query). So the following will work correctly during runtime:<br />
<br />
<source lang="java"><br />
pattern superClassWithName(self : Classifier) {<br />
Classifier.superClass(self, superClass);<br />
Classifier.name(superClass, "mySuperClass");<br />
}<br />
</source><br />
<br />
=== Important information on developing surrogate queries ===<br />
<br />
Surrogate queries defined in workspace projects are not yet visible to the Query Explorer, so loading queries that use those derived features will result in incorrect match results. If you want to try such queries in the Query Explorer, do the following:<br />
* If the surrogate query definition and the pattern using it are in different projects, simply start a runtime Eclipse where at least the defining query is included.<br />
* If the surrogate query definition and the pattern using it are in the same project, simply use a subpattern call (find) instead.<br />
<br />
== Example ==<br />
<br />
The UML metamodel used in EMF-UML contains a large number of derived features (see [[EMFIncQuery/UMLSupport#Status_of_derived_features]] for details), most of which are not [[EMFIncQuery/UserDocumentation/Query_Based_Features#Well-behaving_structural_feature|well-behaving]], which significantly complicated the definition of patterns over UML models in the past.<br />
<br />
Consider the following pattern:<br />
<br />
<source lang="java"><br />
pattern superClassWithQualifiedName(self : Classifier) {<br />
Classifier.superClass(self, superClass);<br />
Classifier.qualifiedName(superClass, "my::favorite::package::SuperSuperClass");<br />
}<br />
</source><br />
<br />
Both Classifer.superClass and NamedElement.qualifiedName are derived features, therefore<br />
* the pattern editor will display a warning about these features are not amenable to incremental evaluation;<br />
* the runtime will index the value of these features and no matches will be returned.<br />
<br />
Since the value of these feature can be computed from the rest of the model, users often manually defined helper patterns, for example:<br />
<br />
<source lang="java"><br />
pattern superClass(self : Classifier, super : Classifer) {<br />
Classifier.generalization(self, generalization);<br />
Generalization.general(generalization, classifier);<br />
}<br />
<br />
pattern superClassWithQualifiedName(self : Classifier) {<br />
find superClass(self, superClass);<br />
Classifier.qualifiedName(superClass, "my::favorite::package::SuperSuperClass");<br />
}<br />
</source><br />
<br />
However, this approach has several drawbacks:<br />
* Reinventing the wheel: derived features are redefined over and over again.<br />
* Error-prone definition: you can easily overlook some detail in the computation and get unexpected results.<br />
* Disallowed use in patterns: the derived feature cannot be used directly in other pattern bodies, you need to explicitly call the helper pattern (by the ''find'' construct).<br />
<br />
Surrogate queries are introduced to help overcome these issues.<br />
<br />
== Technical details ==<br />
<br />
Surrogate query support includes the @Surrogate annotation in the pattern editor, the corresponding code generator fragment, the runtime loading and usage of surrogate query registry, the runtime replacement of derived feature usage in queries. However, when running outside of Eclipse, some additional setup is required.<br />
<br />
=== Definition of surrogate queries ===<br />
<br />
The '''@Surrogate''' annotation has a single, optional parameter ''feature'' which specifies the name of the EStructuralFeature that the surrogate query replaces. If omitted, the name of the pattern must match the name of the feature. The first parameter of the pattern is always the source, and the second parameter is the target.<br />
<br />
Let us assume you want to surrogate a derived feature ''someExternalModelFeature'' in EClass ''ExternalClass'' with type ''OtherExternalClass''.<br />
<br />
You can choose between:<br />
<source lang="java"><br />
@Surrogate(feature = "someExternalModelFeature")<br />
pattern mySurrogatePattern(this : ExternalClass, target : OtherExternalClass) {<br />
[...] // pattern body<br />
}<br />
</source><br />
<br />
and:<br />
<br />
<source lang="java"><br />
@Surrogate<br />
pattern someExternalModelFeature(this : ExternalClass, target : OtherExternalClass) {<br />
[...] // pattern body<br />
}<br />
</source><br />
<br />
The annotation is defined by the ''querybasedfeatures.runtime'' plug-in together with a validator (also provided by the same plug-in), which checks several things:<br />
* the pattern has exactly two parameters<br />
* the feature specified by the pattern name or the parameter of the annotation exists in the source EClass<br />
* the target type of the feature is compatible with the second parameter of the pattern<br />
* there is only one Surrogate annotation for a pattern or each of them define different features<br />
<br />
The code generator fragment is defined by the ''querybasedfeatures.tooling'' plug-in and it simply creates an extension for the surrogate query extension point in the plugin.xml:<br />
<br />
<source lang="xml"><br />
<extension id="extension.surrogate.mySurrogates.mySurrogatePattern" point="org.eclipse.incquery.patternlanguage.emf.surrogatequeryemf"><br />
<surrogate-query-emf class-name="ExternalClass" feature-name="someExternalModelFeature" package-nsUri="external.ecore.uri"<br />
surrogate-query="org.eclipse.incquery.runtime.extensibility.PQueryExtensionFactory:mySurrogates.MySurrogatePatternQuerySpecification"/><br />
</extension><br />
</source><br />
<br />
=== Runtime behavior ===<br />
<br />
During runtime, the surrogate queries are loaded into a surrogate query registry (defined in the ''runtime.matchers'' plug-in) by reading the extension registry of Eclipse.<br />
When a given pattern is loaded into an engine, path expressions including derived features with defined surrogate queries are replaced in the PSystem representation.<br />
<br />
This means that the surrogate queries are only used if they are available and registered. Additionally, for query backends that can handle non well-behaving derived features (e.g. the [[EMFIncQuery/DeveloperDocumentation/LocalSearch|local search]] backend), this rewriting is skipped.<br />
<br />
=== Usage outside of Eclipse ===<br />
<br />
Since the extension registry is not available when running outside of Eclipse, users have to manually register surrogate queries before they can be used for query evaluation.<br />
<br />
In addition to the instructions in [[EMFIncQuery/UserDocumentation/HeadlessExecution#Using_IncQuery_in_a_Java_application]], the following setup is required for each surrogate query:<br />
<br />
<source lang="java"><br />
SurrogateQueryRegistry.instance().registerSurrogateQueryForFeature(<br />
new EStructuralFeatureInstancesKey(ExternalPackage.Literals.EXTERNAL_CLASS_SOME_EXTERNAL_MODEL_FEATURE),<br />
MySurrogatePatternQuerySpecification.instance.getInternalQueryRepresentation());<br />
</source><br />
<br />
See http://git.eclipse.org/c/incquery/org.eclipse.incquery.git/tree/plugins/org.eclipse.incquery.uml/src/org/eclipse/incquery/uml/IncQueryUMLStandaloneSetup.java for an example.</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/ReleaseNotes3.3&diff=311971VIATRA2/ReleaseNotes3.32012-08-02T15:20:53Z<p>Daniel.varro.gmail.com: </p>
<hr />
<div>= Release Notes for VIATRA2 R3.3 =<br />
<br />
VIATRA2 R3.3 is the newest release of the VIATRA2 model transformation framework. R3.3, like its predecessor R3.2, is mainly a bugfix-oriented release containing fixes for many issues, and performance as well as usability enhancements; it is compatible with Eclipse Indigo and Juno. For notes on the previous major release (R3.2), refer to [[VIATRA/ReleaseNotes3.2]]<br />
<br />
Fixed issues include:<br />
* improved error management, more robust behaviour for erroneous transformations<br />
* various GUI and model transformation engine fixes and enhancements<br />
* improved incremental pattern matcher performance<br />
<br />
Most important enhancements include:<br />
* updated help contents, based on the wiki<br />
* trace-based transformation execution, to support design-space exploration<br />
* integrated efficient incremental transitive closure into the incremental pattern matcher</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/ReleaseNotes3.3&diff=311963VIATRA2/ReleaseNotes3.32012-08-02T14:48:50Z<p>Daniel.varro.gmail.com: New page: = Release Notes for VIATRA2 R3.3 = VIATRA2 R3.3 is the newest release of the VIATRA2 model transformation framework. R3.3, like its predecessor R3.2, is mainly a bugfix-oriented release c...</p>
<hr />
<div>= Release Notes for VIATRA2 R3.3 =<br />
<br />
VIATRA2 R3.3 is the newest release of the VIATRA2 model transformation framework. R3.3, like its predecessor R3.2, is mainly a bugfix-oriented release containing fixes for many issues, and performance as well as usability enhancements; it is compatible with Eclipse Indigo and Juno. For notes on the previous major release (R3.2), refer to [[VIATRA/ReleaseNotes3.2]]<br />
<br />
Fixed issues include:<br />
* improved error management, more robust behaviour for erroneous transformations<br />
* various GUI and model transformation engine fixes and enhancements<br />
<br />
Most important enhancements include:<br />
* updated help contents, based on the wiki<br />
* trace-based transformation execution, to support design-space exploration</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2&diff=311962VIATRA22012-08-02T14:45:43Z<p>Daniel.varro.gmail.com: </p>
<hr />
<div>== Quick links ==<br />
* [http://www.eclipse.org/gmt/VIATRA2/ Project page]<br />
* [http://www.eclipse.org/gmt/VIATRA2/download/ Downloads]<br />
* [http://www.eclipse.org/forums/index.php/f/147/ Forum]<br />
* [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=GMT&content=viatra BugTracker]<br />
* [[VIATRA2/Frequently Asked Questions]]<br />
* [[VIATRA2/Installation]]<br />
* [[VIATRA2/GettingStarted]]<br />
* [[VIATRA2/Benchmarks]]<br />
<br />
Release notes:<br />
* [[VIATRA2/ReleaseNotes3.3]]<br />
* [[VIATRA2/ReleaseNotes3.2]]<br />
* [[VIATRA2/ReleaseNotes3.1]]<br />
<br />
== Project Overview ==<br />
The main objective of the VIATRA2 (VIsual Automated model TRAnsformations) framework is to provide a general-purpose support for the entire life-cycle of engineering model transformations including the specification, design, execution, validation and maintenance of transformations within and between various modeling languages and domains. <br />
<br />
VIATRA2 intends to complement existing model transformation frameworks in providing<br />
* a [[VIATRA2/GettingStarted/Model_Editing | model space]] for uniform representation of models and metamodels<br />
* a [[VIATRA2/GettingStarted/Creating_Transformations | transformation language]] with <br />
** both declarative and imperative features <br />
** based upon popular formal mathematical techniques of ''graph transformation (GT)'' and ''abstract state machines (ASM)''<br />
* a high performance transformation engine <br />
** supporting '''incremental model transformations'''<br />
** trigger-driven [[VIATRA2/Live Transformations | live transformations]] where complex model changes may trigger execution of transformations<br />
** handling well over 100,000 model elements (see our [[VIATRA2/Benchmarks | benchmarks]])<br />
* with main target application domains in<br />
** model-based tool integration framework <br />
** model analysis transformations<br />
<br />
== Documentation and Research Papers ==<br />
This wiki (with sub pages) is intended to serve as the primary source of documentation related to VIATRA2.<br />
<br />
For older documentation, you can refer to the [http://www.eclipse.org/gmt/VIATRA2/doc/ official page], which has details on the available documentation. In short, the following off-line documentation is available:<br />
<br />
* Transformation language specification: [http://www.eclipse.org/gmt/VIATRA2/doc/ViatraSpecification.pdf PDF] (this is a bit outdated)<br />
* User's guide: [http://www.eclipse.org/gmt/VIATRA2/doc/viatratut.pdf PDF] (this is completely superseded by this wiki)<br />
<br />
For a list of the most important research papers on VIATRA2, see [[VIATRA2/ResearchPapers]]<br />
<br />
== Getting started with VIATRA2 ==<br />
You can find introductory information on getting stared with VIATRA2 on the [[VIATRA2/GettingStarted|Getting Started]] pages.<br />
{{:VIATRA2/GettingStarted}}<br />
<br />
== VIATRA2 Common Use Cases ==<br />
VIATRA2 primarily aims at designing model transformations to support the precise model-based systems development with the help of invisible formal methods. Invisible formal methods are hidden by automated model transformations projecting system models into various mathematical domains (and, preferably, vice versa). In this way, VIATRA2 nicely complements other model transformation tools within the GMT initiative.<br />
<br />
The most traditional application area for VIATRA2 – started as early as 1998 – is to support the transformation-based dependability analysis of system models taken from various application areas (safety-critical and/or embedded systems, robust e-business applications, middleware, serviceoriented architecture) described using various modeling languages (BPM, UML, etc.) during a model-driven systems engineering process. Such a model (and transformation)-based dependability analysis typically also includes the verification & validation, the testing, the safety and security analysis as well as the early assessment non-functional characteristics (such as reliability, availability, responsiveness, throughput, etc.) of the system under design. In addition, model transformations for specification, design, deployment, optimization or code generation in traditional model-driven systems engineering are also focal areas for VIATRA2.<br />
<br />
The VIATRA framework is a universal model transformation tool, in the sense that it supports a number of typical use-cases in MDD:<br />
* '''Model import and export'''. through its universal model storage ([[VIATRA2/GettingStarted/Model_Editing]]), VIATRA2 is able to support several models (conforming to potentially distinct metamodels) within the same ''model space''. Models can be imported and exported ([[VIATRA2/UseCases/ModelExportImport]]) through plugins, with built-in support for important formats such as UML.<br />
* '''Model-to-model transformations'''. VIATRA can run your model-to-model transformations very efficiently thanks to its incremental graph pattern matching engine. Transformations may be specified in a high-level language ([[VIATRA2/GettingStarted/Creating_Transformations]]).<br />
* '''Model-to-code transformations'''. VIATRA is also a code generator. Code generation is essentially a special case of model transformations, where textual output is also emitted. VIATRA can simultaneously write to multiple outputs, both to in-memory buffers and workspace files ([[VIATRA2/UseCases/CodeGeneration]]).<br />
<br />
== Transformation development with VIATRA2 ==<br />
You can find the detailed description of the transformation language of VIATRA2 here: [[VIATRA2/Transformation_Language]]<br />
<br />
VIATRA2 supports a number of advanced techniques for transformation development. <br />
*'''Invoking native code''. '''''One of the most important features is VIATRA's ability to invoke your Java code directly from transformation programs. This way, you can integrate your transformations to any existing software environment. A few examples: VIATRA can manipulate external data resources - databases, remote services -, you can create efficient native functions for advanced data queries such as custom random number and ID generation, etc.) For details, see [[VIATRA2/UseCases/InvokeNativeCode]]. <br />
*'''Debugging and visualisation'''. See [[VIATRA2/UseCases/DebuggingAndVisualisation]] for details. <br />
*'''Traceability modeling'''. See [[VIATRA2/UseCases/TraceabilityModels]] for details.<br />
*Modelspace visualization: [[VIATRA2/ExtraFeatures/ModelVisualisation]]<br />
*API example: [[VIATRA2/API_Example]]<br />
<br />
For further information on general best practices, see [[VIATRA2/UseCases/TransformationBestPractices]].<br />
<br />
== Case studies ==<br />
<br />
You can find information on user-contributed case studies here: [[VIATRA2/Case_Studies]]<br />
<br />
== Standard conformance ==<br />
We need to point out that the underlying modeling and transformation concepts of VIATRA2 are nonstandard.<br />
* the model management framework is more expressive than MOF / EMF, <br />
* the VIATRA2 transformation language is not QVT, but combines formal techniques being in use for more than 15 years. <br />
<br />
VIATRA2 plans to support related standards by offering <br />
* powerful and extensible model importers and exporters <br />
* exporters/importers of other transformation languages (e.g. QVT)<br />
* domain specific languages integrated to the framework as VIATRA2 (and thus Eclipse) plug-ins.<br />
<br />
== Known uses ==<br />
The VIATRA2 framework currently served as a key underlying model transformation technology in various research projects including:<br />
* the [http://www.decos.at/ DECOS EU FP6 IP] in the field of dependable embedded systems<br />
* the [http://www.sensoria-ist.eu/ SENSORIA EU FP6 IP] in the field of service-oriented computing<br />
* the [http://diana.skysoft.pt/ DIANA EU FP6 STREP] in the avionics domain<br />
* the [http://hidenets.aau.dk/ HIDENETS EU FP6 IP] in the field of vehicular networking.<br />
* the [https://www.mogentes.eu/ MOGENTES EU FP7 ICT STREP] <br />
* the [https://www.securechange.eu/ SecureChange EU FP7 ICT FET] <br />
<br />
We ''regularly'' received valuable feedback from the following institutes:<br />
* [http://www.ait.ac.at/?L=1 AIT Austrian Institute of Technology], Vienna, AUT<br />
* LMU Munich, GER<br />
* TU Kaiserslautern, GER<br />
* University of Pisa, ITA<br />
* University of Leicester, UK<br />
* Georgia Institute of Technology, USA<br />
<br />
== Partners and supporters ==<br />
VIATRA2 development is supported by the following institutions and companies:<br />
* Budapest University of Technology and Economics, HUN<br />
* OptXware Research and Development LLC, HUN<br />
* YourKit LLC, RUS<br />
YourKit is kindly supporting open source projects with its full-featured Java Profiler.<br />
YourKit, LLC is the creator of innovative and intelligent tools for profiling<br />
Java and .NET applications. Take a look at YourKit's leading software products:<br />
[http://www.yourkit.com/java/profiler/index.jsp YourKit Java Profiler] and<br />
[http://www.yourkit.com/.net/profiler/index.jsp YourKit .NET Profiler].<br />
<br />
== Downloads and Installation ==<br />
<br />
Check [http://www.eclipse.org/gmt/VIATRA2/download/ here] for more information.<br />
For installation instructions, see [[VIATRA2/Installation]].<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:MDD]]<br />
[[Category:GMT]]</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=166455VIATRA2/Examples/VTCL/TypeChecking2009-08-02T08:35:12Z<p>Daniel.varro.gmail.com: /* Typed variables within ASM rules */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. Moreover, it also implies that detailed type checking is only initiated if a type is defined ''explicitly'' for a variable (or an ASM function).<br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
In case of user defined ASM rules, types may be attached to symbolic parameters of the rule with the following syntax: '''Dir VarName : TypeConst''' where '''Dir''' denotes the direction of the parameter (i.e. it is either '''in''', '''out''' or '''inout''').<br />
<br />
'''TODO: Maybe, the following example should not be a type error'''<br />
<br />
<source lang="text"><br />
rule calledAsmRule(in X: datatypes.Integer, out Y: datatypes.Double) = seq {<br />
update Y = 2 * X;<br />
}<br />
<br />
rule typecheck_asmrule() = <br />
let X : datatypes.Integer = 2, Y : datatypes.Integer = 0 in <br />
seq {<br />
// Type error: The type 'Integer' of actual parameter is not compatible with the type 'Double' of symbolic parameter 'Y'. <br />
// See the definition of 'calledAsmRule'.<br />
call calledAsmRule(X, Y);<br />
}<br />
</source><br />
<br />
'''Important''': Since type declarations for variables are optional, the typing of symbolic parameter lists (or variable declarations with '''let''') are different from the Java convention, i.e. if no type is indicated for a variable in a symbolic parameter list then it is not explicitly typed. For instance,<br />
<br />
<source lang="text"><br />
let X = 2, Y : datatypes.Integer = 0 in ... // Y is typed, X is untyped<br />
rule calledAsmRule(in X, out Y: datatypes.Double) = ... // Y is typed, X is untyped<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
In case of ASM functions, types can be defined (separately) for each parameter (location) as well as for the return value with the following syntax: <br />
<br />
'''asmfunction myFun (TypeConst1, TypeConst2) : ReturnTypeConst '''<br />
<br />
<source lang="text"><br />
machine typecheck_asmfun {<br />
<br />
asmfunction goals(datatypes.String) : datatypes.Integer {<br />
// Correct initialization<br />
("Messi") = 3;<br />
// Type error (left value): type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
// Type error (right value): type incompatible initialization: expecting a term of type 'Integer' instead of type 'String'<br />
(3) = "Giggs";<br />
}<br />
<br />
rule main () = let X : datatypes.Integer = 0, Y : datatypes.String = "Giggs" in seq {<br />
// Correct assignment<br />
update X = goals("Messi");<br />
// Type error: Type incompatible assignment: left value is of type 'String', right value is of type 'Integer'<br />
update Y = goals("Messi");<br />
// Correct assignment<br />
update goals(Y) = 2; <br />
// Type error: Type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
update goals(X) = 2; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
In case of graph patterns, there are two kinds of type definitions for pattern variables: <br />
* '''Types of symbolic parameters''': This is defined similarly to the type definition in case of ASM rules, i.e. '''X: Class'''.<br />
* '''Pattern body elements''': the type of pattern variables defined within a pattern body is defined by the prefixing type constant. For instance, the type X in '''Class(X)''' is, obviously, '''Class'''. <br />
<br />
The following situations are typechecked: <br />
* a pattern is called with incompatible types (see '''find childPattern(P)''' below)<br />
* the type of a pattern body element is incompatible with the type of the symbolic parameter (see '''X: Class''' and '''Classifier(X)''' below)<br />
<br />
<br />
<source lang="text"><br />
pattern myPattern(X: Class, Y: Classifier) = <br />
{<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Classifier(X);<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Element.ownedElement(OE1, P, X);<br />
Package(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Classifier' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern1'.<br />
find childPattern1(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Class' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern2'.<br />
find childPattern2(P);<br />
Element.ownedElement(OE2, P, Y);<br />
Class(Y);<br />
} <br />
<br />
pattern childPattern1(A: Classifier) = <br />
{ <br />
Class(A);<br />
} <br />
<br />
pattern childPattern2(A) = <br />
{ <br />
Class(A);<br />
} <br />
</source><br />
<br />
Note that the type of a pattern variable is infered (if possible) from the local pattern body elements. Therefore, an error message is reported when calling '''childPattern2''' with an incorrectly typed parameter '''P''' as the symbolic parameter '''A''' of '''childPattern2''' is typed implicitly by the pattern body '''Class(A)'''.<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=166454VIATRA2/Examples/VTCL/TypeChecking2009-08-02T08:34:35Z<p>Daniel.varro.gmail.com: /* Typed variables within ASM rules */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. Moreover, it also implies that detailed type checking is only initiated if a type is defined ''explicitly'' for a variable (or an ASM function).<br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
In case of user defined ASM rules, types may be attached to symbolic parameters of the rule with the following syntax: '''Dir VarName : TypeConst''' where '''Dir''' denotes the direction of the parameter (i.e. it is either '''in''', '''out''' or '''inout''').<br />
<br />
'''TODO: Maybe, the following example should not be a type error'''<br />
<br />
<source lang="text"><br />
rule calledAsmRule(in X: datatypes.Integer, out Y: datatypes.Double) = seq {<br />
update Y = 2 * X;<br />
}<br />
<br />
rule typecheck_asmrule() = <br />
let X : datatypes.Integer = 2, Y : datatypes.Integer = 0 in <br />
seq {<br />
// Type error: The type 'Integer' of actual parameter is not compatible with the type 'Double' of symbolic parameter 'Y'. <br />
// See the definition of 'calledAsmRule'.<br />
call calledAsmRule(X, Y);<br />
}<br />
</source><br />
<br />
'''Important''': Since type declarations for variables are optional, the typing of symbolic parameter lists (or variable declarations with '''let''') are different from the Java convention, i.e. if no type is indicated for a variable in a symbolic parameter list then it is not explicitly typed. For instance,<br />
<br />
<source lang="text"><br />
let X = 2, Y : datatypes.Integer = 0 in ... // Y is typed, X is untyped<br />
rule calledAsmRule(in X, out Y: datatypes.Double) = ... // Y is typed, X is untyped<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
In case of ASM functions, types can be defined (separately) for each parameter (location) as well as for the return value with the following syntax: <br />
<br />
'''asmfunction myFun (TypeConst1, TypeConst2) : ReturnTypeConst '''<br />
<br />
<source lang="text"><br />
machine typecheck_asmfun {<br />
<br />
asmfunction goals(datatypes.String) : datatypes.Integer {<br />
// Correct initialization<br />
("Messi") = 3;<br />
// Type error (left value): type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
// Type error (right value): type incompatible initialization: expecting a term of type 'Integer' instead of type 'String'<br />
(3) = "Giggs";<br />
}<br />
<br />
rule main () = let X : datatypes.Integer = 0, Y : datatypes.String = "Giggs" in seq {<br />
// Correct assignment<br />
update X = goals("Messi");<br />
// Type error: Type incompatible assignment: left value is of type 'String', right value is of type 'Integer'<br />
update Y = goals("Messi");<br />
// Correct assignment<br />
update goals(Y) = 2; <br />
// Type error: Type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
update goals(X) = 2; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
In case of graph patterns, there are two kinds of type definitions for pattern variables: <br />
* '''Types of symbolic parameters''': This is defined similarly to the type definition in case of ASM rules, i.e. '''X: Class'''.<br />
* '''Pattern body elements''': the type of pattern variables defined within a pattern body is defined by the prefixing type constant. For instance, the type X in '''Class(X)''' is, obviously, '''Class'''. <br />
<br />
The following situations are typechecked: <br />
* a pattern is called with incompatible types (see '''find childPattern(P)''' below)<br />
* the type of a pattern body element is incompatible with the type of the symbolic parameter (see '''X: Class''' and '''Classifier(X)''' below)<br />
<br />
<br />
<source lang="text"><br />
pattern myPattern(X: Class, Y: Classifier) = <br />
{<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Classifier(X);<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Element.ownedElement(OE1, P, X);<br />
Package(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Classifier' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern1'.<br />
find childPattern1(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Class' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern2'.<br />
find childPattern2(P);<br />
Element.ownedElement(OE2, P, Y);<br />
Class(Y);<br />
} <br />
<br />
pattern childPattern1(A: Classifier) = <br />
{ <br />
Class(A);<br />
} <br />
<br />
pattern childPattern2(A) = <br />
{ <br />
Class(A);<br />
} <br />
</source><br />
<br />
Note that the type of a pattern variable is infered (if possible) from the local pattern body elements. Therefore, an error message is reported when calling '''childPattern2''' with an incorrectly typed parameter '''P''' as the symbolic parameter '''A''' of '''childPattern2''' is typed implicitly by the pattern body '''Class(A)'''.<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=155035VIATRA2/Examples/VTCL/TypeChecking2009-05-25T15:56:05Z<p>Daniel.varro.gmail.com: /* Typed variables within ASM rules */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. Moreover, it also implies that detailed type checking is only initiated if a type is defined ''explicitly'' for a variable (or an ASM function).<br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
In case of user defined ASM rules, types may be attached to symbolic parameters of the rule with the following syntax: '''Dir VarName : TypeConst''' where '''Dir''' denotes the direction of the parameter (i.e. it is either '''in''', '''out''' or '''inout''').<br />
<br />
'''TODO: Maybe, the following example should not be a type error'''<br />
<br />
<source lang="text"><br />
rule calledAsmRule(in X: datatypes.Integer, out Y: datatypes.Double) = seq {<br />
update Y = 2 * X;<br />
}<br />
<br />
rule typecheck_asmrule() = <br />
let X : datatypes.Integer = 2, Y : datatypes.Integer = 0 in <br />
seq {<br />
// Type error: The type 'Integer' of actual parameter is not compatible with the type 'Double' of symbolic parameter 'Y'. <br />
// See the definition of 'calledAsmRule'.<br />
call calledAsmRule(X, Y);<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
In case of ASM functions, types can be defined (separately) for each parameter (location) as well as for the return value with the following syntax: <br />
<br />
'''asmfunction myFun (TypeConst1, TypeConst2) : ReturnTypeConst '''<br />
<br />
<source lang="text"><br />
machine typecheck_asmfun {<br />
<br />
asmfunction goals(datatypes.String) : datatypes.Integer {<br />
// Correct initialization<br />
("Messi") = 3;<br />
// Type error (left value): type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
// Type error (right value): type incompatible initialization: expecting a term of type 'Integer' instead of type 'String'<br />
(3) = "Giggs";<br />
}<br />
<br />
rule main () = let X : datatypes.Integer = 0, Y : datatypes.String = "Giggs" in seq {<br />
// Correct assignment<br />
update X = goals("Messi");<br />
// Type error: Type incompatible assignment: left value is of type 'String', right value is of type 'Integer'<br />
update Y = goals("Messi");<br />
// Correct assignment<br />
update goals(Y) = 2; <br />
// Type error: Type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
update goals(X) = 2; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
In case of graph patterns, there are two kinds of type definitions for pattern variables: <br />
* '''Types of symbolic parameters''': This is defined similarly to the type definition in case of ASM rules, i.e. '''X: Class'''.<br />
* '''Pattern body elements''': the type of pattern variables defined within a pattern body is defined by the prefixing type constant. For instance, the type X in '''Class(X)''' is, obviously, '''Class'''. <br />
<br />
The following situations are typechecked: <br />
* a pattern is called with incompatible types (see '''find childPattern(P)''' below)<br />
* the type of a pattern body element is incompatible with the type of the symbolic parameter (see '''X: Class''' and '''Classifier(X)''' below)<br />
<br />
<br />
<source lang="text"><br />
pattern myPattern(X: Class, Y: Classifier) = <br />
{<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Classifier(X);<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Element.ownedElement(OE1, P, X);<br />
Package(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Classifier' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern1'.<br />
find childPattern1(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Class' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern2'.<br />
find childPattern2(P);<br />
Element.ownedElement(OE2, P, Y);<br />
Class(Y);<br />
} <br />
<br />
pattern childPattern1(A: Classifier) = <br />
{ <br />
Class(A);<br />
} <br />
<br />
pattern childPattern2(A) = <br />
{ <br />
Class(A);<br />
} <br />
</source><br />
<br />
Note that the type of a pattern variable is infered (if possible) from the local pattern body elements. Therefore, an error message is reported when calling '''childPattern2''' with an incorrectly typed parameter '''P''' as the symbolic parameter '''A''' of '''childPattern2''' is typed implicitly by the pattern body '''Class(A)'''.<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=155027VIATRA2/Examples/VTCL/TypeChecking2009-05-25T15:51:05Z<p>Daniel.varro.gmail.com: /* Typed variables within ASM rules */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. Moreover, it also implies that detailed type checking is only initiated if a type is defined ''explicitly'' for a variable (or an ASM function).<br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
In case of user defined ASM rules, types may be attached to symbolic parameters of the rule with the following syntax: '''Dir VarName : TypeConst''' where '''Dir''' denotes the direction of the parameter (i.e. it is either '''in''', '''out''' or '''inout''').<br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
In case of ASM functions, types can be defined (separately) for each parameter (location) as well as for the return value with the following syntax: <br />
<br />
'''asmfunction myFun (TypeConst1, TypeConst2) : ReturnTypeConst '''<br />
<br />
<source lang="text"><br />
machine typecheck_asmfun {<br />
<br />
asmfunction goals(datatypes.String) : datatypes.Integer {<br />
// Correct initialization<br />
("Messi") = 3;<br />
// Type error (left value): type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
// Type error (right value): type incompatible initialization: expecting a term of type 'Integer' instead of type 'String'<br />
(3) = "Giggs";<br />
}<br />
<br />
rule main () = let X : datatypes.Integer = 0, Y : datatypes.String = "Giggs" in seq {<br />
// Correct assignment<br />
update X = goals("Messi");<br />
// Type error: Type incompatible assignment: left value is of type 'String', right value is of type 'Integer'<br />
update Y = goals("Messi");<br />
// Correct assignment<br />
update goals(Y) = 2; <br />
// Type error: Type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
update goals(X) = 2; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
In case of graph patterns, there are two kinds of type definitions for pattern variables: <br />
* '''Types of symbolic parameters''': This is defined similarly to the type definition in case of ASM rules, i.e. '''X: Class'''.<br />
* '''Pattern body elements''': the type of pattern variables defined within a pattern body is defined by the prefixing type constant. For instance, the type X in '''Class(X)''' is, obviously, '''Class'''. <br />
<br />
The following situations are typechecked: <br />
* a pattern is called with incompatible types (see '''find childPattern(P)''' below)<br />
* the type of a pattern body element is incompatible with the type of the symbolic parameter (see '''X: Class''' and '''Classifier(X)''' below)<br />
<br />
<br />
<source lang="text"><br />
pattern myPattern(X: Class, Y: Classifier) = <br />
{<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Classifier(X);<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Element.ownedElement(OE1, P, X);<br />
Package(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Classifier' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern1'.<br />
find childPattern1(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Class' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern2'.<br />
find childPattern2(P);<br />
Element.ownedElement(OE2, P, Y);<br />
Class(Y);<br />
} <br />
<br />
pattern childPattern1(A: Classifier) = <br />
{ <br />
Class(A);<br />
} <br />
<br />
pattern childPattern2(A) = <br />
{ <br />
Class(A);<br />
} <br />
</source><br />
<br />
Note that the type of a pattern variable is infered (if possible) from the local pattern body elements. Therefore, an error message is reported when calling '''childPattern2''' with an incorrectly typed parameter '''P''' as the symbolic parameter '''A''' of '''childPattern2''' is typed implicitly by the pattern body '''Class(A)'''.<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=155021VIATRA2/Examples/VTCL/TypeChecking2009-05-25T15:48:15Z<p>Daniel.varro.gmail.com: /* Typed variables in graph patterns */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. Moreover, it also implies that detailed type checking is only initiated if a type is defined ''explicitly'' for a variable (or an ASM function).<br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
In case of ASM functions, types can be defined (separately) for each parameter (location) as well as for the return value with the following syntax: <br />
<br />
'''asmfunction myFun (TypeConst1, TypeConst2) : ReturnTypeConst '''<br />
<br />
<source lang="text"><br />
machine typecheck_asmfun {<br />
<br />
asmfunction goals(datatypes.String) : datatypes.Integer {<br />
// Correct initialization<br />
("Messi") = 3;<br />
// Type error (left value): type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
// Type error (right value): type incompatible initialization: expecting a term of type 'Integer' instead of type 'String'<br />
(3) = "Giggs";<br />
}<br />
<br />
rule main () = let X : datatypes.Integer = 0, Y : datatypes.String = "Giggs" in seq {<br />
// Correct assignment<br />
update X = goals("Messi");<br />
// Type error: Type incompatible assignment: left value is of type 'String', right value is of type 'Integer'<br />
update Y = goals("Messi");<br />
// Correct assignment<br />
update goals(Y) = 2; <br />
// Type error: Type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
update goals(X) = 2; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
In case of graph patterns, there are two kinds of type definitions for pattern variables: <br />
* '''Types of symbolic parameters''': This is defined similarly to the type definition in case of ASM rules, i.e. '''X: Class'''.<br />
* '''Pattern body elements''': the type of pattern variables defined within a pattern body is defined by the prefixing type constant. For instance, the type X in '''Class(X)''' is, obviously, '''Class'''. <br />
<br />
The following situations are typechecked: <br />
* a pattern is called with incompatible types (see '''find childPattern(P)''' below)<br />
* the type of a pattern body element is incompatible with the type of the symbolic parameter (see '''X: Class''' and '''Classifier(X)''' below)<br />
<br />
<br />
<source lang="text"><br />
pattern myPattern(X: Class, Y: Classifier) = <br />
{<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Classifier(X);<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Element.ownedElement(OE1, P, X);<br />
Package(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Classifier' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern1'.<br />
find childPattern1(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Class' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern2'.<br />
find childPattern2(P);<br />
Element.ownedElement(OE2, P, Y);<br />
Class(Y);<br />
} <br />
<br />
pattern childPattern1(A: Classifier) = <br />
{ <br />
Class(A);<br />
} <br />
<br />
pattern childPattern2(A) = <br />
{ <br />
Class(A);<br />
} <br />
</source><br />
<br />
Note that the type of a pattern variable is infered (if possible) from the local pattern body elements. Therefore, an error message is reported when calling '''childPattern2''' with an incorrectly typed parameter '''P''' as the symbolic parameter '''A''' of '''childPattern2''' is typed implicitly by the pattern body '''Class(A)'''.<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=155010VIATRA2/Examples/VTCL/TypeChecking2009-05-25T15:38:44Z<p>Daniel.varro.gmail.com: /* Typed variables in graph patterns */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. Moreover, it also implies that detailed type checking is only initiated if a type is defined ''explicitly'' for a variable (or an ASM function).<br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
In case of ASM functions, types can be defined (separately) for each parameter (location) as well as for the return value with the following syntax: <br />
<br />
'''asmfunction myFun (TypeConst1, TypeConst2) : ReturnTypeConst '''<br />
<br />
<source lang="text"><br />
machine typecheck_asmfun {<br />
<br />
asmfunction goals(datatypes.String) : datatypes.Integer {<br />
// Correct initialization<br />
("Messi") = 3;<br />
// Type error (left value): type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
// Type error (right value): type incompatible initialization: expecting a term of type 'Integer' instead of type 'String'<br />
(3) = "Giggs";<br />
}<br />
<br />
rule main () = let X : datatypes.Integer = 0, Y : datatypes.String = "Giggs" in seq {<br />
// Correct assignment<br />
update X = goals("Messi");<br />
// Type error: Type incompatible assignment: left value is of type 'String', right value is of type 'Integer'<br />
update Y = goals("Messi");<br />
// Correct assignment<br />
update goals(Y) = 2; <br />
// Type error: Type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
update goals(X) = 2; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
<source lang="text"><br />
pattern myPattern(X: Class, Y: Classifier) = <br />
{<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Classifier(X);<br />
// Type error for X: The type 'Classifier' of variable reference is not compatible with the type 'Class' of its definition. <br />
Element.ownedElement(OE1, P, X);<br />
Package(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Classifier' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern1'.<br />
find childPattern1(P);<br />
// The type 'Package' of actual parameter is not compatible with the type 'Class' of symbolic parameter 'A'. <br />
// See the definition of 'childPattern1'.<br />
find childPattern2(P);<br />
Element.ownedElement(OE2, P, Y);<br />
Class(Y);<br />
} <br />
<br />
pattern childPattern1(A: Classifier) = <br />
{ <br />
Class(A);<br />
} <br />
<br />
pattern childPattern2(A) = <br />
{ <br />
Class(A);<br />
} <br />
</source><br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154964VIATRA2/Examples/VTCL/TypeChecking2009-05-25T14:32:48Z<p>Daniel.varro.gmail.com: /* Overview: Type checking */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. Moreover, it also implies that detailed type checking is only initiated if a type is defined ''explicitly'' for a variable (or an ASM function).<br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
In case of ASM functions, types can be defined (separately) for each parameter (location) as well as for the return value with the following syntax: <br />
<br />
'''asmfunction myFun (TypeConst1, TypeConst2) : ReturnTypeConst '''<br />
<br />
<source lang="text"><br />
machine typecheck_asmfun {<br />
<br />
asmfunction goals(datatypes.String) : datatypes.Integer {<br />
// Correct initialization<br />
("Messi") = 3;<br />
// Type error (left value): type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
// Type error (right value): type incompatible initialization: expecting a term of type 'Integer' instead of type 'String'<br />
(3) = "Giggs";<br />
}<br />
<br />
rule main () = let X : datatypes.Integer = 0, Y : datatypes.String = "Giggs" in seq {<br />
// Correct assignment<br />
update X = goals("Messi");<br />
// Type error: Type incompatible assignment: left value is of type 'String', right value is of type 'Integer'<br />
update Y = goals("Messi");<br />
// Correct assignment<br />
update goals(Y) = 2; <br />
// Type error: Type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
update goals(X) = 2; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154962VIATRA2/Examples/VTCL/TypeChecking2009-05-25T14:32:32Z<p>Daniel.varro.gmail.com: /* Overview: Type checking */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. Moreover, it also implies that detailed type checking is only initiated if a type is defined explicitly for a variable (or an ASM function).<br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
In case of ASM functions, types can be defined (separately) for each parameter (location) as well as for the return value with the following syntax: <br />
<br />
'''asmfunction myFun (TypeConst1, TypeConst2) : ReturnTypeConst '''<br />
<br />
<source lang="text"><br />
machine typecheck_asmfun {<br />
<br />
asmfunction goals(datatypes.String) : datatypes.Integer {<br />
// Correct initialization<br />
("Messi") = 3;<br />
// Type error (left value): type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
// Type error (right value): type incompatible initialization: expecting a term of type 'Integer' instead of type 'String'<br />
(3) = "Giggs";<br />
}<br />
<br />
rule main () = let X : datatypes.Integer = 0, Y : datatypes.String = "Giggs" in seq {<br />
// Correct assignment<br />
update X = goals("Messi");<br />
// Type error: Type incompatible assignment: left value is of type 'String', right value is of type 'Integer'<br />
update Y = goals("Messi");<br />
// Correct assignment<br />
update goals(Y) = 2; <br />
// Type error: Type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
update goals(X) = 2; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154960VIATRA2/Examples/VTCL/TypeChecking2009-05-25T14:31:03Z<p>Daniel.varro.gmail.com: /* Typed variables in ASM functions */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
In case of ASM functions, types can be defined (separately) for each parameter (location) as well as for the return value with the following syntax: <br />
<br />
'''asmfunction myFun (TypeConst1, TypeConst2) : ReturnTypeConst '''<br />
<br />
<source lang="text"><br />
machine typecheck_asmfun {<br />
<br />
asmfunction goals(datatypes.String) : datatypes.Integer {<br />
// Correct initialization<br />
("Messi") = 3;<br />
// Type error (left value): type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
// Type error (right value): type incompatible initialization: expecting a term of type 'Integer' instead of type 'String'<br />
(3) = "Giggs";<br />
}<br />
<br />
rule main () = let X : datatypes.Integer = 0, Y : datatypes.String = "Giggs" in seq {<br />
// Correct assignment<br />
update X = goals("Messi");<br />
// Type error: Type incompatible assignment: left value is of type 'String', right value is of type 'Integer'<br />
update Y = goals("Messi");<br />
// Correct assignment<br />
update goals(Y) = 2; <br />
// Type error: Type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
update goals(X) = 2; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154958VIATRA2/Examples/VTCL/TypeChecking2009-05-25T14:29:54Z<p>Daniel.varro.gmail.com: /* Typed variables in ASM functions */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
In case of ASM functions, types can be defined (separately) for each parameter (location) as well as for the return value with the following syntax: '''asmfunction myFun (datatypes.String, datatypes.String) : datatypes.Integer '''<br />
<br />
<source lang="text"><br />
machine typecheck_asmfun {<br />
<br />
asmfunction goals(datatypes.String) : datatypes.Integer {<br />
// Correct initialization<br />
("Messi") = 3;<br />
// Type error (left value): type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
// Type error (right value): type incompatible initialization: expecting a term of type 'Integer' instead of type 'String'<br />
(3) = "Giggs";<br />
}<br />
<br />
rule main () = let X : datatypes.Integer = 0, Y : datatypes.String = "Giggs" in seq {<br />
// Correct assignment<br />
update X = goals("Messi");<br />
// Type error: Type incompatible assignment: left value is of type 'String', right value is of type 'Integer'<br />
update Y = goals("Messi");<br />
// Correct assignment<br />
update goals(Y) = 2; <br />
// Type error: Type incompatible initialization: expecting a term of type 'String' instead of type 'Integer'<br />
update goals(X) = 2; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154951VIATRA2/Examples/VTCL/TypeChecking2009-05-25T14:20:35Z<p>Daniel.varro.gmail.com: /* Overview: Type checking */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker. '''Note that currently, these messages are classified as warnings!'''<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154949VIATRA2/Examples/VTCL/TypeChecking2009-05-25T14:19:41Z<p>Daniel.varro.gmail.com: /* Typed variables within ASM rules */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
// Type error: Type incompatible initialization: expecting a term of type 'Integer' instead of 'String' <br />
Y : datatypes.Integer = "oops0"<br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154948VIATRA2/Examples/VTCL/TypeChecking2009-05-25T14:17:35Z<p>Daniel.varro.gmail.com: /* Typed variables within ASM rules */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
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.<br />
<br />
The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0, <br />
Y : datatypes.Integer = "oops0" // Type error: <br />
in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154946VIATRA2/Examples/VTCL/TypeChecking2009-05-25T14:15:51Z<p>Daniel.varro.gmail.com: /* Overview: Type checking */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
In ASM rules, types can be assigned to variables within the '''let''' rule with the following syntax '''VarName : TypeConst = InitValue'''. The following example demonstrates two typical type errors identified by the typechecker. <br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0 in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154945VIATRA2/Examples/VTCL/TypeChecking2009-05-25T14:13:25Z<p>Daniel.varro.gmail.com: /* Overview: Type checking */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
<source lang="text"><br />
machine typechecking_errors {<br />
rule main() = <br />
let X : datatypes.Integer = 0 in<br />
seq {<br />
// Type error: operation '*' undefined for types ('Integer', 'String') <br />
update X = X * "oops1";<br />
// Type error: type incompatible assignment: left value is of type 'Integer', right value is of type 'String'<br />
update X = X + "oops2";<br />
// This is correct<br />
update X = X + 3; <br />
}<br />
}<br />
</source><br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/GraphPattern&diff=154942VIATRA2/Examples/VTCL/GraphPattern2009-05-25T14:07:57Z<p>Daniel.varro.gmail.com: /* Pattern Matching Semantics */</p>
<hr />
<div>== Overview: Graph patterns ==<br />
<br />
=== Pattern Matching Semantics ===<br />
<br />
'''NOTE: The shareable keyword and thus noninjective matches will be available from VIATRA R4 (expected by the end of June, 2009).<br />
This description serves as a documentation of the new features.'''<br />
<br />
Patterns may be composed in VTCL a complex way by using the '''find''' construct. <br />
Moreover, the injectivity of pattern matching can be further controlled by using the new '''shareable''' keyword as follows: <br />
* '''Injective pattern matching (default)''': the default behavior of the pattern matcher is that two local pattern variables cannot be bound to the same value (i.e. element in the model space). Pattern variable assignments (in the form of '''A=B''') can enforce that the two variables take the same value during pattern matching.<br />
* '''Shareable (or non-injective) pattern matching''': the injectivity condition is not checked for local pattern variables (thus two variables may be bound to the same value) unless a non-injectvity constraint (in the form of '''A =/= B''') is prescribed explicitly for a pair of variables. <br />
<br />
The following examples highlight the semantic corner cases using of pattern composition and injective pattern matching. As a example, we use <br />
a simple state machine formalism (with states as entities and transitions as relations), which potentially contain loop transitions (where the source and target state of a transition is the same).<br />
<br />
<source lang="text"><br />
// A and B should be different, i.e. loop transitions are not matched<br />
pattern childPatternInj1(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
// A and B may be equal, loop transitions are matched<br />
shareable pattern childPatternSha1(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
// Equivalent match set with childPatternInj1: A =/= B<br />
pattern childPatternInj2(A, B) = {<br />
find childPatternSha1(A, B);<br />
}<br />
<br />
// Equivalent match set with childPatternInj1: A =/= B<br />
shareable pattern childPatternSha2(A, B) = {<br />
find childPatternSha1(A, B);<br />
A =/= B;<br />
}<br />
</source><br />
<br />
And now, let us present some more complex scenarios. As a general rule, the caller (parent) pattern <br />
may prescribe additional injectivity constraints for the local variables. <br />
<br />
<source lang="text"><br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern1(X, Y, Z) = {<br />
find childPatternInj1(X, Y); <br />
find childPatternInj1(Y, Z);<br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern2(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternSha1(Y, Z); <br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern3(X, Y, Z) = {<br />
find childPatternSha1(X, Y);<br />
find childPatternSha1(Y, Z); <br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z (thanks to the injectivity of the child pattern)<br />
shareable pattern parentPattern4(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternInj1(Y, Z);<br />
}<br />
<br />
// Constraints: X =/= Y (thanks to the injectivity of the child pattern)<br />
shareable pattern parentPattern5(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternSha1(Y, Z);<br />
}<br />
<br />
// Constraints: none<br />
shareable pattern parentPattern6(X, Y, Z) = {<br />
find childPatternSha1(X, Y);<br />
find childPatternSha1(Y, Z);<br />
}<br />
</source><br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 14:07, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/GraphPattern&diff=154941VIATRA2/Examples/VTCL/GraphPattern2009-05-25T14:07:14Z<p>Daniel.varro.gmail.com: /* Pattern Matching Semantics */</p>
<hr />
<div>== Overview: Graph patterns ==<br />
<br />
=== Pattern Matching Semantics ===<br />
<br />
'''NOTE: The shareable keyword and thus noninjective matches will be available from VIATRA R4 (expected by the end of June, 2009).<br />
This description serves as a documentation of the new features.'''<br />
<br />
Patterns may be composed in VTCL a complex way by using the '''find''' construct. <br />
Moreover, the injectivity of pattern matching can be further controlled by using the new '''shareable''' keyword as follows: <br />
* '''Injective pattern matching (default)''': the default behavior of the pattern matcher is that two local pattern variables cannot be bound to the same value (i.e. element in the model space). Pattern variable assignments (in the form of '''A=B''') can enforce that the two variables take the same value during pattern matching.<br />
* '''Shareable (or non-injective) pattern matching''': the injectivity condition is not checked for local pattern variables (thus two variables may be bound to the same value) unless a non-injectvity constraint (in the form of '''A =/= B''') is prescribed explicitly for a pair of variables. <br />
<br />
The following examples highlight the semantic corner cases using of pattern composition and injective pattern matching. As a example, we use <br />
a simple state machine formalism (with states as entities and transitions as relations), which potentially contain loop transitions (where the source and target state of a transition is the same).<br />
<br />
<source lang="text"><br />
// A and B should be different, i.e. loop transitions are not matched<br />
pattern childPatternInj1(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
// A and B may be equal, loop transitions are matched<br />
shareable pattern childPatternSha1(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
// Equivalent match set with childPatternInj1: A =/= B<br />
pattern childPatternInj2(A, B) = {<br />
find childPatternSha1(A, B);<br />
}<br />
<br />
// Equivalent match set with childPatternInj1: A =/= B<br />
shareable pattern childPatternSha2(A, B) = {<br />
find childPatternSha1(A, B);<br />
A =/= B;<br />
}<br />
</source><br />
<br />
And now, let us present some more complex usage. As a general rule, the caller (parent) pattern <br />
may prescribe additional injectivity constraints for the local variables. <br />
<br />
<source lang="text"><br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern1(X, Y, Z) = {<br />
find childPatternInj1(X, Y); <br />
find childPatternInj1(Y, Z);<br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern2(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternSha1(Y, Z); <br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern3(X, Y, Z) = {<br />
find childPatternSha1(X, Y);<br />
find childPatternSha1(Y, Z); <br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z (thanks to the injectivity of the child pattern)<br />
shareable pattern parentPattern4(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternInj1(Y, Z);<br />
}<br />
<br />
// Constraints: X =/= Y (thanks to the injectivity of the child pattern)<br />
shareable pattern parentPattern5(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternSha1(Y, Z);<br />
}<br />
<br />
// Constraints: none<br />
shareable pattern parentPattern6(X, Y, Z) = {<br />
find childPatternSha1(X, Y);<br />
find childPatternSha1(Y, Z);<br />
}<br />
</source><br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 14:07, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/GraphPattern&diff=154938VIATRA2/Examples/VTCL/GraphPattern2009-05-25T14:06:22Z<p>Daniel.varro.gmail.com: /* Pattern Matching Semantics */</p>
<hr />
<div>== Overview: Graph patterns ==<br />
<br />
=== Pattern Matching Semantics ===<br />
<br />
'''NOTE: The shareable keyword and thus noninjective matches will be available from VIATRA R4 (expected by the end of June, 2009).<br />
This description serves as a documentation of the new features.'''<br />
<br />
Patterns may be composed in VTCL a complex way by using the '''find''' construct. <br />
Moreover, the injectivity of pattern matching can be further controlled by using the new '''shareable''' keyword as follows: <br />
* '''Injective pattern matching (default)''': the default behavior of the pattern matcher is that two local pattern variables cannot be bound to the same value (i.e. element in the model space). Pattern variable assignments (in the form of '''A=B''') can enforce that the two variables take the same value during pattern matching.<br />
* '''Shareable (or non-injective) pattern matching''': the injectivity condition is not checked for local pattern variables (thus two variables may be bound to the same value) unless a non-injectvity constraint (in the form of '''A =/= B''') is prescribed explicitly for a pair of variables. <br />
<br />
The following examples highlight the semantic corner cases using of pattern composition and injective pattern matching. As a example, we use <br />
a simple state machine formalism (with states as entities and transitions as relations), which potentially contain loop transitions (where the source and target state of a transition is the same).<br />
<br />
<source lang="text"><br />
// A and B should be different, i.e. loop transitions are not matched<br />
pattern childPatternInj1(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
// A and B may be equal, loop transitions are matched<br />
shareable pattern childPatternSha1(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
// Equivalent match set with childPatternInj1: A =/= B<br />
pattern childPatternInj2(A, B) = {<br />
find childPatternSha1(A, B);<br />
}<br />
<br />
// Equivalent match set with childPatternInj1: A =/= B<br />
shareable pattern childPatternSha2(A, B) = {<br />
find childPatternSha1(A, B);<br />
A =/= B;<br />
}<br />
</source><br />
<br />
And now, let us present some more complex usage. As a general rule, the caller (parent) pattern <br />
may prescribe additional injectivity constraints for the local variables. <br />
<br />
<source lang="text"><br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern1(X, Y, Z) = {<br />
find childPatternInj1(X, Y); <br />
find childPatternInj1(Y, Z);<br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern2(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternSha1(Y, Z); <br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern3(X, Y, Z) = {<br />
find childPatternSha1(X, Y);<br />
find childPatternSha1(Y, Z); <br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z (thanks to the injectivity of the child pattern)<br />
shareable pattern parentPattern4(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternInj1(Y, Z);<br />
}<br />
<br />
// Constraints: X =/= Y (thanks to the injectivity of the child pattern)<br />
shareable pattern parentPattern5(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternSha1(Y, Z);<br />
}<br />
<br />
// Constraints: none<br />
shareable pattern parentPattern6(X, Y, Z) = {<br />
find childPatternSha1(X, Y);<br />
find childPatternSha1(Y, Z);<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/GraphPattern&diff=154934VIATRA2/Examples/VTCL/GraphPattern2009-05-25T14:03:03Z<p>Daniel.varro.gmail.com: /* Pattern Matching Semantics */</p>
<hr />
<div>== Overview: Graph patterns ==<br />
<br />
=== Pattern Matching Semantics ===<br />
<br />
'''NOTE: The shareable keyword and thus noninjective matches will be available from VIATRA R4 (expected by the end of June, 2009).<br />
This description serves as a documentation of the new features.'''<br />
<br />
Patterns may be composed in VTCL a complex way by using the '''find''' construct. <br />
Moreover, the injectivity of pattern matching can be further controlled by using the new '''shareable''' keyword as follows: <br />
* '''Injective pattern matching (default)''': the default behavior of the pattern matcher is that two local pattern variables cannot be bound to the same value (i.e. element in the model space). Pattern variable assignments (in the form of '''A=B''') can enforce that the two variables take the same value during pattern matching.<br />
* '''Shareable (or non-injective) pattern matching''': the injectivity condition is not checked for local pattern variables (thus two variables may be bound to the same value) unless a non-injectvity constraint (in the form of '''A =/= B''') is prescribed explicitly for a pair of variables. <br />
<br />
The following examples highlight the semantic corner cases using of pattern composition and injective pattern matching. As a example, we use <br />
a simple state machine formalism (with states as entities and transitions as relations), which potentially contain loop transitions (where the source and target state of a transition is the same).<br />
<br />
<source lang="text"><br />
// A and B should be different, i.e. loop transitions are not matched<br />
pattern childPatternInj1(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
// A and B may be equal, loop transitions are matched<br />
shareable pattern childPatternSha1(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
// Equivalent match set with childPatternInj1: A =/= B<br />
pattern childPatternInj2(A, B) = {<br />
find childPatternSha1(A, B);<br />
}<br />
<br />
// Equivalent match set with childPatternInj1: A =/= B<br />
shareable pattern childPatternSha2(A, B) = {<br />
find childPatternSha1(A, B);<br />
A =/= B;<br />
}<br />
</source><br />
<br />
And now, for some more complex usage: <br />
<br />
<source lang="text"><br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern1(X, Y, Z) = {<br />
find childPatternInj1(X, Y); <br />
find childPatternInj1(Y, Z);<br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern2(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternSha1(Y, Z); <br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z, X =/= Z (thanks to the injectivity of the parent pattern)<br />
pattern parentPattern3(X, Y, Z) = {<br />
find childPatternSha1(X, Y);<br />
find childPatternSha1(Y, Z); <br />
}<br />
<br />
// Constraints: X =/= Y, Y =/Z (thanks to the injectivity of the child pattern)<br />
shareable pattern parentPattern4(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternInj1(Y, Z);<br />
}<br />
<br />
// Constraints: X =/= Y (thanks to the injectivity of the child pattern)<br />
shareable pattern parentPattern5(X, Y, Z) = {<br />
find childPatternInj1(X, Y);<br />
find childPatternSha1(Y, Z);<br />
}<br />
<br />
// Constraints: none<br />
shareable pattern parentPattern6(X, Y, Z) = {<br />
find childPatternSha1(X, Y);<br />
find childPatternSha1(Y, Z);<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/GraphPattern&diff=154927VIATRA2/Examples/VTCL/GraphPattern2009-05-25T13:51:55Z<p>Daniel.varro.gmail.com: /* Pattern Matching Semantics */</p>
<hr />
<div>== Overview: Graph patterns ==<br />
<br />
=== Pattern Matching Semantics ===<br />
<br />
'''NOTE: The shareable keyword and thus noninjective matches will be available from VIATRA R4 (expected by the end of June, 2009).<br />
This description serves as a documentation of the new features.'''<br />
<br />
Patterns may be composed in VTCL a complex way by using the '''find''' construct. <br />
Moreover, the injectivity of pattern matching can be further controlled by using the new '''shareable''' keyword as follows: <br />
* '''Injective pattern matching (default)''': the default behavior of the pattern matcher is that two local pattern variables cannot be bound to the same value (i.e. element in the model space). Pattern variable assignments (in the form of '''A=B''') can enforce that the two variables take the same value during pattern matching.<br />
* '''Shareable (or non-injective) pattern matching''': the injectivity condition is not checked for local pattern variables (thus two variables may be bound to the same value) unless a non-injectvity constraint (in the form of '''A =/= B''') is prescribed explicitly for a pair of variables. <br />
<br />
The following examples highlight the semantic corner cases using of pattern composition and injective pattern matching. As a example, we use <br />
a simple state machine formalism (with states as entities and transitions as relations), which potentially contain loop transitions (where the source and target state of a transition is the same).<br />
<br />
<source lang="text"><br />
// A and B should be different, i.e. loop transitions are not matched<br />
pattern childPatternInj1(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
// A and B may be equal, loop transitions are matched<br />
shareable pattern childPatternSha1(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
// Equivalent match set with childPatternInj1: A =/= B<br />
pattern childPatternInj2(A, B) = {<br />
find childPatternSha1(A, B);<br />
}<br />
<br />
// Equivalent match set with childPatternInj1: A =/= B<br />
shareable pattern childPatternSha2(A, B) = {<br />
find childPatternSha1(A, B);<br />
A =/= B;<br />
}<br />
</source><br />
<br />
And now, for some more complex usage: <br />
<br />
<source lang="text"><br />
pattern parentPatternInj(X, Y, Z) = {<br />
find childPattern<br />
<br />
}<br />
<br />
shareable pattern parentPatternSha(X, Y, Z) = {<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/GraphPattern&diff=154924VIATRA2/Examples/VTCL/GraphPattern2009-05-25T13:45:30Z<p>Daniel.varro.gmail.com: /* Pattern Matching Semantics */</p>
<hr />
<div>== Overview: Graph patterns ==<br />
<br />
=== Pattern Matching Semantics ===<br />
<br />
'''NOTE: The shareable keyword and thus noninjective matches will be available from VIATRA R4 (expected by the end of June, 2009).<br />
This description serves as a documentation of the new features.'''<br />
<br />
Patterns may be composed in VTCL a complex way by using the '''find''' construct. <br />
Moreover, the injectivity of pattern matching can be further controlled by using the new '''shareable''' keyword as follows: <br />
* '''Injective pattern matching (default)''': the default behavior of the pattern matcher is that two local pattern variables cannot be bound to the same value (i.e. element in the model space). Pattern variable assignments (in the form of '''A=B''') can enforce that the two variables take the same value during pattern matching.<br />
* '''Shareable (or non-injective) pattern matching''': the injectivity condition is not checked for local pattern variables (thus two variables may be bound to the same value) unless a non-injectvity constraint (in the form of '''A =/= B''') is prescribed explicitly for a pair of variables. <br />
<br />
The following examples highlight the semantic corner cases using of pattern composition and injective pattern matching.<br />
<br />
<source lang="text"><br />
pattern parentPattern1(X, Y, Z) = {<br />
<br />
}<br />
<br />
shareable pattern parentPattern2(X, Y, Z) = {<br />
}<br />
<br />
pattern childPattern1(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
shareable pattern childPattern2(A, B) = {<br />
state(A);<br />
state.transition(T, A, B);<br />
state(B);<br />
}<br />
<br />
// Equivalent with childPattern1: A != B<br />
pattern childPattern1A(A, B) = {<br />
find childPattern2(A, B);<br />
}<br />
<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/GraphPattern&diff=154919VIATRA2/Examples/VTCL/GraphPattern2009-05-25T13:27:50Z<p>Daniel.varro.gmail.com: /* Pattern Matching Semantics */</p>
<hr />
<div>== Overview: Graph patterns ==<br />
<br />
=== Pattern Matching Semantics ===<br />
<br />
<source lang="text"><br />
pattern parentPattern1(X, Y, Z) = {<br />
}<br />
<br />
sharedvar pattern parentPattern2(X, Y, Z) = {<br />
}<br />
<br />
pattern childPattern1(A, B) = {<br />
}<br />
<br />
sharedvar pattern childPattern2(A, B) = {<br />
<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/GraphPattern&diff=154918VIATRA2/Examples/VTCL/GraphPattern2009-05-25T13:24:51Z<p>Daniel.varro.gmail.com: New page: == Overview: Graph patterns == === Pattern Matching Semantics ===</p>
<hr />
<div>== Overview: Graph patterns ==<br />
<br />
=== Pattern Matching Semantics ===</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL&diff=154917VIATRA2/Examples/VTCL2009-05-25T13:23:31Z<p>Daniel.varro.gmail.com: /* Overview */</p>
<hr />
<div>== Overview ==<br />
The VTCL transformation language of VIATRA2 has the following main parts:<br />
<br />
* [[VIATRA2/Examples/VTCL/Terms | Expressions and Terms]]<br />
* [[VIATRA2/Examples/VTCL/ASM | Abstract State Machines (ASMs)]]<br />
* [[VIATRA2/Examples/VTCL/ModelManipulation | Model manipulation]]<br />
* [[VIATRA2/Examples/VTCL/GraphPattern | Graph Patterns]]<br />
* Graph transformation rules<br />
<br />
Type checking will be available from the next release (expected by the end of June, 2009).<br />
* [[VIATRA2/Examples/VTCL/TypeChecking | Type checking rules]]<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 13:23, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL&diff=154915VIATRA2/Examples/VTCL2009-05-25T13:23:17Z<p>Daniel.varro.gmail.com: /* Overview */</p>
<hr />
<div>== Overview ==<br />
The VTCL transformation language of VIATRA2 has the following main parts:<br />
<br />
* [[VIATRA2/Examples/VTCL/Terms | Expressions and Terms]]<br />
* [[VIATRA2/Examples/VTCL/ASM | Abstract State Machines (ASMs)]]<br />
* [[VIATRA2/Examples/VTCL/ModelManipulation | Model manipulation]]<br />
* [[VIATRA2/Examples/VTCL/GraphPattern | Graph Patterns]]<br />
* Graph transformation rules<br />
<br />
Type checking will be available from the next release (expected by the end of June, 2009).<br />
* [[VIATRA2/Examples/VTCL/TypeChecking | Type checking rules]]</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154877VIATRA2/Examples/VTCL/TypeChecking2009-05-25T11:02:26Z<p>Daniel.varro.gmail.com: /* Overview: Type checking */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
=== Typed variables in graph patterns ===<br />
<br />
=== Error messages ===<br />
<br />
The following error messages are issued by the type checker<br />
* '''Operator '-' is undefined for the argument type ('datatypes.String')''': issued when checking an ASM term<br />
* '''Operator '*' is undefined for the argument types ('datatypes.String', 'datatypes.String')''': issued when checking an ASM term<br />
* '''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<br />
* '''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<br />
* '''Type incompatible assignment: left value is of type 'datatypes.String', right value is of type 'datatypes.Integer' ''': issued in case of an '''update''' rule <br />
* '''Type incompatible initialization: expecting a term of type 'datatypes.String' instead of 'datatypes.Integer' ''': issued when initializing an ASM function<br />
<br />
--[[User:Varro.mit.bme.hu|Varro.mit.bme.hu]] 11:02, 25 May 2009 (UTC)</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154875VIATRA2/Examples/VTCL/TypeChecking2009-05-25T10:41:45Z<p>Daniel.varro.gmail.com: /* Overview: Type checking */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
=== Typed variables in ASM functions ===<br />
<br />
=== Typed variables in graph patterns ===</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154874VIATRA2/Examples/VTCL/TypeChecking2009-05-25T10:41:17Z<p>Daniel.varro.gmail.com: /* Overview: Type checking */</p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions<br />
<br />
Then the VIATRA2 parser checks if these variables are used in a type conformant way. <br />
<br />
=== Typed variables within ASM rules ===<br />
<br />
=== Typed variables in graph patterns ===</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154873VIATRA2/Examples/VTCL/TypeChecking2009-05-25T10:38:54Z<p>Daniel.varro.gmail.com: </p>
<hr />
<div>== Overview: Type checking ==<br />
Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/TypeChecking&diff=154872VIATRA2/Examples/VTCL/TypeChecking2009-05-25T10:35:56Z<p>Daniel.varro.gmail.com: New page: 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...</p>
<hr />
<div>Type checking is introduced to the VTCL language in a backward compatible way. This means that any existing VTCL transformation should compile without modification. <br />
<br />
As the main extension of the language, one can add type information to <br />
* all variables defined locally with the '''let''' rule<br />
* a parameter of an ASM rule, graph pattern or graph transformation rule<br />
* for the parameters and return values of ASM functions</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL&diff=154871VIATRA2/Examples/VTCL2009-05-25T10:30:29Z<p>Daniel.varro.gmail.com: /* Overview */</p>
<hr />
<div>== Overview ==<br />
The VTCL transformation language of VIATRA2 has the following main parts:<br />
<br />
* [[VIATRA2/Examples/VTCL/Terms | Expressions and Terms]]<br />
* [[VIATRA2/Examples/VTCL/ASM | Abstract State Machines (ASMs)]]<br />
* [[VIATRA2/Examples/VTCL/ModelManipulation | Model manipulation]]<br />
* Graph patterns<br />
* Graph transformation rules<br />
<br />
Type checking will be available from the next release (expected by the end of June, 2009).<br />
* [[VIATRA2/Examples/VTCL/TypeChecking | Type checking rules]]</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2&diff=141877VIATRA22009-02-27T16:17:01Z<p>Daniel.varro.gmail.com: /* Documentation */</p>
<hr />
<div>== Quick links ==<br />
<br />
* [http://www.eclipse.org/gmt/VIATRA2/ Project page]<br />
* [http://www.eclipse.org/gmt/VIATRA2/download/ Downloads]<br />
* [http://www.eclipse.org/newsportal/thread.php?group=eclipse.viatra2 Newsgroup]<br />
* [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=GMT&content=viatra BugTracker]<br />
* [[VIATRA2/Project Plan]]<br />
* [[VIATRA2/Frequently Asked Questions]]<br />
* [[VIATRA2/Installation]]<br />
* [[VIATRA2/Basics]]<br />
* [[VIATRA2/HowTos]]<br />
* [[VIATRA2/Examples]]<br />
* [[VIATRA2/Components]]<br />
* [[VIATRA2/Benchmarks]]<br />
<br />
== Project Overview ==<br />
The main objective of the VIATRA2 (VIsual Automated model TRAnsformations) framework is to provide a general-purpose support for the entire life-cycle of engineering model transformations including the specification, design, execution, validation and maintenance of transformations within and between various modeling languages and domains. <br />
<br />
VIATRA2 intends to complement existing model transformation frameworks in providing<br />
* a [[VIATRA2/Components#Model_space | model space]] for uniform representation of models and metamodels<br />
* a [[VIATRA2/Components#Transformation_Language | transformation language]] with <br />
** both declarative and imperative features <br />
** based upon popular formal mathematical techniques of ''graph transformation (GT)'' and ''abstract state machines (ASM)''<br />
* a high performance transformation engine <br />
** supporting '''incremental model transformations'''<br />
** trigger-driven [[VIATRA2/Live Transformations | live transformations]] where complex model changes may trigger execution of transformations<br />
** handling well over 100,000 model elements (see our [[VIATRA2/Benchmarks | benchmarks]])<br />
* with main target application domains in<br />
** model-based tool integration framework <br />
** model analysis transformations<br />
<br />
== Target Application Domains ==<br />
VIATRA2 primarily aims at designing model transformations to support the precise model-based systems development with the help of invisible formal methods. Invisible formal methods are hidden by automated model transformations projecting system models into various mathematical domains (and, preferably, vice versa). In this way, VIATRA2 nicely complements other model transformation tools within the GMT initiative.<br />
<br />
The most traditional application area for VIATRA2 – started as early as 1998 – is to support the transformation-based dependability analysis of system models taken from various application areas (safety-critical and/or embedded systems, robust e-business applications, middleware, serviceoriented architecture) described using various modeling languages (BPM, UML, etc.) during a model-driven systems engineering process. Such a model (and transformation)-based dependability analysis typically also includes the verification & validation, the testing, the safety and security analysis as well as the early assessment non-functional characteristics (such as reliability, availability, responsiveness, throughput, etc.) of the system under design. In addition, model transformations for specification, design, deployment, optimization or code generation in traditional model-driven systems engineering are also focal areas for VIATRA2.<br />
<br />
== Standard conformance ==<br />
We need to point out that the underlying modeling and transformation concepts of VIATRA2 are nonstandard.<br />
* the model management framework ([[VIATRA2 Model Space]]) is more expressive than MOF / EMF, <br />
* the [[VIATRA2 Transformation Language]] is not QVT, but combines formal techniques being in use for more than 15 years. <br />
<br />
VIATRA2 plans to support related standards by offering <br />
* powerful and extensible model importers and exporters <br />
* exporters/importers of other transformation languages (e.g. QVT)<br />
* domain specific languages integrated to the framework as VIATRA2 (and thus Eclipse) plug-ins.<br />
<br />
== Known uses ==<br />
The VIATRA2 framework currently served as a key underlying model transformation technology in various research projects including:<br />
* the [http://www.decos.at/ DECOS EU FP6 IP] in the field of dependable embedded systems<br />
* the [http://www.sensoria-ist.eu/ SENSORIA EU FP6 IP] in the field of service-oriented computing<br />
* the [http://diana.skysoft.pt/ DIANA EU FP6 STREP] in the avionics domain<br />
* the [http://hidenets.aau.dk/ HIDENETS EU FP6 IP] in the field of vehicular networking.<br />
* the [https://www.mogentes.eu/ MOGENTES EU FP7 ICT STREP] <br />
<br />
We ''regularly'' received valuable feedback from the following institutes <br />
* Budapest University of Technology and Economics, HUN<br />
* OptXware Research and Development LLC, HUN<br />
* ARCS, Vienna, AUT<br />
* LMU Munich, GER<br />
* TU Kaiserslautern, GER<br />
* Univ. of Pisa, ITA<br />
* Georgia Institute of Technology, USA<br />
<br />
== Technical Information ==<br />
=== Obtaining VIATRA2 ===<br />
==== VIATRA2 Downloads ====<br />
<br />
Check [http://www.eclipse.org/gmt/VIATRA2/download/ here] for more information.<br />
<br />
==== Installation ====<br />
See [[VIATRA2/Installation]].<br />
<br />
=== Documentation ===<br />
<br />
For basic examples of VTCL code, you should first check [[VIATRA2/Examples/VTCL]] <br />
<br />
For more up-to-date tutorials, howtos and descriptions you can browse [[VIATRA2/Basics]] and [[VIATRA2/Examples]].<br />
<br />
The [http://www.eclipse.org/gmt/VIATRA2/doc/ official page] has details on the available documentation. In short, the following off-line documentation is available (which are not completely up-to-date, unfortunately):<br />
<br />
* User's guide: [http://www.eclipse.org/gmt/VIATRA2/doc/viatratut.pdf PDF]<br />
* Transformation language specification: [http://www.eclipse.org/gmt/VIATRA2/doc/ViatraSpecification.pdf PDF]<br />
<br />
[[Category:Modeling]]<br />
[[Category:MDD]]<br />
[[Category:GMT]]</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Transformation_Language&diff=141876VIATRA2/Transformation Language2009-02-27T16:12:53Z<p>Daniel.varro.gmail.com: /* Overview */</p>
<hr />
<div>== Overview ==<br />
Since precise model-based systems development is the primary application area of VIATRA2, it necessitates that (i) the model transformations are specified in a mathematically precise way, and (ii) these transformations are automated so that the target mathematical models can be derived fully automatically. For this purpose, VIATRA2 have chosen to integrate two popular, intuitive, yet mathematically precise rule-based specification formalisms, namely, graph transformation (GT) and abstract state machines (ASM) to manipulated graph based models.<br />
<br />
* '''(Graph) Patterns''' are the basic concept in defining model transformations within VIATRA2. A pattern is a collection of model elements arranged into a certain structure fulfilling additional constraints (as defined by attribute conditions or other patterns). Patterns can be matched on certain model instances<br />
* Elementary model manipulation is specified by '''graph transformation rules'''. Like OCL, graph transformation rules describe pre- and postconditions to the transformations, but graph transformation rules are guaranteed to be executable, which is a main conceptual difference. Upon successful matching of the ''precondition pattern'', the graph transformation rules changes the underlying model elements according to the ''postcondition pattern''. <br />
* Graph transformation rules are assembled into complex model transformations by '''abstract state machine rules''', which provide a set of commonly used imperative control structures with precise semantics.<br />
<br />
Advanced features of the VIATRA2 transformation language (called VTCL) are <br />
* '''Pattern composition''' (for pre and postcondition patterns) <br />
* '''Recursive (graph) patterns'''<br />
* '''Negative patterns''' with arbitrary depth of negation<br />
<br />
'''Main language features of VTCL are demonstrated [[VIATRA2/Examples/VTCL | here ]].'''</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Transformation_Language&diff=141875VIATRA2/Transformation Language2009-02-27T16:12:14Z<p>Daniel.varro.gmail.com: /* Overview */</p>
<hr />
<div>== Overview ==<br />
Since precise model-based systems development is the primary application area of VIATRA2, it necessitates that (i) the model transformations are specified in a mathematically precise way, and (ii) these transformations are automated so that the target mathematical models can be derived fully automatically. For this purpose, VIATRA2 have chosen to integrate two popular, intuitive, yet mathematically precise rule-based specification formalisms, namely, graph transformation (GT) and abstract state machines (ASM) to manipulated graph based models.<br />
<br />
* '''(Graph) Patterns''' are the basic concept in defining model transformations within VIATRA2. A pattern is a collection of model elements arranged into a certain structure fulfilling additional constraints (as defined by attribute conditions or other patterns). Patterns can be matched on certain model instances<br />
* Elementary model manipulation is specified by '''graph transformation rules'''. Like OCL, graph transformation rules describe pre- and postconditions to the transformations, but graph transformation rules are guaranteed to be executable, which is a main conceptual difference. Upon successful matching of the ''precondition pattern'', the graph transformation rules changes the underlying model elements according to the ''postcondition pattern''. <br />
* Graph transformation rules are assembled into complex model transformations by '''abstract state machine rules''', which provide a set of commonly used imperative control structures with precise semantics.<br />
<br />
Advanced features of the VIATRA2 transformation language (called VTCL) are <br />
* '''Pattern composition''' (for pre and postcondition patterns) <br />
* '''Recursive (graph) patterns'''<br />
* '''Negative patterns''' with arbitrary depth of negation<br />
<br />
Main language features of VTCL are demonstrated [[VIATRA2/Examples/VTCL | here ]].</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141076VIATRA2/Examples/VTCL/ASM2009-02-20T18:12:30Z<p>Daniel.varro.gmail.com: /* Composite rules */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== User defined ASM rules ===<br />
<br />
Users can define ASM rules as means for encapsulating certain functionality as a reusable operation.<br />
A user-defined ASM rule has an arbitrary number of parameters with the following directions: <br />
* '''in''': input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.<br />
* '''out''': output parameter, which means that (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule<br />
* '''inout''': input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.<br />
<br />
An optional '''type''' can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).<br />
<br />
<source lang="text"><br />
import datatypes;<br />
machine callrules_01{<br />
rule test(in X:String , out Y, inout Z) = seq { <br />
update Y = X+Z;<br />
print(X + Y + Z); // prints "aacc"<br />
} <br />
rule main() = seq{<br />
call test("a", "b", "c"); <br />
}<br />
}<br />
</source><br />
<br />
The further use of user-defined ASM rules are illustrated in the following example:<br />
<br />
<source lang="text"><br />
machine symParams<br />
{<br />
rule main() = seq<br />
{<br />
let A=1, B=2, C=undef in seq {<br />
call myRule(A,B,C);<br />
println(A + "," + B + "," +C); // 1,1,2<br />
call myRule(3,B,C);<br />
println(3 + "," + B + "," +C); // 3,3,6<br />
call myRule(A,B,A); <br />
println(A + "," + B + "," +A); // 2,1,2<br />
}<br />
}<br />
<br />
rule myRule(in A, inout B, out C) = seq<br />
{<br />
update B = A;<br />
update C = A + B;<br />
}<br />
}<br />
</source><br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main(in X) = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===<br />
<br />
Composite rules allow to assemble more complex transformation algorithms. Composite control structures in VTCL are as follows:<br />
* '''if (C) R1 else R2''': If condition C holds then executes R1, else executes R2; fails if the selected execution branch fails; (''else'' part is optional)<br />
* '''try R1 else R2''': Executes R1, and if its execution fails, then it executes R2 (where the ''else'' part is optional); try/else rule fails if R2 fails, try rule (without else) fails when R1 fails<br />
* '''seq {R1; R2;}''': Executes R1 and R2 in this specific order. Sequential rule fails if either R1 or R2 fails.<br />
* '''random {R1; R2; }''': Non-deterministically selects R1 or R2, and executes it. Random rule fails if the selected rule (R1 or R2) fails.<br />
* '''let X = t1, Y= t2 in R1''': Defines new variables X and Y, and initializes them with values ''t1'' and ''t2'', respectively, then rule R1 is executed. The let rule fails if the execution of R1 fails.<br />
* '''choose X with C(X) do R''': Computes an assignment of variable X, which fulfills condition C (where X appears in a pattern call, a GT rule application or in an ASM function). If a valid binding exists, then executes rule R, otherwise the choose rule fails. The choose rule also fails if the execution of rule R fails.<br />
* '''forall X with C(X) do R''': Computes all assignments of variable X, which fulfills condition C (where X appears in a pattern call, a GT rule application or in an ASM function). Then it executes rule R for all valid assignments. The forall rule never fails (even if no valid assigns are found) .<br />
* '''iterate R''': executes rule R as long as possible, i.e. it subsequently calls rule R until the final execution of R fails. Note that this rule can cause non-termination.<br />
<br />
Example for using '''if''' rule<br />
<source lang="text"><br />
machine ifrules_01{<br />
rule main (in X)= seq {<br />
print(X);<br />
if (X == 10) print("OK:if"); <br />
else print("ERR:else");<br />
if (X != 10) print("ERR:if"); <br />
else print("OK:else");<br />
}<br />
}<br />
</source><br />
<br />
Example for using '''try''' rule <br />
<source lang="text"><br />
machine tryrules_01{<br />
rule testing(in X)= seq {<br />
if (X == 4) fail;<br />
print(X);<br />
}<br />
<br />
rule main ()= seq {<br />
try call testing(2); <br />
else print("ERR");<br />
try call testing(4); <br />
else print("OK");<br />
}<br />
}</source><br />
<br />
Example for '''choose''' rule with ASM functions as conditions (more examples will be given for GT patterns)<br />
<source lang="text"><br />
import datatypes;<br />
machine chooserules_01{<br />
// Untyped version <br />
asmfunction testFunc/1 {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule main() = seq{<br />
choose Y with (testFunc(Y) > 1) do seq{<br />
if (Y == "b" || Y == "c") print("OK");<br />
else print("ERR");<br />
}<br />
call myRule1(); <br />
}<br />
<br />
// Typed version<br />
asmfunction testFunc2(String): Integer {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule myRule1() = seq{<br />
choose Y: String with (testFunc(Y) > 1) do seq{<br />
if (Y == "b" || Y == "c") print("OK");<br />
else print("ERR");<br />
} <br />
}<br />
}<br />
</source><br />
<br />
Example for '''forall''' rule with ASM functions as conditions (more examples will be given for GT patterns)<br />
<source lang="text"><br />
machine forallrules_01{<br />
asmfunction testFunc/1 {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule main() = let C1 = false, C2 = false in seq{<br />
forall Y with (testFunc(Y) > 1) do seq{<br />
if (Y == "b") update C1 = true; <br />
if (Y == "c") update C2 = true;<br />
} <br />
if (C1 == true && C2 == true) print("OK");<br />
else print("ERR");<br />
call forallRule1(); <br />
}<br />
<br />
asmfunction testFunc2 (datatypes.String) : datatypes.Integer {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule forallRule1 () = let C1 = false, C2 = false in seq{<br />
forall Y with (testFunc2(Y) > 1) do seq{<br />
if (Y == "b") update C1 = true; <br />
if (Y == "c") update C2 = true;<br />
} <br />
if (C1 == true && C2 == true) print("OK");<br />
else print("ERR"); <br />
}<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141075VIATRA2/Examples/VTCL/ASM2009-02-20T17:51:52Z<p>Daniel.varro.gmail.com: /* Composite rules */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== User defined ASM rules ===<br />
<br />
Users can define ASM rules as means for encapsulating certain functionality as a reusable operation.<br />
A user-defined ASM rule has an arbitrary number of parameters with the following directions: <br />
* '''in''': input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.<br />
* '''out''': output parameter, which means that (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule<br />
* '''inout''': input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.<br />
<br />
An optional '''type''' can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).<br />
<br />
<source lang="text"><br />
import datatypes;<br />
machine callrules_01{<br />
rule test(in X:String , out Y, inout Z) = seq { <br />
update Y = X+Z;<br />
print(X + Y + Z); // prints "aacc"<br />
} <br />
rule main() = seq{<br />
call test("a", "b", "c"); <br />
}<br />
}<br />
</source><br />
<br />
The further use of user-defined ASM rules are illustrated in the following example:<br />
<br />
<source lang="text"><br />
machine symParams<br />
{<br />
rule main() = seq<br />
{<br />
let A=1, B=2, C=undef in seq {<br />
call myRule(A,B,C);<br />
println(A + "," + B + "," +C); // 1,1,2<br />
call myRule(3,B,C);<br />
println(3 + "," + B + "," +C); // 3,3,6<br />
call myRule(A,B,A); <br />
println(A + "," + B + "," +A); // 2,1,2<br />
}<br />
}<br />
<br />
rule myRule(in A, inout B, out C) = seq<br />
{<br />
update B = A;<br />
update C = A + B;<br />
}<br />
}<br />
</source><br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main(in X) = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===<br />
<br />
Composite rules allow to assemble more complex transformation algorithms. Composite control structures in VTCL are as follows:<br />
* '''if (C) R1 else R2''': If condition C holds then executes R1, else executes R2; fails if the selected execution branch fails; (''else'' part is optional)<br />
* '''try R1 else R2''': Executes R1, and if its execution fails, then it executes R2 (where the ''else'' part is optional); try/else rule fails if R2 fails, try rule (without else) fails when R1 fails<br />
* '''seq {R1; R2;}''': Executes R1 and R2 in this specific order. Sequential rule fails if either R1 or R2 fails.<br />
* '''random {R1; R2; }''': Non-deterministically selects R1 or R2, and executes it. Random rule fails if the selected rule (R1 or R2) fails.<br />
* '''let X = t1, Y= t2 in R1''': Defines new variables X and Y, and initializes them with values ''t1'' and ''t2'', respectively, then rule R1 is executed. The let rule fails if the execution of R1 fails.<br />
* '''choose X with C(X) do R''': Computes an assignment of variable X, which fulfills condition C (where X appears in a pattern call, a GT rule application or in an ASM function). If a valid binding exists, then executes rule R, otherwise the choose rule fails. The choose rule also fails if the execution of rule R fails.<br />
* '''forall X with C(X) do R''': Computes all assignments of variable X, which fulfills condition C (where X appears in a pattern call, a GT rule application or in an ASM function). Then it executes rule R for all valid assignments. The forall rule never fails (even if no valid assigns are found) .<br />
* '''iterate R''': executes rule R as long as possible, i.e. it subsequently calls rule R until the final execution of R fails. Note that this rule can cause non-termination.<br />
<br />
Example for using '''if''' rule<br />
<source lang="text"><br />
machine ifrules_01{<br />
rule main (in X)= seq {<br />
print(X);<br />
if (X == 10) print("OK:if"); else print("ERR:else");<br />
if (X != 10) print("ERR:if"); else print("OK:else");<br />
}<br />
}<br />
</source><br />
<br />
Example for using '''try''' rule <br />
<source lang="text"><br />
machine tryrules_01{<br />
rule testing(in X)= seq {<br />
if (X == 4) fail;<br />
print(X);<br />
}<br />
<br />
rule main ()= seq {<br />
try call testing(2); else print("ERR");<br />
try call testing(4); else print("OK");<br />
}<br />
}</source><br />
<br />
Example for '''choose''' rule with ASM functions as conditions (more examples will be given for GT patterns)<br />
<source lang="text"><br />
import datatypes;<br />
machine chooserules_01{<br />
// Untyped version <br />
asmfunction testFunc/1 {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule main() = seq{<br />
choose Y with (testFunc(Y) > 1) do seq{<br />
if (Y == "b" || Y == "c") print("OK");<br />
else print("ERR");<br />
}<br />
call myRule1(); <br />
}<br />
<br />
// Typed version<br />
asmfunction testFunc2(String): Integer {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule myRule1() = seq{<br />
choose Y: String with (testFunc(Y) > 1) do seq{<br />
if (Y == "b" || Y == "c") print("OK");<br />
else print("ERR");<br />
} <br />
}<br />
}<br />
</source><br />
<br />
Example for '''forall''' rule with ASM functions as conditions (more examples will be given for GT patterns)<br />
<source lang="text"><br />
machine forallrules_01{<br />
asmfunction testFunc/1 {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule main() = let C1 = false, C2 = false in seq{<br />
forall Y with (testFunc(Y) > 1) do seq{<br />
if (Y == "b") update C1 = true; <br />
if (Y == "c") update C2 = true;<br />
} <br />
if (C1 == true && C2 == true) print("OK");<br />
else print("ERR");<br />
call forallRule1(); <br />
}<br />
<br />
asmfunction testFunc2 (datatypes.String) : datatypes.Integer {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule forallRule1 () = let C1 = false, C2 = false in seq{<br />
forall Y with (testFunc2(Y) > 1) do seq{<br />
if (Y == "b") update C1 = true; <br />
if (Y == "c") update C2 = true;<br />
} <br />
if (C1 == true && C2 == true) print("OK");<br />
else print("ERR"); <br />
}<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141074VIATRA2/Examples/VTCL/ASM2009-02-20T17:49:48Z<p>Daniel.varro.gmail.com: /* Composite rules */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== User defined ASM rules ===<br />
<br />
Users can define ASM rules as means for encapsulating certain functionality as a reusable operation.<br />
A user-defined ASM rule has an arbitrary number of parameters with the following directions: <br />
* '''in''': input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.<br />
* '''out''': output parameter, which means that (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule<br />
* '''inout''': input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.<br />
<br />
An optional '''type''' can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).<br />
<br />
<source lang="text"><br />
import datatypes;<br />
machine callrules_01{<br />
rule test(in X:String , out Y, inout Z) = seq { <br />
update Y = X+Z;<br />
print(X + Y + Z); // prints "aacc"<br />
} <br />
rule main() = seq{<br />
call test("a", "b", "c"); <br />
}<br />
}<br />
</source><br />
<br />
The further use of user-defined ASM rules are illustrated in the following example:<br />
<br />
<source lang="text"><br />
machine symParams<br />
{<br />
rule main() = seq<br />
{<br />
let A=1, B=2, C=undef in seq {<br />
call myRule(A,B,C);<br />
println(A + "," + B + "," +C); // 1,1,2<br />
call myRule(3,B,C);<br />
println(3 + "," + B + "," +C); // 3,3,6<br />
call myRule(A,B,A); <br />
println(A + "," + B + "," +A); // 2,1,2<br />
}<br />
}<br />
<br />
rule myRule(in A, inout B, out C) = seq<br />
{<br />
update B = A;<br />
update C = A + B;<br />
}<br />
}<br />
</source><br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main(in X) = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===<br />
<br />
Composite rules allow to assemble more complex transformation algorithms. Composite control structures in VTCL are as follows:<br />
* '''if (C) R1 else R2''': If condition C holds then executes R1, else executes R2; fails if the selected execution branch fails; (''else'' part is optional)<br />
* '''try R1 else R2''': Executes R1, and if its execution fails, then it executes R2 (where the ''else'' part is optional); try/else rule fails if R2 fails, try rule (without else) fails when R1 fails<br />
* '''seq {R1; R2;}''': Executes R1 and R2 in this specific order. Sequential rule fails if either R1 or R2 fails.<br />
* '''random {R1; R2; }''': Non-deterministically selects R1 or R2, and executes it. Random rule fails if the selected rule (R1 or R2) fails.<br />
* '''let X = t1, Y= t2 in R1''': Defines new variables X and Y, and initializes them with values ''t1'' and ''t2'', respectively, then rule R1 is executed. The let rule fails if the execution of R1 fails.<br />
* '''choose X with C(X) do R''': Computes an assignment of variable X, which fulfills condition C (where X appears in a pattern call, a GT rule application or in an ASM function). If a valid binding exists, then executes rule R, otherwise the choose rule fails. The choose rule also fails if the execution of rule R fails.<br />
* '''forall X with C(X) do R''': Computes all assignments of variable X, which fulfills condition C (where X appears in a pattern call, a GT rule application or in an ASM function). Then it executes rule R for all valid assignments. The forall rule never fails (even if no valid assigns are found) .<br />
* '''iterate R''': executes rule R as long as possible, i.e. it subsequently calls rule R until the final execution of R fails. Note that this rule can cause non-termination.<br />
<br />
Example for using '''if''' rule<br />
<source lang="text"><br />
machine ifrules_01{<br />
rule main (in X)= seq {<br />
print(X);<br />
if (X == 10) print("OK:if"); else print("ERR:else");<br />
if (X != 10) print("ERR:if"); else print("OK:else");<br />
}<br />
}<br />
</source><br />
<br />
Example for '''choose''' rule with ASM functions as conditions (more examples will be given for GT patterns)<br />
<source lang="text"><br />
import datatypes;<br />
machine chooserules_01{<br />
// Untyped version <br />
asmfunction testFunc/1 {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule main() = seq{<br />
choose Y with (testFunc(Y) > 1) do seq{<br />
if (Y == "b" || Y == "c") print("OK");<br />
else print("ERR");<br />
}<br />
call myRule1(); <br />
}<br />
<br />
// Typed version<br />
asmfunction testFunc2(String): Integer {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule myRule1() = seq{<br />
choose Y: String with (testFunc(Y) > 1) do seq{<br />
if (Y == "b" || Y == "c") print("OK");<br />
else print("ERR");<br />
} <br />
}<br />
}<br />
</source><br />
<br />
Example for '''forall''' rule with ASM functions as conditions (more examples will be given for GT patterns)<br />
<source lang="text"><br />
machine forallrules_01{<br />
asmfunction testFunc/1 {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule main() = let C1 = false, C2 = false in seq{<br />
forall Y with (testFunc(Y) > 1) do seq{<br />
if (Y == "b") update C1 = true; <br />
if (Y == "c") update C2 = true;<br />
} <br />
if (C1 == true && C2 == true) print("OK");<br />
else print("ERR");<br />
call forallRule1(); <br />
}<br />
<br />
asmfunction testFunc2 (datatypes.String) : datatypes.Integer {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule forallRule1 () = let C1 = false, C2 = false in seq{<br />
forall Y with (testFunc2(Y) > 1) do seq{<br />
if (Y == "b") update C1 = true; <br />
if (Y == "c") update C2 = true;<br />
} <br />
if (C1 == true && C2 == true) print("OK");<br />
else print("ERR"); <br />
}<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141073VIATRA2/Examples/VTCL/ASM2009-02-20T17:47:12Z<p>Daniel.varro.gmail.com: /* Composite rules */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== User defined ASM rules ===<br />
<br />
Users can define ASM rules as means for encapsulating certain functionality as a reusable operation.<br />
A user-defined ASM rule has an arbitrary number of parameters with the following directions: <br />
* '''in''': input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.<br />
* '''out''': output parameter, which means that (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule<br />
* '''inout''': input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.<br />
<br />
An optional '''type''' can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).<br />
<br />
<source lang="text"><br />
import datatypes;<br />
machine callrules_01{<br />
rule test(in X:String , out Y, inout Z) = seq { <br />
update Y = X+Z;<br />
print(X + Y + Z); // prints "aacc"<br />
} <br />
rule main() = seq{<br />
call test("a", "b", "c"); <br />
}<br />
}<br />
</source><br />
<br />
The further use of user-defined ASM rules are illustrated in the following example:<br />
<br />
<source lang="text"><br />
machine symParams<br />
{<br />
rule main() = seq<br />
{<br />
let A=1, B=2, C=undef in seq {<br />
call myRule(A,B,C);<br />
println(A + "," + B + "," +C); // 1,1,2<br />
call myRule(3,B,C);<br />
println(3 + "," + B + "," +C); // 3,3,6<br />
call myRule(A,B,A); <br />
println(A + "," + B + "," +A); // 2,1,2<br />
}<br />
}<br />
<br />
rule myRule(in A, inout B, out C) = seq<br />
{<br />
update B = A;<br />
update C = A + B;<br />
}<br />
}<br />
</source><br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main(in X) = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===<br />
<br />
Composite rules allow to assemble more complex transformation algorithms. Composite control structures in VTCL are as follows:<br />
* '''if (C) R1 else R2''': If condition C holds then executes R1, else executes R2; fails if the selected execution branch fails; (''else'' part is optional)<br />
* '''try R1 else R2''': Executes R1, and if its execution fails, then it executes R2 (where the ''else'' part is optional); try/else rule fails if R2 fails, try rule (without else) fails when R1 fails<br />
* '''seq {R1; R2;}''': Executes R1 and R2 in this specific order. Sequential rule fails if either R1 or R2 fails.<br />
* '''random {R1; R2; }''': Non-deterministically selects R1 or R2, and executes it. Random rule fails if the selected rule (R1 or R2) fails.<br />
* '''let X = t1, Y= t2 in R1''': Defines new variables X and Y, and initializes them with values ''t1'' and ''t2'', respectively, then rule R1 is executed. The let rule fails if the execution of R1 fails.<br />
* '''choose X with C(X) do R''': Computes an assignment of variable X, which fulfills condition C (where X appears in a pattern call, a GT rule application or in an ASM function). If a valid binding exists, then executes rule R, otherwise the choose rule fails. The choose rule also fails if the execution of rule R fails.<br />
* '''forall X with C(X) do R''': Computes all assignments of variable X, which fulfills condition C (where X appears in a pattern call, a GT rule application or in an ASM function). Then it executes rule R for all valid assignments. The forall rule never fails (even if no valid assigns are found) .<br />
* '''iterate R''': executes rule R as long as possible, i.e. it subsequently calls rule R until the final execution of R fails. Note that this rule can cause non-termination.<br />
<br />
Example for '''choose''' rule<br />
<source lang="text"><br />
import datatypes;<br />
machine chooserules_01{<br />
// Untyped version <br />
asmfunction testFunc/1 {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule main() = seq{<br />
choose Y with (testFunc(Y) > 1) do seq{<br />
if (Y == "b" || Y == "c") print("OK");<br />
else print("ERR");<br />
}<br />
call myRule1(); <br />
}<br />
<br />
// Typed version<br />
asmfunction testFunc2(String): Integer {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule myRule1() = seq{<br />
choose Y: String with (testFunc(Y) > 1) do seq{<br />
if (Y == "b" || Y == "c") print("OK");<br />
else print("ERR");<br />
} <br />
}<br />
}<br />
</source><br />
<br />
Example for '''forall''' rule<br />
<source lang="text"><br />
machine forallrules_01{<br />
asmfunction testFunc/1 {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule main() = let C1 = false, C2 = false in seq{<br />
forall Y with (testFunc(Y) > 1) do seq{<br />
if (Y == "b") update C1 = true; <br />
if (Y == "c") update C2 = true;<br />
} <br />
if (C1 == true && C2 == true) print("OK");<br />
else print("ERR");<br />
call forallRule1(); <br />
}<br />
<br />
asmfunction testFunc2 (datatypes.String) : datatypes.Integer {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule forallRule1 () = let C1 = false, C2 = false in seq{<br />
forall Y with (testFunc2(Y) > 1) do seq{<br />
if (Y == "b") update C1 = true; <br />
if (Y == "c") update C2 = true;<br />
} <br />
if (C1 == true && C2 == true) print("OK");<br />
else print("ERR"); <br />
}<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141063VIATRA2/Examples/VTCL/ASM2009-02-20T16:37:38Z<p>Daniel.varro.gmail.com: /* Composite rules */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== User defined ASM rules ===<br />
<br />
Users can define ASM rules as means for encapsulating certain functionality as a reusable operation.<br />
A user-defined ASM rule has an arbitrary number of parameters with the following directions: <br />
* '''in''': input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.<br />
* '''out''': output parameter, which means that (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule<br />
* '''inout''': input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.<br />
<br />
An optional '''type''' can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).<br />
<br />
<source lang="text"><br />
import datatypes;<br />
machine callrules_01{<br />
rule test(in X:String , out Y, inout Z) = seq { <br />
update Y = X+Z;<br />
print(X + Y + Z); // prints "aacc"<br />
} <br />
rule main() = seq{<br />
call test("a", "b", "c"); <br />
}<br />
}<br />
</source><br />
<br />
The further use of user-defined ASM rules are illustrated in the following example:<br />
<br />
<source lang="text"><br />
machine symParams<br />
{<br />
rule main() = seq<br />
{<br />
let A=1, B=2, C=undef in seq {<br />
call myRule(A,B,C);<br />
println(A + "," + B + "," +C); // 1,1,2<br />
call myRule(3,B,C);<br />
println(3 + "," + B + "," +C); // 3,3,6<br />
call myRule(A,B,A); <br />
println(A + "," + B + "," +A); // 2,1,2<br />
}<br />
}<br />
<br />
rule myRule(in A, inout B, out C) = seq<br />
{<br />
update B = A;<br />
update C = A + B;<br />
}<br />
}<br />
</source><br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main(in X) = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===<br />
<br />
Composite rules allow to assemble more complex transformation algorithms. Composite control structures in VTCL are as follows:<br />
* '''if (C) R1 else R2''': If condition C holds then executes R1, else executes R2; fails if the selected execution branch fails; (''else'' part is optional)<br />
* '''try R1 else R2''': Executes R1, and if its execution fails, then it executes R2 (where the ''else'' part is optional); try/else rule fails if R2 fails, try rule (without else) fails when R1 fails<br />
* '''seq {R1; R2;}''': Executes R1 and R2 in this specific order. Sequential rule fails if either R1 or R2 fails.<br />
* '''random {R1; R2; }''': Non-deterministically selects R1 or R2, and executes it. Random rule fails if the selected rule (R1 or R2) fails.<br />
* '''let X = t1, Y= t2 in R1''': Defines new variables X and Y, and initializes them with values ''t1'' and ''t2'', respectively, then rule R1 is executed. The let rule fails if the execution of R1 fails.<br />
* '''choose X with C(X) do R''': Computes an assignment of variable X, which fulfills condition C (where X appears in a pattern call, a GT rule application or in an ASM function). If a valid binding exists, then executes rule R, otherwise the choose rule fails. The choose rule also fails if the execution of rule R fails.<br />
* '''forall X with C(X) do R''': Computes all assignments of variable X, which fulfills condition C (where X appears in a pattern call, a GT rule application or in an ASM function). Then it executes rule R for all valid assignments. The forall rule never fails (even if no valid assigns are found) .<br />
* '''iterate R''': executes rule R as long as possible, i.e. it subsequently calls rule R until the final execution of R fails. Note that this rule can cause non-termination.<br />
<br />
<source lang="text"><br />
import datatypes;<br />
machine chooserules_01{<br />
<br />
// Untyped version <br />
asmfunction testFunc/1 {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule main() = seq{<br />
choose Y with (testFunc(Y) > 1) do seq{<br />
if (Y == "b" || Y == "c") print("OK");<br />
else print("ERR");<br />
}<br />
call myRule1(); <br />
}<br />
<br />
// Typed version<br />
asmfunction testFunc2(String): Integer {("a") = 1; ("b") = 2; ("c") = 3;}<br />
rule myRule1() = seq{<br />
choose Y: String with (testFunc(Y) > 1) do seq{<br />
if (Y == "b" || Y == "c") print("OK");<br />
else print("ERR");<br />
} <br />
}<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141061VIATRA2/Examples/VTCL/ASM2009-02-20T16:18:43Z<p>Daniel.varro.gmail.com: /* Composite rules */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== User defined ASM rules ===<br />
<br />
Users can define ASM rules as means for encapsulating certain functionality as a reusable operation.<br />
A user-defined ASM rule has an arbitrary number of parameters with the following directions: <br />
* '''in''': input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.<br />
* '''out''': output parameter, which means that (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule<br />
* '''inout''': input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.<br />
<br />
An optional '''type''' can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).<br />
<br />
<source lang="text"><br />
import datatypes;<br />
machine callrules_01{<br />
rule test(in X:String , out Y, inout Z) = seq { <br />
update Y = X+Z;<br />
print(X + Y + Z); // prints "aacc"<br />
} <br />
rule main() = seq{<br />
call test("a", "b", "c"); <br />
}<br />
}<br />
</source><br />
<br />
The further use of user-defined ASM rules are illustrated in the following example:<br />
<br />
<source lang="text"><br />
machine symParams<br />
{<br />
rule main() = seq<br />
{<br />
let A=1, B=2, C=undef in seq {<br />
call myRule(A,B,C);<br />
println(A + "," + B + "," +C); // 1,1,2<br />
call myRule(3,B,C);<br />
println(3 + "," + B + "," +C); // 3,3,6<br />
call myRule(A,B,A); <br />
println(A + "," + B + "," +A); // 2,1,2<br />
}<br />
}<br />
<br />
rule myRule(in A, inout B, out C) = seq<br />
{<br />
update B = A;<br />
update C = A + B;<br />
}<br />
}<br />
</source><br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main(in X) = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===<br />
<br />
Composite rules allow to assemble more complex transformation algorithms. Composite control structures in VTCL are as follows:<br />
* '''if (C) R1 else R2''': If condition C holds then executes R1, else executes R2; fails if the selected execution branch fails; (''else'' part is optional)<br />
* '''try R1 else R2''': Executes R1, and if its execution fails, then it executes R2 (where the ''else'' part is optional); try/else rule fails if R2 fails, try rule (without else) fails when R1 fails<br />
* '''seq {R1; R2;}''': Executes R1 and R2 in this specific order. Sequential rule fails if either R1 or R2 fails.<br />
* '''random {R1; R2; }''': Non-deterministically selects R1 or R2, and executes it. Random rule fails if the selected rule (R1 or R2) fails.<br />
* '''let'''<br />
* '''choose'''<br />
* '''forall'''<br />
* '''iterate'''<br />
<br />
<source lang="text"><br />
machine composite_rules {<br />
rule main() = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141057VIATRA2/Examples/VTCL/ASM2009-02-20T16:03:37Z<p>Daniel.varro.gmail.com: /* User defined ASM rules */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== User defined ASM rules ===<br />
<br />
Users can define ASM rules as means for encapsulating certain functionality as a reusable operation.<br />
A user-defined ASM rule has an arbitrary number of parameters with the following directions: <br />
* '''in''': input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.<br />
* '''out''': output parameter, which means that (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule<br />
* '''inout''': input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.<br />
<br />
An optional '''type''' can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).<br />
<br />
<source lang="text"><br />
import datatypes;<br />
machine callrules_01{<br />
rule test(in X:String , out Y, inout Z) = seq { <br />
update Y = X+Z;<br />
print(X + Y + Z); // prints "aacc"<br />
} <br />
rule main() = seq{<br />
call test("a", "b", "c"); <br />
}<br />
}<br />
</source><br />
<br />
The further use of user-defined ASM rules are illustrated in the following example:<br />
<br />
<source lang="text"><br />
machine symParams<br />
{<br />
rule main() = seq<br />
{<br />
let A=1, B=2, C=undef in seq {<br />
call myRule(A,B,C);<br />
println(A + "," + B + "," +C); // 1,1,2<br />
call myRule(3,B,C);<br />
println(3 + "," + B + "," +C); // 3,3,6<br />
call myRule(A,B,A); <br />
println(A + "," + B + "," +A); // 2,1,2<br />
}<br />
}<br />
<br />
rule myRule(in A, inout B, out C) = seq<br />
{<br />
update B = A;<br />
update C = A + B;<br />
}<br />
}<br />
</source><br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main(in X) = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===<br />
<br />
Composite rules allow to assemble more complex transformation algorithms. Composite control structures in VTCL are as follows:<br />
* '''if/else'''<br />
* '''try/else'''<br />
* '''let'''<br />
* '''choose'''<br />
* '''forall'''<br />
* '''iterate'''<br />
<br />
<source lang="text"><br />
machine composite_rules {<br />
rule main() = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141037VIATRA2/Examples/VTCL/ASM2009-02-20T14:34:43Z<p>Daniel.varro.gmail.com: /* User defined ASM rules */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== User defined ASM rules ===<br />
<br />
Users can define ASM rules as means for encapsulating certain functionality as a reusable operation.<br />
A user-defined ASM rule has an arbitrary number of parameters with the following directions: <br />
* '''in''': input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.<br />
* '''out''': output parameter, which means that (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule<br />
* '''inout''': input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.<br />
<br />
An optional '''type''' can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).<br />
<br />
<source lang="text"><br />
import datatypes;<br />
machine callrules_01{<br />
rule test(in X:String , out Y, inout Z) = seq { <br />
update Y = X+Z;<br />
print(X + Y + Z); // prints "aacc"<br />
} <br />
rule main() = seq{<br />
call test("a", "b", "c"); <br />
}<br />
}<br />
</source><br />
<br />
The further use of user-defined ASM rules are illustrated in the following example:<br />
<br />
<source lang="text"><br />
machine symParams<br />
{<br />
rule main() = seq<br />
{<br />
let A=1, B=2, C=undef in seq {<br />
call myRule(A,B,C);<br />
print(A + "," + B + "," +C);<br />
call myRule(3,B,C);<br />
print(3 + "," + B + "," +C);<br />
call myRule(A,B,A);<br />
print(A + "," + B + "," +A);<br />
}<br />
}<br />
<br />
rule myRule(in A, inout B, out C) = seq<br />
{<br />
update B = A;<br />
update C = A + B;<br />
}<br />
}<br />
</source><br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main(in X) = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===<br />
<br />
Composite rules allow to assemble more complex transformation algorithms. Composite control structures in VTCL are as follows:<br />
* '''if/else'''<br />
* '''try/else'''<br />
* '''let'''<br />
* '''choose'''<br />
* '''forall'''<br />
* '''iterate'''<br />
<br />
<source lang="text"><br />
machine composite_rules {<br />
rule main() = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141034VIATRA2/Examples/VTCL/ASM2009-02-20T14:24:20Z<p>Daniel.varro.gmail.com: /* Abstract State Machines */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== User defined ASM rules ===<br />
<br />
Users can define ASM rules as means for encapsulating certain functionality as a reusable operation.<br />
A user-defined ASM rule has an arbitrary number of parameters with the following directions: <br />
* '''in''': input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.<br />
* '''out''': output parameter, which means that (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule<br />
* '''inout''': input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.<br />
<br />
An optional '''type''' can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).<br />
<br />
<source lang="text"><br />
import datatypes;<br />
machine callrules_01{<br />
rule test(in X:String , out Y, inout Z) = seq { <br />
update Y = X+Z;<br />
print(X + Y + Z); // prints "aacc"<br />
} <br />
rule main() = seq{<br />
call test("a", "b", "c"); <br />
}<br />
}<br />
</source><br />
<br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main(in X) = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===<br />
<br />
Composite rules allow to assemble more complex transformation algorithms. Composite control structures in VTCL are as follows:<br />
* '''if/else'''<br />
* '''try/else'''<br />
* '''let'''<br />
* '''choose'''<br />
* '''forall'''<br />
* '''iterate'''<br />
<br />
<source lang="text"><br />
machine composite_rules {<br />
rule main() = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source></div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141032VIATRA2/Examples/VTCL/ASM2009-02-20T13:27:17Z<p>Daniel.varro.gmail.com: /* Abstract State Machines */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== User defined ASM rules ===<br />
<br />
Users can define ASM rules as means for encapsulating certain functionality as a reusable operation.<br />
A user-defined ASM rule has an arbitrary number of parameters with the following directions: <br />
* '''in''': input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.<br />
* '''out''': output parameter, which means that (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule<br />
* '''inout''': input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.<br />
<br />
An optional '''type''' can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).<br />
<br />
<source lang="text"><br />
import datatypes;<br />
machine callrules_01{<br />
rule test(in X:String , out Y, inout Z) = seq { <br />
update Y = X+Z;<br />
print(X + Y + Z); // prints "aacc"<br />
} <br />
rule main() = seq{<br />
call test("a", "b", "c"); <br />
}<br />
}<br />
</source><br />
<br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main(in X) = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141030VIATRA2/Examples/VTCL/ASM2009-02-20T13:15:40Z<p>Daniel.varro.gmail.com: /* Simple rules */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main(in X) = seq {<br />
skip; <br />
print("abc"); <br />
log(error, "Error");<br />
update X = "sec";<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===<br />
<br />
=== User defined ASM rules ===</div>Daniel.varro.gmail.comhttps://wiki.eclipse.org/index.php?title=VIATRA2/Examples/VTCL/ASM&diff=141029VIATRA2/Examples/VTCL/ASM2009-02-20T12:53:56Z<p>Daniel.varro.gmail.com: /* Simple rules */</p>
<hr />
<div>== Abstract State Machines ==<br />
<br />
Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.<br />
<br />
=== ASM functions ===<br />
<br />
ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use.<br />
Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function <br />
can be updated using the '''update''' ASM construct (see later). <br />
<br />
<source lang="text"><br />
machine asmFuns {<br />
asmfunction team / 2 {<br />
// Initialization<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// Any values are allowed to be used in the untyped version<br />
(7.1, 6) = 2;<br />
}<br />
<br />
asmfunction anotherFun / 1; // An ASM function without initialization<br />
}<br />
</source><br />
<br />
In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.<br />
<br />
<source lang="text"><br />
// Import is needed if types are intended to be used by local names<br />
import datatypes;<br />
machine asmFuns {<br />
asmfunction team(Integer, datatypes.String) : String { // FQNs can always be used for defining types<br />
(1, "real") = "Casillas";<br />
(7, "real") = "Raul";<br />
// The following initialization would be a type error<br />
// (7.1, 6) = 2;<br />
}<br />
<br />
rule main() = seq <br />
{<br />
update team(1, "mu") = "van der sar";<br />
}<br />
}<br />
</source><br />
<br />
=== Simple rules ===<br />
<br />
Simple rules include the following elementary ASM control structures:<br />
<br />
* '''skip''': no operation<br />
* '''fail''': execution is terminated along the given path (with a failure)<br />
* '''print(X)''', '''println(X)''': prints term X (simply, or as a separate line). Buffered output can be initiated by '''print(B, X)''' and '''println(B, X)''', where buffer variable B should be initialized by a previous call to '''getBuffer/1'''.<br />
* '''log(Sev, X)''': prints term X to the error log with severity Sev (error, info, warning, debug, fatal)<br />
* '''update X = Y''', '''update fun(X) = Y''': assigns a new value Y to variable X or ASM function location fun(X)<br />
* '''call asmRule(X)''': calls user-defined ASM rule with actual parameter X<br />
<br />
<source lang="text"><br />
machine simple_rules {<br />
rule main() = seq {<br />
}<br />
}<br />
</source><br />
<br />
=== Composite rules ===<br />
<br />
=== User defined ASM rules ===</div>Daniel.varro.gmail.com