Transformation of Applicative Specifications into Imperative ...
Transformation of Applicative Specifications into Imperative ... Transformation of Applicative Specifications into Imperative ...
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
- Page 1: Transformation of Applicative Speci
- Page 5: Resumé RAISE udviklingsmetoden er
- Page 8 and 9: viii
- Page 10 and 11: CONTENTS 6.4.3 Transforming Value E
- Page 12 and 13: CONTENTS 12.2.4 Interactive Transfo
- Page 14 and 15: xiv
- Page 16 and 17: LIST OF FIGURES xvi
- Page 18 and 19: CHAPTER 1. INTRODUCTION This stepwi
- Page 20 and 21: CHAPTER 1. INTRODUCTION 1. Formulat
- Page 22 and 23: CHAPTER 1. INTRODUCTION 1.7 Content
- Page 24 and 25: CHAPTER 2. GENERAL IDEA end value e
- Page 26 and 27: CHAPTER 2. GENERAL IDEA • In the
- Page 28 and 29: CHAPTER 2. GENERAL IDEA value incre
- Page 30 and 31: CHAPTER 3. TERMINOLOGY Expected Typ
- Page 32 and 33: CHAPTER 3. TERMINOLOGY Example 3.5
- Page 34 and 35: CHAPTER 3. TERMINOLOGY 18
- Page 36 and 37: CHAPTER 4. CONSTRAINTS further deve
- Page 40 and 41: CHAPTER 4. CONSTRAINTS 24
- Page 42 and 43: CHAPTER 5. TRANSFORMABILITY scheme
- Page 44 and 45: CHAPTER 5. TRANSFORMABILITY 28
- Page 46 and 47: CHAPTER 6. TRANSFORMATIONS 6.2.1 Tr
- Page 48 and 49: CHAPTER 6. TRANSFORMATIONS Example
- Page 50 and 51: CHAPTER 6. TRANSFORMATIONS Applicat
- Page 52 and 53: CHAPTER 6. TRANSFORMATIONS object A
- Page 54 and 55: CHAPTER 6. TRANSFORMATIONS type T =
- Page 56 and 57: CHAPTER 6. TRANSFORMATIONS where ge
- Page 58 and 59: CHAPTER 6. TRANSFORMATIONS Ranged s
- Page 60 and 61: CHAPTER 6. TRANSFORMATIONS ✄ end
- Page 62 and 63: CHAPTER 6. TRANSFORMATIONS Value In
- Page 64 and 65: CHAPTER 6. TRANSFORMATIONS ✄ sche
- Page 66 and 67: CHAPTER 6. TRANSFORMATIONS A case e
- Page 68 and 69: CHAPTER 6. TRANSFORMATIONS is due t
- Page 70 and 71: CHAPTER 6. TRANSFORMATIONS 6.4.4 Tr
- Page 72 and 73: CHAPTER 6. TRANSFORMATIONS 56
- Page 74 and 75: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 76 and 77: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 78 and 79: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 80 and 81: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 82 and 83: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 84 and 85: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 86 and 87: CHAPTER 7. CORRECTNESS OF TRANSFORM
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