a new translator which handles a slightly larger subset of RSL. This version of the translator is referred to as “the second version of the translator”.
The front end and the back end is only modified slightly by hand to fit the new constructs. The conclusion is that only a few modifications in Java are needed, while the main work in this step is done in RSL.
At this point, one can keep expanding and optimizing the translation module by specifying the new version in RSLn−1. The specification can then be translated using the three–stage translator of the previous step. The translated specification can then be combined with the front end and the back end into a new three–stage translator translating from RSLn to Java source code.
alternative may consist of several other constructs. To make variant defini-tions with one alternative simpler to define, short record definidefini-tions should also be included. Some constructs in RSL may contain a number of other constructs of the same type. As an example the variant definition may have a number of alternatives. To specify this lists must also be added to RSL0. To handle simple examples the built–in types in RSL must be added, except for Nat which is a subtype of Int.
In order to be able to manipulate the two AST’s defined, and to create one from the other, functions are needed. Therefore, explicit function definitions are part of RSL0. Functions in a translation module are quite complex, so they must be able to take more than one parameter. Therefore, product type expressions in the first part of a function type expression is allowed. However, to make the implementation simple, multiple outputs from functions are not permitted. The outcome of an explicit function is described by a value expression. Therefore, a number of value expressions must be selected to define the outcome of functions.
In order to be able to make choices and differentiate between the different alternatives of a variant definition, case expressions and if expressions are part of RSL0. Furthermore, it must be possible to manipulate the lists allowed in RSL0, therefore prefix expression using the list operator hd and tl are also part of RSL. To cope with simple examples using the built–in types and to be able to combine lists and compare different value expressions, value infix expressions using +, *, ˆ and = are part of RSL0. In order to be able to call functions recursively, call other functions, construct records using constructors and make functions of short record definitions, application expressions are also part of RSL0.
All these functions, and types which are needed in order to define a spe-cification of a translation module must be put in some kind of module in order for them to be valid RSL. Furthermore, it would definitely be an ad-vantage if the specification could be divided into several modules, because a specification of a translation module is quite large. These requirements mean that schemes and some kind of extend should be allowed in RSL0, in order to divide the specification into several modules.
Overview of RSL0:
• Top level constructs:
– Schemes using the class expressions allowed. Parameterization not allowed.
– Class expression:
∗ Basic class expression using the declarations allowed.
∗ Extending class expression with the base class as a scheme instantiation.
∗ Scheme instantiations in an extending class expression.
• Type definitions:
– Short Record definitions; destructors are required, reconstructors are not allowed.
– Variant definition; destructors are required, reconstructors are not allowed.
• Value definitions:
– Explicit function definitions using an id application and not prod-ucts as result, using the value expressions allowed.
• Test case definitions using the value expression allowed. The test cases in RSL0 must include an identifier.
• Type Expressions:
– Function type expression. Only in form of total functions using the other type expression described as domain, and a function result description containing any of the other type expressions except product and function type expressions.
– List type expression.
– Product type expression as part of the domain of a function type expression.
– Type literals excluding Nat.
• Value Expressions:
– Value infix expressions using ˆ ,=, +and *.
– Value prefix expressions using hd and tl.
– Enumerated list expressions.
– Value or variable names.
– Application expressions.
– Structured expressions:
∗ Case expressions using name, literal and record patterns
∗ If expressions not containing elsif statements – Value literals.
3.4.2 Description of RSL
1The RSL1 subset of RSL is the next subset after RSL0. This would be the point, where one tried to add as many features of the source language as possible. In this work, however, only one feature has been added namely the division operator for value infix expression. The reason for this is that the second step of the bootstrapping process in this project is only to prove that it is possible to get the process started. In Chapter 7 suggestions for how to extend the translator to a larger subset are given.
Implementation of the Translator
This chapter describes some of the details of the implementation of the trans-lator. It starts, in Section 4.1, with an introduction to the library classes developed for representations of lists, sets and maps. Afterwards, in Sec-tion 4.2 and 4.3, there is a presentaSec-tion of the two versions of the translator implemented in this project.