Transformation of Applicative Specifications into Imperative ...

CHAPTER 5. TRANSFORMABILITY
scheme I_SPEC =
class
type
T = Int
variable
t : T
value
f : Unit → read t write t Int
f() ≡ (g() ; t) + t,
end
g : Unit → read t write t Unit
g() ≡ t := t + 1
It is obvious that the the imperative specification in Example 5.1 is not
a correct development of the applicative specification. This means that the
transformation is invalid. The problem is that the variable t changes its value
during execution of the function g in the imperative specification, while in
the applicative specification it is the original value of the x parameter that
is used during the whole execution of the function body of f.
This means that the transformation from applicative into imperative
specification not always is a correct development when using the transformation
rules defined in Chapter 6. This means that only some applicative
specifications written within RSLA can be transformed using the transformation
rules. The problem is that there is only one placeholder for each
variable. This means that only one value per variable can be stored at a
time.
The applicative specifications that can be transformed are in the following
called transformable. Before an applicative specification is transformed,
it has to be checked if the transformation can be done. That is, if the specification
is transformable.
5.2 Conditions for Transformability
The following conditions for transformability are based on the transformation
rules proposed in this project. Other transformation rules would probably
lead to other conditions for transformability.
In order for an applicative specification to be transformable, it has to
fulfill stronger scope rules than the static semantics of RSL allows. The
general idea is that at any point of execution references to at most one value
name of a certain type of interest are allowed.
26