Xtext is a popular language workbench conceived to support development of tooling (e.g. parsers and editors) for textual languages. Although Xtext o ers strong support for source code generation when building tooling for Domain Speci c Languages (DSL), the amount of hand-written source code required to give support to complex General Purpose Languages (GPL) is still signi cant. This research investigates techniques for reducing the amount of hand-written source code for supporting GPLs, via the development of new DSLs from which source code can be automatically generated. In particular, these techniques will be researched in the context of the OCL and QVT Operational languages.
Since 2010, Eclipse OCL has evolved to better align with the OMG OCL
standard, while at the same time providing enhancements in the form of high-quality
textual editors. These editors have the particular feature that they are mostly
automatically generated using the Xtext [
turn evolves according to the OMG standard.
When undertaking that alignment, parsers and editors generated by Xtext are desired (e.g. reuse). However, in the Eclipse OCL implementation, there is a signi cant amount of hand written source code which should be avoided in favour of higher level of abstraction languages from which the source code can be generated. Those languages will ease the provision of the parsers and editors for Eclipse QVTo, which provides enough motivation for this EngD project.
provide support { in the form of Eclipse-based parsers and editors { for the OMG
4
tooling (e.g. parsers and editors) for textual languages. However, whilst Xtext is suitable to fully generate tooling for textual DSLs, it cannot currently be used for a completely automated generation process to cope with more complex
in which Xtext provides automation in the rst step, and generated code is complemented by hand-coding to support particular language requirements. A more complete automated generative process from language descriptions, with a higher level of abstraction that reduces the amount of hand-coding, is desirable.
4.1
syntax tree from a parser, and with further analysis algorithms such a syntax tree is re ned. This re nement is declared in OCL by the grammar synthesized attributes showed in Figure 2. However, if this information was moved into an
1 VariableExp : 2 referredVariable=[Variable|simpleNameCS] 3 | referredVariable=[Variable|’self’];
essence of separating the abstract syntax from concrete syntax as it is done in the
4.2
i ed accesses, nested scopes, and inheritance; these constructs are common in OO-derived GPLs. For instance, listing 1.2 depicts a typical name resolution scenario, with respect to the method which can be referred to by a method call expression.
1 class A { 2 public void methodA() { // do something } 3 } 4 class B extends A{ 5 public void methodB() { // do something } 6 public static void main(String [ ] args) { 7 B b = new B(); 8 b.methodA(); 9 } 10 }
4.3
syntax tree can't be obtained with simple context-free grammar syntax rules. Consider the OCL expression self.aProperty->size(). The size() library operation is normally applied on collections in order to obtain its number of elements. In this case, it is a applied on the value of aProperty of a model element. The issue is that it isn't known in advance if the value of aProperty is a collection until some semantic analysis is done. In the OCL language, if aProperty turned out to be de ned as a single-value, there is a syntactic rewrite { an implicit collection conversion. This kind of syntax rewrite is described in the OMG OCL speci cation by Listing 1.3; it can't be expressed in Xtext.
1 OperationCallExpCS.ast.source = 2 if OclExpressionCS.ast.type.oclIsKindOf(CollectionType) 3 then OclExpressionCS.ast 4 else OclExpressionCS.ast.withAsSet() 5 endif
5
Given the issues mentioned previously, we propose improvements to Xtext to provide support for generating tooling for more complex GPLs. Currently, crucial activities such as name resolution and syntax rewrites have to be hand-written by customizing code generated by Xtext1. Our idea is to use DSLs which capture the variability of these activities, in order to further automatically generate the corresponding source code. The overall approach is depicted in Figure 3. The following subsections describe the expected contributions. 1 Xtext has a generated, but naive name resolution strategy
5.2
E
cient scheduling of activities
resolution and syntax rewrites. These di erent activities are closely related: the
some names resolutions can't be undertaken until some AS elements are available. Some syntax rewrites are not possible without performing name resolution.
activities with the aim of generating an e cient implementation capable of exploiting them for faster AS model retrieval. This area of research will produce a contribution to the eld, because related work either addresses these activities in an isolated way, or does not consider the overall dependency issue at all. 6
abstract descriptions to complement Xtext grammars so as to generate additional source code for GPLs. There exists some work related to the detailed research activities that may provide good ideas or inspiration to individual problems (though none target Xtext tool generation or grammars). 6.1
The most relevant related work on name resolution is by Konat et al [
language (a avour of attribute grammar) in which not only are there syntactic rules to initially build AS trees but also language constructs to de ne inherited and synthesised attributions; these can be used to address name resolution concerns, as well as context-dependent syntax rewrites.
From the name resolution point of view, NaBL provides a more convenient
language with a higher level of abstraction. However, JastAdd introduces
constructs for syntax rewrites, though we know of no work that analyses
dependencies between syntax rewrites and name resolution. JastEMF [
Gra2Mol
tool provides the means to facilitate the creation of AS models generated from CS models produced by a parser { in this case by the means of a domain speci c transformation language (DSTL). Despite the accepted convenience of DSTLs for this task, a bespoke query language is used which is fragile in scenarios where the structure to be queried changes. For instance, the CS metamodel (the source of a transformation) frequently changes when incrementally building support for a language. Gra2Mol also doesn't generate a textual editor for the target language. 7
of code will be measured and compared: the Java sources which currently need to be hand written, with respect to the new descriptions based on those DSLs.
8 8.1
Instead of pursuing the aforementioned DSLs, a more general language will be
used as part of the rst prototype. In this case, the descriptions are given in the
form of Complete OCL documents [
{ It is not yet clear what expressiveness is needed of a language to represent complex scenarios for name resolution or syntax rewrites. A GPL like OCL, we hypothesise, may provide enough exibility. { The source code generated by Xtext is Java. The Eclipse OCL project includes an OCL2Java code generator so that complex scenarios described with OCL can be translated to Java. { One of the goals proposed by the sponsor is producing some parts of the
rectly producing Java code, the source code generators will produce Complete
One of the mentioned activities consists of specifying the CS2AS description and generate source code2 from them. Assuming that Complete OCL documents will be used to describe how CS and AS could be bridged, Listing 1.4 shows an example related to an OCL language concept: 1 context VariableExpCS 2 def : ast(env : env::Environment) : ocl::VariableExp = 3 let refVariable : ocl::Variable = env.lookupVariable(self.name) 4 in ocl::VariableExp { 5 referredVariable = refVariable, 6 type = refVariable.type 7 }
8.3
Some progress has currently been done with respect to how name resolution descriptions will be expressed and Complete OCL documents will also be used 2 Due to space limitations details about source code generator will be omitted for this task. They will describe, for instance, how AS elements, with the corresponding name, are contributed to an environment so that those elements can be found by name later on. Listing 1.5 shows an example of how a Package contributes named elements (nested packages and types) to the environment. 1 context Package 2 def : _env(env : env::Environment) : env::Environment = 3 env.nestedEnv() 4 .addElements(self.nestedPackage) 5 .addElements(self.ownedType) 6 }
9
Future work { Finish source code generators from CS2AS and name resolution descriptions. { Design a solution for syntax rewrites including source code generator. { Improve generated source code implementation based on dependency analysis of CS2AS, name resolution and syntax rewrites activities. { Design high level of abstraction DSLs and implement the corresponding generators to produce Complete OCL documents. { Evaluate the contribution of nal solutions as described in this paper.