Transformation of Applicative Specifications into Imperative ...
Transformation of Applicative Specifications into Imperative ... Transformation of Applicative Specifications into Imperative ...
CHAPTER 8. SPECIFICATIONS out, that using this approach made updating of the map more difficult than the selected solution. The TYPES Map The TYPES map is defined as follows: TYPES = Binding →m ExpType, ExpType == Known(type_expr : TypeExpr) | Unknown The TYPES map maps value names to their corresponding expected type if known. It is used both during the check for transformability and during the transformation phase to decide if value names are of the type of interest. As for the ENV map, the TYPES map is related to a function and not to the entire specification. The initial value of the TYPES map is computed in the functions CheckValueDef and TRValueDef when dealing with explicit function definitions. 8.3.2 The Structure of a Transformation The main function of the transformer is TRRSLAst which as arguments takes an applicative RSL AST, a new scheme id and a TRANS map and returns the corresponding imperative RSL AST, if the applicative RSL AST is transformable. In some cases the applicative specification cannot be transformed either because it is not transformable or because it is not within RSLA. This requires the result of the transformation to be specified as a variant definition: TRResult == RSLast_transformable(result : RSLAst) | RSLast_not_transformable The transformation of an applicative RSL AST is divided into three parts: 1. The TYPINGS map and FUNC map are established. 2. A check for transformability is performed. 3. If the specification is transformable the actual transformation is done. First the two maps TYPINGS and FUNC are established. Then the transformer starts from the top of the RSL AST and then moves down the RSL AST until the whole RSL AST has been processed checking for transformability and transforming the RSL AST on its way. In the following the structure of the check for transformability and the transformation will be described. 78
The Check for Transformability 8.3. SPECIFICATION OF THE TRANSFORMER The check for transformability is simply a check to see whether the special scope rules defined in Chapter 5 are fulfilled. This check is done using the ENV map, which is updated such that it at all times shows which value names of the type of interest that are in the scope at a certain point of execution, cf. Section 8.3.1. During the check for transformability it is also checked whether the specification fulfills the non-syntactically constraints listed in Chapter 4. To get an idea of how this is done, the main function CheckTypeDef for checking if a type definition is transformable is shown in Specification 8.1. Specification 8.1 – Check for transformability of a type definition CheckTypeDef : TypeDef × TYPINGS × FUNC × TRANS → Bool CheckTypeDef(td, typings, func, trans) ≡ case td of SortDef(id) → id ∈ dom trans, VariantDef(id, vl) → CheckVariantList(id, vl, typings, func, trans) ∧ id ∈ elems typings(id), ShortRecordDef(id, cl) → CheckComponentKindList( id, cl, typings, func, trans) ∧ id ∈ elems typings(id), AbbreviationDef(id, te) → CheckTypeExpr(te, typings, func, trans) ∧ id ∈ elems typings(id) end As can be seen in Specification 8.1 the check of a type definition is made by casing over the kind of type definitions. For sort type definitions it is checked whether the type is not of the type of interest using the TRANS map. For the other kinds of type definitions it is checked whether they are not recursively defined using the TYPINGS map and it is checked if the contents of the type definitions fulfill the constraints given in Chapter 4 using the functions CheckVariantList, CheckComponentKindList and CheckTypeExpr. The Actual Transformation The actual transformation of the RSL AST is done walking through the constructs of the RSL AST and whenever needed changing the applicative 79
- 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
- Page 88 and 89: CHAPTER 8. SPECIFICATIONS The rewri
- Page 90 and 91: CHAPTER 8. SPECIFICATIONS RSL speci
- Page 92 and 93: CHAPTER 8. SPECIFICATIONS The FUNC
- Page 96 and 97: CHAPTER 8. SPECIFICATIONS construct
- Page 98 and 99: CHAPTER 8. SPECIFICATIONS 8.4.1 Mor
- Page 100 and 101: CHAPTER 8. SPECIFICATIONS PRECOND_T
- Page 102 and 103: CHAPTER 8. SPECIFICATIONS if length
- Page 104 and 105: CHAPTER 8. SPECIFICATIONS subtypes.
- Page 106 and 107: CHAPTER 8. SPECIFICATIONS 8.5.2 Cha
- Page 108 and 109: CHAPTER 8. SPECIFICATIONS axiom [ m
- Page 110 and 111: CHAPTER 8. SPECIFICATIONS Specifica
- Page 112 and 113: CHAPTER 8. SPECIFICATIONS the lack
- Page 114 and 115: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 116 and 117: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 118 and 119: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 120 and 121: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 122 and 123: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 124 and 125: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 126 and 127: CHAPTER 10. EXAMPLES OF TRANSFORMAT
- Page 128 and 129: CHAPTER 10. EXAMPLES OF TRANSFORMAT
- Page 130 and 131: CHAPTER 10. EXAMPLES OF TRANSFORMAT
- Page 132 and 133: CHAPTER 10. EXAMPLES OF TRANSFORMAT
- Page 134 and 135: CHAPTER 10. EXAMPLES OF TRANSFORMAT
- Page 136 and 137: CHAPTER 11. TEST 11.1.1 Lexer and P
- Page 138 and 139: CHAPTER 11. TEST An overview of the
- Page 140 and 141: CHAPTER 12. POSSIBLE EXTENSIONS OF
- Page 142 and 143: CHAPTER 12. POSSIBLE EXTENSIONS OF
CHAPTER 8. SPECIFICATIONS<br />
out, that using this approach made updating <strong>of</strong> the map more difficult than<br />
the selected solution.<br />
The TYPES Map<br />
The TYPES map is defined as follows:<br />
TYPES = Binding →m ExpType,<br />
ExpType == Known(type_expr : TypeExpr) | Unknown<br />
The TYPES map maps value names to their corresponding expected type<br />
if known. It is used both during the check for transformability and during<br />
the transformation phase to decide if value names are <strong>of</strong> the type <strong>of</strong> interest.<br />
As for the ENV map, the TYPES map is related to a function and not to<br />
the entire specification. The initial value <strong>of</strong> the TYPES map is computed<br />
in the functions CheckValueDef and TRValueDef when dealing with explicit<br />
function definitions.<br />
8.3.2 The Structure <strong>of</strong> a <strong>Transformation</strong><br />
The main function <strong>of</strong> the transformer is TRRSLAst which as arguments<br />
takes an applicative RSL AST, a new scheme id and a TRANS map and returns<br />
the corresponding imperative RSL AST, if the applicative RSL AST is<br />
transformable. In some cases the applicative specification cannot be transformed<br />
either because it is not transformable or because it is not within<br />
RSLA. This requires the result <strong>of</strong> the transformation to be specified as a<br />
variant definition:<br />
TRResult ==<br />
RSLast_transformable(result : RSLAst) |<br />
RSLast_not_transformable<br />
The transformation <strong>of</strong> an applicative RSL AST is divided <strong>into</strong> three parts:<br />
1. The TYPINGS map and FUNC map are established.<br />
2. A check for transformability is performed.<br />
3. If the specification is transformable the actual transformation is done.<br />
First the two maps TYPINGS and FUNC are established. Then the<br />
transformer starts from the top <strong>of</strong> the RSL AST and then moves down the<br />
RSL AST until the whole RSL AST has been processed checking for transformability<br />
and transforming the RSL AST on its way.<br />
In the following the structure <strong>of</strong> the check for transformability and the<br />
transformation will be described.<br />
78