Transformation of Applicative Specifications into Imperative ...

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

26.09.2013 Views

CHAPTER 12. POSSIBLE EXTENSIONS OF THE TRANSFORMER 12.1.10 Recursive functions Recursive functions can be part of an imperative specification, but are sometimes not wanted. Using the transformer the recursive functions from the applicative specification stay recursive after the transformation. This is done to simplify the transformer. Recursions can usually be turned into either for loops or while loops. Another option is to transform recursive functions into non-recursive functions using continuations, as described in [Wan80]. The idea behind continuations is that the future course of the computation is represented while executing the computation. The use of continuations may have the unwanted effect of reducing the readability of the specification compared to using loops. 12.1.11 Collections of a Fixed or Bounded Size Collections of a fixed or bounded size can be implemented by introducing the proper amount of objects or variables. This requires that the maximum sizes of the collections are known in advance. 12.2 Further Work As this project was limited in time not all the desired functionality could be implemented. During the process several ideas for further development of the transformer have come to mind. In the following some of these ideas will be discussed. 12.2.1 A Greater Subset of RSL One obvious extension is to extend the transformer such that it covers a greater subset of RSL. Ideas for some of the transformation rules are given above. This would make the transformer even more useful. Furthermore, it could be useful if the transformer could deal with specifications that were partly applicative and partly imperative. This would be an even better way to support the RAISE Development Method. 12.2.2 Integrating the Transformer with Other RAISE Tools Another idea is to integrate the transformer with Emacs such that it only requires one Emacs command to start the transformation. Furthermore, it would be pleasant if the transformer process were coupled with the RSL type checker and pretty printer such that type checking and pretty printing were a part of the transformation process. 126

12.2.3 Optimization of the Transformer 12.2. FURTHER WORK As described in Chapter 9 the transformation process can in some cases be very slow. It would be nice if the transformer could be optimized such that the transformation process for some specifications was a bit faster. 12.2.4 Interactive Transformer Another extension could be to make the transformer interactive such that the user can choose which of the occurrences of values and type names of the types of interest that have to be transformed as such. This would ease the requirements on the specification style, but it would complicate the use of the transformer. 12.2.5 Full Verification of the Transformation Rules In Chapter 7 a proof of the correctness of the transformation rules is outlined. If this proof was completed, the step from applicative into imperative specification would be verified automatically if it was done applying the transformation rules, e.g. by using the transformer. This would mean that no further work would have to be done in order to verify the development step, which would ease the development step even further. 12.2.6 Other Extensions When a specification cannot be transformed it is not specified what and where the problem is unless the problem is caught by the lexer and parser. An extension to the transformer could be to improve the error handling. This would ease the use of the transformer. 127

12.2.3 Optimization <strong>of</strong> the Transformer<br />

12.2. FURTHER WORK<br />

As described in Chapter 9 the transformation process can in some cases be<br />

very slow. It would be nice if the transformer could be optimized such that<br />

the transformation process for some specifications was a bit faster.<br />

12.2.4 Interactive Transformer<br />

Another extension could be to make the transformer interactive such that<br />

the user can choose which <strong>of</strong> the occurrences <strong>of</strong> values and type names <strong>of</strong><br />

the types <strong>of</strong> interest that have to be transformed as such. This would ease<br />

the requirements on the specification style, but it would complicate the use<br />

<strong>of</strong> the transformer.<br />

12.2.5 Full Verification <strong>of</strong> the <strong>Transformation</strong> Rules<br />

In Chapter 7 a pro<strong>of</strong> <strong>of</strong> the correctness <strong>of</strong> the transformation rules is outlined.<br />

If this pro<strong>of</strong> was completed, the step from applicative <strong>into</strong> imperative<br />

specification would be verified automatically if it was done applying the<br />

transformation rules, e.g. by using the transformer. This would mean that<br />

no further work would have to be done in order to verify the development<br />

step, which would ease the development step even further.<br />

12.2.6 Other Extensions<br />

When a specification cannot be transformed it is not specified what and<br />

where the problem is unless the problem is caught by the lexer and parser.<br />

An extension to the transformer could be to improve the error handling.<br />

This would ease the use <strong>of</strong> the transformer.<br />

127

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

Saved successfully!

Ooh no, something went wrong!