Transformation of Applicative Specifications into Imperative ...

Chapter 4
Constraints
In this project only a subset of RSL, named RSLA for an applicative subset
of RSL, is considered. This chapter gives an overview of the RSL expressions
and forms not considered. Explanations for the omissions are given when
possible.
It is assumed that the specifications given to the transformer are static
correct specifications according to the static semantics of RSL. This means
that a specification should be type checked using the RSL type checker before
it is transformed using the transformer.
4.1 The RSL Constructions Not Considered
In order to be able to transform applicative specifications into imperative
specifications and in order to avoid that the work gets to extensive compared
to the benefits only a subset of RSL is considered.
The RSL constructs not considered are either of no relevance or are not
considered in order to simplify matters. Furthermore, most of the constraints
introduced do not limit the expressive power, as these constructs can be
rewritten into constructs which comply with the constraints.
In the following a list of the RSL constructs not within RSLA is given as
well as reasons as to why these are not considered. The list is divided into
syntactical and non syntactical constraints, according to how the checks for
them are implemented in the transformer.
Syntactical Constraints
• Abstract specifications (e.g. sort definitions and axiomatic value definitions).
Reason: To simplify matters. Furthermore, the most common way
of applying the RAISE Development Method, is to start out with an
abstract applicative specification, which is made concrete before it is
19