Transformation of Applicative Specifications into Imperative ...

Transformation of Applicative Specifications into Imperative ... Transformation of Applicative Specifications into Imperative ...

26.09.2013 Views

CHAPTER 4. CONSTRAINTS of interest. Reason: Only collections of a fixed or bounded size would be possible to transform, but very few specifications need such collections, wherefore this is not considered in the transformer. • Recursive type definitions of the types of interest. Reason: As only one variable is established per type of interest, recursive type definitions of the types of interest are not possible to transform as this would require more than one variable per type of interest. • In application expressions of the form value_expr(value_expr1, ..., value_exprn), value_expr has to be a value name. Reason: To simplify matters. • Overloading. Reason: To simplify matters. • Value expressions in pre-conditions containing generators, either explicit, implicit or hidden. Reason: The requirement that the transformed specification shall be syntactically correct is impossible to fulfill if pre-conditions consist of any kinds of generators. This is due to the fact that pre-conditions are read-only. The only exception to this rule is that function applications taking only value names of the types of interest are allowed as these value names are just removed during the transformation. • Patterns in case expressions which are constants of a type of interest. Reason: The requirement that the transformed specifications shall be syntactically correct is impossible to fulfill if patterns of case expressions are of a type of interest. This is due to the fact that constants of a type of interest are transformed into explicit function definitions and function applications are not allowed as patterns according to the syntax of RSL. • Patterns in case expressions containing value names of the types of interest. Reason: The requirement that the transformed specifications shall be syntactically correct is impossible to fulfill if patterns of case expressions consist of value names of the types of interest. This is due to the fact that value names of the types of interest are transformed into variables and variables are not allowed as patterns according to the syntax of RSL. • The number of parameters of a function has to be at least as big as the number of components of the type expression on the left hand side 22

4.1. THE RSL CONSTRUCTIONS NOT CONSIDERED of the function signature - both formal and actual parameters. Reason: To simplify matters. Problems arise especially when type names of the types of interest are involved. • In let bindings only a product binding having at least as many components as the product expression is allowed. Reason: To simplify matters. Problems can arise especially when type names of the type of interest are involved. Ideas for transformations of some of the constructs given in the lists above are provided in Chapter 12. 23

4.1. THE RSL CONSTRUCTIONS NOT CONSIDERED<br />

<strong>of</strong> the function signature - both formal and actual parameters.<br />

Reason: To simplify matters. Problems arise especially when type<br />

names <strong>of</strong> the types <strong>of</strong> interest are involved.<br />

• In let bindings only a product binding having at least as many components<br />

as the product expression is allowed.<br />

Reason: To simplify matters. Problems can arise especially when<br />

type names <strong>of</strong> the type <strong>of</strong> interest are involved.<br />

Ideas for transformations <strong>of</strong> some <strong>of</strong> the constructs given in the lists above<br />

are provided in Chapter 12.<br />

23

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!