529
Lecture Notes in Computer Science Edited by G. Goos and J. Hartmanis 292 III IIIII IIIIIII 7 The Munich Project CIP Volume ii: The Program Transformation System CIP-S By the CIP System Group: F.L. Bauer, H. Ehler, A. Horsch, B. M611er, H. Partsch, O. Paukner, and P. Pepper IIIIII III Springer-Verlag Berlin Heidelberg NewYork London Paris Tokyo IIIIIIIIIIIIII !

The Munich Project CIP: Volume II: The Program Transformation System CIP-S

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Page 1: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Lecture Notes in Computer Science Edited by G. Goos and J. Hartmanis

292 III IIIII IIIIIII 7

The Munich Project CIP Volume ii: The Program Transformation System CIP-S

By the CIP System Group: F.L. Bauer, H. Ehler, A. Horsch, B. M611er, H. Partsch, O. Paukner, and P. Pepper

IIIIII III

Springer-Verlag Berlin Heidelberg NewYork London Paris Tokyo

IIIIIIIIIIIIII !

Page 2: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Editorial Board

D. Barstow W. Brauer R Br inch Hansen D. Gries D. Luckham C. Moler A. Pnueli G. Seegm(Jller J. Stoer N. Wir th

Authors

F.L. Bauer H. Ehler B. MSIler Institut f(Jr Informatik der Technischen Universit~t M~nchen Postfach 202420, 8000 MOnchen 2, Federal Republic of Germany

A. Horsch O. Paukner Klinikum rechts der Isar, Rechenzentrum Block A Ismaninger StraBe 22, 8000 M0nchen 80 Federal Republic of Germany

H. Partsch Department of lnformatics Vl, Catholic University of Nijmegen Toernooiveld 1, 6525 ED Nijmegen, The Netherlands

P. Pepper Fachbereich 20 Informatik, Technische Universit&t Berlin Franklinstraf3e 28/29, 1000 Bedin 10 (West)

CR Subject Classification (1987): D. 1.0, D.2.1-2, D.2.4, D.2.6-7, D.2.9-10, E3.1, 1.1.3, 1.2.2-3, K.6.1, K.6 .3-4

ISBN 3-540-18779-0 Springer-Verlag Berlin Heidelberg New York ISBN 0-38?-18779-0 Springer-Verlag New York Berlin Heidelberg

This work is subject to copyright, All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in other ways, and storage in data banks. Duplication of this publication or parts thereof is only perm~ed under the pro'Asions of the German Copyright Law of September 9, 1965, in its version of June 24, 1985, and a copyright fee must always be paid. Violations fall under the prosecution act of the German Copyright Law. © Springer-Verlag Berlin Heidelberg 1987 Printed in Germany Printing and binding" Druckhaus Beltz, Hemsbach/Bergstr. 2145/3140.543210

Page 3: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

PREFACE

This book is the second of two volume~ that present the main results having ~ e d from the project CIP - _Co~$~ter-Aided, _Intuition-Guided _Programm4ng - at the Technical University of Munich. The central theme of this project is program development by transformation, a methodology which is felt to become more and more important.

Whereas Volume I contains the description and formal specification of a wide spectrum language CIP-L particularly tailored to the needs of transformational programming, the present Volume II contains the description, formal specification, and transformational development of a system CIP-S, that is to assist a pFogrammer in this methodology.

This work originated from t~o rather different motivations: On the one hand, i t is to be seen as an attempt to gain methodical experience with non-toy, medium-size software projects and, in this way, to demonstrate the feasibility of the CIP approach as a software engineering discipline. On the other hand, the system is intended to incorporate recent ideas as well as experience with our own protot]4De system and other people's systems. Thus, in the very end, i t is to constitute the basis for a practicable software development tool usable by other people either in gaining experience themselves or in producing software.

Part I deals with general issues such as "W~ to use an implemented system to assist in transformational programming?" and "What are the interesting aspects with respect to transformation systems?". I t also gives a brief summa~ of the running CIP prototype transformation system and an informal overview of the system to be dealt with in all subsequent parts. A short account of the global requirements and their implications for the organization of the system project is given and some aspects of an appropriate user environment conclude this part.

In Part I I a calculus of program transformations (including induction) is presented as a theoretical basis for the entire transformation system project.

Part I I I starts with a more detailed and in particular more user-oriented informal collection of technical requirem~ts for the transformation system. In i ts main part a formal, algebraic specification (including all design decisions) for the language-independent core of such a system can be found, whereas language-dependent aspects and issues of an appropriate user environment are deferred to Part VI. Part I I I closes with a kind of validation of the formal specification and a summa~ of experiences made in writing the formal specification.

Part IV takes Part I I I as a basis and demonstrates for selected system functions how running programs can be derived from the respective specifications by means of transfomations. The main criterion for selection was the probable interest of the derivations. Therefore obvious or less interesting developments deliberately have been left out. As to the derivations selected, although actually done in very small steps by using the prototype system, particular emphasis has been laid on expressing the essential lines of thought rather than particular concrete rules. However, these rationales of design also have been supplemented with enough technical information such that an interested reader should be able to redo the detailed developments himself. The essential purpose of giving these selected develo~mmts in Part IV is to denwmstrate that they can be done with an implemented transformation system. Many further developmants of functions specified in Part I l l have been carried out with the prototype. They can be found in full deta17 in [Ehler et al. 87], out of which Part IV has actually been selected. Like Part I l l , Part IV closes with a summa~ of the experiences gained when doing the actual developments.

Page 4: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV

Part V is a collection of transformation rules used in Part IV. According to the ph~osophy of the language CIP-L used for specification and development these rules are differentiated into rules for the scheme language, rules for particular data ~)~es, and rules connected im particular computation struc~Fes.

Part Vl is intended to give the main hints on how to exi~nd ~he system core as specified in Part I I I to a running system exemplified with a sublanguage of CIP-L. In particular this part contains some more information on ~he language-dependent i~ypes (that have been left "open" in Part I l l ) , on converters between exb~rnal and internal pFogram representations, about the way of treating context conditions, semantic relations, and meta-predicates.

The report also contains an index of sorts, objects, and operations introduced, where the given page number refers to the defining occurrence in the specification. Cross-Feferences within one part are given by section numbers only; references to other parts are made by prefixing the respective section numbers with the (roman) part n~bers.

We would like to express our thanks to the Deutsche Forschungsgemeinschaft who has sponsored this research within ~he Sonderforschungsbereich 49 "Programmiertechnik" for ten years. Also, we gratefully acknowledge valuable criticism by the me~i~ers of IFIP Working Group 2.1, notably by R. Bird, P. King, C.H. Lindsey, L.G.L.T. Meertens, S.A. Schumm, and, above all, M. Sintzoff. Moreover, we would like to thank H. Remus and D.E. Shough from the Santa Teresa Laboratory of IBM for their continuing support. Last, but by no means least, we gratefully acknowledge many helpful remarks by our (present or former) colleagues R. Berghammer, C. Delgado Kloos, F. Erhard, U. Hill-Samelson, R. Obermeier, H.-O. Riethmayer, G. Schmidt, R. Steinbr~ggen, M. Wirsing, and H. WBssner as well as the speedy and competent assistance by M. Glashauser in doing the developments on the prototype ~stem and in preparing the t~pescript.

Munich, October 1987

The CIP System Grow

Page 5: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

TABLE OFCONTENTS

PART I : INTRODUCTION

i , 2. 3. 4. 5. 6.

Transformational progranming assisted by an implemented system Issues of transfontBtion systems The CIP protoi~ype system Informal overview of CIP-S Global requirements Some aspects of an appFopriate user environment

PART I I : ll-E TRANSF(3~MATION CALCB_US 11

1. 2.

2.1. 2.1.1. 2.1.2.

2.2. 2.3.

2.3.1. 2.3.2. 2.3.3. 2.3.4.

2.4. 2.4.1. 2.4.2.

2.5. 3.

3.1. 3.2. 3.3. 3.4. 3.5.

4. 4.1.

4.1.1. 4.1.2. 4.1,3. 4.1.4.

4.2. 4.2.1. 4.2.2.

5.

Introduction Definition of the calculus

An algebraic view of programs and transformations Signatures and terns Formulas

Clauses The calculus of inferences

Meta-deductions Meta-inferences About higher-level rules Relationship to further proof principles

Derived meta-inferences Language-independent derived meta-inferences Language-dependent derived meta-inferences

The role of free variables RepFesentat~on of transfomation tasks in t~e calculus

Genuine transformation steps C(mI~ctification of development histories Verification of applicability conditions Reduction of applicability conditions (goal reduction) "Claims"

Induction rules C~tat ional induction

Scott induction Rccursion induction "Transformational" induction Fixpoint induction

Structural induction Term induction Deccmposition induction

Discussion

13 15 15 16 16 19 20 21 22 23 23 24 24 24 26 30 30 33 33 34 35 35 37 37 38 38 38 39 39 39 41

Page 6: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Vl

PART I I I : FI~q~AL SPECIFICATION 43

1. 1.1.

1.1.1. 1.1.2. 1.1.3. 1.1.4. 1.1.5. 1.1.6. 1.1.7. 1.1.8.

1.2.

Informal requirements Technical recNi rements

Programs and program schemes Transformation rules and their application Verification of applicability conditions (goal reduction) Development of l~es and computational structures Documentation of a developmmt Record of a goal reduction Further a~nistrat ive tasks of the system User e n v i r ~ t

Example: A f ict i t ious session with the systm~ 2. Formal specification of the system core

2.1. Fundamental design decisions 2.1.1. General design decisions 2.1.2. Technical design decisions

2.2. Preliminary remarks on the fomal specification 2.2.1. Structure of the specification 2.2.2. Remarks on notation

2.3. ~ system core EFFECT, SYSTEM~ GEN-CCM NEUTR-COM DERIV-COM DEVIREE-CCM MOVE-COM RED-COM CAT-CCM

2,4. The state 2.5. The catalog-base

CATALOG-BASE CATALOG MAP EM~P GROUP

2.6. Reductions 2.7. Derivations

DERIVATION MIEBM DEVTREE REL-C(]MP I~O

2,8. Inferences I~ERENCE CLAUSE FORMULA PRED-SYIVB

2.9. Terms INSTANCE

45 45 45 45 46 46 46 47 47 47 47 52 53 53 54 56 56 57 61 62 64 68 69 73 78 80 83 89 96 97

103 107 I08 110 112 115 117 122 127 133 134 135 137 145 147 149 151 153

Page 7: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Vll

T~M IPOS L~GUAGE OPERATOR SORT

2,10. Basic ~es sEqu PRIMSET SET

3. Validation of the specification: Example revisited 3.1. General remarks 3.2. The sample session in terms of system functions 3.3. Technical detailization of the system functions used in the sample session

4. Experiences 4.1. Experiences in using a formal specification 4.2. Technical experiences with algebraic specifications

158 168 169 171 174 176 176 180 181

183 186 203 203 205

PART IV : F C ~ DEVELOI~ OF SELECTED SYSTE~ FLI~CTIONS 207

I . 1.1, 1.2.

1.2.1. 1.2.2. 1.2.3. 1.2.4. 1.2.5. 1.2.6. 1.2.7.

1.3. 1.4.

2. 2.1. 2.2. 2.3.

3. 3.1. 3.2. 3.3.

4. 4.1. 4.2. 4.3.

5. 5.1. 5.2. 5.3.

Preliminaries Survey From algebraic tb~es to computation structures

Structures and algebras Implementation of types by structures The transition from Imm-valued to three-valued logic Nondeterminate structures as implementations ImpIBmmtation of standard recursions Implementation of descriptive operations Implemmtation of modes with equality predicates

From co~mztation structures to modules Technical r~marks

OEVTREE Devel opmmts Description of additional functions and modules Specific rules

INFERENCE, CLAUSE, and FOR~ Description of auxiliary functions Developments of functions Developments of selected theorems

TERM Infomal description of the match functions Specification of auxiliary functions Developments

Experiences Methodological experiences with transformational developments Experi~es in usir~ the CIP prototype system,, Overall remarks in retrospect

209 209 209 209 210 211 212 213 213 217 219 219 220 220 264 274 276 282 285 333 349 349 350 352 385 385 386 387

Page 8: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

VIII

PART V : TRANSF(]RMATION RULES

i . Remarks about rules 2. Rules for constructs of the scheme-language

2.1. Boolean expressions 2.2. Conditional s and guards 2.3. Applicative level 2.4. Pre-algorithmic constructs 2.5. Procedural level

3. Rules for data types and computation structures 3.1. Maps 3.2. Sets 3.3. Nai~ral numbers 3.4, Conditional join operations 3.5. DEVIREE 3.6. CLAUSE 3.7. F(I~MULA 3.8. TE~M 3.9. INSTANCE 3.10. OPERATOR

4. Technical transformation rules 4.1. Abstraction rules 4.2. Equal ities 4.3. Change of recursion 4.4. Unfold, fold, and renaming

389

391 393 393 400 404 405 410 413 413 414 418 420 430 433 434 435 442 451 452 452 454 455 458

PART Vl : A SAMPLE INSTANTIATION OF I}E SYSIEM FOR A CONCRETE L/~GUAGE

2. 3. 4. 5. 6. 7. 8.

The basic objects and operations of the language Abstract syntax: The ~ LANGUAGE Conversion between external and internal form: Parser and unparser Syntactic and semantic predicates Generating the context conditions Co~uting environment information Inferences for propagating definedness information Two sample transformation rules

465

467 468 472 478 479 481 485 486

REFERENCES

APPEal)IX : BIBLIOC¢~ OF THE PROJECT CIP (CONT.)

INOEX I : KEY NOTIONS INDEX II : TYPES, SORTS, OPBRATIONS INDEX I I I : I~ANSFO~TION RULES

488

493

503 5O6 52O

Page 9: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

PART I

INTRODUCTION

In this part we set out the global requirements for the transfomation system CIP-S. To this end, existing transformation systems and particularly the Munich prototype transformation system are bn'efly reviewed. Based on this discussion, we l is t the new goals we want to achieve with CIP-S and give the overall design decisions for the system project.

Page 10: The Munich Project CIP: Volume II: The Program Transformation System CIP-S
Page 11: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

1.1 Transformational programming assisted by an implemented system

1. Transformational programming assisted by an implemented system

Transformational pFogrammingl) as a n~chedology is independent of specific tools. I t can be done merely with pencil and paper2) , as has been demonstrated in a great number of case studies. However, there are also quite a number of good reasons for aiming at an implemented system that supports the methodology.

By its very nature, transformational program development involves a lot of rewriting according to predefined rules. Usually, this re~t ing affects only small portions of the program under consideration, such that most of the program text remains unchanged when a transformation is performed. I t is obvious, that this kind of clerical work, i.e. copying and rewriting, can and should be done by a mechanical system. In particular, a system is more reliable in such a mechanical activity than a human being.

Using a system, furthermore, enforces p ~ s i o n and formality in program development. A transformation is either applicable or not. Thus, any "handwaving" and "cheating in details" during a development are excluded, which promotes discipline and helps in avoiding silly mistakes.

Since at least the fundamental transformation rules will be permanently available, a system, as a side-effect, provides the user with a compendium of basic methodological knowledge. This knowledge comprises not only the transformation rules proper, but also the purposes for which the rules serve, which may be reflected by an appropriate indexing scheme. Thus, combined with the facility for checking applicability, a transformation system, in principle, could be considered as an "expert system" that not only performs given transformations, but also supports the development process further by making proposals for applicable rules when provided with some goal to be achieved.

As another side-effect, a system can record the development history and thus serve for several further purposes. A full history not only reflects the correctness proof for the final program, but also constitutes a comprehensive sofi~vare documentation. In condensed form, a history may be used as a c o ~ c t description of the essential ideas of an algorithm. A history also may serve as a tool for program maintenance: When, due to altered requirements, the original specification has to be modified, the recorded development can he "replayed" for the altered specification.

2. Issues of transformation systems

There exist a number of experimental transformation systems, differing in various aspects. They are built according to different intentions with transformational programming (e.g. ~ i f icat ion, adaptation, verification, or even synthesis of programs) and cover a more or less wide sector of possible machine support for programming. Apart from the transformation component that exists in every such system, they vary with respect to the data base facilities, input/output mechanisms, the support in documentation or assessment of programs.

Further significant differences concern the organization and the types of transformations. Transformations are either stored in a huge catalog or constructed from a small generative set of fundamental rules. The rules themselves deal with general programming knowledge, with optimizations based on certain language

1) For introductions to the specific view of transformational programming we are dealing with here, cf. [Pepper 84a], [Broy 84], and [Bauer et al. 85].

2) Some people even believe that t)n's is the only reasonable way to do i t (cf. e.g. [Dijkstra 76]).

Page 12: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

1.2 Issues of t ransformat ion systems

features, with data domain knowledge, or with efficiency information.

As to the form of the rules used, there are procedural rules and schematic ones (i.e. replacement patterns). These rules may serve different purposes in the program development process: Locally applicable rules relate language constructs, describe algebraic properties, or express domain knowledge; global rules are used for flow analysis, consistency checks, or representation of programming paradigms; certain semi-schematic hybrids, e.g. fold and unfold (cf. [Burstall, Darlingten 77]), are simply codified programming knowledge.

The particular way of performing the transformation, process (completely user-controlled, partly or fully automatic) and the particular techniques used (e.g. for matching and unification) are further important criteria.

A sirmqar variety is encountered with respect to the languages used. There are pure (non-operational) specification languages, applicative languages, or conventional procedural languages. In particular, there are also languages that cover the whole spectrum from problem description to efficient machine-oriented solutions. Another interesting aspect in connection with languages is the degree to which the system depends on a particular language. There, too, a broad variety is encountered. Some systems are (conceptually) completely independent of a particular language (by e.g. just requiring that there exists an algebraic lanc~age definition), others are specifically tailored to a particular language, and some even incorporate features of the implementation language into the system.

A more elaborate classification scheme and a comprehensive survey on most of the existing systems and how they f i t into this classification scheme may be found in [Partsch, Steinbr~ggen 83].

3. The CIP prototype system

Within the CIP project a prototype transformation system (cf. [Brass et al. 82], [Riethm~yer et al. 85]) has been developed according to the specific ClP view of transformational programming (cf. [Bauer, W~ssner 82], [M~ller et al. 84], [Bauer et al. 85]). Starting from a formal (pre-algorithmic) specification based on suitable algebraic types (cf. [Steinbr{]ggen 80]), the development (by hand) passed half a dozen intermediate versions and ended in a PASCAL program running under CMS on a SIEMENS 7.865 computer and also under UNIX on a Micro-VAX at the Technical University of Munich.

The purpose of this prototype system is the interactive, transformational manipulation of program schemes. (Since concrete programs are but specific schemes, this also includes the transformation of programs in the usual sense. )

In an algebraic view of language definition (cf. [Bauer et al. 85]), program schenms are terms3) over free variables (scheme parameters) for subterms. Due to this view the p r o t o ~ system is independent of a particular language; any algebraically defined language is suited for manipulation (provided that translation functions to and from the internal representation of pFograms are available). Most of the actual work in Munich was done with the PASCAL-variant of the wide spectrum language CIP-L of the CIP Language Report [Bauer et al. 85]. There have also been experiments with a system version using an experimental test language, and a version for manipulations in relational algebra. The system also has been extended to allow

3) Actually pairs each consisting of a term and its environment, i.e. the underl~dng theory in form of an abstract data t~4De.

Page 13: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

1.3 The ClP prototype system

dealing with abstract data types.

Transforming program schemes, with a schematic view of transformation rules as triples of schemes (input template, output template, applicability condition),

not only allows the treatment of concrete programs, but also the formal derivation of new, complex rules within the system. In this way the well-known problems with huge general catalogs are avoided, since a user may derive (within the system) a (private) catalog of more complex rules that are specifically tailored to his individual problem domain.

In addition to these schematic rules, the prototype also admits transformation expressions (sinnqar to the well-known regular expressions), a tentative "meta-language" for expressing program developments (cf. [Steinbr~ggon 82]). By this possibility of formulating "transformation tasks" to be performed by the system, the rigorous ClP viewpoint that transformation rules are exclusively selected by the user (and thus the system lacks any built-in strategies or other means for automatic search of transformations) remains practical.

In addition to the conventional approach to schema parameterization the concept of context parameters has been developed (cf. [Steinbr~ggen 81]). I t allows marking fragmentary terms ("contexts") as being replaceable. By this concept a whole class of rules that differ only in varying contexts may be expressed by one single rule.

A typical example is a rule that expresses the d is t r ibut iv i ty of the i f-then-else construct over varying contexts:

F[if C then A else B fi]

C i f C then F[A] else FEB] f i

(where F is a context parameter and A,B,C are usual scheme parameters).

The application of this rule to a piece of program such as x : = i f x~O then 1 e l s e - 1 f i

yields i fx~O then x := 1 else x : = - I fi.

In the algebraic view, context parameters are free variables for term-building operations, and thus a second-order principle; with respect to semantic correctness they have to be handled with extreme care.

In the above example no problems arise, i f F is a function (or procedure) call or the l e f t side of an assignment; i f F is a (complete) statement or another conditional, C must not depend on F.

Of course, besides the proper transformation component (cf. [Erhard 81]) the prototype system also provides the usual functions such as access to files for rules and program versions, or a dialogue subsystem for communication with the user (cf. [Riethmayer 81]). However, the prototype lacks an elaborate faci l i ty for documentation as well as a system component that assists t ~ user in the verification of applicability conditions.

The prototype has been used for experiments by its creators, within students' programming courses, and to verify parts of i ts own development. Its main role, however, has been to serve as the major software tool in the development of the definitive transformation system CIP-S presented in this volume.

Page 14: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

1.4 Informal overview of CIP-S

4. Informal overview of CIP-S

The purpose of the (definitive) system CIP-S is the transformational development of program schemes. This includes manipulation of concrete programs, derivation of new transformation rules within the system, transformation of algebraic type (scheme)s, and verification of applicability conditions.

Apart from an appropriate component for dealing with transformations, the system support includes interactive input/output, data base facilities for programs, rules, types, and transformation programs, and an advanced documentation component. For the practical assessment of programs, links to an already implemented compiler for (executable) CIP-L and to a rapid prototyping system for algebraic specifications vnql be provided; further system components, e.g. a type analyser, are still under consideration.

As to the organization of transformations, in principle the generative set approach is favoured. According to the language definition, the basic rules ~nql include general principles (such as unfold, fold, etc., cf. [Burstall, Darlington 77]), the definitional rules of the language (cf. [Bauer et al. 85]), and the axioms and inference rules of the predefined types. In addition to this basic set, some frequently used derived rules about language constructs, and a few general techniques concerning control constructs, e.g. embedding, elimination of non-determinism, recursion removal, or tabulation techniques, as well as standard implementation techniques for abstract data types, ~nql be made available.

This permanent set of rules is intended to provide the user with a solid basis for deriving further rules that he considers useful for his particular problem domain. The system guarantees that all rules that are inferred within the system are correct wrt. the initial collection of rules. Of course, for all other rules, the responsibility for correctness rests with the user.

Basically, the rules in the system are schematic rules over which more complex rules may be formulated as transformation al~orithms. These algorithms also serve for partly automating the basically user-controlled transformation process.

There are several languages involved in the system design. As the object language, i.e. the language for formulating program schemes, an algebraically defined language is assumed. As the meta-language for formulating transformation algorithms we envisage a simple applicative language; as the language for enabling conditions we use simply predicates over terms of the object language.

The intended running implementation vaTl work with CIP-L as its object language, and with a suitable subset of CIP-L as the language for transformation algorithms. CIP-L has also been used for the formal development from high-level, descriptive specifications of CIP-S dewn to machine-oriented features, and PASCAL (or C) ~nTl be used for the actual running version.

5. Global requirements

There are a number of global requirements concerning the system project as a whole.

The system should be portable (on the basis of a widely used implementation language), and adaptable to different hardware configurations and operating systems with reasonable effort. In particular, the system design and implementation should be flexible enough to allow also an adaptation of (the essential parts of) the system to a suitable personal computer, or an incorporation of comfortable input/output devices (e.g.

Page 15: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

1.5 Global requirements

graphical d~splay, double screens, "mouse", etc. ).

In order to enhance practicability of the system, the user environment of the system should be as comfortable as possible. Within reasonable bounds it. should also support different users' habits (e.g. allowing sets of keywords in different languages, etc. ).

Similarly to the prototype system, the core of the (new) system should be conceptually independent of a particular language. This means, in the f irst place, that the system must not depend on a specific language for formulating programs; then for any algebraically defined language special "variants" of the system should be derivable with reasonable effort. This means also that the other languages used in the system, ~.e. for operating the system and for forn~lating transformational tasks should be exchangeable as well. Of course, the standard implementation of the system ~nql use the wide-spectrb~ language CIP-L of the CIP Language Report [Bauer et al. 85] in Its ALGOL or i ts PASCAL variant.

Finally, the system should be extensible (concerning e.g. user environment, data base access, type transformations, etc. ) in a reasonable manner, in order to allow the integration of future (theoretical and methodological) knowledge. Furthermore, the system should not be "stand-alone", i.e. i t should be usable in combination with other tools from an existing programming environment.

In order to make sure that the final CIP-system really meets i ts specification, the transformational approach to software production has been adopted in this report. Thus, adaptability to other implementation languages will result as a by-product, since switching to another implementation language "simply" means branching at a certain development stage and transformation into another direction. Extensibility is achieved by structuring the specification and the respective developments as much as possible; language-independence results from a suitable parameterization. Consequent use of these latter two techniques also provides the basis for a modifiable user environment and thus the fundament for practicability. The report thus presents an exan~le of an advanced software production method which can be used quite generally.

6. Some aspects of an appropriate user environment

In this section, some aspects of an appropriate user environment are discussed. By user environment we denote the component of a transformation system which bases on the primitive operations of the system-core and provides the environnmnt in which the user is actually working. Only a "super-user" ~n]l be allowed to make modifications to this environment, for example in order to construct a new user command out of the primitive core commands. The functional requirements given here represent a maximal set of features of a user environment. They have evolved from the experiences made when the developments, which are partially given in Part IV, were performed with the prototype transformation system.

An implemented system, which is supposed to be used as a software development tool, has to offer at least the possibilities one has with pencil and paper. Hence, i t has to support each individual step and task which may occur in a program development. The starting point of a formal development consists of a f i rst formal specification and possibly certain ideas for an algorithmization. How to obtain such a specification is a matter of requirements engineering. The implemented system can aid the formulation of a f i rst formal specification by offering the following facilities:

Page 16: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

1.4 Informal overview of CIP-S

- A basic stock of standard data types that are frequently used at the specification level. A f i rs t set of such types is given in [Bauer et al. 85], pp. 75-84.

- Various surveys over the collection of these types, such as of the set of types, the signatures, sorts, and operations of individual types, the laws of individual operations, the relations among the t~pes (e.g. hierarchy structure, implementation relation).

- Support for modifications of already available types, e.g. . enrichment, restriction,

renaming and other purely syntactic changes, . additional parametrization, - instantiation. Support for the instantiation of a type, together with the instantiation of the transformation rules gained from its laws.

This sort of system support facilitates the formulation of specifications, since the necessary data types are either already available or obtainable by modification of available ones.

Having fixed a formal specification one typically tries one or several alternative development drafts consisting of rather big steps. A transformation system can help in the following aspects:

I t can provide a basic stock of quite schematic transformation rules which express general programming techniques or strategies such as "divide and conquer", "formal differentiation", "embedding", "recursion removal", "backtracking", "function tabellation", "function inversion" and others; The selection of rules and techniques ("desi~ decisions") is a central task in program development. An implemented system can take care of the following parts: • various surveys over rule catalogs, rules, and techniques, . search of syntactically applicable rules, - graphical presentation of a rule application, i .e. showing the instantiation obtained by the matching

process, showing those scheme variables which are not instantiated by the matching ("indefinite rules", cf. 11.3.1.) and must be instantiated by the programmer, showing a selection of the instantiated applicability conditions of the rule application.

• tentative application of different techniques in parallel without the need for backtracking each time in the development history

The trial of different strategies and the selection of applicable rules demand a graphically expressive representation of the various program- and specification versions as well as of the transformation rules. This means in detail: • exploiting graphic facilities of the hardware . external representation of terminal sy~ols of the progra~ng language in graphical form, i.e.

without auxiliary representations (e.g. quantifiers, operator symbols, boldface for key-words, diverse kinds of parentheses etc.)

• syntax oriented pretty printing I t was the lack of these facilities which caused the most trouble when performing the developments of Part IV with the prototype (cf. IV.5.2.) . Transformation rules should allow external representations of different degree of detailization, e.g. • formal, complete, • without the less essential applicability conditions (such as context conditions and syntactical

Page 17: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

1.6 Some aspects of an appropriate user environment

conditions), which should be verified by the system itself anyhow, . informal, descriptive Since f i rst development drafts consist of comparatively big steps, there must be possibilities for annotating developments and individual steps, for example with the technique applied, the design decisions, or the desired goal. Typically, drafts contain more or less big gaps. The transformational appFeach allows at least the following three formal possibilities for them:

"open transition" between t~o program versions by use of "claims" (cf. II.3.5.), i.e. transitions yet to be verified,

• postponement of the ~uc t i on of applicability conditions (cf. I I .3 .4 . ) , • use of completely non-deterministic object, functions, procedures, statements etc., which are refined

to more deterministic ones at a later stage.

In the course of a development i t is in general necessary to backtrack and to continue with an earlier program version. Once one or several development drafts exist, they will be detailed or modified selectively. This also includes a return to previous development steps.

In both cases, the programmer has to cope with pretty co~Dlex (tree- or graph-like) and voluminous objects such as developm(mt histories. This calls for extensive system support. Besides the possibilities modern hardware combined with window-systems offers, further support by the user environment of a transformation system is possible purely due to its functionality.

I t should offer various ways of browsing through (parts of) developments: • scanning of individual paths ("depth scanning"), to survey single specific developments, • scanning the breadth of a node in the development tree ("breadth scanning"), to survey alternative

design decisions, graphical presentation of automated replays of (parts of) developments allowing the programmer to determine the further direction and to interfere for annotations, modifications, or compressions,

• parallel presentation or replay of alternative developments (e.g. in different windows of the screen). Developments should also have different external representations with varying degree of detail just as rules have. Thus individual transformation steps could be represented with/without • the applied rule in specified degree of detailization • the program versions involved • not yet verified applicability conditions or "claims" • annotation The browsing through developments should allow the following user interactions, for example: • selection of "open transitions" for detailization (i.e. verification and reduction of claims and

applicability conditions, respectively; transition to more deterministic descer~nts) - selection of leaves in the development tree for melioration • instantiation of scheme vaFiables in the case of indefinite rules

Since the tasks performed with a transformation system can be quite complex and large, the pFogrammer must be able to obtain information on the state of the system at any moment. Minimal but permanent information can be given by a system line. However, i t must allow to obtain more and more detailed information on demand, for example about the

• stack of act iv i t ies • catalogs

Page 18: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

10

1.4 Informal overview of CIP-S

• program units • developments - claims etc.

In general, the screen should not contain too much state information in the normal mode. Hence, the state should also allow various external views. Since a transformation activity is usually highly interactive (computer-aided, intuition-guided), the interaction should be fast, convenient, and require l i t t le typing. This means that modern facilities like window- and menu-techniques, mouse etc. are recommendable.

Page 19: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

PART II

THE TRANSFORMATION CALCULUS

In this part we present the logical calculus that underlies the transformation system; i t is a very particular calculus streamlined to meet the needs of program transformation. Although a formal calculus is needed as the basis of such a system, this very fact shall be hidden from the actual user; to him, each activity shall have the appearance of a goal-directed transformation step or of a step in reducing applicability conditions, but net of a proof step in a calculus. Therefore we show how typical transformation tasks can be expressed as derivations within that calculus.

To ease both understanding and implementation we have decided to keep the calculus as simple as possible. In particular, we content ourselves with just two levels of nested Horn clauses rather than working with arbitrary nesting; moreover, we use special "scheme variables" and "indeterminates" instead of arbitrary universal and existential quantification to avoid the associated technical problems with binding and scoping. A thorough comparison with classical logical calculi can be found in [Pepper 87].

Page 20: The Munich Project CIP: Volume II: The Program Transformation System CIP-S
Page 21: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I . i Introduct ion

13

1. Introduction

Program transformation means the stepwise development of programs

TI T2 Tn Po > PI > P2 > . . . . > Pn-1 > Pn

where the individual transitions T i : Pi-1 --> Pi are done according to st r ic t ly formal rules. In this part we present a formal calculus that allows us to specify the central activities that take place during such a transformational program development.

Consider the following transformation rule which codifies a standard technique for "recursion removal". We use here the PASCAL-variant of ClP-L (cf. [Bauer et al. 85]). A[x], B[x], etc. stand for arbitrary expressions that possibly contain free occurrences of the identi f ier x. The notation of transformation rules again is taken from [Bauer et al. 85].

f ~ o n f ( x : m lIP[x] ) : r; i f B[x] then D[x]

else E[A[x], f(C[x])] endif

fimction f ( xO : m {I P[xO] ) : r ; i f B[xO] then D[xO]

else (vat x : m, vat z : r) : : (C[xO], A[xO]) ; while ~ B[x] lonp (x, z) := (C[x], E[z, A[x]]) e~oop ;

E[z, D[x]] ~gi f

[FTl, Ex~ = E[E[a,b],c]

The above rule states that the original declaration of the function f can be replaced by the new declaration, provided that the expression E allows re-bracketing. The predicate NEWIFz]] actually is an abbreviation for a collection of predicates NOTOCCURS[[z in B]], NOTOCCURSIFz in D]], . . . , which together guarantee that no name clashes are introduced.

To demonstrate the application of such a rule, we consider the following function that searches the least element of a nonempty sequence:

f ~ - % i ~ minsearch ( s : sequ II length(s) > 0 ) : elem ; i f length{s) = 1 then f i rs t (s )

else rain(f irst(s), m~nsearch(rest(s))) e~ l i f

A matching of the input template of the above rule with this program yields the instantiation

g = { f "= minsearch, x "-- s, . . . , E[x, y ] =" min(x,y), C[x] --" rest(s) } .

Here, the notion of instantiation is the usual one that is known from unification problems; see e.g. [Robinson 65], [Manna, Waldinger 81]. So from applying the rule we obtain the new program

Page 22: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

14 I I . I Int roduct ion

f~mcticm minsearch ( sO : sequ II length(sO) > 0 ) : elem ; i f length(sO) : 1

first(sO) else (vat s : sequ, varm : elem) := (rest(sO), first(sO)) ;

while ~ length(s) = I ](mp (s, m) := (rest(s), min(m, f irst(s))) endloop ; min(m, first(s))

m~lif

This transition is correct, since min is indeed associative; that is, the instantiated applicability condition

V a, b, c: min(a, rain(b, c)) ~ min(min(a, b), c)

holds.

There are also transformations that depend on knowledge from surrounding expressions. This can sometimes be specified with the help of slightly more complex applicability conditions: Consider the transformation rule

i f B ~ El else E2 e ~ f /

f B ~ true --> E1 - F1 l \ B false --> E2 - F2

i f B then F1 else F2 endif

for determinate B. To bring this into the form of an inference in a logical calculus we write this rule as

--> DETF~INATE rF B~

B - true --~ E1 = F1

B - false --> E2 - F2

--> i fB i~emEle ]seE2e~ i f - i f B t h e n F l e ] s e F 2 e ~ f

From this vie~oint, in the sequence

Tn Po T1 ....> P1 T2 > P2 > " " " ~ ' > Pn-1 > Pn

a transition from program Pi to program Pi+1 now is read as the application of the inference

"Pi is transformable into Pi+1"

with a set A i of applicability conditions. Here, "is transformable into" usually means "is correctly implemented by"; in the example above we used the semantic equivalence : as this relation. The presence of

sets A I . . . . , A n of applicability conditions now means that A I U . . . U A n is the set of hypotheses to be verified in order to show the validity of these transitions.

Page 23: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

11.1 Introduction

15

In the sequel, we present a formal calculus that allows us to define precisely the basic activities that take place in a transformational program development, viz.

o application of a transformation rule; o verification of applicability conditions; o derivation of new rules; o use of induction principles.

Thus the calculus serves as part of the requirements specification for our transformation system.

The calculus aims above all at a unified treatment of the actual transformation steps and of the verification of applicability conditions. Moreover, in order to admit the derivation of new transformation rules from existing ones, the calculus also allows the transformation of program schemes rather than just of programs. In the development of this calculus, our design choices are constrained by the following i ~ requirements:

o The calculus must not become unduly complex. o The resulting system must be sound and robust.

This latter requirement means that the system should prohibit the derivation of invalid results rather than rely on a disciplined use by the programmer. This constraint sometimes conflicts with the f i rst one, which states that we should e.g. avoid predicate logic when propositional logic will do, or that we should abandon full propositional logic when positive implicational logic suffices. The calculus presented below is a compromise between these two goals. I t can be seen essentially as a system of two levels of Horn clause logic, that is, as a Gentzen-like (intuitionistic) system, or as a system of "consequence logic" in the sense of [Lorenzen 55].

The remainder of this part is organized as follows: Section 2 introduces the basic notions of this calculus, such as "term", "formula", "clause", "inference", and so forth; the treatment is based on an algebraic view of programming languages. Section 3 discusses the realization of transformation tasks within the calculus. Section 4 shows how the major induction principles available in Computer Science, viz. computational induction and its derivatives as well as several variants of structural induction, can be expressed in the calculus. Section 5 summarizes and discusses the calculus.

2. Definition of the calculus

In this section we define the syntactic constructions of our calculus as well as the admissible deduction rules. The semantic intuition behind the various constructs is given only informally; a more formal treatment can be found in [Pepper 87].

2.1. An algebraic ~ew of programs and trmsfomatims

In connection with the semantics of programming languages and in particular with program transformation, algebraic techniques have turned out to be most valuable. We merely sketch here those aspects that are relevant for the following considerations; for details we have to refer to the literature, e.g. [Goguen et al. 77], [Broy et al. 81, 82].

Page 24: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

16 11.2 Def in i t ion of the calculus

2.1.1. Signatures and terms

We view the syntax of the programming language considered as a signature, and thus program parts as terms over that signature corresponding to abstract syntax trees. For example, the program fragment

Wm']e x>Oloopx :=x - y ~

corresponds to the term

loop(apply(gt, x, zero), assign(x, apply(sub, x, y))).

Thus, we start from the following algebraic basis: o PL is the signai~rre of a programming language (in the sense of [Goguen et al. 77]); o V is a (countable) set of symbols, called scheme variables; o X is a (countable) set of symbols, called i ~ r m i n a i ~ ; o a program is a well-formed term from the term algebra W[PL]; o a program scheme is a well-formed term from W[PL; V U ~. o an instam~iation O : V --> W[PL; V U~] assigns terms to scheme variables; tO denotes the application of

O to the schen~ variables of term t; that is, for a term t containing the scheme variables Xl, ..., x n

the term t8 has the form t ~ t I . . . . . t n for x I . . . . . Xn]] , where t i = 8(xi). o a subsi~i~i~on ~ : V UX-->W[PL; V U ~ assigns terms to scheme variables and indeterminates; tG, the

application of C to a term t, is defined analogously to tO. C is called a ground substii~Jtiom i f for all u e V U~wehaveO~u) e W[PL],i.e. ~u) is a ground term.

Remarks • - The distinction of V and )~ has mainly technical masons (see Section 2.5): Instantiations 8 are

restricted to scheme variables from V. The indeterminates from )~ are used to give a simplified treatment of universal quantification.

- We use the notion "term" for programs as well as for program schemes. - We admit only instantiations tO that ~eld well-formed terms.

Semantic interpretation: We presuppose the existence of a s e m ~ c ~ 1 for the progran~ning language considered, viz. a PL-algebra M (in the sense of [Goguen et al. 77], [Broy et al. 82]); by pM we denote for a well-formed program term p i ts semantic interpretation in M.

Notation: We le t a, b, c . . . . , r, s, t range over terms from W[PL; V U~ , u, v, . . . , z range over scheme variables from V, and C~ ~, . . . , ~ range over indeterminates from X.

2.1.2. Formulas

Now we add the level of formulas over terms. A fomula is of the form

PITt I . . . . . tn]]

where P is a prt~ficai~ ~ I of ar i ty n, and where t l , . . . , t n e W[PL; V U~ are terms ( i .e. program

schemes). I f the t i are ground terms from W[PL], the formula is called a ground formula.

Page 25: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

11.2.1 An algebraic view of programs and transformations 17

For an instantiation (~ we set

P~ t I . . . . . tn]]~) = PEt I8 , . . . . tnS]] ;

analogously we define P~ t 1 . . . . . tn ] ]6 for a substitution 6.

Semantic interpretation: The definition of the predicates P and their interpretations pM in the semantic model M is again part of the definition of the underlying programming language. We say that a ground formula P~ t l , . . . , tr i l l holds

i f (~ , . . . , ~ ) e pM. A formula A is valid i f for all ground substitutions Cthe ground formula AChelds.

Notation: We let A, B, C, . . . range over formulas, and/A, ~ . . . . over l ists (i.e. conjunctions) of formulas.

Conceptually (and pragmatically), one may distinguish between "syntactic predicates" that are defined over W[PL], and "semantic predicates" that are defined over the semantic model M. The former are generally decidable, whereas the lat ter usually are not (cf. [Broy et al. 82]). The following l is t il lustrates syntactic and semantic predicates. Note that we also use mL~ta-<~rai~, i .e. auxlqiary operators of functionali~ W[PL] --> W[PL] that compute certain attributes for terms. Moreover, we use an equali~ symbol and (f inite) sets. For further details on syntactic and semantic predicates we refer to [Bauer et al. 85] and [Broy et al. 80a, b].

T)~pical ~ntactic predicates are

o OCCURS~[x in t ] ] <<The identifier x occurs free in the term t. >>

o m = KIND[[E~ <<The expression E has kind m. >>

o F : DECLAP~ATION E f]} <<The identif ier f has the term F as the right-hand side of i ts declaration. >>

o USEDVARS[[p]] =- {v I . . . . . Vn} <<Procedure p uses at most the global variables Vl, . . . , Vn.>>

The most important semantic predicates are

o E~IVALENT[[tl, t2]l , also denoted t I -z t2

<<The programs t I and t 2 are semantically equivalent. >>

o DESCENDANTI~tl, t211 , also denoted t I _]D t2 << The possible values of the (non-deterministic) program t 2 form a subset of the possible values of t I

(cf. [McCarthy 63]). >>

o WEAKER[[tl, t21l , also denoted t I [ t 2 << The interpretation of program t I is weaker in the approximation ordering than the interpretation of

program t 2 (cf. [Scott 70], [Manna 74]). >>

Page 26: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

18 11.2 Definit ion of the calculus

o DEFINED IF t l l <<The interpretation of program t always yields a defined value. >>

o DETERMINATE [[ t]D <<The interpretation of program t yields a uniquely determined value.

o CONTINUOUS[[cn[.]ll << The interpretation of the context cn[.] is continuous with respect to the approximation ordering

considered. >>

The bina~ semantic predicates EQUIVALENT, DESCENDANT, and WEAKER are the genuine focus of attention in a transformation system, since they realize the transitions Ti: Pi--> Pi+l. By contrast, the additional

semantic predicates DEFINED, DETERMINATE, CONTINUOUS, and so forth are less amenable to treatment within the framework of such systems. Therefore one often uses corresponding syntactic predicates that are at least sufficient to guarantee the desired semantic properties. So DETERMINATE can be guaranteed by the absence of nondeterministic operators, and DEFINED by the absence of recursion/iteration and partial operations; CONTINUOUS can be deduced from the fact that certain language constructs are known to be continuous (as part of their semantic definition) and that the composition of continuous constructs is again continuous. Note that the semantic predicates DEFINED and DETERMINATE are closely related to the "equality test" . =. (which is a strict, boolean-valued operation); for an expression e we have

(e = e) ~ true i f f DEFINEDTFe~ A DETERMINATE~e~ ,

since for undefined e the equality test yields ~ and for nondeterminate e i t may yield true as well as false.

In the transformation system, for simple equations such as

m : KIND I]E II or F = DECLARATION [[ f l l ,

where the left-hand sides are scheme variables and the right-hand sides are applications of (language-dependent) meta-operators, the respective instances are to be calculated automatically rather than to be recNested from the user.

Whereas i t is the purpose of a transformational program development to establish or.e of the semantic relationships (~, -]D, _[ ) bel~een the initial version Pl and the final version Pn of a given program, the syntactic predicates are only needed in certain applicability conditions, mainly in order to guarantee that context conditions are observed. Although i t is possible to specify these axiomatically, e.g.

OCCURS[Fx in Bll --> OCCURS[Ix in i f B ~, E else F endlfll,

they ~nTl in practice be implemented by simple (recursive) algorithms over the terms from W[PL].

The only complication arises, when program schemes from W[PL; V U ~ are to be transformed. Then the evaluation of a predicate like OCCURS[Fx in t l l ~nll usually not yield true or false but rather one or more predicates OCCURS[[x in t l l l , . . . , OCCURS[Fx in tnll for subterms t i of t, the conjunction of which is equivalent to the original predicate. Thus, in this case the applicability conditions cannot be completely verified, but only reduced to simpler ones.

Page 27: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I .2.2 Clauses 19

2.2. Clauses

Since we want to model the notion of transformability and not to invmt a system for program verification, our calculus is a "constructive" one: The basic statements in our calculus are of the form "a certain fact is derivable under certain assumptions" rather than of the form "a certain fact is valid under certain assumptions". In this context i t does not make sense to work with the negated form "is not transformable into" or with the ambiguous form "is transformable into ... or into ...". Moreover, we can always introduce suitable pairs of predicates such as e.g. DEFINEDFF...~ and UNDEFINED r[ ... ]] (as is usually also done in PROLOG-pmogramming).

Therefore we exclude negation and disjunction and define: A clause is of the form

A1, ..., A n --> B (or short: /A --> B ),

where At, ..., An, B are atomic formulas. The formulas in the set /A = {AI,...~ n} are called the ani~ect~Jents, the formula B is called the consequent of the clause.

For an instantiation g we define

(A1, ..., A n -~ B)E) = AIB, ..., AnO --> BE) ;

analogously we define (A1, ..., A n --> B)¢ for a substitution ¢.

Semantic Interpretation: A clause At, ..., A n -~ B is valid i f for all ground substitutions Cfor which A1¢, ..., AnChold, also Be holds.

The following l is t of examples shows that not only classical transformation rules can be expressed as clauses.

[1] DEFINEO~x]] --> EQUIVALENT~COnd{x#6,), y]~

[2] DESCENDANT~x, y~D, EQUIVALENT[Fy, zll --> DESCENDANTI[x, zll

[3] DEFINEDI~x]], WEAKER[Tx, y]] --> DEFINED[[y]]

[4] OCCURSIFx in r~ --> OCCURS[[x in cond(r,s,t)]]

[5] --> KINDI[apply(f, a)~D = RESULTKIND[Ff~

The soundness of all these assertions must be established by the semantic definition of the programming language under consideration. (Note that [3] only holds in fiat domains.)

Notation: We let o<, p, I . . . . range over clauses, and ~ ~ . . . . over sets of clauses. As usual, the symbol "," binds tighter than the ~/mbol "--~'.

Page 28: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

20 11.2 Definition of the calculus

2.3. The calaJlus of inferences

Next we want to set up rules that allow us to derive new valid clauses from given ones.

An inference is of the form

All, ..., Aln I --> B 1

Aml, . . . ,#~m --> B n (short: or - - )

A I . . . . . A n --> B p p

where the ~ i . . . . . cK m, ~ are clauses. The clauses o( i in the set ~ = {~ l , . . . ,~m} are called i ~ s e s , the clause p conclusi~.

Interpretation: An inference

cK

is valid i f for all ground substitutions C for which ~ holds, also ~ ~ holds.

There are three basic, language-independent valid inferences which essentially date back to [Gentzen 34].

[ I ] Tautologies:

( i ) A - - ) A

[ I I ] Extension of the antecedent:

( i) • -->C

/A, IB -->C

[ I I I ] C~ (modus ponens):

(i) /A --~B B, ]B --> C

/A,B ~ C

Note that/~ and ~ stand for sets and thus may be empty.

A first example of a language-dependent inference has already been given in the introduction. Other examples are induction rules, e.g. for the data type SET:

Page 29: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

11.2.3 The calculus of inferences 21

--> P IF emptyset II -> PI[singleton( R) ll P~CL~, P[[~ --~ P[[union(~, ~)ll

-~ P~w~

where P [[w~ denotes a forn~la in the scheme variable w, for instance union(r,w) = uhion(w,r) . Note the use of indetern~nates and scheme variables in the above rule (which is explained in Section 2.5).

But also elementa~ transfor~tions can be given in the form of inferences rather than in the form of clauses:

--~ DEFINEI) [[ b~

--> cond(a, cond(b,r,s), u) ~ oond(b, cond(a,r,u), cond(a,s,u))

2.3.1. Meta-deductions

We can make the inference rules into formal objects themselves. This way we ebtain a calculus in which we can formalize the derivation of new inferences from given ones.

Let p be a given basic set of clauses and let IT be a set of inferences. Following e.g. the terminology of [Kleene 52] or [Enderton 72] we define as a dt~L-t i~ (from the hypotheses I ~ according to the inferences IT) a sequence /~ = < ~ i , " " , an> of clauses such that for eve~ k, l<k~n, either

(i) the clause ~k e ~, (ii) the inference

or

~ i I

a i m

~k

is in ~, ~th l<_ij<k. (That is, the clauses ~ i l , . . . , aim occur before ~k in the deduction

sequence A. )

So a deduction consists of clauses that are in the set F ~ of hypotheses (step (i)) or that are i~mmdiate consequences wrt. IT of preceding formulas in the sequence (step ( i i )) .

Notation: We write

A : P FIT

to express the fact that A is a deduction of the clause ~ from the hj~Dotheses p vat. inferences IT.

Page 30: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

22 11.2 Definition of the calculus

2.3.2. Meta-inferences

Next we want to set up rules that allow us to derive mew inferences from given ones. Following [Lorenzen 55], we call such a rule [R] "admissible" i f any deduction ~ involving the new inference generated by [R] can be translated into a deduction A' that only uses the old inferences. This means that rule [R] points out "shortcuts" for clause deductions. More formally this can be expressed as follows:

Let [R] be a rule that yields an inference Q from inferences QI, " ' , Qn- We write

[R] From QI . . . . . Qn infer Q.

and call [R] a m e t a - i m ~ . [R] is admis~l)le, i f f for any set of clauses I ~, set of inferences IT, clause ~ and deduction A with A : F ~ ~'IT ~ there exists a deduction A' such that A' : I ~ ~-IT' ~,where IT' = ( I T \ { Q }) U {Q1 . . . . . Qn}"

There are four basic ac~nissible meta-inferences. Rule [IV] connects the ~ levels of inferences and meta-inferences.

I l l Tautologies:

( i i )

This is an axiom schema for the meta-calculus.

[ I I ] Extension of the premise:

( i i ) From infer

[ I I I ] Cut (n~xJus ponens):

( i i ) From and infer

[IVa] Importation:

From

[IVb] Exportation:

C-->B infer

/A-->C A ,B , C --> C

C-->B From infer

/A,B, C --> C /A, C --> C

Page 31: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

11.2.3 The calculus of inferences 23

In addition to these general rules, there is one further meta-inference that is oriented towards our underlying notion of program schemes:

[V] Instantiation:

F~om infer c~ ~(~

where 0 is an instantiation of scheme variables by terms.

Note that/A and • as well as ~ and V stand for sets and thus may be empty.

The admissibility of the above meta-inferences is shown in [Pepper 87].

In the practical realization of a transformation system these meta-inferences should be realized by basic algorithms of the system, since then in particular there is no general schema matching on th~s level and consequently no need for "variables for clauses" and the like.

2.3.3. About higher-level rules

Our clauses represent a "calculus of level 1", and the inferences represent a "calculus of level 2". Both levels are connected to each other through the rules [IV a,b]. Obviously, the same kind of relation holds again bei~een inferences and meta-inferences. So the meta-inferences (the logical connective of which is written here as "from ... infer . . .") form a "calculus of level 3", which is related to the calculus of inferences by virtue of meta-meta-inferences analogous to the rules [IV a,b].

This construction can be continued to an arbitrary extent, leading to the "consequence logic" (German: Konsequen2kalk~l) of [Lorenzen 55]. Our specific application area (namely that of program transformation) allows us, however, to stop at level 2.

2.3.4. Relationship to further proof principles

So far our only proof principle is that of "modus ponons" (cf. rule [ l l l ( i i ) ] ) . However, in mathematics there are further important proof methods such as "modus tollens", "reductio ad absurdum" or "case distinction" (see also [Gentzm 34]).

Reductio ad absurdum (proof by contradiction):

From and infer A-->B A--~ ~ B --> ~ A

Modus tollens:

From infer A-->B ~ B - - > ~ A

Page 32: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

24 11.2 Definition of the calculus

Case distinction:

From - and and --> A V B A --> C B --> C

i nfer -->C

We cannot include these rules into our calculus, since we do not even have the negation symbol "~" disjunction symbol "V" at our disposal.

or the

2.4. Derived m e t a - i ~

We have kept the basic meta-inferences in Section 2.3 as simple as possible in the interest of easier readability. But in practical applications i t is interesting to have more flexible variants available.

2.4.1. Language-independent derived meta-inferences

The following derived (in the sense of [Manna 74]) meta-inferences form an equally expressive system. For the derivation of these new meta-inferences see [Pepper 87].

[11"] Extension of selected antecedents:

/A --> A ~, C --> A From infer

IB --> B ]B, C --> B

More generally, one can add antecedents to the conclusion and simultaneously to zero or more premises. Note that an extension in the conclusion is always possible (according to [ I I ( i ) ] ) , whereas an extension in a p~mise necessitates a simultaneous extension in the conclusion.

[111"] Modified Cut:

From / A - ~ A

[IVa*] Modified Im~ortati~:

! D ---~ A

F r ~

1B --~ C

/A,]B ~ A

and in~r

J l

infer A, IB --> C

2.4.2. Language-dependent derived meta-inferences

The predicates (such as EQUIVALENT, DETERMINATE, etc.) that are defined as part of the semantic specification of the programming language considered exhibit certain properties that can be represented in the form of (lan~age-dependent) clauses or inferences. The most important of these pFoperties are

Page 33: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I . 2 .4 Derived meta-inferences 25

transitivity and monotonicity (see e.g. [Broy et al. 81]), which can be represented in the form of clauses.

Due to their distinguished role, certain axioms may be "lifted" to the level of "derived meta-inferences" (in the sense of the previous section). The envisaged transformation system should contain procedures that apply such axioms automatically, either forward (program derivation) or backward (reduction of applicability conditions).

[Vl] '~Fransitivity" in conclusions (language-dependent): For illustration we consider the combination of the predicates "--]D" (i.e. DESCENDANTFF.,.]] ) and .

=. (i.e. EQUIVALENT{[ .,. l l ). By virtue of Exportation and Modus ponens the language axiom

r = s, S_]Dt --> r_ ]D t

leads to the meta-inference

From and infer /A ~ r~s • -->S_]Dt /A, • --> r_]Dt

[VI I ] "Fransitivity" in premises (language-dependent): As before, we consider the combination of the predicates "--]D" and . = ., but now applied to premises rather than to conclusions. The same axiom as in rule [VI] gives rise to the meta-inference

jA ~ r_]Dt ~ /A --> S_]Dt From and infer

cK ]B - -> r - s

[V I I I ] Monotonicity (language-dependent): All language constructs should be monotonic with respect to the relations . = ., "_]D', "_[" (see [Broy et al. 81]). So we have for exan~le the language axiom (for any context cn[.])

r --]D s --> cn[r] _]D cn[s] ,

which yields the corresponding meta-inference

From infer IA --> r_]DS /A --> cn[r] -]D cn[s]

for any context cn[.] from W[PL ;V U

One gets variants of these meta-inferences for every possible combination of predicates like DESCENDANT, WEAKER, and E~IVALENT - provided "transitivity" actually holds. In other words, these meta-inferences realize applications of the following axioms:

Page 34: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

26 11.2 Definition of the calculus

r ~ s, s ~ t --> r ~ t , r ~ s, s ] D t --> r ]D t , r o s , s_[ t -~ r [ t;

r [ ' s , s [ t ~ r [ t .

Si~n]arly, we can express properties of unary predicates such as DETERMINATE or DEFINED. As examples we give the following claoses:

DE~INED[Fr~, r -= s -~ DEFINED[[s]], I]EFINED~s]], r = s --> DEFINED~r~, DEFINED[[rlI, r [ s --> DEFINED[Is11, DETERMINATEEr~, r ~ s -~ DETEI~INATEEsI~, DEEI~INATEEs3, r =- s --> DETERMINATE[[r~, DETERMINATE[[rl], r ] D s --> DETEI@IINATE~s~

The importance of the derived rules Vl to V l l l lies in the fact that the focus of attention in a transformation system is the derivation of new programs from given ones. In our terminology this means the establishment of inferences of the kind

, , or /A -~ r~s /A --> r]Ds /A -~ r [ s

The derived meta-inferences VI to VII I just show, how such inferences can be combined with other inferences or how they can be used in the reduction of premises to simpler ones (that is, in the reduction of applicability conditions). Rule VIII is the basis for local transformations, i.e. for transformations of program parts rather than always of complete programs.

2.5. The role of free variables

I t is well known from studies in formal logic that free variables have to be handied with great care (see e.g. the extensive discussions in [Kleene 52], pp. 94-151, or in [H17bert, Bernays 68], pp. 86-94 and 150-154). The point is that the free variables must remain unaffected throughout a complete proof. To see the problem, we biefly present a wrong derivation:

As has been demostrated in the introduction, there are transformation rules that rt~luire certain algebraic properties as their applicability conditions. So let us suppose that we could infer the equivalence of given functions f and g under the assumption that some operation "A" has a right neutral element "e". In predicate logic such a situation might be expressed as follows:

( V z :A[z, e] -= z) ~ (~/ x : f(x) - g(x, e)) ;

that is, we have a universal quan~fication on the left-hand side of an implication. For p~icate logic we have the so-called "generalization rule" (cf. [Shoenfield 67]):

-->B

-~ V x : B

So, in order to establish our desired equivalence f(x) = g(x, e) by way of modus ponens, i t would suffice to prove A[z, e] - e with the "free variable" z. Yet, the resulting inference

Page 35: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

11.2o5 The role of free variables 27

--> A[z, e] = e

--> f(x) -= g(x, e)

is not sound, since when we interpret "A" --" O, e "- 2, A[.,.] --" .*. } and obtain

--> 0 * 2 ~ 0

e.g. as multiplication, we can apply the instantiation 8 = { z

--> f(x) =- g(x, 2)

ThiS is certainly not the intended effect, since "2" is not a neutral element for multiplication.

In our context, the only purpose of the above universal quantification on z is to prohibit illegal instantiations. To achieve the same effect, we have introduced the set )~ of indeterminates. So a correct statement of the intended inference in our calculus reads ("generalization on constants", see [Enderton 72] or [Manna 74]):

--> A[z, e] =

--~ f(x) - g(x, e)

with ~ e X being an indeteminato.

As in the case of universal quantification we also have to derive the premise

A[Z, e] = z..

This, in turn, can be achieved by deriving transformationally the clause

A[x, e] =- x

with the variable x and then instantiating i t with @ = {x "-- ~}.

So, whenever we want to translate a predicate-logic formula with "local" universal quantifiers into our formalism, we simply have to introduce indeterminates in place of the bound variables.

Note that without a device like our indeterminates we would not be able to express properties such as

" i f P[[all holds for all values a, then Q holds"

(cf. [Hilbert, Bernays 68], pp. 93-94). On the other hand, our design allows us to achieve this effect without going into full pYt~icate logic. Since indeterminates cannot be instantiated, they are necessarily "held constant throughout subsidiary deductions" (in the terminology of [Kleene 52]).

For similar reasons we cannot apply instantiations at the level of clauses; that is, an inference like

/A-~B is not valid!

/A B-~B O

If we would allow inferences such as the one above, the distinction between scheme variables and indeterminates would vanish. For instance, by using the inference

- ~ P~x~

--> PIT ~]]

Page 36: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

28 11.2 Definition of the calculus

we could infer from any inference of the kind

--> PEEl]

- ~ Q

by the Cut Rule the new inference

-> PEx~

- ~ Q

However, the converse direction of the above inference is valid! That is, indeterminates in the premise can be replaced by scheme variables in the conclusion:

[Va] Substitution of indeterminates by scheme variables

o~ where {) assigns to variables their corresponding

indeterminates

Using this mechanism, we can make e.g. the associativity of a certain operation "." available for further transformations:

-~ u - ( v - w ) - ( u - v ) -w

Note that Rule [Va] above is just the counterpart of the well-known Substitution Theorem of predicate logic (cf. [Shoenfield 67]) :

(V x : B[x]) ~ B[a] .

Let us give an example for the application of this meta-inference: Consider b~o recursive functions f and g that are characterized by the following EKluivalences (where A, B, C, D are defined and determinate terms):

(1) f(x) -: i fB themf(A) -CelseDendi f ,

(2) g(x,y) - f(x) -y .

We want to show (as part of a well-known paradigm for recursion removal - cf. [Bauer, WBssner 82]) - that the following equivalence also holds:

Page 37: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I .2.5 The role of free variables 29

( * ) g(x,y) ~ i f B theng(A,C -Y) elseD . y e n d i f ,

provided that "." is associative.

A corresponding deduction proceeds as follows:

We start from the associativi~ of "-":

(3) u - ( v - w ) ~ ( u - v ) - w .

By the Instantiation Rule [V] we obtain

f(A) - (C -y) =- (f(A) -C) - y .

By the Monotonicity Rule [VII I ] this yields

i f B then f(A) - (C . y) else D • y emdif i f B then (f(A) • C) • y else D . y em¢~f.

One of the fundamental axioms for if-constructs then leads to

i f B then (f(A) - C) - y else D - y em(Iif i f B then (f(A) - C) else D ~ f . y .

Now an application of (1) using the Transitivity Rule [Vl], yields

i f B thenf(A) - (C -y) elseD -yemdif = f(x) -Y •

Finally, by applying (2) twice, again using the Transitivi~ Rule [Vl] we obtain

i f B theng(A,C -y) elseD -yendi f ~ g(x,y) ,

which is the desired result.

I f we want to freeze this development into the single inference

-> f(x) ~ i fB thenf (A) -CelseDem(lif --> g(x,y) -- f ( x ) - Y

--> g(x,y) = i fBtheng(A, C -Y) elseD -yem(l i f

we have to convert the scheme variables u, v, w from (3) into indeterminates ~, ~, C~ since we have applied a 'qocal" instantiation to them during the proof. Therefore we must prohibit that other instantiations are applied to u, v, w in the context of the overall inference. Formally, this is achieved by applying Rule [Va] above to equation (3).

Page 38: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

30 11.3 Representation of transformation tasks in the calculus

3. Representation of transformation tasks in the calculus

Now we demonstrate how the central tasks in transformational program development can be explained in terms of our calculus.

Note that by virtue of the Rules [IVa] and [IVb] we can make use of the following sin~plifications: (i) Every transformation rule (such as Exa~les 1 and 2 from the Introduction) is an inference. (ii) The conclusion of eve~ transformation rule is a clause without antecedents; that is, every inference

has the form

- ->A where A is a formula.

3.1. Genuine br~formation ~b=ps

Let >~ ("is transformable into") stand for any binary semantic predicate Q{F.,.]], and suppose that a program development has alrea~ proceeded through k versions of a given program, that is,

Pl >-> P2 >-> "'" >-> Pk,

(where different occurrences of ">->" may stand for different predicates) and that we now want to apply the rule

a

{ ~ i , " ' , ~m b

which in our framework reads

~ i , ---, ~m [A]

--> a>->b However, we usually just want to apply this rule to a small fragment t of Pk; then for some context cn[-] we have Pk=cn[t]. We have to match the input 1~plai~ a against t; i f successful, this match yields an instantiation g such that t = ag. Then we obtain the new version Pk+l by instantiating the output i~nplai~ b accordingly, that is, Pk+l = cn[bS]. In order to guarantee the legality of the transformation step, we still have to veri~ the - instantiated - applicabili~ conditions ~1 O, ..., ~m 8. Thus, the transformation step is expressible in our calculus as follov~:

Let Pk = cn[t] be given. Con~te O = Match(a,t), that is, find 8 with ag=t, i f possible. Then apply the Instantiation Rule [V] to obtain ~ new inference

~1 e . . . . . ~m e [A ' ]

- ~ t >-> be

Together with the Monotonicil~ Rule [V l l l ] this gives (since Pk = cn[t]}

O(lg . . . . . O(mg [A"]

-~ Pk >~ cn[be]

Page 39: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I .3.1 Genuine transformation steps 31

So our development has been extended to

Pl >-> P2 >-> "'" >-> Pk >-> Pk+l =def cn[b(~]

oc18 . . . . . O{m8

Note that the transition Pk >-> Pk+1 is annotated by the pren~ses (applicabili~ conditions) still to be verified; this is just another graphical representation for the deduced inference [A"].

Sum~ng up, a genuine transformation step consists of a composition of the three basic steps - ma tch ing ;

- instantiation; - m o n o t o n i c i t y .

The central aspect of the above process is the instantiation of a certain inference with an instantiation 8. However, besides matching, there are two other ways, in which such a 0 can be obtained:

(i) Completion of indefinite rules: A rule is indefinite i f the output ten,plate contains schen~ variables that are not present in the input template (and thus cannot be completely instantiated through matching). An exan~ole is given by rules for recursion removal, which require the existence of suitable inverses for operations (cf. [Cooper 66], [Bauer, WSssner ~ ] , [Partsch, Pepper 86]). Let rec[f] be a recursive form of a function involving some primitive operation f, and suppose that, using an inverse g of f one can obtain an equivalent tail-recursive function tailrec[g] according to the inference

, . ,

g(f(R)) • X

--> ~=c[f] ~ tailrec[g]

We want to apply this inference to some concrete function natrec[succ] over the natural nun~rs where f corresponds to the successor function. Matching and instantiation 3held the intermediate inference

g(succ(x)) -

--> natrec[succ] >-> tailrec[g]

This inference is "indefinite" {cf. [Brass et al. 82]) in the sense that g is not yet instantiated with a suitable value. This value "pred" is either to be provided by the user or may even be found by the transformation system by browsing through the relevant data t&Ioes. This gives

, . ,

-> pred(succ(RJ) = R

-~ natrec[succ] ~ tailrec[pred]

Page 40: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

32 I I .3 Representation of transformation tasks in the calculus

Note that in a further step the user may instantiate tailrec with some concrete name, say nattalTrec.

Since in the underlying data type NAT we have the law

pFed(succ(R) ) = x ,

the inference

-~ pred(~(R)) ~

is so~nd; thus, using the meta-inference Cut, the premise pred(suoc(x)) - x in the above inference can be eliminated.

(ii) Special algorithms: One can, instead of general pattern matching, use special-purpose algorithms that produce suitable instantiations. Typical examples are the fold- and unfold-rules (cf. [Burstall, Darlington 77], [Bauer et al. 85]):

(Unfol d)

--> F : DECLARATION [[ f]] --> x = FOI~MPAP~Ef]] --> DETEI~MINATE E a ]]

--> f(a) [ F[Fa for x]]

(Fold)

--> F = DECLARATION [Z f ] ]

--> x = FORFI'ARAMITf]]

--> FI[a for x]l -]D f(a)

I f we want to apply the rule (Fold) to a given expression E, vm must find a suitable expression a such that F~a for x]] = E. This can be done by an algorithm which treats the parameters of the body of f like scheme variables during the matching of E with F.

More sophisticated algorithms could be employed in the verification of applicability conditions (see below). Here i t may be interesting to cut a predicate like

r _ ] D t into I~o predicates

r_]D S~D t. This means that a suitable term s should be found based on the forms of bath r and t.

Page 41: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I .3 .2 Compactification of development histories 33

3.2. Compactification of developm~ histories

Suppose that we have a development sequence of the form

pl >-> p2 >~ . . . >~ pk

- - -

but that we are actually Ynterested fn the relationship between Pl and Pk- (Recall that ">->" may stand for different semantic predicates such as . ~ . , -_]D', or ._[ . ) So we have to apply repeatedly a compactification of the following kind:

Consider

" '" >-> Pi-1 >-> Pi >-> Pi+l >-> " '"

which is nothing but another representation for the two fnferences

--> Pi-1 >-> Pi ~ Pi >-> Pi+l

Now ~e apply the Transitivi~ Rule [VI] {provided that ~e two semantic relations P~-I >'> P~ and Pi >'> P~+I are indeed compatible) and cbtain the new inference

--> Pi-1 >-> Pi+l

or, in graphical notation,

" '" >-> Pi-1 >-> Pi+l >-> "'"

So i t is seen that Compactification of Developments is nothing but an application of the Transitivity Rule [V l ] .

3.3. VeriFkc3tion of applicalm'lity conditions

Suppose that we have a development step of the form

"'" >~ Pi >-~ Pi+1 >-> " '"

{ i : {°~i . . . . . °~m}

and that we want to "verify" the condition ~ i" Suppose moreover that with /A ~ {~. So we are actually dealing with an inference of the form

~-~A

~2, --- , (Xm [ * ]

-~ Pi >~ Pi+l

I is of the form /A -->A

Page 42: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

34 II .3 Representation of transformation tasks in the calculus

According to the Cut Rule [ I I I ] , we can simplify this inference [ * ] to

~2, " " , am [ * * ]

--> Pi >~ Pi+1

i f we are able to derive the inference

G~2, ---, mm [#]

/A --> A

Because of the Importation Rule [IVa] i t suffices to establish the inference

~2, " - , CXm [##]

--> A

Thus, in the transformation system, the command "Veri~ ~ 1" can be realized by a subdevelopment for which the clauses /A, a2, ..., a m are te~rar i ly made available as "ass~m~ptions" until the desired conclusion A has been derived. The logical justification of the correctness of this proceeding is that from [##] we infer [#], which can be applied to [ * ] in order to Held ~ siiRplified F * * ].

3.4. RedUc-Um of applicatn]i~ u.,~,~ti~ ( p l re(IJction)

A con~)lete verification of applicability conditions (as shown above) is not always possible, in particular ~ahen dealing v~th program schemes rather than with p ~ . But we m~y still be able to reduce certain conditions to simpler ones. In this connection we also speak of the reduction of a goal to subgoals. We presuppose the same situation as above, but now look more closely at the structure of the goal to be reduced. Assume a situation like

--> r > ~ t

~2, " " , ~m [ * ]

--~ Pi )-> Pi+1

in which we want to reduce the condition r )-~ t . As shown above, we start a development for ~ term r (or for t ) under the assumptions m2 . . . . , ~m" This is a "normal" transformation activity as described in 3.1. and 3.2.. In the most general case, this subdevelopment establishes (after compactification) an inference of the form

F~,-.., P~, a 2 , , am [#]

- -~ r >-> S

(where the ~ , . . . , ~ are a collection of additional applicability conditions that were encountered during the development from r to s).

By the Transitivity Rule [VI I I this leads from [ * ] to the new inference

i> s>-~ t

[ * * ]

--> Pi >-> Pi+1

Page 43: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I .3.4 Reduction of applicability conditions (goal reduction) 35

(provided that the semantic relations in r ~> t and r >-> s are indeed compatible). So the goal

--> r> -> t

has been replaced by the subgoals

- > (s~t), ~ . . . . . Pn-

3.5. "ClaiII~"

During a program development i t will sometimes happen that one needs (for an activity of 3.1.) a rule that does not yet exist in the system. However, one cannot expect the user to always abandon his current development in such a situation in order to f irst establish the required rule. The system rather should allow him to "claim" the validity of the rule.

In the calculus this just means that one adds the tautology (according to meta-inference [ I ] ) O(

or

A --> A o~

By the mechanisms demonstrated before, the use of such a tautology ~I I establish the clauses --> A and ~ , respectively, as goals that remain to be verified. These goals are inherited by all further inferences generated using the claim. Thus using an invalid claim results in inferences with irreducible premises; however, these inferences still are valid and thus no inconsistency is introduced into the system.

4. Induction rules

Frequently one needs induction in order to derive new transformation rules or to verify applicabili~ conditions. In connection with programming, there are t~o major induction principles available:

- computational induction, which is based on the fixed-point theorem of K1eene; structural indUcticr~ v#dch is based on Noetherian orderings.

Coni~tational induction is justified by the principle of "~proximations of functions". I t has been introduced by D. Scott, and i t comprises in principle also "recursion induction" ([McCarthy 63]) and "fixpoint induction" ([Park 69]).

Structural induction comprises as its most important special case term induction which is based on generation principle for algebraic i~pes (cf. [Bauer, W~ssner 82], [Wirsing et al. 83]).

We consider each of these principles in turn and demonstrate how they can be cast into inferences following the im(bction scheme

Ainduction base --> #induction step

-->A

Page 44: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

36 I I .4 Induction rules

In our treatment, we are not interested in the most general versions of these rules but - on the contrary - aim at technically simple (but still useful) instances.

All our induction principles ultimately are founded upon the principle of Noetherian induction. This principle is based on Noetherian partial orders (see e.g. [Birkhoff 67]): A poset (S, 4) is Noethm~iam ( w e ] l - f ~ ) , i f every non-empty subset of S has a minimal element, or, equivalently, i f every descending chain in S is finite.

The following formula of first-order logic is valid in a Noetherian poset (S, ~ ):

( * ) ( V a: (V b,b ~ a: AEb]l) ~ AEa~ ) ~ ( V x: AEx]] ).

Accordingly, in first-order logic the following inference rule is valid:

--> (V b, b~a: AITb]]) => AE~]I

AEx~

(Note that a is an indeterminate, whereas x is a scheme variable.)

In this general form, the "local" universal quantifier sti l l exceeds our formalism. This problem could be overcome by using the meta-inference

From infer --> AIF~3 --> AEx~

However, then we would need to introduce meta-inferences as formal cbjects into our calculus. The resulting addition of a further level together with the corresponding "meta-meta-inferences" would have severe impacts on the interaction between inferences, scheme variables, and indeterminates (see Section 2.5). Therefore we refrain from this extension to our system. But we can realize a special instance of Noetherian induction, namely " s ~ s e Noetherian induction" (cf. [Manna 74]): Let for any xeS the (possibly e ~ ) set {pred1(x), ..., predn(x)} denote all immediate predecessors of x with respect to * . Then we have the

following scheme for valid inferences:

[IX] Stepwise Induction:

[ * ]

A[Fpredl(~) ~ . . . . . A[Fpredn~(~)]l --> A[F~]I (one such clause

for every combination of pred-operations)

-> AEx~

In the remainder of this chapter we give a number of instances of the above inference-scheme with concrete instatiations for the operations pre(~ and for the formula A. Note that the validity of all these rules depends on the semantics of the programming language under consideration. These induction rules also demonstrate that i~o features of our calculus are indeed mandatory: We need at least two levels of entailment, and we need indeterminates in addition to scheme variables; otherwise the following induction rules could not be represented within the calculus.

Page 45: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

11.4.1 Computational induction 37

4.1. Comp=tational ind-ction

The principle of con~Dutational induction is derived from the fact that the meaning of a recursive function is the least solution of the equation

f : F [ f ] ,

where F[f] is the abstraction of the function (procedure), and that, for continuous F[. ] , this fixed point is the limit of the sequence

! , F[I], F211], . . . , Fk [ ! ] . . . . .

where I is the totally undefined function (procedure). I f F[. ] is not continuous but merely monotonic, the sequence has to be extended into the transfinite ordinals. In this case, the Noetherian induction uses the ordinal numbers as the underlying well-founded set. The following considerations are based on [de Bakker, de Roever 73], [Hitchcock, Park 73], [McCarthy 63], [Park 69], and [Scott 70]. We merely l is t the appropriate rules of inference; their soundness is discussed in [Pepper 87].

We presuppose that we are given as a representative for systems of n functions declarations (analogously for procedures) of the form

function f (x: m): r; F[f,g] g (y: n): s; G[f,g]

and that we need to establish an assertion of the kind

- two function

m F R[f,g] >-> S[f,g]

for "embeddings" R[.,.] and S[.,.], and with >-> standing for me of the predicates ~, ~D, _[-

4.1.1. Scott induction

For the two functions f and g as defined above and with )-> standing for ; , ~D • or _[, the following

rule of inference is valid (where hl, h2 e )~ are indeterminates)

-~ CONTZNUOUS E R[.,. ] 3 -> CONTINUOUSES[.,. ] -> R [ I , ! ] ~ S [ ! , l ]

-> R[f,g] >-> S[f,g]

Note that only the enl)eddings R[.,.] and S[.,.] need to be continuous (in order to establish the validi~ of R[FO< [ 1 , I ] , G~ [1 ,_L ] ] >-> S[F~ [ I , I ] , G~ [ J ,1 ] ] also for limit ordinals c~ ). For the function bodies F and G monotonici~ suffices.

Note: In a technical realization one has to avoid our "for the functions ... as defined above", in order to make the rule self-contained. So one needs the additional pren~ses

Page 46: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

38 11.4 Induction rules

F = DECLARATION [F f]] , G = DECLARATION~g]],

with a syntactic function DECLAP~ATIONI[.ll that yields the right-hand side of the declaration of an identifier.

4.1.2. recursion induction ([McCarthy 63])

Let f and g be defined as above. Let moreover

fln~-ti(m h (x: m): r; H[h]

be given. The following rule of inference is valid {where R e )~ is an indeterminate):

--> DEFINED[[h(R)ll --> f(R) =- H[f]( ~J -~ g(x) -= H[g](x)

f(x) ~ g(x)

Note that one can often use f or g itself in the place of h. (The problem with this rule is, of course, the definedness proof.)

4.1.3. "Transfomational" induction

This is a special case of Scott induction, suggested in [Stoy 77] and [BroySO] for its technical simplicity. We consider simplified functions

f1~B~i~ f (x: m): r; F[f] ~ o n g (x: m): s; Gig]

and a simpler assertion that is to be established, namely (for >-> being ~ or [ )

f >-> S[g].

Then Scott induction can be replaced by (with an indeterminate h e )~)

--> CONTINUOUS[IS[. ] II

-~ I ~> s i l l --> F[S[h]] >-> S[G[~]

--> f >-> S[g]

Note that for >-> = [ the second premise is redundant.

4.1.4. Fixpoint induction ([Park 69])

For the relation [ there is a special case of Scott induction: Consider the defini-tion

Page 47: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Iio4.1 Computational induction 39

fLmctim f (x: m): r; F[f]

and a functional expression E. Then we have the valid assertion

F[E] [ E --> f [ E

and thus the rule

--~ F[E] [ E

~ f [ E

(The proof simply follows from the fact that _L _[ E, and thus by monotonicity F [ I ] _[ F[E] _[ E; hence F

~ [ ! ] _[ E for all ordinals (x .)

4.2. Struci~ral induction

In the sequel we consider an instance of stepwise induction that is based on the "generation principle" of algebraic data twpes. This leads to the meta-rule of term induction. (The following considerations are based on the theory of algebraic types - in the form described e.g. in [Wirsing et al. 83] or [Bauer, WSssner 82]).

4.2.1. Term induction

The principle of term induction relies on the generation principle for algebraic ~ypes (cf. e.g. [Wirsing et al. 83], [Bauer, W~ssner 82]): A sort elem that is defined by an algebraic ~ comprises exactly those objects that are generable with the operations of the type. This leads to the idea of a c ~ t r u c l ~ set (cf. [Guttag 75]): A set of operations (with range elem) is called a constructor set, i f all objects of eIem are gener~le with these operations only. Clearly, the set of all operations with range eIem constitutes a constructor set (at least for i~ypes that introduce only one new sort).

To reduce the number of cases, we are for term induction interested in "minimal" constructor sets. Unfortunately, the proper~y of being a minimal constructor set is in general undecidable. For the type NAT of natural numbers, the constant "zero" and the operation "succ" form a minimal constructor set. All other operations, such as "pred", "add", "mult", etc., can be defined in terms of these i~o constructor operations. Similarly, in a ~ BINTREE defining LISP-like binary trees, the operations "emptytree" and "cons" are constructors, while "car" and "cdr" are derived operations.

4.2.2. Decomposition induction

Using the notion of a constructor set, we can distinguish a particular kind of le~as for a given t~pe T: A Decm~it im Lemma for a sort elem is of the form

V x : elem II 3 (x11:mj1 . . . . . Xnl:mnl JlQ1[x11,...,Xnl])

(Xlm:m11 . . . . . Xr~m:mnm II~xlm .... ,x~) II

x ~ c1(Xll . . . . . Xnl) V

V x - Cm(Xlm . . . . . Xnm)

where in each existential quantification zero or more xij may again be of sort eIem and where the operations {Cl, . . . , c m} form a constructor set.

Page 48: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

40 11.4 Induction rules

From the above lemma we derive the following induction rule:

. . ** ~ A~Cl(~11 .. . . . Xln l ) ] ] , -~ Q1[x11 ..... Xln 1] = true, AI[x11]l . . . . . A[[Xljll -->

--> A~x~

where xij are those xi j that are again of sort elem. Note that this actually is an instance of the "proof by case distinction" that was mentioned at the end of Section 3.

This shows that a transformation system should support the introduction of algebraic types and that every algebraic type that is entered into the system should come equipped with a collection of suitable (and verified) Decomposition Lemmas, since these provide the essence of important induction rules.

Let us consider again the t~o examples NAT and BINTREE. Here we obtain the inferences

--> A[Fzem~, AEk~ -~ A[[succ(R)~

A~x~

and si~n3arly

--> A[F emptytree ~, A[F~]], A[[~I] --> A[[cons(~, x, v)]]

--> AFF t]]

To see both t~e variety of possible Decomposition Lemmas and the role of the additional predicates Q for domain restriction, consider a type FINSET over an element sort elem with a strict-ordering < that is extended to sets by defining

r < s - V (x:elem, y:elem ~x e r A y e s) l J x<y . Then we have the following Decomposition Lemma:

V s : set II s - : ~ V ] x : e lm 11 s --- {x} V ] ( u : s e t , v : ~ t l l u ~ A v ~ A u < v - t r u e ) II s =-u U v

This lemma essentially says that we can partition any non-trivial set s into a set of "small" elements and a set of 'qarge" elements. Thus we obtain the rule

A~{x}~ u ~ , v ~ , u< v = true, A{Fu]l, a[[~ll ~ A~u U ~]I

AI~s]]

Page 49: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

11.5 Discussion 41

which is useful e.g. in the development of the "quicksort" algorithm.

There are many variations of this paradigm. Well-known are partitionings into "almost e~ally large" subsets, i.e.

card(u) ~ card(v) < 1

(where card(u) gives the cardinality of u, and i -" j is the "symmetric difference" max(i,~) - min(i~)), or partitionings into a singleton set and the remainder set, i.e.

card(u) = 1.

This shows that the use of Decomposition Le~mas is mere powerful than merely working on the basis of constructor sets, because we can utilize more powerful assumptions during the proofs. From existing Decomposition Lemmas new ones can be derived within our calculus as shown in [Pepper 87].

5. Discussion

We have presented a calculus that formalizes many of the activities that take place - often justified only pragmatically - in many transformation systems. The calculus is part of the "requirements specification" for the system CIP-S. Our experience has shown that without such a calculus i t would have been virtually impossible to produce a "correct" transformation system (in the sense of Section I) . The design and specification of such a system involves an abundance of details ranging from the concrete representation of "terms", "clauses", "inferences", etc. to the forms of the rule catalogues and auxiliary service routines - such that the issues of soundness and adequacy (that are addressed in our calculus) would become almost intractable due to the overPr~Iming mass of programming technicalities.

The major motivation behind the calculus was to make the corresponding transformation system sound such that i t ~aramtees correctness of all developments. To this end, we have reduced the usual calculi from formal logic to a form that exactly meets the needs of program transformation.

A question that arises naturally in connection with formal calculi is that of completeness. Obviously, our calculus cannot be complete, since i t is a true impoverishment of the usual Gentzen system. However, this question is not very relevant here, since our calculus is built on top of atomic predicates (such as DEFINED, DETERMINATE, EQUIVALENT, etc.) that are not axiomatizable in a complete way anyhow - at least for programming languages with repetition or recursion. Clearly, completeness relative to inherently incomplete atomic predicates is not very interesting. Analogously, the complexi~ of (relative) decision procedures is net a relevant issue in our context, since the calculus is built for an interactive system that is under strict user control.

As a particular aspect, we have incorporated two prominent induction principles into the calculus, thus giving i t enough power for deriving an abundance of new valuable rules from a small set of fundam~tal rules. As has been seen, algebraic types play a major role in the use of induction techniques, viz. by their associated Decomposition Lemmas. Unfortunately, the verification of such lemmas in general is a non-trivial and time-consuming task. However, once this time has been invested upon definition of a type, i t I~VS in each of its applications. So a predefined collection of fundamental types together with their appropriate Decomposition Lemmas is a most valuable tool in any programming environment.

Page 50: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

42 I I .5 Discussion

A final remark concerns the structure of the calculus. I t is tempting to try to incorporate the predicates used in formulas into the language (more precisely, to enrich the language PL to a language EPL ~ PL), rather than regarding them as being on the same (meta-) level as the semantic predicates. The reason why this does not wrk is illustrated by the following trivial example: The pFogram fragment

i f x+l>x then z := z*2 else x := x-1 e ~ f

is semantically equivalent to (and thus can be transformed into) the fragment

z := z*2,

(under the assumption that x has a defined value). However, the syntactic predicates

OCCURS~x in i f ... em~f]] and OCCURS{Ix in z := z *2 )

obviously have different truth values. So "correct" transformations may be forbidden in particular contexts. This just means that syntactic predicates are not monotonic with respect to the relation "is

transformable into".

Page 51: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

PART I I I

FORMAL SPECIFICATION

According to the CIP philosophy of programming, program development begins with the formal specification of the problem. We start this part of the report with a verbally formulated collection of re~adrements for the transformation system aimed at. This collection is supplemented with a simple example which is intended to give further insight into the problem to be tackled.

Then the formal specification follows. I t is organized strictly hierarchically into a system of algebraic types. The top level of this type hierarchy, the type SYSTEM-CORE constitutes the link to the "user environment", i.e. i t contains all those functions the system is able to perform. At the bottom level of the hierarc~ there are some tj4oes, viz. mainly PRED-SYMB and LANGUAGE, that are deliberately not specified completely, as they are intended to allow the treatment of language-dependent issues. They ~nll be reconsidered in Part VI.

We demonstrate the adequacy of the operations specified by re-doing the example introduced in section 1.2 in a much more technical way on the basis of the formal specification. Part I I I closes with a summary of the experiences made in composing the formal specification.

Page 52: The Munich Project CIP: Volume II: The Program Transformation System CIP-S
Page 53: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I l l . 1 Informal requirements

45

I . Informal requirements

Rather than just relying on the purely theoretical view of a transformation system as given in Part I I , this section aims at giving a more user-oriented view by means of a collection of informally stated requirements and by exemplifying some of the system's capabilities in the framework of a ~4)ical example.

1.1. Teclliical requiren~iI~

The technical requirements given below have emerged from various people's experience. As in other soft~are projects they should be seen as an attempt of an informal characterization rather than as a complete l ist .

In order to allow a quick overview of the expected abilities of the system, we have structured the requirements by grouping them into related topics. We denote ~bjects of the system in boldface, whereas operations are underlined. Note that we only specify elementary system operations which should suffice for realizing all more involved ones. The system should be extensible, i.e. a means for formulating such complex operations should be available.

I . I . i . Programs and program ~nemes

A program is a well-formed term over an algebraic signature PL that defines a programming language over some ( e x c ~ l e ) set of primitive types. A pn~gr~ scheme is a well-formed term over PL[X], i.e. a tern over PL possibly containing free variables from the set X of scheme variables. Thus, a program is a program scheme that does not contain free variables.

The system has to handle these (abstract) terms, i.e. tree-like structures. This implies, in particular, that the system has to take care of string-to-tree translation (including syntax checking), but also of tree-to-string retranslation. In general, there are a nun~er of context conditions that have to hold for a program scheme. Because of the presence of scheme variables, these conditions cannot alwaYs be fully reduced. For instance, the scheme

i f C then E else F emdif with scheme variables C, E, F of type "expression" must satisfy the conditions

KIND[FC]I = bool and KIND[FEll = KIND[[Fll in order to be meaningful. However, only after instantiation of C, E, and F with proper, expressions the conditions can be (partially) checked. Therefore there has to be a facility for obtaining the set of unresolved context conditions from the abstract syntax trees.

Furthermore, program schemes can be named, stored for later use, and retrieved by name. Within a program scheme any subterm maY be selected (and consi~red as a program scheme itself). Thus, also (well-defined) parts of program schemes are amenable to manipulation within the system.

Finally, program schemes can also be subjected to transformation rules.

1.1.2. Transformation rules and their application

Transformation rules are just special inferences (cf. 11.1.1.4) of the form A

where A is a set of applicability conditions and REL is a semantic predicate.

Page 54: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

46

111.1 Informal requirements

Applica~li~ conditions are Horn clauses over an enrichment of PL[X], i.e. they may contain additional predicates, such as OCCURS-FREE, DEFINED, DETERMINATE, etc. Thus, applicability conditions are amenable to transformations themselves.

Instances are partial finite mappings X -->PL[X] from scheme variables to terms.

Appl)~ng a transformation rule A

RmC~T~ to a program scheme t results in a new inference

B

such that t , w, B result from instantiatin~ u, v, A by a certain instance i which is determined by matching the ~ templai~e u against t .

1.1.3. Verification of applicability conditions (goal reduction)

The above way of transforming programs allows deferring b~e verification of the applicability conditions; the result of such a development then is a final program version together with a set of applicability conditions ("assumptions") still to be verified. The system is to provide assistance in reducing these assumptions ("goals") to "simpler" ones ("subgoals", in the ideal case to "true") according to built-in meta-inferences (cf. II.i.1.5). Since the verification of applicability conditions generally needs information from the environment of the transformed subexpFession, the system must be able to preserve environment information.

1.1.4. Development of types and comp~tional struc~res

A program scheme usually is based on primitive t~Des that specify the admissible primitive operations. Thus, apart from manipulating programs, there should also be fundamental means for handling ~ (inputting, deleting, or modifying during construction), and their models, ~ o n a ] s i ~ and mmJbles. Of course, this has to include checking of syntax and context conditions. Moreover, since (conditional) equational axioms of a ~¥pe correspond directly to transformation rules, there should be a facility for deriving such rules from type axioms.

The system should be kept extensible for handling ~ ~ in a more comprehensive sense. This may comprise more complex operations for manipulating types (enrich, hide, rename, instantiate, etc.), or some interactive support for constructing implementations in terms of other t~es. Another possible extension could be a "type analyzer" for semantically supporting the construction of t~es (e.g. checking hierarc~ constraints or sufficient completeness, or for reasoning about classes of models). Currently such a tool for CIP-L is being constructed.

1.1.5. Documentation of a development

A program (L=velq~mm~t is a (tree-like) structure reflecting a partial ordering ("a is derived from b under condition c") between program schemes a and b. Whenever a transformation has successfully been applied to a program scheme, the new program scheme and the necessary information on i ts derivation (usually the respective transformation) has to be recorded together ~4th the ordering relation.

Page 55: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . l . 1 Technical requirements

47

Recovery from blind alleys in a development should be supported; in particular, this requires (convenient) access to "prLodecessors" of schemes as well as the possibility for deleting useless sub-developments.

Furthermore, recorded developments should be amenable to c~c t i f i ca t ion and to various kinds of selective inspections. Apart from the starting point of a development (the "contract", cf. [Bauer 81]) and the current "actual" program scheme, some "milestones" should be conveniently accessible.

In a more general view, program developments themselves could be considered as formal and thus manipulateable objects (cf. [Wile 83]).

1.1.6. Record of a goal reduction

A proof record is a sequence of proof steps that mirrors the temporal succession of applications of meta-inferences to the set of subgoals.

1.1.7. Further administrative tasks of the system

The various objects involved in program development (program schemes, types, transformation rules, etc.) are to be administered by the system and made available upon request.

1.1.8. User environment

Since the system ~nll be used mainly interactively, a comfortable user environment has to be provided offering commands that are based on the system primitives. A command language has to provide a great varie~ of rea~-made user commands (e.g. allowing to get any kind of information available in the system). I t may also provide the user with the possibilita, of defining new (complex) comm~ds.

The principles developed in operating systems such as UNIX or SMALLTALK provide good guidelines here. When available, such operating systems should be useable as direct environments for the CIP system core.

1.2. Example: A fictitious session with the

In order to 111ustrate the intention with the CIP transformation system and also to give some motivation for the design decisions that have influenced the formal specification, we consider, as an example, a fictitious session with the ~stem. Our pr im~ concern with this example is pointing out some of the problems arising in program development and to provide an intuitive access to their solution. After having given the formal specification, we will resume this example and deal with i t in more technical details.

The problem to be tackled in this sample session is the derivation of a new transformation rule by the successive application of available rules to an initial program scheme. A i~ypical instance of this kind of rule derivation is e.g. the development of a rule that allows transforming a descriptively specified problem class for a certain data type into an operative solution scheme. Given e.g. (for SET cf. [Bauer et. al. 85]) the program scheme

ftmL'tion enumerate (s : set-of-m) : set-of-n ; (*) { f(x) II x e s } ,

Page 56: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

48

I l l . 1 Informal requirements

the application of a number of elementary rules (such as unfold, fold, axioms of the data type SET, case introduction, and simplification according to data t ~ properties) will eventually result in the scheme

(**) function enumerate (s : set-of-m) : set-of-n ;

i f s = ) then 0 elm con~x:m -- somx' :m II x' e s ;

{f(x)} U enumerate (s \ {x}) endi f .

Each rule application, i f successful, establishes a certain semantic relation (equivalence, descendance, less definec~ess, etc.) bei~een i ts input and output program schemes. I f the "composition" of these semantic relations betvmen the successive intermediate program sessions itself is a well-defined semantic relation R, the initial and final program schemes (*) and (**) may be related by R to constitute a new transformation rule. The applicability condition for this new rule results from the union of the instantiated applicability conditions of the rules applied. Of course, technically, computing the relation R as well as finding the "combined" applicability condition require that the system has recorded the necessary information, i.e. that i t has kept track of all intermediate program versions, the respective semantic relations between them, and the respective (instantiated) applicability conditions that ensure correctness of the transition.

However, an applicability condition obtained in this way can often be simplified - which is all the more advisable i f i t is to serve as the applicability condition of a transformation rule that is to be used frequently. Thus, apart from supporting the (deductive) derivation of new program schemes by the application of transformation rules (i.e. inferences, cf. 2.8), the system should also support the simplification of applicability condii~ons.

Simplifying an applicability condition usually is a typical "goal reduction" task: the condition is the goal to be achieved, and the reduction aims at finding a set of "simpler" subgoals from which the original goal may be inferred according to a set of meta-inferences, the most essential of which is the "cut rule" (cf. II.1.1.5). However, i t is not excluded that the reduction of some of the subgoals may be done in a deductive way, i.e., by applying suitable transformation rules. Of course, this in turn may involve reduction of further applicability conditions, and so forth. Thus, one may temporarily be in the "situation" of a whole hierarchy of nested, not yet completed derivation or reduction activities. Here a problem results from the fact that for each of these activities different kinds of "knowledge" may be used legally: within derivations only inferences (i.e. already proved rules) are allowed, whereas within reductions "assumptions" (i.e. properties still to be proved) can be used which, in turn, may be used in a subordinate derivation, but, of course, not in encompassing derivations or reductions.

To free the user from the burden of keeping track of the respective "situation" he is in and to enforce in this way considerably the robustness and safe use of the system, we have introduced the notion of a "state" which, for any situation, mirrors the information a~ut the nesting of pending activities and their respective "environments", i .e. the collections of available "knowledge". Its basic organization is stack-like thus exhibiting the nesting; environments are represented as catalogs of transformation rules (inferences), local assumptions, etc.

Apart from the i~m kinds of activities encountered, viz. "derivation" or "reduction", our simple example also suggests a third class of activities that consists just of those tasks that make certain objects such as rules, axioms, etc. available to the user. Since these activities conceptually are neither restricted to derivations nor to reductions, they simply vn31 be r e f e r ~ to as "neutral".

Page 57: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.1.2 Example: A f i c t i t i ous session with the system

49

Of course, this form of safe organization cannot be done automatically by the system; rather i t requires that the user indicates any change in activity. Additionally, i t also requires some organizational things to happen when the user starts working with the system and when he quits.

Within the overall organizational frame, our fictitious session may proceed along the following individual steps:

(I) Initialization of the system and installation of an appropriate knowledge base:

The system installs an initial state, consisting of an empty stack of pending activities and an empty activity-specific knowledge base; the mode of the current activity is "neutral". For our sample derivation we will use some elementary rules and axioms of the data ~ SET which are supposed to be available in external files. These files are f i rst "converted" into respective catalogs and then "added" to the activity-specific knowledge base in order to allow direct access to their entries.

(2) Start derivation with initial program scheme Po:

For simplicity we have assumed that the program scheme, Po, the starting point of our intended derivation, already is accessible in one of the catalogs for program schemes and now made available for the subsequent derivation. The unresolved context conditions about this scheme are taken into the derivation as assumptions to be verified later. As outlined above, a derivation activity also comprises keeping track of the different program versions and their relations. Thus an appropriate structure for docL~entation is initialized with the initial program scheme Po, marked as a whole. The mode of the current activity now is "derivation".

(3) Move markings and apply rules (cf. 11.3.1.):

Now, a sequence of elemantary rules is successively applied to Po yielding a sequence P1, P2,.'., Pn of intermediate program versions. Any individual rule application, causing a transition from Pi to Pi+1, is preceded by an appropriate movement of the marking that indicates the subterm where the respective rule is to be applied. The rule application itself consists in matching the marked subterm against the input scheme and replacing i t , in case of a successful match, by the correspondingly instantiated output scheme, thus producing the new program version Pi+l and the correspc~ngly instantiated applicability conditions. In addition, a set of formulas representing the relevant ~nformation about the environment of the marked subtem is computed and is used to strengthen the set of antecedents of each applicability condition. Each movement of a marking and each application of a rule is also recorded in the doc~entation structure; the relevant information I i for the i-th derivation step consists of - the rule that has been used,

the semantic relation bei~een Pi and Pi+l (here indicated by an arrow), the instantiated conditions ensuring the correctness of the transition, and possibly a comment explaining the intention with this individual step.

Page 58: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

50 I l l . 1 Informal requirements

After having reached version Pn, the documentation of the development may be sketched as follows:

Po

I o

P1

I I

In_ 1 Pn

(4) Deduce inference (cf. II.3.2.):

In this step, from the development as obtained in the previous step an inference of the form

Po

Pn is extracted, where AC is a set of clauses (cf. II.1.1.3) which is the union of all the (instantiated) conditions contained in the I i above.

(5) Simplification of the applicability conditions (cf. II.3.3.):

Our next efforts aim at simplifying the set AC of applicability conditions obtained in the previous step •

For each of the individual clauses C i e AC that is to be simplified, a corresponding goal Feduction is started. This means that the goal to be reduoed is initialized with C i . At the same time, a sequential structure, the proof record, for keeping track of the individual reduction steps is installed. The mode of the current activity is now "reduction", while the previous "derivation" activity is made "pending" (since the intended reduction is done relative to this derivation),

In a sequence of individual steps the clause C i is reduced to a set of simpler ones. Each of these individual steps is done according to a user-determined inference, relative to a fixed given set of axioms (e.g. the fundamental properties of the language in which the program schemes are formulated), and noted in the proof record. The final set of subgoals together with the original goal C i

constitute a valid inference which is returned to the "pending" derivation activity as the "Fesult" of the reduction activity. Then the pending derivation activity is resumed. (Note that this means that any information that has been locally available during the reduction activity, e,g. the proof record, now is no longer available~ For this reason, any information that is to be used later on has to be saved by the user before he finishes the reduction activii~/,)

Page 59: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . l . 2 Example: A f i c t i t i o u s session with the system

51

(6)

(7)

In i~e derivation, the inference resulting from the reduction may be used for simplifying AC to AC(1), e.g. by using the meta-inference "cut", which, technically, means that a new inference of the form

Po

¢ AC(1)

Pn is obtained. I f AC(1) can be further simplified, another series of steps like those just outlined is applied, until an inference "new-rule" of the form

Po

¢ AC(n)

Pn

is yielded such that the user cannot or does not want to simplify Ac(n) any further.

Conservation of the developed rule:

The inference "new-rule" is stored in one of the catalogs; in order that i t can be used in other sessions with the system, this "updated" catalog is written onto some external file.

End of the session:

The system orderly "closes" all "open" activities and stops by giving an appropriate message.

Page 60: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

52

111.2 Formal specif icat ion of the system core

2. Formal specif ication of the system core

The ~stem core is to provide basic tasks which are the semantic pri~tives for user commands. In this way, a strict separation of external appearance and internal organization is achieved.

Within the informal requirements (cf. 1.2) we have alrea~ marked important objects (in boldface) and operations (underlined). By further analysing the informal requirements using the methodoloc]y outlined in [Partsch, Laut 82] or [Partsch, Pepper 83], and incorporating (by now standard) knowledge about interactive systems, we come ~p with a gross structure of the system that may be sketched as follows:

~ ~ tasks~, - - ~ p r e s s i o n s over~ ~+ responscs_~" U abstract tasks,, j

t reactions + f ~- - - " k~output ] ~demands

I KNOWLEDGE BASE

Within this diagram the following main components can be identified:

The user environment As in the prototype, this component is to manage the user/system interaction. A typical task is the realization of the user/system communication by activating translations between external and internal representations.

The system core This central co~Ix~nent summarizes different tasks, e.g. for dealing v~th program schemes and their manipulation by transformational expressions, for simplifying applicabili~ conditions, or for handling the different data bases. Its main functions ~nTl be initializing and activating system-specific operations, keeping track of different internal system states, and preparing reactions of the system to be conveyed as output to the user by the user environment.

The kn~ledge b~e There are various data bases (collectively referred to as the "knowledge base"), each consisting of a number of catalogs, e.g. for - (global or local) transformation rules - (pre-defined or user-defined) ~stract types, realized as signatures and

transformation rules that correspond to the axioms - (tem~ora~ or permanent) program schemes - program developments (development tree)

Page 61: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.2.1 Fundamental design decisions

53

2.1. Fw~ammtal design dB~isions

The specification of the CIP transformation system that is presented in the following sections was influenced by a number of important design decisions. Presenting these decisions and discussing possible alternatives below is intended to provide insight into the overall system design and thus to help in understanding the specification.

2.1.1. General design decisions

The general design decisions address fundamental questions about the underlying theory, about the basic model of the system, about the "vie~Ix~nt" to be taken in the specification, as well as organizational questions (i.e. which parts of the system as sketched in sect. i actually should be specified) and questions of mere representation.

Underlying t ~ . ~

As already mentioned, the specification is based on a ~Iculusof~~t~o-level~Hom~clauses (cf. Part I I ) . We state clearly that this decision is to be seen as a compromise beip~een generali~ of an approach and complexity of the resulting system. This decision is not based on theoretical results, but exclusively relies on the specifiers' (and other people's) experience. We are fully aware that i t is possible to construct {in our opinion artificial) situations where this restriction is too narrow. But we have not yet encountered such a situation in the great number of case studies that have been published t i l l today.

Basic model of the system

As the basic model of the system specification we have chosen a s t a ~ s i ~ o n ~ m ~ l rather than a general system of communicating processes. First, the communication in a transformation system is of a very restricted form, viz. a "dialogue", the basic form of communication in an interactive system which can be v ~ adequatly modelled with a state transition approach (cf. [Kupka, Wilsing 73], [Partsch 83]). Second, we feel that the theory of systems of general communicating processes is not yet satisfactorily consolidated. In particular, nearly all the existing approaches (e.g. CSP [Heare 78], CCS [Milner 80], or AMPL [Broy 83]) all lack sufficient methodological support {especially appropriate transformation rules) that would guarantee a smooth and successful development of the specification into a running version.

Viewpoint of ~ s~fication

On the basis of Part II, i t would have been a comparatively easy exercise to give a fomal system specification reflecting the underlying theory. However, for obvious reasons, we decided to specify the u~r's~~ev~of thes~stem rather than the theoretician's view.

User discil~liu~

Rather than being able to do anything at any time (which sooner or later would end in hopeless confusion) the user can work with the system only in a very disciplined way (such that he should always be able to keep track of his current activities). This mainly is reflected in the particular structure of the "state":

Under all thinkable circumstances the system should be in a safe state. Although this prohibits sophisticated error recovery and repair mechanisms and maybe slightly decreases the system performance,

Page 62: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

54

I l l . 2 Formal specif icat ion of the system core

i t certainly increases its robustness.

Rather than having one gigantic monolithic data base where any piece of information is kept, the system provides a imp-level structure of entity-specific catalogs which should help the user in structuring his data.

Restriction to the system core

A full system, as outlined in the informal requirements, is a huge software project. Due to limited resources (especially of manpower), we decided to concentrate on the ~s~m~core~ and abstained from also specifying (and developing) a comfortable user environment or a more sophisticated data base mechanism - in particular, since other people certainly have more experience in these specific areas. Nevertheless, the core has been specified with a particular emphasis on modularization such t~at adding an interface module or replacing our "data base module" by a richer one could be done without affecting other parts of the system. In a sim~lar way a module for handling transformation algorithms can be added as soon as the notion of transformation algorithms is sufficiently clarified. Moreover, the selection of operations provided by the system core was guided by the assumption that there will be a user environment that can handle compositions of these "elementary" operations through an appropriate command interpFeter.

Representation of the specification

The design of the system is strictly hierarchical. On the one hand, this results in very clean interfaces of the abstract types in the specification (and, hence, in clean module interfaces in the implementation). On the other hand, the specification of quite a number of operations (in particular those in the type SYSTEM-CORE) appears rather trivial, since they merely 'qift" operations from "lower" types. The hierarchy is constructed and presented in a strict top-down manner.

For formulating the specification we have chosen a lq~raic data~.~s~ denoted in the "PASCAL variant" of ClP-L (cf. [Bauer et al. 85]) with a few, trivial notational extensions (cf. 2.2 below). Choosing the pascal-like style was primarily motivated by the ultimate goal of deriving a running version of the system in (orthodox) PASCAL (or C).

2.1.2. Technical design decisions

Apart from the global design decisions just discussed, the system specification is based on a number of decisions of purely technical nature. Some of these technical decisions will be discussed in the sequel, others within the specification when appropriate.

Modes of activity

The system provides three modes of activity: neutral, derivation, and reduction. Each of the latter two modes provides typical operations that are not available in other modes. Thus, in "derivation" mode only operations related to program development are allowed, whereas "reduction mode" summarizes operations typical for proofs or the reduction of assumptions. But there are also a number of operations available in either mode - this can be even made explicit by switching to "neutral mode". The idea of system modes, their number, and the choice of just these three is a consequence of the above (additional) safety requirement.

Page 63: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 o l Fundamental design decisions 55

Structure of the state

The system state is a triple consisting of the "current" activity, a stack of "pending" activities and a collection of catalogs, the "knowledge base". Again, this organization, in particular the stack-like administration of nested activities, is a consequence of the above safety requirement. Other administrative forms have been discussed thoroughly, but finally have turned out to be not only much more complex, but also far less intuitive than the stack organization.

Separation of assumptions and inferences

Within each activity a (local) catalog of assumptions and inferences is kept, where inferences are globally valid rules and assumptions are not yet verified assertions. Theoretically this distinction is superfluous, since every assumption could be made into a tautological inference. From the user's point of view, however, the distinction should help in not losing track within an activity.

Algebraic t~es

The system is based on the scheme language view of programming languages. Thus the main purpose of algebraic t~es is to provide an environment for expressions (by their signature) and a stock of rules for the primitive operations (by their axioms). Therefore, algebraic types as they appear in CIP-L do mt appear as entities within the system. Rather, their axioms are translated into inferences which are kept in appropriate catalogs.

Total operations

To keep the system always in a stable state, all operations available at the level visible to the user are ~ l func~ons~: partialities are dealt with internally by the system core by means of suitable test operations and by using error messages. However, in order to allow flexible compositions of these operations within the user environment, the respective test operations are also made available.

Language-independence

The specification of the system, as given below, is completely language-independent and thus incomplete in some respects: For a particular language, the types LANGUAGE (cf. 2.9.) and PRED-SYMB (cf. 2.8.) still have to be instantiated appropriately. Algorithms for calculating the unresolved context conditions (cf. 2.8.) for schemes as well as the relevant environment information (cf. 2.7.) for marked terms have to be provided. Furthermore, a "composition table" for semantic predicates has to be given in ~e ~ype REL-COMP (cf. 2.7.) and a set of basic language-dependent inferences has to be supplied via appropriate catalogs.

Development tree and proof chain

In a derivation activity, the system internally maintains a tree of program versions, decorated with information about the history of the development, to keep track of program developments. This tree organization again tries to reflect the user's wishes by exhibiting the logical structure of a development and by keeping explicitly track of alternative derivations ("fannqy tree" of programs). Of course, i t also allows backtracking in the developments.

Page 64: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

56

111.2 Formal spec i f icat ion of the system core

In connection with reductions, alternative reductions do net make as much sense, since the user ultimately is only interested in one resulting set of subgoals. Therefore, for documenting reductions, only a "preof chain", i .e. a temporally ordered sequence of proof-steps, is provide. This proof-chain also records all relevant information, but accessing the information can only be done by temporal rather than by logical relationship.

Meta-inferences

Meta-inferences are available in the system not as objects but only as built-in operations. Having them as objects as well would have caused a tremendous increase in complexity, but no gain in power.

Catalogs

The basic entities of the knowledge base are named catalogs which are sets of named and anonymous objects. Providing this liberality was motivated by the fact that referencing objects by name is convenient, but not everything needs to be named.

For reasons of comprehensibility we have decided to use entitiy-specific catalogs in the system. At least with respect to the visible operations this would have implied defining several nearly identical copies of all catalog operations, just working with different kinds of objects. Therefore, we introduced the notion of "gro~" for further distinguishing different types of catalogs without explixit duplication. As an additional advantage the concept of "catalog" can be defined for a unique type ENTRY and also has to be implemented by only one module.

Input and Output

In order to be independent of particular external representations, we assume a user environment that is able to translate external representations of objects into internal form. Similarly, the execution of every system command generates some abstract objects which are to be translated into their external representations by the user environment. To this end we assume that in defining such a user environment every object sort s in the specification is equipped with ~ operations parse-s and unparse-s that effect the translations from external to internal form and vice versa.

For operations that output whole collections of entities we have decided to use sequences rather than sets, since most output devices show a sequential behaviour, and also access to the individual members becomes much easier.

2.2. Preliminary ~ m ~ on the fon~1 specifica~on

2.2.1. Structure of the specification

A formal specification of a transformation system, as outlined in the previous sections, is complex by nature. Therefore, we have tried to ease understanding not only by choosing mnemonic identifiers, but also by adding additional comments whenever we fel t them appropriate, and by using visible aids for structuring.

Page 65: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.2.2 Prel iminary remarks on the formal spec i f icat ion

57

To support comprehensibility further we indicate the overall structure of the entire system by a hierarchy diagram of the specification:

SYSTEM-CORE

D E R I V A ~ U C T I O N ~TALOG-BASE

IN~~ The arcs in this diagram represent proper base~ relations, i.e, those where the respective upper type uses both sort(s) and operations of the respective lower one. Simple base~ relations where only some sort has to be known are not indicated. Furthermore, subordinate elementary types such as STACK, GREX, PNAT, STRING, or BOOL are also not explicitly mentioned; for their definitions we refer to [Bauer et al. 85].

Furthermore, in every subsequent specification we use the convention that all visible operations are marked by boxes rather than collected into a list of constituents.

The specification is given such that most operations are defined in a sufficiently complete way (cf. [Guttag 75], [Wirsing et al. 83]); the few exceptions are explicitly mentioned for each ~ype. This ensures that the type hierarchy is sound.

2.2.2. Remarks on notation

For brevi~ we have used a few notational extensions in the ~ language of CIP-L which are beyond those given in [Bauer et al. 85]. We now give definitional transformations for them thus showing that they de not add to the power of "pure" CIP-L.

(i) t where x I : m I = t l ; ... ;Xn :m n -= t n

l e t x 1 : m 1 -- t l ; . . . ; X n : ~ ~- t n i n t

(2) let x I : m 1 ~ t I in t

I t i l t 1 for xl]]

Page 66: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

58 I l l .2 Formal specification of the system core

(3) let x I : m 1 - t l ; . . . ; x n : m n - t n in t

let x 2 : m 2 ~ t2{[t I forxl]~ ; ... ; x n : m n - tn[[t l f o rx l~ in tFFt l fOrxl~

(4) t ~ tl{f(b~at x : m I$ P]]

I x : m II P /~ t =

/~ OCCURSFFy in p~ / o OCCURSIFx in t1~

.( KINDI~tl]I --" n

\ IS-EQUAL-PRE ~ eq_m, roll \IS-E~AL-PRE[Feq n, n]~

\ V x : m ; y :m--If (eq_m(x,y) ~ eq_n(tl~xll, tiFFy]]) )

tlEX]) V x : m ; y : m II (p A p~yforx~ ~ eq_m(x,y) )

A special case of (4) is the following rule:

(5) t ~ Ibat x : m II P

p{[tforx~ ~ true, V x : m ~ (p ~ ecLm(x, t) )

IS-EqJAL-PRE IZ eq_m, roll

(6) t -- { x : m tl p}

I JlS-EC~AL-PRE ~ eq_m, ml) ~ * OCCURSEs in p~

ba~bn ( ~et, . 6 . . . . . ) frQm ~(m, eq_m) , t ~ thats : miEet ~ ( V x : m ~ x e s~=~p )

(7) { f ( x , y ) liP }

......... i { z : p II ~ Y : n ItPA eq_p(z, f(x,y)) }

KNOWN = {x} - - - - \ K I m ~ f l l = ftmction (m, n) p,

\IS-E~UAL-PI~ IF eq_p, p])

For a formula F (not a boolean term! ) we define:

Page 67: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 .2 Preliminary remarks on the formal specification

59

(8) t m F

t • tnJee*F

I f FI, ..., F n are pairwise disjoint formulas, we abbreviate the following set of conditional formulas

F 1 ~ t i t I

F n ~ t ~ t n

by the shorthand notation

t ; i f F l t h e n t 1

[l F2 tlmm t 2

o" F+n t,., emlif

Many object kinds in the specification are defined by variant record types. The corresponding equality tests are defined component~se by variant; thus, in order to avoid lots of trivial axioms defining these equality tests, we simply name i~em and indicate the equality tests for the components on which they are based, Thus, e.g.

~ e t (eq-t) =+ variantl rec~ sl: ~ (eq~) ; s2: m~ (eq-m2) e m ~ I variant2 re~Lw~ s3:m3 (eq-m3) e ~

is equivalent to

t • variant1 record sl: mE ; s2: m~ endremor(l I variant2 record s3:,8 e ~ ,

f ~ m eq-t ( xl, x2 : t) : Imol ,

laws eq-t(tl, t2) i f t l is variant1 A t2 is variant1

then eq-ml(s1(t~), sl(t2)) A eq-m~(s2(tl), s2(t2)) [] t l is variant2 A t2 is variant2

~Km e ~ ( ~ ( ~ ) , s3(t2)) else false

er~f

Page 68: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

60

111.2 Formal spec i f i ca t ion of the system core

We also introduce the possiblli~ of naming the valiant tests in modes:

(9) ~ m ~ v l ~ i s l reoJ4p l :m~endrec°rd ) ... ) Vn test isl record pn : % encW~cord

include SU%(m I .. . . . %)

as (m, Vl, is1, pl,...,Vn, iSn, pn )

For sequences and sets we introduce standard notations:

Standard notation for sequences:

(i0) <t I . . . . . tn>

<t1> ~ ... ~ <%>

Standard notation for sets:

(11) { t1, . . . , t n}

{t 11 U ... U {t n}

Occasionally, in instantiating and renaming primitive types, we introduce ~ synonymous identifiers for an operation by using idl slfn id2 in the respective instantiation. Finally, we mark those sorts, constants, and functions of a type, which are visll)le constituents, i.e. available to other types, by putting them in a box like _~, [ ] . Therefore, we drop the often quite long explicit l ist of constituents.

Page 69: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 3 The system core

61

2.3. The ~lmm o~e

The abstract ~ S Y S I ~ constitutes the highest level of abstraction in the specification of the system core. I t provides all (abstract) elementary operations from which the actual user commands are composed and made available to the user via an appropriate user environment.

We envisage a command interpreter in the envimnm~qt part of the system that serves the follovAng

purposes: (i) provide a convenient ~ntactic form for the various commands (possibly menu-directed); (i i) allow compositions of elementary tasks into single commands (possibly definable by the user); ( i i i) regulate access-rights to catalogs etc. (protection mechanism).

Since the type SYSTEM-CORE is the basis for the connection of the system core to the environment, every operation has to effect a well-defined state transition (possibly the identity) as well as a result (possibly the dumnly no-result) and an abstract output (possibly an error message). In particular, all its operations have to be total.

In addition to this totalization, the only purpose of the type SYSTEM-CORE is to collect those operations that shall be visible to the user environment. Hence, in the specifications of the various operations we essentially just '1ift~' the corresponding operations from the other abstract types. In order to obtain an explanation of these operations one therefore should consult the respective basic types.

The specific activities to be performed in the system fall into t~o major categories:

- proper transformation activities; - manipulation of the knowledge base.

The ~ SYSTEM-CORE has a fairly simple (hierarchical) structure:

[SYSTEM-CORE i

PNAT INFERENCE OUTPUT ~ G E

In this diagram (as in all following ones) the t j~s marked by boxes are those defined in the respective section. A solid line between two types indicates a proper base(Ion relation.

Page 70: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

62 I I I . 2 Formal specification of the system core

The operations of the SYSTEM-CORE produce ,~ffec6, i.e. triples each consisting of a new state, a (pFOper or improper) re, I t , and an otFqmJt. For reasons of readability we denote the constructor of tl~se triples by the terna~ infix operator .+.+. I t is possible to access the components of an effect using operations s (state), r (result), and o(output). The operation show-result transforms the result of an effect into an outpJt.

===*/

~ F ~ , F ~ , ~ , I T S , mAT,

/* . . . . . . . . . . . . . . . . . . . . . . .-===./

/* DATA ~ ~ #J~(ILI~RY OPBIATIONS */

~ • make-effect record [ ] : stzlte ;

[ ] : ~ e ~ ,

flm%-ti~ .+.+. ( state : ~ ; result : result ; output : output ) : effect,

laws state + result + output = n~i<e-effect(state, result, output),

/* ==*/

A proper result may be any of the entities manipulated by the system (except a state). We also include the improper result no-result. Results serve to provide actual parameters for calls of system functions.

~ F ~ - -

cat-res record ~ : ~l~ ~ ) inf-res record F ~ : inf~owie endrecortl ) cl s-res record ~ : clause endreo~ 1 scl-res record ~ : set-of-clause emJreoc~ I ins-res record FT~ : i n s t ~ em(Irecom~l l

m - ~ ~ ~ : ~ o f - - , ~ ~ I trm-res record ~ : tern endrec(~ I pna-res record ~ : l ~ t ~ec~w~l I grp-res , e ~ ~ : group ~ l nm-res r e c ~ I"~-'l : nine mdmc,~ l sna-res record ~ : se(iJ-of-~ end~r( l I

Page 71: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 3 The system core: Type EFFECT

63

ent-res record | : ~ ~m(lreclm~l I sen-res ~ , i ~ : s e ~ - e ~ r y ~-~eco~! I s~-res rec~d ~ : s e ~ x m ~ e , ~ ~ I no-result ,

function ~ ( res : ~=sult ) : boo] ,

laws is-proper(res) = ~ res is no-result ,

I* . . . . . . . . . . . . . . . . . . *I We assume a function edit that converts a result into output. A function show-result is used for displaying the result of an effect as output.

f ~ t i ~ edit ( r e~ I t ) : output,

<<the axioms for this function depend on the concrete system instantiation>> ,

function lshow-result) ( e : effect ) : effect,

la~s show-result(e) = s(e) + r(e) + edit(r(e))

The ~ype SYSTEM-CORE now provides the various commands t ~ t achieve effects. For easier comprehensibili~ i t is divided into several types corresponding to the various kinds of commands. Each of these types in turn is based on EFFECT.

base,~ ~ , ~ , ~ , [DEV'mEE-COMI,

Page 72: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

64 I l l . 2 Formal specif icat ion of the system core

There are three system modes: neutral, derivation, and m~J~t-ti~. But a number of tasks can be performed in any of these modes:

performing meta-inferences, such as cut, importation, exportation, instantiation, generation of tautologies, extension or certain combinations of meta-inferences such as antecedent-addition postulating claims or returning inferences to the previous pending activity, or asking for the number of pending activities.

Furthermore, the system allows some orgamizational activities. These are: start-system initializes the system, quit closes the system.

ab~ra~pe F ~

/ * =

~ F ~ , ,

/ *

. . . . . . . . . . . : = = = : = = = = : = = = - - - = = = : = = _ - = = = = = = = . . . . - _ : . /

. . . . . . . . . . . . . . . . . . . . . . . . . . _ - . /

/* OR~,~IIZATIOII~ ~ */

When the system is started, i t is in neutral mode.

I start-system] : e f fect ,

l a~ start-system ~ init-state + no-result + answer(ready),

, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * I

f u m t i o n l - ~ T l , ( z : s ~ ) : o u t l ~ ,

]~bsquit(z) ~ end-message,

/ * META-mFB~}~ES * /

As already mentioned before, there are three system ~KxJes: neutral, derivation, reduction. But a number of tasks can be performed in any of these ~ e s .

The following operations are 'qifted" versions of operations that are specified in the ~ype II~-EREI~CE. The operations add-to-inf-actual and add-to-cls-actual update particular system-provided actual catalogs of inferences and clauses (see type STATE).

Page 73: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 3 The system core: Type GEN-COM

65

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f ~ i o n add-to-inf-ac~l ( i : i I ~ ; z : state II addable-to(inf-actual, conv-inf(i), cat-base(z)) ) : state ,

|aws add-to-inf-actual(i, z) m Feplace-cat-base(new-base, z) where new-base : cat-base ~ add-to(inf-actual, conv-inf(i), cat-base(z)) provided addable-to(inf-actual, conv-inf(i), cat-base(z)) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ * /

fl~Lt.i~ add-to-cls-actual ( c : clause ; z : state H

addable-to(cls-actual, conv-cls(c), cat-base(z)) ) : state ,

I ~ add-to-cls-actual(c, z) ~ replace-cat-base(new-base, z) w~m-e r~-base : cat-base i add-to(cls-actual, conv-cls(c), cat-base(z)) provi(E~l addable-to(cl s-actual, conv-cl s(c), cat-base(z)) ,

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

ftmction I.perform-cut! ( i l , i2 : i m ~ ; z : s-tai~ ) : effect ,

law~ perform-cut(il, i2, z) = i f cutable(il, i2)

then add-to-inf-actual(new-inf, z) + inf-res(new-inf) + answer(done) w ~ e new-inf : inference - cut( i l , i2)

FI ~ cutable(il, i2) them id(z) + no-result + answer(not-curable)

endi f ,

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _*/

f~mction Iperform-imp~'~ionI ( cl : clause ; inf : inference ; z : state ) : ef fect ,

I a w s perfonn-i~Dortation(cl, inf, z) i f importable(cl, inf)

then add-to-inf-actual(new-inf, z) + inf-res(new-inf) + answer(done) where new-inf : inferemce ~ import(cl, inf)

l] ~ importable(cl, inf) them id(z) + no-result + ans~v~r(not-importable)

endif ,

Page 74: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

66

I l l . 2 Formal speci f icat ion of the system core

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f~mctim l,~..rfonmexportationl ( cl : clause ; inf : iafe~-emce ; z : sta~e ) : effect ,

]aws perform-exportation(cl, inf, z) i f exportable(cl, inf)

then add-to-inf-actual(new-inf, z) + inf-res(new-inf) + answer(done) ~ - e new-inf : inference ; export(cl, inf)

(] ~ exportable(cl, inf) then id(z) + no-result + answer(not-exportable)

e ~ i f ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /

f~mctim Iperform-instantiationl ( inf : iafeTe-Le ; inst : i~bn~e ; z : stalin ) : ef fect,

laws perform-instantiation(inf, inst, z) add-to-inf-actual(new-inf, z) + inf-res(new-inf) + answer(done) ~ L ~ new-inf : infemBnce = inst-inf(inf, inst) ,

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ * /

flJ1ction I generate-tautology t ( cl : clal~e ; z : state ) : effect ,

laws generate-tautoloc~(cl, z) -- add-to-inf-actual(new-inf, z) + inf-res(new-inf) + an~er(done) where new-inf : infere-~e ; make-tautology(cl) ,

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f~mction IPerfonn-extensionl ( inf : ia[~e-ce ; clauses : set-of-clause ; z : s i ~ ) : ef fect ,

|a~ perform-extension(inf, clauses, z) add-to-inf-actual(new-inf, z) + inf-res(new-inf) + answer(done) ~ - e new-inf : inference ~ extend-inf(inf, clauses) ,

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ * /

fLmctim IPerfonn-antecedent-additionl ( inf : i , F ~ ; sc : set-of-clau~e ; sf : set-of-fon~ula ; z : stai~ ) : ef fect ,

laws perfonn-antecedent-addition(inf, sc, sf, z) = i f addable(inf, sc, sf)

then add-to-inf-actual(new-inf, z) + inf-res(new-inf) + answer(done) ~ new-inf : i . ~ L e -- add-antecedents(inf, sc, sf)

[l ~ addable(inf, sc, sf) id(z) + no-result + answer(net-addable)

e ~ i f ,

Page 75: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.2.3 The system core: Type GEN-COM

67

/ * ~/

/* ( IAI ]~D I } F ~ B [ I ~ R T I ~ */

f~,~tion ~ (c l :clame ; z : s t a t e ) : e f f e c t ,

laws claim(cl, z) add-to-cls-actual(cl, z) + no-result + answer(done),

function I retum-inference[ { in f : i . ~ w : e ; z : state ) : e f f e c t ,

laws return-inference(inf, z) : i f nmlber-of-acts(z) > 2

add-~Tx)-prev-act(inf, z) + inf-res(inf) + answer(done) [I nun~er-of-acts(z) = 1

t#mm id(z) + no-result + answer(no-previous-activity) endif,

/ * . . . . . . . . . . . . - . . . . . . . . . . . . . * I / * STATUS mFOR~TION * /

f~mction I get-activity-!evel I ( z : state ) : e f f e c t ,

]am~activity-level(z) = id(z) + pna-res(number-of-acts(z)) + answer(done)

Page 76: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

68

I l l . 2 Formal specif ication of the system core

The neutral ~ is a mere organizational help for the user: He should enter this mode when he intends to just manipulate his knowledge base (clean-ups, reorganization, etc.), so that he does not risk to do any harm to his previous derivations/reductions. I t should be noted that anything that can be done in neutral mode can also be done in the other modes. When the system is started, i t is in neutral mode.

*/

function I start-neutrall ( z : stai~ ) : effect ,

|aJe~start-neutral(z) ~ add-neutral(z) + no-result + ans~r(dene)

function l end-neutralt ( z : stai~ ) : effect,

laws end-neutral (z) = i f neutral-mode(z)

them remove-activity(z) + no-result + answer(done) else id(z) + no-result + answer(not-neutral-mode)

e ~ f

Page 77: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 3 The system core: Type DERIV-COM 69

Derivard~ indicates the system mode for the transformation of a given program (scheme) into new programs (program schemes). The system performs the various transitions by applying formal rules. The operations are:

perform-rule-application applicable perform-assumption-application

perform-condition-reduction condition-reducible perform-all -conditions-reduction

applies a rule to the current actual program term, tests whether a rule is applicable, applies an assumption (instead of a rule) to the current actual program term, allows simplification of the current applicability condition, tests the preconditions for condition reduction, allows simplification of all applicability conditions.

*/

*/

/*

One of the i~o genuine system tasks is the transformation of a given program (scheme) into new programs (program schemes). The system performs the various transitions by applying formal rules, and i t records the derivation process in a tree of program versions.

Consequently, there are further operations for the movement in and manipulation of these derivation trees.

Finally, one must have the possiblility to mark a subterm of a given program (scheme) in order to indicate the position, where the next transformation is to be applied.

The following operations are essentially 'qifted" versions of operations from the type DERIVATION. The operation update-deriv just performs a selective updating of the system state: The derivation component is replaced by a new one (see the type STATE).

/~ I~IDPER DERIVAI'I~ (DOVMANI)S */

A dorivation of a program (scheme) is initiated by the user with the operation start-derivation. The term from which this derivation starts is either typed in by the user, taken out of some catalog, or, most frequently, a fragment extracted from some enclosing program.

f~mction J start'derivation ( term : 1~mrm ; z : sta~ ) : ef fect,

laws start-derivation(term, z) = start-deriv(term, z) + no-result + answer(done),

Page 78: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

70

I I I . 2 Formal specif ica~on of the system core

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*/

f ~ i ~ lend-derivationl ( z : s i ~ ) : effect,

|a~ end-derivation{z) i f deriv-mode(z)

then remDve-activity(z) + no-result + answer(dlme) {] ~ deriv-made(z)

then id(z) + no-result + answer(not-derivation-m0de) e ~ f ,

.==_--====:==== . . . . . . . . . . . . . . . . . . . . . : = . /

The basic transformation activity is achieved by the operations perform-rule-application and _perform-assumption-applicatio n. I t consists in applying a rule to the actual (marked) subterm of the current derivation. Here a rule can be given either in the form of an inference or in the form of a clause ("assumption"). The parameter k serves for determining the extent of the subterm; for details see the types DERIVATION, MTERM, and TERM.

f~mcti~ Iperform-rule-applicati"~l ( rule : i~-~-Le ; k : pfw~t ; z : sLa~ ) : effect , f~mction lapplicablel (rule : inference ; k : p ~ ; z : stai~ ) : boo! ,

laws applicable(rule, k, z) = deriv-mode(z) A is-applicable(rule, k, derivation(z)) ,

perform-rule-application(rule, k, z) i f applicable(rule, k, z)

then update-deriv(new-deriv, z) + no-result + answer(done) ~-,~e r~w-deriv : derivation ~ rule-application(rule, k, derivation(z)) ;

rl ~ deriv-mede{z) id(z) + no-result + answer(not-derivation-mede)

[l deriv-made(z) A ~ applicable(rule, k, z) them id(z) + no-result + answer{rule-not-applicable)

emdif,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -*/

~ Iperfo~ssumption-applicationl ( clause : clause ; k : pnat ; z : stai~e ) : effect, ft~Liom assumption-applicab-F~j ( clause : clause ; k : pnat ; z : sta~e ) : bool ,

laws assumption-applicable(clause, k, z) = makable-rule(clause) A applicable(make-rule(clause), k, z) ,

perform-assumption-application(clause, k, z) i f assumption-applicable(clause, k, z)

b ~ perform-rule-application(~e-rule(clause)~ k, z) {] ~ makable-rule(clause)

id{z) + no-result + answer(not-makable-rule) II makable-rule(clause) /~ ~ deriv-mode(z)

Page 79: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 3 The system core: Type DERIV-COM

71

id(z) + no-result + answer(not-derivation-mode) Fl makable-rule(clause) /L ~ deriv-m~de(z) A ~ applicable(~Bke-rule(clause), k, derivation(z))

then id(z) + no-result + answer(assumption-not-applicable) emdif,

, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*/

• _ r a m _ _ ~ function I perform-infe~e-deduc'ti ( t : nfcmrm, z : stalin ) : ~ , ,u . : , f ~ o n ~ ( t : m ; z : s ta te) :boo l ,

]a~ deducible(t, z) ~ deriv-mode(z) /L is-deducible(t, derivation(z)) ,

perform-inference-deduction(t, z) i f deducible(t, z)

then add-to-inf-actual(new-inf, z) + inf-res(new-inf) + answer(done) where new-inf : inference • inference-deduction(t, derivation(z))

(] ~ deriv-m~de(z) id(z) + no-result + answer(not-derivation-mode)

{] deriv-mode(z) /L ~ deducible(t, z) id(z) + no-result + answer(not-deducible)

emdif,

/ * * /

The operation perform-condition-reduction allows the verification - or at least the simplification - of an applicability condition of the derivation step that currently is the focus of attention. When this applicabili~ condition appears at several derivation steps, then all i ts instances can be reduced simultaneously with the operation perform-all-conditions-reduction.

~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ V ¢ /

function I perform-condition-reducti'onl ( inf : inference ; z : state ) : effect, function Icondition-reduclblel ( inf : inference ; z : stalin ) : boo1 ,

1 ~ condition-reducible(inf, z) -z deriv-mode(z) ,

perform-condi ti on-reduction( inf, z) i f condition-reducible(inf, z)

then bl)date-deriv(new-deriv, z) + no-result + answer(done) where new-deriv : derivati(m ~ reduce-condition(inf, derivation(z))

0 ~ deriv-mode(z) them id(z) + no-result + answer(not-derivation-mode)

endif ,

Page 80: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

72

111.2 Formal speci f icat ion of the system core

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

~ L t i ~ Iperform-all-conditions-reduction] ( inf : inference ; z : sl~IJe ) : effect ,

laws perform~all-conditions-reduction(inf, z) i f condition-reducible(inf, z)

then update-deriv(new-deriv, z) + no-result + answer(dDne) where new-deriv : (E~vation ~ Feduce-all-conditions(inf, derivation(z))

n ~ deriv-mode(z) then id(z) + no-result + answer(not-derivation-mode)

endif

~ r a c t ~

Page 81: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.2.3 The system core: Type DEVTREE-COM

73

The derivation process is recorded in a dL~ivation b~e. Consequently, there are further operations for the movement in and manipulation of these derivation trees. These are:

- perform-subderivation-deletion - perform-compacti fication

- compactifiable - perform-inference-deduction

deducible - exists-term

perform-actualization get-contract get-actual -term get-all -sons get-all-leaves get-predecessor go-to-p~ecessor

- exists-predecessor

deletes a subtree in the actual derivation tree, compactifies a path in the derivation tree into a single derivation step, tests the precondition for compactification, computes a valid inference constituted by ~ appropriate nodes in the derivation tree, tests the precondition for inference deduction, tests whether a certain term is available, establishes a new actual term, yields the contract of the development, yields the current actual term, yields all sons of the current actual term, yields all leaves of the current derivation tree, yields a predecessor of the current actual term, establishes a predecessor of the current actual term as the new actual term, tests the existence of a predecessor.

I~VTREE~I

====*/

~ F ~ - ~

/*: k/

The development history for a given term is stored in the derivation tree (a fan~7y tree of program versions). This tree then can be used for a number of purposes:

several cccurences of an operator in the actual term may be distinguished by giving them different copy tags using the operation perform-copy-setting; one may position to them using the operation perform-copy-search;

- non-successful derivations ("blind alleys") can be cut of f using the operation per form-subderivation-del etion;

- one can set back to some intermediate version in order to start an alternative derivation; this is performed by the operations perform-actualization and go-to-predecesso r ( '~cktrackin~'); paths in the derivation tree that reflect too many details can be compactified using perform-compactification;

- in particular when a derivation is started from a program scheme, any connected pair of terms in the tree gives rise to a valid inference (i.e. to a new transformation rule); extracting such inferences is achieved by the operation perform-inference-deduction; finally, the user can ask the system to get the actual term under consideration, some predecessor of a given term, all sons of a given term, or all leaves of the derivation tree.

Page 82: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

74

I l l . 2 Formal spec i f i ca t ion of the system core

flmL'Li~ Iperfonn-copy-setting I ( c : copy ; p : tpos ; z : state ) : e f fec t , function Icopy-settablel ( c : copy ; p : tIms ; z : s ta~ ) : bool ,

l a ~ copy-settable(c, p, z) = deriv-mode(z) /L settable-copy-der(c, p, derivation(z)) ,

perform-copy-setting(c, p, z) i f copy-settable(c, p, z)

them update-deriv(new-deriv, z) + no-result + answer(done) whmre new-deriv : dmrivati~ = set-copy-der(c, p, derivation(z))

{l ~ deriv-mode(z) then id(z) + no-result + answer(not-derivation-mode)

[l deriv-mode(z) /L ~ copy-settable(c, p, z) id(z) + no-result + answer(copy-not-settable)

emdif,

,_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _* /

f lmct i~ I perform-copy-searchl ( c : cow ; z : s i ~ ) : e f fec t , function lunique-copyl ( c : copy ; z : slate ) : boo1 ,

laws unique-copy(c, z) = deriv-mode(z) /L unique-copy-der(c, derivation(z)) ,

perform-copy-search(c, z) = i f unique-copy(c, z)

them update-deriv(new-deriv, z) + no-result + answer(done) where new-deriv : der ivat i~ i search-copy-der(c, derivation(z))

[l ~ deriv-mode(z) id(z) + no-result + answer(not-derivation-mode)

D deriv-mode(z) /L ~ unique-copy-der(c, z) id(z) + no-result + answer(copy-not-unique)

e ~ i f ,

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - * /

f lmct i~ I perform-subderivation-deletionl ( z : s ta~ ) : effect , function l actual-is-not-contractl ( z : state ) : I)ool ,

|aws actual-is-not-contract(z) - deriv-mode(z) /L deletable(derivation(z)) ,

perfonn-subderi vation-del etion(z) = i f actual - i s-not-contract (z)

update-deriv(new-deriv,z) + no-result + answer(done) wL~-e new-deriv : ( ~ v a t i ~ ~ delete-subderivation(derivation(z)) ;

[l ~ deriv-mode(z) i ~ id(z) + no-result + answer(not-derivation-mode)

Page 83: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 3 The system core: Type DEVTREE-COM

75

I] deriv-mode(z) A ~ actual-is-not-contract(z) id(z) + no-result + answer(subderivation-not-deletable)

endif,

*: ==:=========./

The operations perform-compactification, compactifiable, ~rform-inference-deduction, and deducible assume (language-dependent) sets of relations on predicate symbols as input. I t is not intended that the user has to explicitly supply these sets. The idea is rather that there exists an app~priate catalog which is selected (probably by name) and converted to a set (cf. operation ~t-all-entm'e_s) by the user environment.

functi(m L,perform-compactification. ( t : m ~ ; z : sta~ ) : effect, f~t. i(m Fc'ompactifiablel ( t : ml;mrm ; z : ~ ) : boo] ,

laws compactifiable(t, z) • deriv-mDde(z) A is-compactifiable(t, derivation(z)) ,

perform-compacti fication ( t , z) i f compactifiable(t, z)

update-deriv(new-deriv, z) + no-result + answer(done) ,~here new-deriv : (IBrivati~ ~ cc~pactification(t, derivation(z))

0 ~ deriv-mode(z) id(z) + no-result + answer(not-derivation-mDde)

0 deriv-mode(z) /L ~ compactifiable(t, z) id(z) + no-result + answer(not-compactifiable)

emdif,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

f~mcti(m l exists-term I ( t : mbmrm ; z : stalin ) : beol ,

laws exists-term(t, z) ~ deriv-mode(z) A has-term(t, derivation(z)) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

fl~mcti~ l~rform-actualizatio-~ ( t : m I ~ ; z : state ) : effect ,

|aws perform-actualization(t, z) i f exists-term(t, z)

then update-deriv(new-deriv, z) + no-result + answer(done) where new-deriv : dm'Ivati~m ~ actualize(t, derivation(z)) ;

0 ~ deriv-mode(z) id(z) + no-result + answer(not-derivation-mode)

[] deriv-mode(z) /~ ~ exists-term(t, z) then id(z) + no-result + answer(term-not-available)

emdif,

Page 84: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

76

I l l . 2 Formal speci f icat ion of the system core

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _*/

function I get-contractl ( z : sta~ ) : effect ,

l~ws get-contract(z) -= i f deriv-mode(z)

id(z) + mi~-res(contract(derivation(z))) + answer(done) D ~ deriv-mode(z)

id(z) + no-result + answer(not-derivation-nDde) endi f ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ * /

ftmcti(m I get-actual-terml ( z : state ) : effect ,

l a~ get-actual-tern(z) i f deriv-mode(z)

then id(z) + mb~res(actual-term(derivation(z))) + answer(done) O ~ deriv-mode(z)

them id(z) + no-result + answer(not-derivation-mode) em(lif,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

function J get-all-sonsl ( z : state ) : e f fect .

l aws get-all-sons(z) i f deriv-mode(z)

them id(z) + smt-res(all-sons(derivation(z))) + answer(done) [I ~ deriv-mode(z)

them id(z) + no-result + answer(not-derivation-mode) efKlif,

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - * /

f~mlction I get-all-leavesl ( z : sta~ ) : effect ,

la~ get-all-leaves(z) i f deriv-mode(z)

id(z) + smt-res(all-leaves(derivation(z))) + answer(done) FI ~ deriv-mode(z)

id(z) + no-result + ans~mr(not-derivation-mDde) emdif,

Page 85: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 3 The system core: Type DEVTREE-COM

77

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ * /

ftmctim l~tLpredecessor-], ( k : ~ ; z : sta~ ) : effect ,

fzmcti~ [exists-predecessorl ( k : Imat ; z : sta~e ) • b(ml ,

laws exists-predecessor(k, z) ~ deriv-mode(z) A has-predecessor(k, derivation(z)) ,

get-precbcessor(k, z) - i f exists-pnedecessor(k, z)

then i d ( z ) + mbn-res(pFedecessor(k, derivation(z))) + answer(done) 0 TM deriv-mode(z)

tlmn id(z) + no-result + answer(not-c~rivation-mode) 0 deriv-mDde(z) A ~ exists-predecessor(k, z)

then id(z) + no-result + answer(term-not-available) endif ,

go-to-p~lecessor(k, z) = i f exists-p~decessor(k, z)

Umm update-deriv(new-deriv, z) + no-Fesult + answer(done) where new-deriv : derivation = go-to-pred(k, derivation(z))

0 ~ deriv-mode(z) then id(z) + no-result + a~wer(not-derivation-m)de)

0 deriv-mode(z) /k ~ exists-predecessor(k, z) them id(z) + no-result + an~er(illegal-goto)

endif

~stract~

Page 86: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

78

I l l . 2 Formal speci f icat ion of the system core

One must have the possibility of marking a subterm of a given program (scheme) in order to indicate the position, where the next transformation is to be applied. The operations are:

- perform-move - legal-reeve - set-mark - legal-mark

perform-copy-setting - copy-settable

perform-copy-search

- unique-copy

moves the marking according to a giwn direction, tests the precondition for moving a marking, sets the marking to an indicated place in the term, tests the precondition for setting a marking, allows to distinguish a subterm by a copy indication, tests the pre-condition for setting a copy indication, moves the actual position within a marked term to the occurrence of a copy indication, tests the precondition for moving to a copy indication.

~ ~ ,

/* */

The marking of the actual term can be modified either relative to the current marking (perform-move) or absolute (set-mark).

fumcti~ J perform-mov~! ( dir : (fir ; z : state ) : effect , function 11egal-movel ( dir : (fir ; z : state ) : Imol ,

laws legal-move(dir, z) = deriv-mode(z) /~ movable(dir, derivation(z)) ,

perfonn-move(dir, z) i f legal-move(dir, z)

them update-deriv(new-deriv, z) + no-result + answer(cbne) w h e r e new-deriv : d~rivati~ - move(dir, derivation(z))

D ~ deriv-mode(z) I ~ id(z) + no-result + answer(not-derivation-mode)

D deriv-rmde(z) A ~ legal-m~ve(dir, z) them id(z) + no-result + answer(illegal-move)

emdif ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

fw~t im F~-~ -~ l (pos : tIms ; z : s t a t e ) : e f f e c t , f imct i~ llegal-markJ ( pos : tpos ; z : stalin ) : bool ,

Page 87: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I i o2 .3 The system core: Type MOVE-COM

79

la~ legal-mark(pos, z) - deriv-mode(z) /~ legal-position(pos, derivation(z)) ,

set-m~rk(pos, z) - i f legal-mark(pos, z)

t ~ ~pdate-deriv(new-deriv, z) + no-result + answer(dDne) where new-deriv : (L~rivati~ = set-pos(pos, derivation(z))

{] ~ deriv-mode(z) i ~ id(z) + no-result + ans~er(not-deriv-mDde)

{] deriv-mode(z) A ~ legal-mark(Ix)s, z) then id(z) + no-result + answer(illegal-mark)

e ~ i f

e~stract~

Page 88: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

80

I I I . 2 Formal specif icat ion of the system core

Redlxctim indicates the system mode for reducing a goal to a (possibly empty) set of simpler subgoals.

The actual reduction is performed with the help of either some inference (pe_~rform-~al-reduction) or some clause (perform-goal-reduction-with-assumption). Details are described in the types REDUCTION and INFERENCE.

The initial goal and the current set of subgoals together always constitute a valid inference. The operation perform-inference-extraction yields this inference and stores i t into the actual inference catalog.

Finally, the user can ask the system to get the initial goal and the current set of subgoals.

*/

~ . ~ _ . - ~ . ~ - - - ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

"Reduction" means to reduce a given goal to a (possibly empty) set of simpler subgoals. The operation start-reduction adds a new activity to the stack; as argument i t has the goal that is to be reduced.

fimctim I start-reduction~ ( goal : cl~mp ; z : stai~ ) : effect,

laws start-reduction(goal, z) = add-red(init-reduction(goal), z) + no-result + answer(done),

, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f imcti(m lend-reductionl ( z : state ) : e f f e c t ,

laws end-reduction(z) = i f red-mode(z)

them remove-activity(z) + no-result + answer(done) D ~ red-m~e(z)

id(z) + no-result + answer(not-reduction-mdde) e ~ f ,

The actual reduction is performed with the help of either some inference (~orm-goal-reduction) or some clause (perform-goal-reduction-with-assumption). Details are described in the types REDUCTION and INFERENCE. SinnTarly to compactification, i t is assumed for goal-reduction that the "axioms", a (language-dependent) set of inferences, are kept in the system in an appropriate catalog. Again, accessing the catalog (probably by name) and converting i t into a set should be done by the user environmeqt rather than the user himself.

Page 89: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 3 The system core: Type RED-COM 81

~,~tian Iperform-goal-reductionl goal : clause ; inf : inference ; axioms: seiL-of-infemmnce ; z : stat~ ) : effect,

fimctian ~ ( goal :cIause ; inf : i n f e f ~ ; axioms : s e t - o f - i n ~ ; z : s~i~ ) : boo1 ,

laws reducible(goal, inf, axioms, z) ~ red-mode(z) A goal-reducible(goal, inf, axioms, reduction(z)) ,

perform-goal-reduction(goal, inf, axioms, z) i f reducible(goal, inf, axioms, z)

i~enupdate-red(new-red, z) + no-result + answer(done) w ~ new-red : m~luction ~ goal-reduction(goal, inf, axioms, reduction(z))

0 ~ red-~e(z) then id(z) + no-result + answ~r(not-reduction-mDde)

0 red-mode A ~ reducible(goal, inf, axion~, z) i ~ id(z) + no-result + answer(goal-not-reducible)

eno~f ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /

f ~ i o n [perform-goal-reduction-with-assumptionl ( goal : clause ; assu : clause ; axioms : set-of-iafe~-~e ; z : s t ~ ) : effect,

laws perform-goal-reduction-with-assu~tion(goal, assu, axioms, z) i f reducible(goal, make-tautology(assu), axioms, z)

Umn perform-goal-reduction(goal, make-tautology(assu), axioms, z) 0 ~ reducible(goal, make-tautology(assu), axioms, z)

Umn id(z) + no-result + answer(goal-not-reducible) endif,

/ * = = * /

The initial goal and the current set of subgoals constitute a valid inference. The operation perform-inference-extraction yields this inference and stores i t into the actual inference catalog.

/* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f i~Lion l.perfc~m-inference-extraction ( z : s - ~ ) : effect ,

laws perform-inference-exi~action(z) = i f red-mode(z)

t~Bnadd-to-inf-actual(new-inf, z) + inf-res(new-inf) + answer(done) where new-inf : i n ~ ~ inference-extraction(reduction(z))

0 ~ red-mode(z) then id(z) + no-result + answer(not-reduction-m0de)

e ~ i f ,

* : = = = . /

Finally, the user can ask the system to get the initial goal and the current set of subgoals. /~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9¢/

Page 90: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

82

111.2 Formal specification of the system core

f~Ltio. ~ ( z : sta~ ) : effect,

l ~ s get-goal(z) - i f red-mode(z)

id(z) + cls-res(urgoal(~uction(z))) + answer(done) O ~ red-m~e(z)

~ , id(z) + no-result + answer(not-reduction-mode) endif,

* _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

~ m c t i m I cjet-subgoal s l ( z : stai~ ) : e f f e c t ,

laws get-subgoel s(z) - i f ~ d - E ~ ( z )

id(z) + scl-res(subgoa]s(reduction(z))) + a n s ~ ( ~ n o ) n - red-mode(z)

them id(z) + no-result + answer(not-reduction-mode) e ~ f

m ~

Page 91: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 3 The system core: Type CAT-COM

83

The I~edge base of the system is organized into ca~logs; each of these catalogs contains e ~ of the same group; as g ~ we have terms, clauses, inferences, derivations, reductions, transformation programs, and relations on predicate symbols.

The first class of operations concerns the generating, loading, deleting, and fusing of whole catalogs. In addition, the user can ask for the names of all currently available catalogs. (For details see type CATALOG-BASE.)

On individual (currently available) catalogs one can perform the usual operations of adding, inserting, deleting, and fetching of entries. (Note that our catalogs contain named as well as anonymous elements.) ~1oreover, entries can be named and renamed. Finally, the user can ask the system to display all (all named, all anonymous) entries. (For deta17s again see ~ CATALOG-BASE.)

/ * _-=*/

*/

The knowledge base of the system is organized into catalogs; each of these catalogs contains entries of the same group; as groups we have terms, clauses, inferences, derivations, reductions, transformation programs, and relations on predicate symbols.

*==== */

/* CIJlJ~FCTI(]NS OF CATALOGS */

The first group of operations concerns the genera~ng, loading, and deleting of whole catalogs. In addition, the user can ask for the names of all currently available catalogs.

f~mcti~ lexists-catalogl ( n : name ; z : ~ ) : ba)l ,

1 ~ exists-catalog(n, z) - has-cat(n, cat-base(z)) ,

, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

fLmcti~ Igenerate-empty-catalogl ( gp : group ; n : name ; z : s i ~ ) : effect , fwlct i~ Icat-generablel ( gp : group ; n : ~ ; z : ~ ) : b(x}l,

laws cat-generable(gp, n, z) m ~ exists-catalog(n, z) ,

generate-B~pty-catalog(~D, n, z) = i f cat-generable(gp, n, z)

replace-cat-base(now-base, z) + no-result + answer(cbne) where new-base : cat-base ~ gen-empty(gp, n, cat-base(z))

FI ~ cat-generable(gp, n, z)

Page 92: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

84

I I I . 2 Formal specif ication of the system core

then id(z) + no-result + answer(illegal-cat-name) endif,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -*/

f~mction ~oad-cata!OgJ ( n : r~me ; c : catalog ; z : stalin ) : effect, f u n c t i o n ~ ( n : n a m e ; c : c a t a l o g ; z ; s t a t e ) : b o o l ,

la~ cat-loadable(n, c, z) ~ Ioadable(n, c, catbase(z)) ,

load-catalog(n, c, z) i f cat-loadable(n, c, z)

then replace-cat-base(new-base, z) + no-result + answer(done) where new-base : cat-base • load(n, c, cat-base(z))

0 ~ cat-loadable(n, c, z) then id(z) + no-result + answer(not-loadable)

endif,

*_ ........................... , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f u n c t i o n [ , ~ - ~ - - ~ ( cn : ~ e ; z : s t a t e ) : e f f e c t ,

laws get-cat-groq~(cn, z) - i f exists-catalog(cn, z)

id(z) + grp-res(cat-group(cn, cat-base(z))) + answer(done), 0 ~ exists-catalog(cn, z)

id(z) + no-result + answer(illegal-cat-name) endif.

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - * /

f i m c t i o n ] " d e l e ~ o g - - - ] ( n : name ; z : s ta~e ) : e f f e c t ,

f l m c t i ~ ! ~ t - d e l e t a b l e { ( n : ramie ; z : stai ;e ) : I x ~ l ,

laws cat-deletable(n, z) = (9 eq-n(n, inf-actual) A ~ eq-n(n, cls-actual)) A exists-catalog(n, z) ,

delete-catalog(n, z) = i f cat-deletable(n, z)

lJ~en replace-cat-base(new-base, z) + no-result + answer(done) w ~ new-base : cat-base ~ delete(n, cat-base(z))

0 eq-n(n, inf-actual) V eq-n(n, cls-actual) i ~ id(z) + no-result + answer(illegal-cat-name)

0 ~ exists-catalog(n, z) id(z) + no-result + answer(not-exists-catalog)

endif,

Page 93: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 3 The system core: Type CAT-COM

85

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

funct ion Ipet-a!!i l-catalog-namesl ( gp : g ~ ; z : s i ~ ) : e f f e c t ,

]a~get-all-catalog-names(gp, z) = id(z) + sna-res(all-names(gp, cat-base(z))) + answer(done),

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

function I fuse-catalogsl ( nl, n2, nn : n ~ ; z : sta~e ) : effect , fumcti~ ~cat-fusabiel ( nl, n2, nn : name ; z : stai~ ) : b~l ,

laws cat-fusab]e(nl, n2, nn, z) ~ fusable(nl, n2, nn, cat-base(z)) ,

)aws fuse-catalogs(nl, n2, nn, z) = i f cat-fusable(nl, n2, m, z)

replace-cat-base(new-base, z) + no-result + answer(done) where new-base : cat-base - fuse(n1, n2, no, cat-base(z))

0 ~ cat-fusable(nl, n2, nn, z) id(z) + no-result + answer(net-fusable)

emJif,

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /

/* INDIVIDUAL C A ~ * /

On individual (currently available) catalogs one can perform the usual operations of adding, inserting, deleting, and fetching entries. (Note that our catalogs contain named as well as anonymous elements.) Moreover, entries can be named and renamed. Finally, the user can ask the system to ~sPlay all (all named, all anonymous) entries.

flmction ~ (cn : n ~ ; e : entry ; z : state) : e f f e c t , function laddab1'~to-catl ( cn : name ; e : ~.t~y ; z : sta~e ) :bml ,

]awS addable-to-cat(cn, e, z) -: addable-to(cn, e, cat-base(z)) ,

add-entry(cn, e, z) - i f addable-to-cat(cn, e, z)

replace-cat-base(new-base, z) + no-result + answer(done) where new-base : cat-base - add-to{cn, e, cat-base(z))

II ~ addable-to-cat(cn, e, z) id(z) + no-result + answer(not-addable)

e ~ i f ,

Page 94: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

86

I I I . 2 Formal s p e c i f i c a t i o n o f the system core

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ * /

f tmc t i~ ~insert-entry I ( cn, en : name ; e : ~ ruy ; z : s ta~ ) : effect , function l insertable-into-catl ( cn, en : n~mle ; e : ~,bry ; z : sta~e ) : boo] ,

law5 insertable-into-cat(cn, en, e, z) = insertable-into(cn, en, e, cat-base(z)) ,

insert-entry(cn, en, e, z) =-

i f insertable-into-cat(cn, en, e, z) replace-cat-base(new-base, z) + no-result + answer(done) where new-base : cat-base ~ insert-into(cn, en, e, cat-base(z))

{] ~ insertable-into-cat(cn, en, e, z) id(z) + no-result + answ~r(not-insertable)

e m l i f ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f~mcti~m l~ le te-ent ry l ( cn, en : ~ ; z : s ta~ ) : ~r~ect ,

flmctiom I deletable-from-catl ( cn, en : ~ ; z : state ) : boo] ,

laws doletable-from-cat(cn, en, z) ~ deletable-from(cn, en, cat-base(z)) ,

delete-entry(cn, en, z) = i f deletable-from-cat(cn, en, z)

i ~ replace-cat-base(new-base, z) + no-result + answer(done)

wbeme new-base : cat-base m delete-from(cn, en, cat-base(z)) {] ~ deletable-fmm-cat(cn, en, z)

id(z) + no-result + answer(not-doletable)

e ~ i f ,

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f~w~t i~ ~ _ ( cn, en : name ; z : sta~e ) : effect ,

fmlctiom I fetchable-from-catl ( cn, en : rune ; z : s i ~ ) : boo] ,

] a ~ fetchable-from-cat(cn, en, z) ~ fetchable-from(cn, en, cat-base(z)) ,

get-entry(cn, en, z) i f fetchable-from-cat(cn, en, z)

then id(z) + ent-res(fetch-from(cn, en, cat-base(z))) + answer(done) D ~ fetchable-from-cat(cn, en, z)

id(z) + no-result + answer(not-fetchable)

e ~ f ,

Page 95: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 3 The system core: Type CAT-COM

87

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _*/

fm~tiom In am e-entry I ( cn. en : nm~ ; i : Imat ; z : sta1~ ) : : ~ r ~ , f ~ c m Inamable-in-catl ( cn, en : name ; i : pmat ; z : state ) : bool ,

laws namable-in-cat(cn, en, i , z) • namable-in(cn, en, i , cat-base(z)) ,

name-entry(cn, en, i , z) -- i f namable-in-cat(cn, en, i , z)

then replace-cat-base(rmw-base, z) + no-result + answer(done) Where new-base : cat-base - name-in(cn, en, i , cat-base(z))

B ~ namable-in-cat(cn, en, i , z) id(z) + no-result + answer(not-namable)

emdif,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _*/

f ~ o n l, rename-entry[ ( cn, oen, hen : n~me ; z : stalin ) : err~-t, fu,ction l,,rt~amable-in-catl ( cn, oen, nen : name ; z : state ) : bool ,

l a~ renam~ble-in-cat(cn, oen, nen, z) -- renameble-in(cn, oen, nen, cat-base(z)) ,

rt~ame-ent~%z(cn, o~q, ~n, z) = i f renan~ble-in-cat(cn, oen, hen, z)

i ~ ~:place-cat-base(new-base, z) + no-result + answer(done) Where new-base : cat-base ; rename-in(cn, oen, hen, cat-base(z))

~ renam~le-in-cat(cn, oen, nen. z) id(z) + no-result + answer(not-renamable)

e ~ f ,

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - * /

funct'ion ~ ( cn , en : n a m e ; z : s'taim ) : b o o 1 ,

]a~ has-entry(cn, en, z) ~ exists-cat(cn, z) A contains(cn, en, cat-base(z)) .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _*/

function [get-all-~ntriesl ( n : ~ ; z : stalin ) : effect ,

l a~ get-all-entries(n, z) _ i f exists-cat(n, z)

id(z) + sen-res(all-elemmts-of(n, cat-base(z))) D ~ exists-cat(n, z)

then id(z) + no-result + answer(not-exists-catalog) endif ,

+ answer(done)

Page 96: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

88

111.2 Formal speci f icat ion of the system core

._ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

fu,~tion I get-all-entry-namesl ( n : ~ ; z : state ) : ef fect ,

1 ~ get-all-entry-names(n, z) = i f exists-cat(n, z)

them id(z) + sna-res(all-names-of(n, cat-base(z))) + answer(done) {} ~ exists.cat(n, z)

id(z) + no-result + answer(not-exists-catalog) endif ,

._ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _* /

f~mctim I get-all-names-and-entriesl ( n : name ; z : state ) : effect ,

l a ~ get-all-nmnes-and-entries(n, z) -z i f exists.cat(n, z)

id(z) + sne-Fes(all-names-and-elements-of(n, cat-base(z))) + answer(done) 0 ~ exists-cat(n, z)

then id(z) + no-result + answer(not-exists-catalog) endif ,

* - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * I

fwlc t i~ i get-all-named-entriesl ( n : n~me ; z : state ) : effect ,

1 ~ get-all-named-entries(n, z) i f exists.cat(n, z)

id(z) + sen-res(all-named-elements-of(n, cat-base(z))) + answer(done)

0 ~ exists.cat(n, z) id(z) + no-result + answer(not-exists-catalog)

endif ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _* /

ftmction I~t-all-anonymous-entriesl ( n : name ; z : state ) : ~ { ~ t ,

|aws get-all-anonj~ous-entries(n, z) - i f exists-cat(n, z)

id(z) + sen-res(all-anonymous-elements-of(n, cat-base(z))) 0 ~ exists.cat(n, z)

them id(z) + no-result + answer(not-exists-catalog) e ~ f

+ anoint(done)

~ s t r ~

Page 97: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 4 The state

89

2.4. The state

The system state is a triple, consisting of a current activity, a stack of pending activities, and a collection of catalogs which constitutes the knowledge base. Consequently, the operations on state serve mainly for manipulating these entities.

The collection of catalogs can be obtained by cat-base and updated by replace-cat-base.

For accessing and updating the stack the following operations are available:

- add-to-prev-act adds the information to the previous pending activity; - remove-activity removes an activity frem the stack; - number-of-acts informs about the total n~ber of pending activit ies; - add-(neutral/deriv/red) adds a new (neutral/derivation/reduction) activity to the stack.

In connection with the cun~ent activity the following operations are previded:

- ( neutral/deriv/red)-mode ~ate-(deriv/md)

- derivation/reduction

gives the mode of the current activity; allows to update a (derivation/reduction) activity; yields the current derivation/reduction activity.

In addition to the above (conceptual) operations, there are some further ones of a more technical nature:

- id - init-state

yields the identity on states; establishes the initial state by generating an initial (neutral) activity and the empty actual catalogs.

The hierarchical structure of the corresponding t~pe STATE is giwn by the following diagram:

IDERIVATIONI ~ ICATALOG-BASEI

l TE~M PNAT

Page 98: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

90

I l l . 2 Formal specif ication of the system core

.,sm,m =

/ .- */

bamm~ I CATAL(X?.--BASEI, ) DERIVATION I, I - -~ - - 'T~ , l-C-~-~-l, IEm4,

. . . . . . . . . ,,,, */

/* STAIES */

The system state is a triple, consisting of a current activity, a stack of nested activities, and a knowledge base. The stack records pending activities together with their corresponding catalogs of inferences and assumptions. The knowledge base is a collection of catalogs. I t has to contain two catalogs for the inferences and assumptions pertaining to the current activity; this condition is tested by admissible.

make-state reccw~ actual-activity : activity ; stack : stack ;

F ~ : ~t-ba~ II admissibl e(cat-base)

en~+ecc~d,

/* A~ILI~RY 0PERATIONS */ /*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

flmctien replace-activity ( new-act : activity ; z : state ) : CWm , function replace-stack ( new-stack : stack ; z : state ) : state, function l replace-cat-basel ( new-base : cat-base ; z : state ) : state,

l a~ replace-activity(new-act, z) replace-stack(new-stack, z) replace-cat-base(new-base, z)

; make-state(new-act, stack(z), cat-base(z)) , ; make-state(actual-activity(z), new-stack, cat-base(z)) , = make-state(actual-activity(z), stack(z), new-base) ,

/ * :*/

/* ~'l'IVIl'IIEIS */

/*- ............................................................................................. -*/

An activity is either neutral, or a derivation, or a reduction. /*- ................................................................................................. * /

~ e act iv i ty ; neutral I tier-to-act record deriv : (E, r ivat ion endrecord I red-to-act record reduc : reduction emdmecGrd ,

Page 99: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 4 The state: Type STATE 91

/* */

/ * THE STACK * /

The stack of nested activities also records the catalogs of inferences and assumptions that belong to these activities.

~ e s tacke~ - triple n~zx~ act : activity ;

assu-cat : cata|og ; inf-cat : c~ Iog II eq-grp(group(assu-cat), cl s-grp) A eq-grp(group(inf-cat), inf-grp)

e ~ ,

I ~ ( stack, e,l)ty-stack, is-emptystack, push, pop, top, length) fru~ S T A C K ( ~ ) ,

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ * /

function add-activity ( new-act : activity ; assu : set-of-clause ; z : state ) : state,

l aws add-activity(new-act, z) = make-state(n~-act, new-stack, new-cat-base) old-cat-base : cat-base ; cat-base(z) ; old-cls-actual : catalog = select-cat(cls-actual, old-cat-base) ; old-inf-actual : catalog ; select-cat(inf-actual, old-cat-base) ; new-stack : stack

push(stack(z), triple(actual-activity(z), old-cls-actual, old-inf-actual) ; new-cls-actual : catalog - add-set-cl(assu, old-cls-actual); new-cat-base : cat-base - replace-cat(cls-actual, new-cls-actual, old-cat-base) ,

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ * /

fu,cticn add-set-cl ( scl : set-of-clause ; cat : catalog JJ eq-orp(gro~p(cat), cls-grp) ) : catalGg,

laws add-set-cl(scl, cat) = i f is-emptyset-cl (scl)

cat el m add-set-cl (scl \{cl }, add(cat, conv-cl s(cl ) ) )

wherecl :clause - arb-cl(scl) e ,d i f ,

Page 100: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

92

I I I . 2 Formal specif ication of the system core

/* OP~ATmWSFORALLACTIVIT~S */ 9¢ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~¢/

The operation number-of-acts yields the n~ber of pending activities (including the actual activity). Thus the system has the invariant property that nu~r-of-acts is at least one.

function I number-of-actsl ( z : s i ~ ) : I~mt,

laws nun~er-of-acts(z) - lengi~(stack(z)) + 1 ,

/._-_=~ ....... ~ ._--_-==~===~==~_____-____===:==./

The operation remove-activity makes the previous pending activity into the actual one. Note that this means in particular that the old catalogs of actual assumptions and actual inferences are restored.

¢c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . @c/

function I remove-activity] ( z : sta~ I] nu~r-of-acts(z) ~ 2 ) : s i ~ ,

laws remove-activity(z) ~ make-state(saved-activity, pop(stack(z)), restored-cat-base) where saved-activity : activity • act(top(stack(z))) ;

saved-inf-cat : catalog -- inf-cat(top(stack(z))) ; saved-assu-cat : catalog = assu-cat(top(stack(z))) ; restored-cat-base : cat-base ~ meplace-cat(cls-actual, saved-assu-cat,

replace-cat(inf-actual, saved-inf-cat, cat-base(z) ))

p ~ number-of-acts(z) > 2 ,

The operation add-to-prey-act allows one to store an inference into the top-most stack-entry (so that i t is not lost ~ finishing the activity). The purpose of this operation is that the user can derive in the current activity a valid inference and then save i t for the return to the previous pending activity.

ftmction l add-to-prey-act] ( new-inf : inF~=ce ; z : sta~ II number-of-acts(z) ~ 2 ) : stai~ ,

l a~ add-to-prev-act(new-inf, z) ~ replace-stack(new-stack, z) whmre new-inf-cat : ca~log - add(inf-cat(top(stack(z))), new-inf) ;

new-stack : stack = push(pop(stack(z)), triple(assu-cat(top(stack(z))), new-inf-cat,

act(top(stack(z))) ) ) provided number-of-acts(z) >_ 2 ,

Page 101: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 4 The state: Type STATE

93

/*=======•=--====: =_-_=.i /* INITIAL 5TA'IE */

Initially, the state consists of a neutral activity, an empty stack, and an (almost) empty collection of catalogs.

I init-statel : state,

law6 init-state m make-state(neutral, empty-stack, init-cat-base) ,

fmctim F~l ( z : ~ ) : m a m ,

laws id(z) - z ,

/* STATE4]PERATIONS FOR ~ ~:TIVITI~ * / / ~ k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .@:/

f~mctim Ineutral-mode] ( z : ~ ) : boo] ,

laws neutral-mode(z) = actual-activity(z) is neutral ,

f ~ i o . l add-mutrall ( z : sta~ ) : sta~,

l a ~ add-neutral(z) = add-activity(neutral, 0, z) ,

Page 102: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

94

I l l . 2 Formal speci f icat ion of the system core

/*-- */ / * s'rAIE-(IPERAIlONS FOR BE~TI(]N ACTIVITIES * /

/ * . . . . . . . . . . . . . . . . . . . . . . . . . . . . * I

run-tim l l r i v ~ d e l ( z : s ~ i ) : boo1 ,

laws deriv-mode(z) -- actual-activity(z) is der-to-act ,

f ~ I start-deriyl ( term : ~ ; z : stai~ ) : s t a l ,

laws start-deriv(t, z) - add-activity(new-act, context-conditions-t(term), z) where new-act : act iv i~ = der-to-act(init-derivation(term)) ,

/ * - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -* I

f ~ l~late-deriyl ( new-deriv : (lerivati~ ; z : ~ II deriv-mode(z) ) : s i ~ ,

1 ~ qodate-deriv(new~riv, z) - replace-activity(der-to-act(new-deriv), z) I ~ ( L ~ I deriv-mode(z) ,

f i ~ o n l~rivationl ( z : stai~e II deriv-mode(z) ) : (IBrivati~ ,

l~der ivat ion(z) • deriv(actual-activity(z)) p ~ v i ~ deriv-mode(z) ,

Page 103: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 4 The state: Type STATE 9S

.:

/* STAIE-O~ATI0~5 FOR RBOU~ ACTIVIIES */

f lmct i~ ~ ( z : stab~ ) : bool ,

laws red-mode(z) = actual-activity(z) is red-to-act ,

f ~ m ~ ( red: ~bct ion ; z : s t a~ ) : state,

ia~ add-red(red, z) - add-activity(red-to-act(red), 0, z) ,

f~mct i~ I,,,,update-redl ( r~w-red : ~ l ~ t i ~ ; z : ~ II red-m~de(z) ) : s t a t e ,

1 ~ update-~d(new-red, z) -- Feplace-activity(Fed-to-act(new-red), z) p ~ i ~ red-~de(z),

function ~ ( z : ~ U ~d~de(z) ) : ~ b c t i m ,

laws reduction(z) = reduc(actual-activity(z)) provided red-mode(z)

. . . . * /

. . . . . * /

..u~/

Page 104: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

96

111.2 Formal specif ication of the system core

2.5. The catalog-base

The knowledge base of the system is structured into twe levels: The basic level are catalogs that consist of named as well as of anonymous entries; the collection of these catalogs, i.e. a mapping from names to catalogs, forms the overall knowledge base.

The hierarchical structure of the 1~4Des in this chapter is as follows:

I CAT~I~'-'-BASE I

I:$1AT ~ NAT F ~

Page 105: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 5 The catalog-base: Type CATALOG-BASE

97

/* */

~ F ~ ,

/* */

/* DA17k TYPES ~ #IJI(ILI#RY OPEI~IIONS */

We describe a collection of catalogs as a mapping from names to individual catalogs.

base(Ira ( F ~ - - - ~ , empty-collection, put, Iselect-catJ, isacc, del, unite, unitable : tc~P(nmme, eq-n, catalog) ,

, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

fumctiom )admissiblel ( cb : cat-base ) : bool ,

l a~ admissible(cb) - has-cat(inf-actual, cb) A has-cat(cl s-actual, cb) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

init-cat-base : cat-base ,

1 ~ init-cat-base ~ gen-emp~(inf-grp, inf-actual, gen-emp~(cls-grp, cls-actual, emp~y-collection)) ,

/ * t4P~III~t.LATIOM OF WHOLE Om t m:CIIOMS OF" CAIAL.OGS * /

The following operations allow the handling of whole collections of catalogs: One can - check for the existence of a catalog having a certain group and name; - generate an empty catalog; - load a new catalog;

delete a catalog; fuse two catalogs into a new one; ask for the names of all catalogs of a given group.

Page 106: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

98

111.2 Formal specif ication of the system core

f ~ o n ~ ( cn : nm~ ; cat-base : cat-base ) : Imol ,

laws has-cat(cn, cat-base) i isacc(cat-base, cn) ,

~r_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _4(/

function ~ (91) : group ; cn : name ; cat-base : cat-base [[ has-cat(cn, cat-base) ) : cat-base ,

laws gen-emp~(gp, cn, cat-base) - put(cat-base, cn, empty-cat(gp)) provi(~d ~ has-cat(cn, cat-base) ,

4(_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4(/

f~mcti~ ~ ( cn : n ~ ; cat : ca~log ; cat-base : cat-base H loadable(cn, cat, cat-base) ) : cat-base,

function ~ ( cn : name ; cat : cai~log ; cat-base : cat-base ) : bool ,

laws loadable(cn, cat, cat-base) -: ~ has-cat(cn, cat-base) ,

load(cn, cat, cat-base) = put(cat-base, cn, cat) pmovided loadable(cn, cat, cat-base) ,

/ ~ k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _4(/

flJmction ~ ( cn : ~ ; cat-base : c a t - ~ [] has-cat(cn, cat-base) ) : cat -b~ ,

la~ delete(cn, cat-base) ~ del(cat-base, cn) provided has-cat(cn, cat-base) ,

4(_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -4 ( /

f ~ o n ~ ( cnl, cn2, cn3 : name ; cat-base : cat-base fusable(cnl, cn2, cn3, cat-base) ) : c~-base,

f ~ o n ~ ( cnl, cn2, cn3 : name ; cat-base : cat-bame ) : baol ,

laws fusable(cnl, cn2, cn3, cat-base) - has-cat(cnl, cat-base) /k has-cat(cn2, cat-base) /~ ~ has-cat(cn3, cat-base) /L union-possible(select-cat(cat-base, cnl), select-cat(cat-base, cn2)) ,

fuse(cnl, cn2, cn3, cat-base) i

put(cat-base, cn3, union(select-cat(cat-base, cnl), select-cat(cat-base, cn2))) pFovided fusable(cnl, cn2, cn3, cat-base) ,

Page 107: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 5 The catalog-base: Type CATALOG-BASE

99

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

function ~ ( gp : 9ram ; cat-base : cat-base ) : s e ~ u , ~ ,

laws all-names(~, mpiT-collection) - empi~equ-n , all-mms(gp, p~(cat-base, cn, Catalog))

i f eq-grp(gp, group(catalog)) then conc-n(all-names(gp, catbase), mke-n(cn)) else all-nam~(gp, catbase)

md i f ,

~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .@c/

The following operation is not made available to ~ user but simplifies the specifications of certain operations in the ~ STATE.

f ~ t l m (replace-cat ( cn : name ; new-cat : cai~log ; cat-base : cat-ba~ () has-cat(cn, cat-base) ) : Cat-base ,

law~ replace-cat(cn, new-cat, cat-base) - put(cat-base, cn, nea-cat) I ~ I has-cat(cn, cat-base) ,

* = __-./

/ * ~ OPEI~TIa~ ON I ~ I V B CAI'EII~ * / .w*/

The following operations merely " l i f t " the operations for the handling of individual catalogs (as specified in the ~ CATALOG) such that they now operate on selected members from i~e knowledge base. In particular, those operations that modify a catalog now lead in addition to a selective updating of the knowledge base.

flmCticm ~ ( cn : mine ; cat-base : cat-base II has-cat(on, cat-base) ) : group ,

I ~ cat-group(cn, Cat-base) - ~roup(select-cat(cat-base, cn)) provided bas-cat(cn, Cat-base) ,

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , /

f~J~L;~ ~ ( cn : ~ ; e : entry ; cat-base : ca t -b~ (I addable-to(cn, e, Cat-base) ) : cat-base,

fmctim )addable-tol ( cn : mine ; e : entry ; cat-base : cat-base ) : bml ,

la~ addable-to(cn, e, cat-base) -z has-cat(cn, cat-base) A adding-possible(select-cat(cat-base, cn), e) ,

add-to(on, e, cat-base) -: replace-cat(cn, new-cat, cat-base) ~ new-cat : catalog E add(select-cat(cat-base, cn), e)

provided addable-to(cn, e, cat-base) ,

Page 108: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

i00

I l l . 2 Formal specif ication of the system core

, _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - * /

function l insert-into! ( cn, en : name ; e : ~ ; cat-base : cat-base II insertable-into(cn, en, e, cat-base) ) : cat-base,

f~mction l insertable-intol ( cn, en : name ; e : entry ; cat-base : cat-base ) : bool ,

laws insertable-into(cn, en, e, cat-base) has-cat(cn, cat-base) /~ insertion-possible(select-cat(cat-base, cn), en, e) ,

insert-into(cn, en, e, cat-base) = replace-cat(cn, new-cat, cat-base) where new-cat : catalog = insert(select-cat(cat-base, cn), en, e)

pFovi~ insertable-inte(cn, en, e, cat-base) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

fmmLti~ ~ ( cn, en : marne ; cat-base : cat-base II has-cat(cn, cat-base) ) : b~)l ,

l~ws contains(cn, en, cat-base) = has-name(select-cat(cat-base, cn), en) pmovided has-cat(cn, cat-base) ,

* . . . _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

fumcti~ [delete-from I ( cn, en : mine ; cat-base : cat-base II deletable-from(cn, en, cat-base) ) : cat-base ,

functi~ Ideletable-froml ( cn, en : name ; cat-base : cat-base ) : bool ,

laws deletable-from(cn, en, cat-base) - has-cat(cn, cat-base) A contains(cn, en, cat-base) ,

delete-from(cn, en, cat-base) = replace-cat(cn, new-cat, cat-base) where new-cat : cai31og ~ delete(select-cat(cat-base, cn), en)

I ~ deletable-from(cn, en, cat-base)

,_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ * /

function I fetch-from'l ( cn, en : ~ ; cat-base : cat-base I I fetchable-from(cn, en, cat-base) ) : entry ,

~ L t i ~ Ifetchable-froml ( cn, en : ~ ; cat-base : cai:-base ) : bool ,

|ams fetchable-from(cn, en, cat-base) -: has-cat(cn, cat-base) A contains(cn, en, cat-base) ,

fetch-from(cn, en, cat-base) ~ select(select-cat(cat-base, cn), en) provided fetchable-from(cn, en, cat-base) ,

Page 109: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 5 The catalog-base: Type CATALOG-BASE

101

/* .-*/

function ~ ( cn, en : name ; i : pnat ; cat-base : cat-base II namable-in(cn, en, i , cat-base) ) : cat-base ,

fkmcti~ Inamable-inl ( cn, en : ~ ; i : pmat ; cat-base : cat-base ) : b(~)| ,

laws namable-in(cn, en, i , cat-base) has-cat(cn, cat-base) /~ naming-possible(select-cat(cat-base, cn), en, i ) ,

name-in(cn, en, i , cat-base) ~ replace-cat(cn, new-cat, cat-base) where new-cat : catalog ~ name(select-cat(cat-base, cn), en, i)

I~(W~I namable-in(cn, en, i , cat-base) ,

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _*/

f~mcti(m r - ~ ( cn, oen, nen: rare ; cat-base : cat-base II renamable-in(cn, oen, nen, cat-base) ) : cat-base ,

function Irenam~le-inl ( on, oen, hen : nine ; cat-base : cat-base ) : Imp)| ,

1 ~ rena~ble-in(cn, oen, nen, cat-base) has-cat(cn, cat-base) /L renaming-possible(select-cat(cat-base, cn), oen, hen) ,

rename-in(cn, oen, hen, cat-base) = replace-cat(cn, new-cat, cat-base) ~ e new-cat : catalog -- rename(select-cat(cat-base, cn), oen, nen)

pn~vide(l rem~le-in(cn, oen, nen, cat-base) ,

*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

ftmL~:i(Tn lall-elemEmts-ofl ( cn : name ; cat-base : cat-base II has-cat(cn, cat-base) ) : sequ-o~-em~:ry ,

l~ws all-elements-of(cn, cat-base) = all-elements(select-cat(cat-base, cn)) provi~l has-cat(cn, cat-base) ,

i , . . . . . . . _ . . . . . . . . . . . . . . . . . _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _*/

f~mction l all-named-elements'-ofl ( cn : nmm ; cat-base : cat-l~e )) has-cat(cn, cat-base) ) : ~-~-of-er~ry,

laws all-named~lemmts-of(cn, cat-base) -: all-named-elements(select-cat(cat-base, cn)) Im~mrid~l has-cat(cn, cat-base) ,

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*/

fumcti~ l all-anonymous-elemmts-ofl ( cn : ~ ; cat-base : cat-base II has-cat(cn, cat-base) ) : sm(luH)f-enC~ ,

Page 110: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

102

I l l . 2 Formal specif ication of the system core

laws all-anonymous-elements-of(cn, cat-base) - all-anonymous-elemEmts(select-cat(cat-base, cn)) p m v i ~ has-cat(cn, cat-base) ,

function lall-names-<)fI ( cn : ~ ; cat-base : cat-base Jl has-cat(cn, cat-base) ) : ~-~-of-nml~ ,

laws all-names-of(cn, cat-base) = all-names(select-cat(cat-base, cn)) provided has-cat(cn, cat-base) ,

function lall-names-and-elements-ofl ( cn : ~ ; cat-base : cat-base lJ has-cat(cn, cat-base) ) : se~f-<m~me,em~ry> ,

lam~ all-names-and-elements-of(cn, cat-base) = all-names-and-elements(select-cat(cat-base, cn)) provided has-cat(cn, cat-base)

Page 111: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 5 The catalog-base: Type CATALOG

103

Catalogs serve for storing inferences, clauses, terms, transformation pFograms, derivatiens, and reductions. These various entities are subsumed under the common type mYory. However, a catalog must only contain entries of the same kind (referred to as group). Therefore, a catalog also possesses a group against which the groups of all entries are matched.

, ~ ~ ~ . .~ .~.~.. __ ~ = , /

b a ~ GROUP, NAME, PNAT,

/ * DATA~mES * /

A catalog is a triple <group, named, anonymous>, where group indicates the i~ype of catalog entries, named is a map from names to entries, and anonymous is a sequence of anonymous entries.

maXe-cat reom~ ~ : group, nm~d : map , anonymous : s e q u - o f - e m ~ y

compatible-map(named, group) A co~tible-sequ(amon~, gro~)

b a ~ E~P(Bm~, eq-n, em~zy, eq-en) ,

. . . . . . . . . . . . . . . . . . . . * /

function compatible-map ( m : ~ ; gp : g ~ ) : boo1 , functi~m compatible-sequ ( sq : sequ-of-eni:ry ; ~p : g ~ ) : boo1 ,

laks compatible-map(m, gp) - compatible-sequ(range(m), gp) ,

compatible-sequ(e~tysequ-e, gp) -: t rue, compatible-sequ(conc-e(s, m~ke-e(e)), gp) ~ compatible-gp(group(e), gp) A compatible-sequ(s, ~ ) ,

/*: ;*/

/ * Omma~ONS * /

An empty ..catalo~ consists of an empty map of named entries and an empty set of anonymous entries. But i t does have a group-tag.

/*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

Page 112: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

104

I l l . 2 Formal specif ication of the system core

Fdnction ~ ( m :group) : catalog ,

l a ~ empty-cat(gp) = make-cat(gp, (~, emptysequ-e) ,

/ * */

One can test whether a name exists in a catalog.

ft~e.tlon F - ~ ( n : n ~ ; cat : catalog ) : bool ,

laws has-name(n, cat) ~ isacc(named(cat), n) ,

/* */

One can add an anonymous element provided that the group of the element is compatible with the group of the catalog.

function r ~ ( cat : cai~Iog ; e : er~bry II adding-possible(cat, e) ) : catalog , function l adding-possibl.e.! ( cat : catalog ; e : entry ) : bool ,

laws adding-possible(cat, e) ~ compatible-gp(group(e), group(cat)) ,

add(cat, e) ~ make-cat(g~oup(cat), named(cat), conc-e(anonymous(cat), n~e-e(e))) provided adding-possible(cat, e) ,

One can insert a named element, provided that the name does not yet exist in the catalog. Of course, the group of the element has to be compatible with the group of the catalog.

f ~ o n r ~ ( cat : catalog ; n :neme ; e : ~ury II insertion-possible(cat, n, e) ) : catalog , function [insertion-~siblel ( cat : catalog ; n : hare ; e : entry ) : beol ,

lam~ insertion-possible(cat, n, e) - compatible-gp(group(e), group(cat)) /~ ~ has-name(cat, n) ,

insert{cat, n, e) = make-cat(group{cat), put(named(cat), n, e), anonymous(cat)) pmovided insertion-possible(cat, n, e) ,

Named entries can be deleted from the catalog.

~ o n ~ ( cat : catalog ; n : nmme Jl has-name(cat, n) ) : catalog ,

lak~ delete(cat, n) - make-cat(~roup(cat), del (named(cat), n), anonj~nous(cat)) pmovided has-name(cat, n) ,

Page 113: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 5 The catalog-base: Type CATALOG

105

/*•===-----:-•--• */

A named element can be selected from a catalog.

flmcticn F ~ ( cat : catalog ; n : nine JJ has-name(cat, n) ) : emery ,

1~ws select(cat, n) ~ get(named(cat), n) provided has-name(cat, n) ,

/* */

One can form the union of two catalogs, provided that no name clashes occur bellmen their named parts. Of course, the groups of the two catalogs have to coincide.

fumctim ~ . ( cl : catalog ; c2 : catalog II union-possible(c1, c2) ) : catalog , fumcti~ J union-possibi"el ( cl : catalog ; c2 : catalog ) : ba)l ,

1 ~ union-possible(cl, c2) = eq-grp(group(cl), group(c2)) A unitable(named(cl), named(c2)) ,

union(c1, c2) ~ make-cat(group(cl), unite(named(cl), named(c2)), conc-e(anonymous(cl), anonymous(c2))) provided union-possible(cl, c2) ,

One can name anonymous entries, and one can rename named entries. Of course, no name-clashes must occur through the new names.

function ~ ( cat : catalog ; n : ~ ; i : pnat II naming-possible(cat, n, i ) ) : catalog , function Jnaming-possibleJ ( cat : ~ 1 o g ; n : ~ ; i : pnat ) : bool ,

lav~ naming-possible(cat, n, i ) - i < Janonymous(cat)J A ~ has-name(cat, n) ,

name(cat, n, i) = make-cat(group(cat), put(named(cat), n, anonymous(cat)[i]), del -e( anonj~Bous (cat), i ))

p r ~ ( ~ naming-possible(cat, n, e) ,

* _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ * /

function ~ ( cat : catalog ; old : name ; new : ~ JJ renaming-lx~sible(cat, old, new) : catalGg, function Jrenaming~s~blel ( cat : ca~1og ; old : ~ ; new : ~ ) : Ixml ,

I ~ renaming-possible(cat, old, new) - has-nanle(cat, old) A ~ has-name(cat, new) ,

rename(cat, old, new) -- make-cat{group(cat), put(del (named(cat), old), new, get(cat, oid)), anonymous(cat))

provided renaming-possible(cat, old, new) ,

Page 114: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

106

I I I . 2 Formal specif ication of the system core

. : ~,,~.*/

One can obtain lists of all elements / all named elements / all a n o ~ elements from the catalog. In addition, one can obtain a l ist of all named elements together with their names.

func t im la11-elB~ntsl ( cat : catal~j ) : s e q ~ } f - m b - y , function l a l l - n=~ l -e IB~n ts l ( cat : catalog ) : s e q ~ f - e r b r y , function lall-anon~mous-el~_J ( cat : catalog ) : s e ~ f - e ~ ,

law~ all-elemmts(cat) - conc-e(range(n~(cat)), anonymous(cat)) , all-named~lemmts(cat) ~ range(named(cat)), all-anonymous-elemmts(cat) ~ amonymous(cat),

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

~ m )a11-names-and-elBr~tsJ ( cat : ca~1~J ) : sequ-of-<mme,efflry> ,

laws all-names-and-elemmts(cat) - entry-list(named(cat)) ,

. _ _ . . . . . . . . . . * /

f ~ i m F a T ~ ( cat : cai~1o@) : seq~-nam,

laksall-n~mes(cat) m domain(named(cat))

Page 115: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 .5 The catalog-base: Type MAP 107

al~-bractl~ ~ ~ ( s ~ i ~ , fumctim eq-i ( index, im(bx ) : bin1. sort elem ) ;

/._---~

fuiw~tion I ~-- ~ : inap ,

* _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

fumct-im F~-tl (m: map ; i : in(bx ; e : e lem) :m~,

I ~ put(put(m, i , e), j , f) - i f eq-i{i, j ) then put(m, j , f) else put(put(m, j , f), i , e) emdif,

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ * /

functlm F-~ ( m : map ; i : index II isacc(m, i) ) : elem, fIHLiI(Im F ~ ( m : map ; i : index ) : ba}1 ,

laws isacc((~, i ) = f a l ~ ,

isacc(put(m, i , e), j ) - eq-i(i, j) V isacc(m, j) ,

get(put(m, i , e), j ) • i feoci( i , j ) ~m e else get(m, j) endif pmmti(~(l isacc(put(m, i , e), j ) .

* _ _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f ~ i . I ~ [ - ~ ( m : map ; i : i I ~ U isacc(m, i) ) : m~p ,

]aw~ delete(put(m, i , e), j) i f eq-i(i, j)

i f isacc(m,j) ~ delete{m, j) else m em(lif else put(delete(m, j ) , i , e)

l~ (L~ l isacc(put(m, i , e), j) , mdif

Page 116: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

108 I I I . 2 Formal specification of the system core

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

fmaim F ~ ( ~ : ~ ; m :mp II unitable(ml, m2) ) : map , Bmcticn F ~ (m l : m@ ;m2 : rap):1:~1 ,

l l l l unitable( l~, 0 ) - true , unitable(ml, ~) ~ unitable(m2, ml) , unitable(put(ml, i , e), r~) - i f isacc(~, i) then false else unitable(ml, n~) eniif , unite(~, I~) - (~ , unite(ml, m2) ~ unite(A, ml) , unite(put(ml, i . e), n~) - put(unite(ml, m2), i , e) l ~ ( i ~ l unitable(put(ml, i , e), m2)

e, x l l s t r a c t ~

abstractl~pe P ' ~ = ( sort index, function eq-i ( index, index ) : boo1, so i l e lm, f lmct im eq-e ( elell, elen ) : boo1 il include EQUIVALENCE(iBI.x. eq-i) , include EC1JIVALENCE(elem, eq-e) ) ;

.== ~-*/

base~ bl4P(i~{i~, eq-i, elem) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

( F~, , F~-~l, FOl, I • T;]., FT I )

( I s e ~ - i n i x l , nat, I emptyse~-i I, I is-Brl)tysec~-i I, ~ i , ~ ,

( I se~-e]eml, nat, L+tysee#-el, lis-&~Dtysequ-el, ~ , ~ ,

F T I, ) ( Ise~-<i~lex, eIe~l, nat,

l e,~tysequ-pl, |is-emptysequ-Pl, F~--~-P], ~ , )

,~ i . NAT ,

.~-~iii SE~(i~dex, eq-i) ,

f~m SEQU(elem, eq-e),

frGm SEQU(<iBd~x, ele~, eq-i-e) ,

Page 117: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.2.5 The ca ta log-base: Type EMAP 109

f~mct-im eq-i-e ( < i l , el> : <index, elem~, <i2, e2> : <index, elem~ ) : Imol ,

laws eq-i-e (< i l , el>, <i2, e2>) = eq - i ( i l , i2) A eq-e(el, e2) ,

ftmctian ~ (m:map) : s e I ~ f - i l ~ ,

l a ~ domain( 0 ) = a~ptysequ-i , domain(put(m, i , x))

i f isacc(m, i ) then conc-i(domain(delete(m, i ) ) , make-i(i)) else conc-i(domain(m), make-i ( i ) )

fi~-Ltlon ~ ( m : m~p ) : sequ-of-e1~ ,

] a ~ range( 0 ) ~ a~ptysequ-e , range(put(m, i , x)) - conc-e(range(m), make-e(x)) ,

m~lif,

. . . . . /

- - * /

furctim Imtry-listJ ( m : map ) : sequ-of-<in(lex, elen~ ,

la~s entry-list( 0 ) - emptysequ-p , entry-list(put(m, i , x)) =

i f isacc(m, i ) then conc-p(entry-list(delete(m,i)), make-p(i, x)) else conc-p(entry-list(m), make-p(i, x)) emii f

Page 118: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

110 I l l . 2 Formal specification of the system core

Since there is only one general data base mechanism in the system, all elements that go into this data base have to he adapted to a common type entry. However, since the database conceptually is to be organized respecting the types of entries, we introduce the auxiliary type gmm4~ the objects of which mirror the original t;ypes of entries.

We have six such groups in the data base, viz. inferences, clauses, terms, transformation programs, derivations, and reductions. The t~IDe TRAFO-PROG is missing from the present specification; i t is intended as a placeholder for a future extension of the system.

INFISRENCE, 1El@i, ~O-PROG, ~ I O N , DERIVATION,

/*

:*/

:*/

/~ DATA ~ /*

r T ~ /* inferences */ I~ /*clauses */ I1-~--~1 /*~ms */ I ~ /* transfornBtion programs */ I ~ /* derivations */ I r - ~ /* reductions */ ,

/* . . . . . . . . . . . . . . . . . . . . . . . */

function compatible-~J ( gpl, gp2 : group ) : I~ I ,

laws compatible-gp(gpl, gp2) = eq-grp(gpl, 9p2) ,

/* ~ */

All kinds of elements that can go into some catalog are adapted to t~e unique sort entry of catalog elemB~ts.

/* . . . . . . . . . . . . . . . . . . . . . . */

~ ~ ( ~ ) recnmd ~ : inference (eq-inf) emJmBcor(l I ~ ~ ~ : cla=e (~-cl) ~,-,~,,~,,; I ~ r,~,'d F'~'~I : tern (eq-t) e ~

I ~ , ~ ~ : _,~_~m (eq-red) e ,~,~=~,

Page 119: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I .2 .5 The catalog-base: Type GROUP

111

/ • _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f~mctim ~ ( elm : :;uy ) : g~m~p,

I ~ g~(elem) ~f elm is conv-inf then inf-grp 0 elm is cmv~Is i ~ cl~grp 0 elm is conv-trm ~ tn~grp 0 elm is conv-tpr i~m ~pr-grp 0 elm is conv-der i ~ der-grp 0 elm is conv-red then red-grp emdif

Page 120: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

112 111.2 Formal spec i f i ca t ion of the system core

2.6. R e ~ m s

The hierarchical structure of REDUCTION is as follows:

INFERENCE CLAUSE

A reduction reflects the current status of a goal reduction/verification effort as a triple consisting of the initial goal, the set of current subgoals, and a proof record (which is a chain of proof steps). The current subgoals as premises and the initial goal as conclusion together form a valid inference.

The following operations are defined:

init-reduction urgoal chain

subgoals goal -reduction goal -reducible inference-extraction

initializes a reduction process; yields the original goal to be reduced; yields the seeAence of individual proof steps. I t can be tested for emptyness by is-emp~ychain and accessed by f i rst and rest. yields the set of current subgoals; yields a set of new subgoals by applying an inference to a goal; tests defineckess of goal-reduction; combines the current subgoals and the initial goal into an inference.

F -- -Tml -

/ * = * /

basednn INFERE~, CLAUSE,

/ * * /

/ * DATAIYP~ * /

A reduction reflects the current status of a verification effort by - the initial goal; - the set of subgoals to which the initial goal has been reduced so far; - a record of the proof steps that led to the current status.

nk~ke-red ~ ~ : clause (~l-Cl); : se4;~<Im {~set-cl ); : p=f-d~in (~)

Page 121: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 6 Reductions: Type REDUCTION

113

baseden (Ipmm)f-c~inl, lis-e~tychainl, eq-ch, empty-chain, <.>, .&., F f i - ~ , F - ~ ) fimm SEqU(m~of-s~, eq-pst),

/* */

A proof step consists of - the subgoal reduced in the step - the set of subgoals to which i t has been reduced - the inference used - the axioms modulo which the inference was applied (cf. the operation apply-inf-modulo-axioms in the

~4De INFERENCE)

~me Immf-~ml ( ~ ) make-proof-step record gl : c 1 ~ (eq-cl); sbgls : set-of-clause (eq-set-cl); inf : inference (eq-inf); axs : set-of-i.~eT~:Le (eq-set-inf)

e b b ,

/*= */

/* GEWUINE REfeCTION O P ~ T I O ~ */

The operation init-reduction sets up a reduction for a giv~ goal. Initially, the set of subgoals to which this goal has been reduced consists just of the given goal itself (this amounts to a trivially valid tautology).

ftJmLiom l init-reductionl ( goal : cla~e ) : reduction ,

laws init-reduction(goal) - make-red(goal, {goal}, e~pty-chain) ,

/•--------== */

The operation goal-reduction essentially applies an inference to a given goal in order to produce a set of new subgoals. The corresponding proof step is recorded. As an additional convenience, a further set of inferences (such as rules of reflexivi~, transitivii~y, or (anti-)symmetry) can be utilized in this pFocess. (The details are described in the specification of the operation apply-inf-modulo-axioms in the type INFERENCE).

fLmction Igoal-reduction I ( goal : clause ; inf : infe~f=-~.e ; axioms : s~c-of-im~mmm~ ; red : red~ctien ~ goal-reducible(goal, inf, axioms, red) ) : mmJucti~,

flJ~ti(m t go al-reduciblel ( goal : cla~p ; inf : i n f ~ ; axioms : s e t - o f - i ~ ; red: red. t im ) : Ixml,

Page 122: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

114

I l l . 2 Formal specification of the system core

laks goal-reducible(goal, inf, axioms, red) = goal e subgoals(red) A applicable-modulo-axioms(inf, goal, axioms) ,

goal-reduction(goal, inf, axioms, red) = make-red(urgoal (red), new-subgoal s, new-chain) ~ e new-clauses : set-of-clause ~ apply-inf-modulo-axionB(inf, goal, axioms) ;

new-subgoals : set-of-clause • (subgoals(red) \ {goal}) U new-clauses ; proof-step : pronf-si~ - make-proof-step(goal, new-clauses, inf, axioms) ; new-chain : proof-chain = chain(red) & <pn)of-step>

provided goal-reducible(goal, inf, axioms, red) ,

At any stage of the reduction process, the current set of subgoals (as premises) and the initial goal (as conclusion) constitute a valid inference. The operation inference-extraction yields that inference.

function l inference-extractionl ( red : reduction ) : i ~ ,

labs inference-extraction(red) a make-inf(subgoals(red), urgoal(red))

e ~

Page 123: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 7 Derivations

115

2.7. Derivat~

The hierarchical structure of the types in this chapter is as follows:

I DERIVATION I

SE~ TPOS SET PNAT SET-TO-SEQU

Page 124: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

116

I l l . 2 Formal speci f icat ion of the system core

A (Imrivai~ reflects the current status of a program development as a pair consisting of the ac~1 marked Imrm and the develqmmnt i~ree that mirrors the logical connections between the program versions derived so far.

There are three groq~s of operations:

proper derivation operations, movements or setting copies in the actual term, and manipulation of and movement in the development tree.

Proper derivation operations are:

- actual-term - init-derivation - contract - rule-application

- is-applicable

- inference-deduction

- is-deducible - reduce-condition - cond-reducible - reduce-all-conditions

yields the actual term; initializes a derivation with a given term; yields this term, i .e. the "contract" of the development; yields a new marked term (that results from applying a transformation rule to the actual term) and records the development step in the development tree; in particular, the environment of the marked part described by formulas is added to the antecedents of the applicability conditions. tests the definedness of rule-application. In particular, to avoid cyclic developments, a marked term must not occur more than once in a derivation. yields a new inference that reflects a development line starting at a given mterm and leading to the actual-term; tests the definedness of inference-deduction; reduces an assumption of the previous development step to a set of new ones; tests definedness of reduce-condition; reduces an assumption to a set of new ones everywhere in the tree.

For movement in terns the following operations are available:

- set-pos - legal-position - move - movable

places a marking; tests definedness of set-pos; shifts the marking according to given indications; tests definedness of move;

For setting and searching copies in terms the following operations are available:

- set-copy-der - settabl e-copy-der - search-copy-der - unique-copy-der

places a copy; tests definedness of set-copy-der; positions to a given copy; tests definedness of search-copy-der.

For accessing and manipulating the development tree the following operations are available:

- has-term tests the presence of a given term in the development tree; -delete-subderivation deletes the subder~vation starting with the actual term; the father of the

actual term is made the new actual one; - deletable tests the definedness of delete-subderivation; - actualize makes a given term (in the development tree) the new actual one;

Page 125: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 7 Derivations

117

- all-sons - all-leaves - predecessor - has-prt~essor - go-to-pred - compacti fication

- is-compacti liable

yields all successors of the actual term with respect to the development tree; yields all final nodes in the development tree; yields a predecessor of the actual term with respect to the development tree; tests definedness of predecessor; makes a predecessor of the old actual term the new actual term; condenses a line of developmmt from a given mterm to the actual-term into a single development step; tests the definedness of compactification.

abstract l~ l DERIVATIONI =

/*~ */

/*.. * /

/* D A T A T Y P E S */

l(L'rivationl ( ~ ) - .~l<e-~r n)cord I actual-terml : ~ (e~);

dev-tree : (kw-tree (eq-dev) ii is-in-devtree(actual-term, dev-tree)

e ~ ,

basedm

( mt~f, mmm, I mq~-of~mml, set-to-sequ,

l~ptysequ-~tl, l is-~ptysequ-mtl, I-~---~--], ] -~ - -~ - ] , from SET-TO-SE~(m~, eq-mt),

/*~ * /

~ DEIIIVATIOH #L'TIVITIES * / c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ ' k /

function J init-derivationl ( t : ~ ) : dmivat ion, function ~ ( der : ~ i v a t i o n ) : nmmn,

laws init-derivation(t) = make-der(~erk-root(t), init-tree(mark-root(t))) ,

contract(der) - root(dev-tree(der)) ,

/ * - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * I

flmctim Irule-applicationJ ( rule : i.F:=~ce ; k : Imat ; tier : dmrivation , is-applicable(rule, k, der) ) : (L~rivatim ,

f~mcti~m i is-applicablet ( ~ le : inference ; k : Imat ; der : ( ~ v a t i ~ ) : Imol ,

Page 126: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

118 I I I . 2 Formal specification of the system core

]a~ is-applicable(rule, k, der) = is-rule(rule) /~ (( V (k: nat It k ~ lengi~-tp(pos)) It

is-monotonic(get-op(terms(oldterm), sub-tp(pos. 1, k)), rel-sy~(rule))) A (has-marked-part(old-term, k) A (applicable(rule, marked-part(old-term, k), environmmt(old-tem)) /~ term-replaceable(old-term, k, out-template(new-inf)) )) /L

is-in-devtree(n-=place-marked-part(old-tem, k, out-template(new-inf)), dev-tree(der) ) )

w~-e old-term : m ~ ~ actual-term(tier) ; pos : ~ ~ tpos(old-term) ; new-inf : infeT~-Le ; apply-rule(rule, marked-part(old-term, k), environmBqt(old-term)),

ru le-appl icat ion(ru le, k, der) -: make-tier(new-term, new-tree) w~ue old- tern : I ~ - actual-term(tier) ;

new-inf : i . ~ - L e ~ apply-rule(rule, marked-part(old-tern, k), envirorment(old-~rm)) ; new-subterms : ~ . b - out-template(new-inf) ; new-conditions: ~=t-of-c lame • extend-set-clause(premises(new-inf), environm~t(old-tem)) ; new-term : m ~ : replace-marked-part(old-term, k, new-subterms) ; new-tree : (~v-iTee : add-to-tree(old-tern, new-term, new-conditions,

ru le - in fo( ru le ) , rel-symb(rule), dev-tree(der)) I ~ d e d is-appl icable(rule, k, d e r ) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*/

f ~ o m l inference-deduction'I ( t : m ~ ; der : dm'ivatim II is-deducible(t, der) ) : infem~e. function l is-cL=ducibl~'il ( t : m ~ ; der: dBrivation ) : bool ,

la~ is-dm~ucible(t, der) = deducible-inf(t, actual-term(der), dev-tree(der)) ,

inference-deduction(t, tier) ~ deduoe-inf(t, actual-term(tier), c~v-tree(der)) pm~vided is-deducible(t, der) ,

._ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -*/

fumctim [reduce-condition'l ( inf : i , , ~ ; der : (~rivatim) : dm-ivatim ,

1am ~:duce-condition(inf. der) : make-tier(actual-term(tier), new-tree) w ~ new-tree : (L:v-1~ee - update-cond(actual-term(~r), conclusion(inf).

pr~ses(inf), dev-tree(der)) ,

Page 127: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 7 Derivations: Type DERIVATION

119

*_ . . . . . . . . . . . . . .

fu,ctio, Ireduce-all<onditionsl ( inf : i~&~n~¢e ; der : dmrivati~ ) : dBrivati(m .

]a~s reduce-all-conditions(inf, der) = make-der(actual-term((~r), new-tree) new-tree : (L:v-b~e = update-all-conds(conclusion(inf), premises(inf), dev-tree(der)) .

. . . . . . * /

*/

/ * ~ I W I E N ~ * /

f ~ ( m F - ~ ( P : t ~ ; der : ~m-ivati~ II legal-position(p, der) ) : derivation . fi~m.~im Jlegal-positionl ( p : ~ ; der : ( ~ v a t i ~ ) : boo].

laws legal-position(p, der) - legal-pos(p, old-term) A is-in-devtree(set-mark(p, old-term), dev-tree(der)) .

w~mre old-term : m ~ = actual-tem(der) .

set-pos(p, c~r) • make-der(new-term, new-tree) w~re old-tern : m ~ ~ actual-term(der) ;

old-pos : tpos • tpos(old-term) ; new-term : m ~ - set-mark(p, old-term) ; • ae-tree : (E~-1~ree ~ add-i~>-tree(old-term, new-tern. (~. move-info(old-pos, p).

id-prsymb, dev-tree(der)) I ~ = ( l legal-position(p, der) .

A*_ . . . . . . . . . . . - * /

function F ~ ( d : (Mr ; der : ~va t i cm U movable(d, der) ) : (~rivatim . functim ~ ( d : (Mr ; der : derivation ) : boo] .

lals movable(d, der) -z movable-rot(d, old-term) A is-in-devtree(move~(d, old-tern), dev-tree(der)) .

Where old-term : m ~ - actual-~rm(der) ;

move(d, tier) • mske-der(new-~rm, new-tree) Where old-tern : m ~ =- actual-term(tier) ;

old-pos : i ~ = tpos(old-term) ; new-tern : Immm • move-rot(d, old-term) ; new-pos : tp~ = tpos(new-term) ; new-tree : ~-~ree ~ add-to-tree(old-term, new-term. (~. move-info(old-pos, new-pos).

id-prsymb. ~ev-tree(der) ) provided movable(d, der) .

Page 128: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

120

I l l . 2 Formal spec i f i ca t i on o f the system core

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

fulctfon I set-copy-der# ( c : copy ; p : ipos ; der : derivation )) settable-copy-der(c, p, der) ) : derivation ,

function I settable-copy-derl ( c : cow ; p : tpos ; ~ r : d~va t ion ) : bool ,

la~s settable-copy-der(c, p, der) ~ settable-nTL(C, p, actual-term(tier)) ,

set-copy-der(c, p, tier) - make-der(rew-term, new-tree) where old-tern : m ~ - actual-term(~r) ;

new-term : mberm - set-copy-mt(c, p, old-term) ; new-tree : dev-lmee • add-to-tree(old-term, new-term, 0,

set-copy-info(c, p), id-prsymb, dev-tree(der)) provided settable-copy-der(c, p, der) ,

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - * /

function Isearch-copy-cbrJ ( c : copy ;der : derivation U unique-copy-der(c, der ) ) : derivation , fwLt lon lunique-copy-~rl ( c : copy ;de r : derivation ) : bool ,

l a ~ unique-copy-~r(c, der) ~ unique-copy-mt(c, actual-tern(tier)) ,

search-copy-der(c, der) = set-pos(new-pos, der) w L ~ new-pos : tpos = position-rot(c, actual-term(tier))

provided unique-copy-tier(c, tier) ,

/*= * /

/ * M ~ N I I ~ O N O F / ~ D I ( O V E ~ IN I l IE I IR IVATIONI I~E * /

function F ~ ( mt : milton ; der : derivation ) : boo1 ,

lak~ has-term(rot, der) = is-in-devtree(mt, dev-tree(der)) ,

function Idelete-subderivationl ( der : dmivation II deletable(der) ) : derivation , function ~ (de r : ek~ivation ) : bool ,

l a ~ ddletable(der) - ~ is-root(actual-term(der), dev-tree(der)) ,

del ete-subderivation(der ) nk~e-der(pred(actual-term(der), 1, old-tree), rew-tree)

~ old-tree : dev-tmee ~ dev-tree(der) , new-tree : dL~-tmee - delete-subtree(actual-term(der), old-tree)

provided ~letable(der) ,

Page 129: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I i o2 .7 Derivations: Type DERIVATION 121

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

fu~ztion { ~ c t i f i c a t i o n l ( t : m m ; der : (E~'ivation {{ is-compactifiable(t, der)) : derivation , function I"i'S-compactifiable{ ( t : ~ ; der: (lerivation) : bonl ,

lab~ i s ~ c t i f i a b l e ( t , der) - ccm~actable(t, actual-term(der), dev-tree(der)) ,

compactification(t, der) -- make-der(old-term, new-~) wllere old-term : mlmm • actual-term(der) ;

new-tree : ~=v-tnm -- compactify(t, old-term, dev-tree(der)) pnovide(l is-compactifiable(t, tier) ,

._ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _./

function ~ ( mt : ~ ; der : derivation )I has-te ( , ~ r ) ) .. va on,

1 ~ actualize(mt, der) - make-tier(mr, dev-tree(der)) provided has-term(mt, der),

*. . . . . . . . . . . * /

function F ~ ( der : derivation ) : sequ-of-m~mrm,

laws all-sons(der) = set-to-sequ(sons(actual-term(der), dev-tree(cler))),

function lal1-1eavesI ( der: (Ilmivation) : s e q u - o f - ~ ,

la~sall-leaves(der) = set-to-sequ(leaves(dev-tree(der))),

function li'pnedecessorl ( k : pnat ; cler : (IL~rivation II has-predecessor(k, c~r) ) : ~ , function {ilgo-to-pred{ ( k : pnat ; der : derivation U has-predecessor(k, der)) : derivation . function !'has-predecessor{ ( k : Imat ; der : derivation ) : baol ,

l a~ has-predecessor(k, der) =- has-pred(actual-term(der), k, dev-tree(der)) ,

p~=decessor(k, der) - pred(actual-tem(der), k, dev-tree(der)) provided has-predecessor(k, der) ,

go-to-pred(k, der) i make-tier(predecessor(k, c~r), dev-tree(der)) provided has-predecessor(k, der)

en~sb~a~l~pe

Page 130: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

122

I I I . 2 Formal specif ication of the system core

An m ~ is a term in which a position is distinguished. In 1~e tree view of terms, this position characterizes the root of a subtree that corresponds to a subterm of the given term. The following operations are provided for ll~l~'ms: -tpos - mark-root - at-root - set-mark - marked-part - replace-marked-part - eq-mt - move-mt - mov~)le-mt - search-coI~,-mt - unique-copy-mt - position-mt

- environment

gives the position of the marked subterm; marks the whole term; tests whether a term is marked at the Foot; changes the marked position; yields the currently focussed sequence of subterms; changes the currently focussed part (e.g. according to a transformation rule); tests the equality of two marked terms; shifts a marking according to a a direction indicator; tests defined~ess of move-mt; moves the marking to the occurrence of a given copy indication; tests the applicab~Tity of search-copy-mt; is an auxlliary operation computing the position of an operator with a given copy indication within a marked term; computes the l~ge-dependent environment, described by formulas, of a marked subterm.

/*==_--•=_-=_ - -7 ...~,.....~.~ . . . . . . . . . . . . . */

baseden TEl@I, TPOS, PNAT ,

, - - - _ _ _ ~ _ _ ~ * /

/* D A T A l ~ *I . . . . . . . . . . . . . . . . . . . . . . . * /

~e ~ ( ~ ) -- mark record F - ~ : ~ (equal-t) ;

: ~ (e~m) U is-in-t(term, tpos)

e n d ~ ,

b a s ~ ( Iset-of -m~I, F ~ - - ~ , f"en~tyset-mtl, lis-emptyset-mtl, link-sing-rot..!, l i s ~ r - m t " ! , ~is-subset-mtl, F ~ , ~ ) finn SET(m~, eq-mt) ,

, ,-=_--_--_ */

/* ~ I E S S O P E R A ~ N S */

function l.marked-partJ ( m : mb~m ; k : pnat H has-marked-part(m, k) ) : ~ , function J has-marked-pa~j ( m : m ~ ; k : pnat ) : bool ,

Page 131: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 7 Derivations: Type MTERM

123

laws has-marked-part(m, k) = are-in-t(tenn(m), tpos(m), k) ,

marked-part(m, k) - subtenm-t(term(m), tpos(m), k) provided has-marked-part(m, k ) ,

9c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _~¢/

function Jreplace-marked-part I ( m : m ~ ; k : pnat ; ts : ~ II term-replaceable(m, k, ts)) : ~ , function Iterm-replaceablel ( m : m ~ ; k : pnat ; ts : Imnm ) : bool ,

laws term-replaceable(m, k, ts) = replaceable-t(term(m), tpos(m), k, ts) ,

replace-marked-part(m, k, ts) - mark(replace-t(term(m), tpos(m), k, ts), tpos(m)) provided term-replaceable(m, k, ts) ,

fimction ~ ( t : t~m): m~enn,

laws mark-root(t) = mark(t, enpty-tp) ,

/ * - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - * I

function F ~ (m : ml~em):bool ,

1 ~ at-root(m) ~ eq-tp(tpos(m), e~l~ty-tp) ,

f ~ i o n ~ ( p : t p o s ; m : m ~ I legal-pos(p,m) ) :mterm, fm~-tion F ~ ( p : t l ~ ;m: m ~ ) :boo1 ,

laws legal-pos(p, m) - is-in-t(tem(m), p) ,

set-mark(p, m) m mark(term(m), p) provided legal-pos(p, m) ,

Page 132: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

124

I I I . 2 Formal specif ication of the system core

/* MDVB~EWTOPE~ATIONS */

~ ~ I I $ I ~ I ~ , *_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

function ~ ( d : dir ; m : mtBrm H movable-mr(d, m) ) : m~Brm, f~c t im Imovable-mtl ( d : dir ; m : ~mnB ) : boo] ,

l ~ s movable-mr(d, m) -- i f d is I them up-ok(term(m), tpos(m)) {] d is ~ then down-ok(term(m), tpos(m)) [ l d is --> then right-ok(~erm(m), tpos(m)) a d is <--then left-ok(tenet(m), tpos(m)) emli f ,

move-mt(d, m) - mark(term(m), new-pos) mhem~ new-pos : tpos -

i f d is T then up(term(m), tpos(m)) n d is $ ~ down(term(m), tpos(m)) {] d is --> then right(~m(m), tpos(m)) I] d is <-- then left(tern(m), tpos(m)) emdif,

._ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _*/

function i set-copy-~tl ( c : cow ; p : ~ ; m : ~ II setable-mt(c, p, m) ) : ,qb~m, function Isetable-mtl ( c : cow ; p : ~ ; m : m~mm ) : bool ,

laws setable-mt(c, p, m) ~ is-in-t(term(m), p) ,

set-copy-rot(c, p, m) - mark(set-copy-t(tem(m), p, c), tpos(m)) provided setable-mt(c, p, m) ,

* _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

function I position-mtl ( c : cow ; m : mb~m II unique-copy-rot(c, m) ) : tpos , fiJ~Lion [unique-cow-mtl ( c : cow ; m : totem ) : bool ,

laws uni~e-copy-mt(c, m) -

l e t t : iL~lii - term(m) in ] t p : ~ II has-copy-t(c, t , tp) A

v tpl : ~ s II t,as--copy-t(c, t , tp~) ~ eq-tp(tp, tp~) ,

Page 133: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 7 Derivations: Type MTERM

125

position-mt(c, m) -- that tp : Ipos II has-copy-t(c, term(m), tp)

pmmli(L~ unique-copy-rot(c, m) ,

/*~ */ /* O]~TION OF lfE B i V I I ~ */

flmLtion l environmentl ( m : ,i~u~., ) : set-of-formula ,

<<language dependent>>

em~bs~

Page 134: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

126

I I I . 2 Formal specif ication of the system core

A (E~elollment thee keeps track of a program development. Its nodes are marked terms, the arcs bei~een i~o nodes (which reflect a development step) are labelled by the assumptions (still to be verified), information on the nature of the development step (i.e. proper transformation or just movement of a marking), and the semantic relation to hold between the adjacent nodes.

The operations either serve to manipulating the tree are:

- init-tree - add-to-tree

- deduce-inf

- deducible-inf - compactify

- compactable - delete-subtree - is-proper-node

- update~ond - update-all-conds

manipulate the tree or to make information available. Operations for

makes a marked term into a tree consisting just of the root; allows adding a new node and an arc that leads from an already present node to the new one; collects the information along a path in the tree and makes i t , together with start and end point of the path, into an inference; tests the definedmess of deduce-inf; condenses a path in the tree into a single development step; tests definedness of compactify; cuts off the subtree having a given node as its Foot; tests whether a node is in the tree and different from the root (definedness of delete-subtree and conditions) ; replaces an assumption for a developmmt step by a set of new ones; replaces an assumption by a set of new ones everywhere in the tree.

Information about the tree is obtained using the operations:

- is-root - root - is-in-devtree - conditions

- pred - has-pred - s o n s

- leaves

tests whether a node is the root of the tree; yields the root of the tree; tests whether a node is contained in the tree; yields the set of ass~tions for the development step leading to a given node (definedmess pFedicate: is-proper-node); yields a predecessor of a node; tests definedness of pr~; yields all successor nodes of a node; yields all leaves of the tree.

Page 135: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 7 Derivations: Type DEVTREE 127

/ * m

/* DATA~ES */

~ , i t (eq-~u) - init-devunit record post : m ~ (eq-mt) ~ - ~ I proper-devunit record pre : m ~ (eq-mt) ;

post : m (eq-mt) ; pre,~ : set-of-clause (eq-set-cl) ; info : info (eq-info) ; ~ l : m ~ (eq~)

e m ~ ,

I ~ - ~ ( s e t - o f - ~ t , eq-set-dvu, is-mBfoer-dvu ~ .e. , union-dvu s~n .U., mk-sing-dvu ~m {.}, diff-dvu ~m .\. ) F,~ ~T(~m~t, eq-dvu),

~ ( F ~ ) -= t : s e t - o f - ~ t (eq-set-dvu) (Vd l , d2: ~k~mit ~dl e t A d2 e t)

eq-mt(pest(dl), post(d2))) <=~ eq-dvu(dl, d2) ,

/~¢_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

function l is-in-devtreel ( n : tmrm ; t : (~-tmee) : bool ,

laws is-in-devtree(n, t) - 3 d : ( k ~ t ) d e t /~ eq-mt(post(d), n) ,

/*

. . . - * /

/* ~ Y Q~ATIO~ */ /* . . . . . . . . . . . . . . . . . . */

The following auxiliary operations are introduced for keeping the specification of devtree reasonably short: - get-devunit yields the (unique) development unit leading to a given node; - path tests whether there is a path of a given length betwaen two nodes; - ispred tests whether there exists a path between i ~ nodes;

Page 136: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

128

I l l . 2 Formal specif ication of the system core

f%mcti(m get-devunit ( n : m ~ ; t : dev-i~B~ II is-in-devtree(n, t) ) : ~ m i t ,

laws get-devunit(n, t) - ~ d : (M~m~it ~ d e t A eq-mt(post(d), n) provided is-in-devtree(n, t) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

fwlcti(m path ( nl, n2 : m ~ ; k : nat ; t : dev-i~ee ) : boo1 ,

la~s path(n1, n2, k, t) = d : ( k ~ t II d e t A (eq-mt(post(d), n2) A i f eq-n(k, O)

then eq-mt(nl, n2) else d is proper-~vunit A path(nl, pre(d), k-l, t)

er~if ) .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _*/

fimction ispred ( nl, n2 : m ~ ; t : (bv-tmee) : bool ,

laws ispred(nl, n2, t) - ~ k : nat II path(n1, n2, k, t) ,

/* OP~RATIONSON~EV~I~ */ . . . . . N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9¢/

fmztim ~ ( root : mt~m ) : d~v-b~e, ftn~tlo. [ - ~ ( t : (~v-b~se) : m~srm. function ~ ( n : mlmm ; t : ~=v-t.m ) : ~ml , fImction lis-proper-node I ( n : m ~ ; t : 4ev-iDree ) : boo| ,

l a~ init-tree(root) ~ { init-devunit(root) } ,

root(t) -- that n : m ~ [I is-root(n, t) ,

is-root(n, t) - init-devunit(n) e t ,

is-proper-node(n, t) = is-in-devtree(n, t) /k ~ is-root(n, t) ,

#c_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ ~ /

f~Ltion l add-to-treel ( nl, n2 : m ~ ; pFemises : set-of-clamse ; info : i . fo ; tel : pn~d-~mI~ ; t : (£=v-Izee II is-in-devtree(nl, t) A ~ is-in-4evtree(n2, t) ) : (L:v-b, Be.

l a~ add-to-tree(n1, n2, premises, info, tel, t) = t U {proper-devunit(nl, n2, premises, info, rel)} provided is-in-devtree(nl, t) A ~ is-in-devtree(n2, t) ,

Page 137: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 7 Derivations: Type DEVTREE 129

function [delete-subtreel ( n : n 1 ~ ; t : (lev-1~mee ~ is-proper-node(n, t) ) : (L=v-tmBe,

lak~ delete-subtree(n, t) = {d : (E~Amit II d e t A ~ ispred(n, post(d), t ) } provided is-proper-node(n, t) ,

function ~ ( n : mbemn ; k : nat ; t : (~v-i~me ~ has-pred(n, k, t) ) : ndmm, function ~ ( n : m ~ ; k : nat ; t : (lev-1~ree) :bool ,

laws has-pred(n, k, t) - 3 nl : n ~ llpath(nl, n, k, t) ,

pred(n, k, t) = that nl : ndmnn II path(nl, n, k, t) pm0~ided has-pred(n, k, t) ,

function ~ ( n : mt~ml ; t : ~:v-i~ee II is-in-devtree(n, t) ) : ~ ; - o f - m ~ , la~ sons(n, t) = [ nl : n d ~ II is-in-devtree(nl, t) /L

( has-p~=d(nl, t) /~ eq-mt(n, pred(nl, 1, t))) } provided is-in-devtree(n, t) ,

function ~ ( t : tier-tree ) : s e t - o f ~ ,

laws leaves(t) = {n : m ~ II is-in-devtree(n, t) /L is-Bnptyset-mt(sons(n, t))} ,

/*_ . . . . . . . . . . . . . . . . . . . . * /

function Iconditionsl ( n : ndm~n ; t : ~=V-i~Be II is-pFoper-node(n, t) ) : set-of-claume,

laws conditions(n, t) - prems(get-devunit(n, t)) provided is-pFoper-node(n, t) ,

/ * . . . . . . . . . . . . . . . . . . . . . . . i

function l~pdate-condl ( n : mb~m ; cl : clause ; ne~cls : set-of-clause ; t : ~=v-17ee II is-in-devtree(n, t) ) : dev-i~ee,

function lupdate-all-condsl ( cl : clause ;newcls : set-of-clause ; t : (~v-i~ee) : (~v-ITee, function M)date-devunit ( d : (lm~nit ; cl : clause ; newcls: set-of-cllse ) : ( ~ t ,

1 ~ update-cond(n, cl, newcls, t) m t\{d} LI {update-devunit(d, cl , ~m~cls)} w l ~ d : ( l ~ t = get-devunit(n, t) pmovi~l is-in-devtree(n, t) ,

Page 138: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

130 I I I . 2 Formal specif icat ion of the system core

~date-all-conds(cl, newcls, t) - { update-devunit(d, cl, rim(Is) l id e t } ,

update-devunit(d, cl , newcl s) i f d is proper-devunit /L cl e prems(d)

then proper-devunit(pre(d), post(d), (prems(d) \ {cl}) U newcls, info(d), rel(d)) elsed

endi f ,

/ . = . ............... _ * /

/* A~(ILIARY OPERATIOWS FOR COMP~eTIFICATION * /

For defining compactification and inference deduction some further auxlliary operations are introduced:

- relsymbol yields the predicate symbol of the development step leading to a given node; - cinfo yields the information of the development step leading to a given node; - del-spath deletes arcs leading to a given node as long as there are no branchings and a

second given node has not been reached. Since this operation is only used in compactify, i t does not destroy the tree properi~y;

- collect-premises unites all assumptions along a path between two nodes; - collect-infos accumulates all the information along a path between two nodes; -rel-compose computes the predicate symbol for the relation to hold between two nodes

connected by a (non-empty) path with respect to a given set of elementary combinations of predicate symbol s;

- compose is an embedding of rel-compose with an additional predicate symbol; - composable checks whether the predicate symbols on the path bet~men t~o given nodes f i t

together.

f ~ i o n re lsy~ l ( n : mbmrm ; t : (~-~ree I~ is-proper-node(n, t) ) : pmml-s~ ,

la~ rel~mbol(n, t) = rel(get-devunit(n, t)) provided is-proper-node(n, t) ,

*_. . . . . . . . . . . . . . . . . . . . . * /

function cinfo ( n : m ~ ; t : ~v-tmBe II is-pFoper-node(n, t) ) : info ,

]ams cinfo(n, t) - info(get-devunit(n, t)) provided is-proper-node(n, t) ,

* - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

funct i~ del-spath ( nl, n2 : m ~ ; t : (L=v-i=ree II ispred(nl, n2, t) ) : ~v-i=ree,

|a~s del-spath(nl, n2, t) = i f eq-mt(nl, n2)

~ t else i f ~ is-emptyset-mt(sons(pre(d), t)\{n2})

Page 139: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 7 Derivations: Type DEVTREE 131

t \ { d }

else del-spath(nl, pre(d), t\{d}) em~f

e ~ f where d : (L~nit ; get-devunit(n2, t) I ~ ( I ~ I ispred(nl, n2, t) ,

, _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , /

function collect-premises ( nl, n2 : mbmrm ; t : (~v-tree II compactable(nl, n2, t) ) : sel;-of-clal~e ,

|aws collect-premises(n1, n2, t) - i f eq-mt(nl, pred(n2, 1, t))

then conditions(t, n2) e|se collect-premises(n1, pred(n2, 1, t) , t) U conditions(n2, t)

ember pr(wi(le(l compactable(nl, n2, t) ,

* . . . . . . . . . . . . . . . . . . . . . * /

f~nction collect-infos ( nl, n2 : m ~ ; t : (~v-1~ee II com~ctable(nl, n2, t) ) : im~o ,

]aws collect-infos(nl, n2, t) -: i f eq-mt(nl, p~ed(n2, I , t))

cinfo(n2, t) else add-info(collect-infos(nl, prL=d(n2, 1, t), t ) , cinfo(n2, t))

endif I ~ ( l e ( l compactable(nl, n2, t) ,

, _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

function compose ( nl, n2 : mbmm ; ps : pred-~mb ; t : dev-b~e II ispred(nl, n2, t) A composable(nl, n2, ps, t)) : p r e ~ ,

function composable ( nl, n2 : m l ~ ; ps : p re ( l -~ ; t : ~:v-b~e II ispr~d(nl, n2, t) ) : ba)l , function rel-compose ( nl, n2 : m ~ ; t : ~v-i~ee II compactable(nl, n2, t) ) : p r e d - ~ , ~ o n Ico~tab le l ( nl, n2 : m ~ ; t : (lev-tTee) : I)ooi ,

laws composable(nl, n2, ps, t) = eq-mt(nl, n2) V ( rel-compable(rel~m~ol(n2, t), ps) A

compile(n1, father, rel-co~(rels~m~ol(n2, t ) , ps), t) ) Wlmme father : .i~e,m - pred(n2, 1, t) provided ispred(nl, n2, t) ,

compose(n1, n2, ps, t) - i f eq-mt(nl, n2)

i ~ p s

Page 140: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

132 I I I . 2 Formal speci f icat ion of the system core

/ *

else compose(n1, father, rel-conlo(relsymbol (n2, t ) , ps), t) emdif

~L~e father : m ~ = pred(n2. 1. t) pnmcid~ ispred(nl, n2. t) /~ composable(nl, n2, ps, t) .

~ c t a b l e ( n l , 112, t) - eq-mt(nl, n2) A (ispred(nl, n2, t) /L composable(nl, father, relsy~bol(n2, t ) , t))

w#mme father : m ~ - pred(n2, i , t) ,

r e l - c o ~ ( n l , n2, t) =- compose(nl, father, rels~mbol(n2, t ) , t) w; :~ father : mbmrm - pred(n2. I , t) pmmfid~ compactable(nl, n2, t) ,

* /

/* OOM~ICATION AND III]~WCE-B~k'TIOM */ . . . . . * /

f~L~;o. Icompactifyl ( nl, n2 : ,.,b~1,, ; t : (L~v-tree II compactable(nl, n2, t) ) : (~v-~ree ,

laws compactify(nl, n2, t) = add-to-tree(nl, n2, new-p~ns, new-info, new-rel-symb, new-tree) W~me new-pFems : set-of-cl_m_~_ ~ collect-premises(n1, n2, t ) ;

new-info : info m collect-infos(nl, n2, t ) ; ne~-rel-sy~b : pr~s~m~ ~ tel-compose(n1, n2, t ) ; new-tree : (E~v-~-~z.~ = del-spath(nl, n2, t)

provided compactable(nl, n2, t) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _*/

fwmtlon I deduce-infl ( nl. n2 : menu ; t : dL:v-tree II deducible-inf(nl, n2, t) ) : i,,fen:.>~. f111cti~m Ideducible-infl ( nl, n2 : mberm ; t : dev-i~ree ) : bool .

laws deducible-inf(nl, n2, t) ~ compactable(nl, n2, t) ,

deduce-inf(nl, n2. t) - construct-inf(new-prems. 0. new-fo) where new-prems : set-of<|ause ~ collect-premises(n1, n2, t) ;

new-rel-s~4fo : pme(l-s~ ~ tel-compose(n1, n2, t) ; new-fo : f ~ l a ~ make-fo(new-rel-symb, concat(<i;erm(nl)>, <tern(n2)>))

pn }v i~ deducible-inf(nl, n2, t)

Page 141: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I .2 .7 Derivations: Type REL-COMP 133

The i ~ REL-CO~P defines a partial monoid the elements of which are symbols for binary predicates or relations. The monoid operation is the partial relation composition re]-comp; a predicate rel-compab]e characterizes its domain of definition.

basedon PRZD-S~B,

function ~ ( sl, s2 : pred-~B~ II rel-compable(sl, s2) ) : pre(l-s~mb , ~ a n I re l -cc~le l ( sl, s2 : prt~l-s~b ) • boo] ,

laws rel-compable(sl, s2) ~ (binary(sl) A binary(s2)) , binary(s1) ~ (rel-compable(sl, id-prsymb) A rel-conioable(id-prsymb, sl)) ,

rel-compable(sl, s2) A rel-conl~]e(rel-comp(sl, s2), s3) rel-campable(s2, s3) A rel-compable(sl, Fel-cc~p(s2, S3)) ,

rel-cc~pable(sl, s2) A rel~le(re1-c~ornp(sl, s2), s3) eq-ps(rel-comp(rel-cc~p(sl, s2), s3), rel-cc~p(sl, rel-comp(s2, s3))) ,

binary(sl) (ecrps(rel-cc~(sl, id-prsymb), s2) A eq-ps(rel-comp(id-prsymb, sl), sl))

<< the remaining axioms are language dependent >>

* /

,~,,, , , , , ,, . /

Page 142: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

134 111.2 Formal specification of the system core

The type INFO defines the information that is stored in the developmmt tree in order to explain the nai~Fe of a development step. The operation ~le-info yields the information about the rule ~at has been applied, the operation mmm-info the information about a movem~t in the actual imrm. The operations set-copy-info and search-copy-info yield informations about setting and searching copy indications in a marked tern. For composing two informations into a single one, the operation ad~-imfo can be used.

/*= */

TE~M, INFERENCE,

/ . . . . . . . . . . . . . . . . . . , /

/* DATA TYPES */ / * - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - * I

r-info ~ r : i~fer~=~= (eq-inf) e r ~ I m-info mB~ old-pos : i ~ (eq-tp) ;

new-pos : ~ (eq-tp) ~w~e~w~ I c-info record c : c ~ (eq-c) ~ e c ~ ,

b a ~ ( ~ , ~ , emp~ysequ-info, make-info ~ <.>, ~ ) from SEQU(s-info, eq-sinf) ,

function ~ ( rule : i ~ ) : info ,

lam~rule-info(rule) = <r-info(rule)>,

function ~ ( pl, p2 : tpos ) : in fo,

fans move-info(pl, p2) = <m-info(pl, p2)> ,

function I set-copy-info] ( c : c ~ ) : info,

laws set-copy-info(c) - <c-info(c)>

Page 143: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 8 Inferences

135

2.8. Inferences

The hierarchical structure of the t~Des in this chapter is as follows:

J

SET

LANGUAGE

Page 144: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

136

I I1 .2 Formal specif ication of the system core

Inferences have been introduced in 11.2.3. in the form

} premises

~n

} conclusion

The premises ~ i , " - , ~n and the conclusion ~ are dauses of the form

A1, ..., A m --> B,

where the antecedents A1, ..., A m and the consequent B are formulas.

An inference is a pair (constructed by make-inf), consisting of a (possibly empty) set of clauses (referred to as premises) and a clause (referred to as conclusion).

Trm-~;'omati(m rules are special cases of inferences, where the conclusion is of the particular form

= P E a , b l

with a bina~c semmtic predicate P~ .,.~ (and empty set of antecedents). (To emp~lasize the distinction, we ~nTl in this case use the identifier "rule" instead of "inf" in the specification.)

There are three groups of operations on inferences:

application of meta-inferences to inferences application of an inference to a clause and operations specific for rules.

Operations concerning meta-inferences are (in parentheses the numbers of the corresponding meta-inferences in II.2. are given):

- make-tautology - inst-inf - cut

- cutable - import

- importable - export

- exportable - extend-inf - add-antecedents

- addable

generates a tautological inference from a given clause ( [ I ] i i ) ; instantiates an inference according to a given instance (IV]); applies the meta-inference "Cut" ( [ I l l ] i i ) to two given inferences thus producing a new one; tests definedness of cut; applies the meta-inference "Importation" ([IV a]) to a given inference and one of its premises; tests definedness of import; applies the meta-inference "Exportation" ([IV b]) to a given inference and a given clause; tests definedness of export; adds further premises to an inference ( [ I I ] ) ; adds further antecedents to the conclusion and to some selected premises of

a given inference ([ I I* ]) ; tests definedness of add-antecedents;

Page 145: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 .8 Inferences

137

For applying an inference to a clause we define the operations:

-apply-inf-mcdulo-axioms applies an inference to a clause with respect to a given set of other inferences as axioms ;

- unifiable-modulo-axioms tests definedness of apply-inf-modulo-axioms;

SI~fically for rules the following operations are available:

- is-rule tests whether the inference fulfills the restrictions for a rule; - in-template yields the left part a of the consequent P[ a, b~ of the conclusion of a

rule; - out-template yields the right part b of the consequent P[ a, b~ of the conclusion of a

rule; - make-rule generates a rule, i.e. a nomalized inference, from a clause; - makable-rule tests definedness of make-rule; - apply-rule applies a rule to a term, yielding a new inference; - applicable tests definedness of apply-rule; - rel-s-ymb yields the (binary) predicate symbol P of the consequent P[ a, b~ of the

conclusion of a rule; -construct-inf constructs an inference, given the premises, the antecedent of the

conclusion, a binary prtK1icate symbol and i~o arguments.

a ~ ~ =-

/* ==--=_~__-=./

b a s e ( ~ n F ~ - - - ~ - l , LANGUAGE, PNAT,

/* DATA~ES *I

m~-inf record ~ : ~t-of-clause (eq-set-cl) ; Iconclusionl : clause (eq-cl)

e ~ ,

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *I

b a ~ ( Iset-of-infeT-~-~el, eq-set-inf, I B~ptyset-inf] ~rn 0, l~s-B~ptyset-infl, ~ , l i s -m~r- in f l ~m .e. , ~ , ~ , Im~-si"ng-infl syn {.},

~m .u., linter~c-infl, ~ , l]~-subset-infl ) f ~ SET(Infemm~e, eq-inf) ,

Page 146: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

138

111.2 Formal specif ication of the system core

/* OP~ATmNS */

f~mcti~ ~ ( prems : ~-of-clause ; concl : clause ) : i n f ~ - ~ e ,

iak~make-inf(prems, concl) = normalize-inf(nk-inf(new-prems, concl)) where new-prems : set-of-claLme -:

pren~ U context-conditions-cl (concl) U { context-conditions-cl (cl) II cl e pren~ } ,

/*

Frcm any clause

the operation make-tautol~ constructs the valid inference

cK

function )~e - tau to l~ ) ( cl : clause ) : inference,

l~ws make-tautology(cl) = make-inf({cl}, cl) ,

/* ~*/

The operation make-rule is a variant of make-tautolocj.y : From the clause

A 1 . . . . . A n --> P~a,b] i t constructs the valid inference

(Ai)l <i~n A 1 . . . . ,A n --> PIa, b~

Pta, b~ For the resul~ng inference to be a rule we have to require that the predicate P is binary. Note that this operation is a particular combination of the two meta-inferences mak~tautology and exportation (see Part II, rules [ I ] and [IVb]).

function ~ ( cl : dame U makable-rule(cl) ) : inf~,~-Le, f l J~on I~able-rulel ( cl : clause ) : boo] ,

laws makable-rule(cl) = is-rule-ps(pred-symb(consequent(cl ))) ,

m~e-rule(cl) ~ make-inf(new-premises, new-conclusion) wherenew-pr~ses : set-of-cla~me : {make-cl((~, f) II f e antecedents(cl)} U {cl} ;

new-conclusion : clau~e = make-cl(O, consequent(cl)) provided makable-rule(cl ) ,

Page 147: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 8 Inferences: Type INFERENCE

139

.___ : * /

From the inference

( ~ i ) l ~ i ( m

P and the instantiation 0 (associating terms with scheme variables) the operation inst-inf produces the new inference

(~ i 8)1%i(m

~8

f~mctim ~ ( inf : infe~-~-~e ; inst : instance ) : iafef~-r~e ,

l ~ s inst- inf( inf, inst) - nonmalize-inf(make-inf(new-premises, nEw-conclusion)) w ~ new-premises : set-of-cla~me ; inst-set-clause(premises(inf), inst) ;

new-conclusion : clat~e = inst-clause(cenclusion(inf), inst) ,

, , /

function nor~Blize-inf ( inf: i ~ ) : inft~.-Le,

<< the la~s for this function are language-dependent; i t applies a language-dependent fixed set of inferences (cf. Part Vl) in order to reduce some premises of inf automatically >> ,

/ * * /

The operation cut (%odus ponens") applies the meta-inference "Cut" to i~o given inferences:

From and infer

functim ~ ( i l , i2 : inference It cutable(il, i2) ) : inference, f l~Lion ~ ( i l , i2 : i~reT-~-~e ) : boo1 ,

l a ~ cutable(il, i2) - oonclusion(il) e premises(J2) ,

cut( i l , i2) - make-inf(r~w-premises, conclusion(i2)) where new-premises : set-of-clause ~ pFemises(il) U (premises(i2) \ {conclusion(il)}) provided cutable(il, i2) ,

. . , /

The operation import applies the meta-inference "Importation" to am inference and a selected premise.

C-->B From infer

/A-->C /A, B, C - ~ C

Page 148: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

140

I l l . 2 Formal specif ication of the system core

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

fancti~ ~ ( cl :clame ; inf : i , , F ~ e II importable(cl, inf) ) : i n ~ , flmlcti~ l importablel ( cl : cl_m__~e ; inf : infemmlce ) : bool ,

laws importable(cl, inf) ;

cl e prBnises(inf) A has-no-indeterminates-cl (cl) ,

import(cl, inf) - make-inf(new-pr~ses, new-conclusion) where new-pFemises : set-of-clame -- premises(inf) \ {cl } ;

new-antecedents : set-of-fomula - antecedents(cl) U {consequent(cl)} U antecedents(conclusion(inf)) ;

new-conclusion : clm_~_ = make-cl (new-antecedents, consequent(conclusion(inf)))

pmm~ided importable(cl, inf) ,

. m */

. _

The operation export applies the meta-inference "Exportation" to an inference and a clause.

C-->B From infer

/A,B, C --> C /A, £ --> C . . . . . . . . . . . . . . . . . . . . . . . . . . ~ /

function ~ ( cl : claLme ; inf : inference II exportable(cl, inf) ) : inference , function lexportablel ( cl : clause ; inf : infeYB-Le ) : boo] ,

law~ exportable(cl, inf) ; antecedents(cl) U {consequent(cl)} -: antecedents(conclusion(inf)) ,

export(cl, inf) - make-inf(new-pFemises, new-conclusion) where new-pFemises : set-of-clause = premises(inf) U {cl} ;

new-antecedents : set-of-fonmla ~ antecedents(conclusion(inf)) \ {consequ~t(cl)} ; new-conclusion : clause -

make-cl (new-antecedents, consequent(concl usion(inf) ) provided exportable(cl, inf) ,

.: */

The opera t ion extend-inf adds further premises to an inference:

From infer

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

Page 149: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 8 Inferences: Type INFERENCE 141

f~mctim lextend-infl ( inf : i ~ ; cls : ~/c-of-clause ) : i , i [ . . ~ ,

laws extend-inf(inf, cls) - make-inf(new-premises, conclusion(inf)) where new-pnmiises : set-of-clause - premises(inf) U cls ,

*/

The operation add-antecedents adds further antecedents to the conclusion and to some selected premises of a given inference.

/A -~ A /A, ~ --> A From infer

--> B B. { --> B

f,,Bction ladd-antecedentsl ( inf : i a ~ e . ~ ; cls : ~t-of-cla.se ; sf : set-of-fom,la II addable(inf, cls, sf) ) : i . ~ L e .

f ~ t ; o n ~ ( inf : infemm:e ; cls : set-of-clause ; sf : ~=t-of-fon,ula ) : b~)1 .

laws addable(inf, cls, sf) = cls =- premises(inf) ,

add-antecedents(inf, cls. sf) • make-inf(new-pFems, new-concl) where new-cls : ~-of-clause =- {extend-clause(cl. sf) II cl e cls} ;

new-prems : set-of-clause = (pr~mises(inf) \ cls ) U new-cls ; new-concl : clause -= extend-clause(conclusion(inf), sf)

provided add~le(inf, cl s, sf) ,

. _ _ __ ../

The operation _apply-inf-modulo-axioms and its corresponding test operation applicable-modulo-axioms use the auxlliary operation filter-and-instantiate, which yields a new set of inferences each of which has the following properties: - i t is an instantiation of one of the given axioms; - the consequent of its conclusion is the same as the consequent of the given goal; - the consequent of at least one of its premises is the same as the consequent of the conclusion of

the given inference. Hence i t yields those axioms up to which the consequent of the desired goal coincides with that of the conclusion of the given inference.

/* .......................................................................................... -*I

f~mctim filter-and-instantiate ( inf : i m ~ ; goal : clause ; axioms : se t -o f - iaF : :~ ) : set-of-infere,ce,

lak~ filter-and-instantiate (inf, goal, axioms) -- { new : i.fem.ce II

3 (ax : ir~rmoe; in : i n s i ~ ; prem : clause) ax ~ axioms A

(instable-inf(ax. in) A eq-inf(inst-inf(ax, in), new)) prt~n e premises(ax) A

A

Page 150: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

142 111.2 Formal specif icat ion of the system core

non-redundant-i(in, used-ops-fo(consequent(conclusion(ax))) U used-ops-fo(consequent(prem))) A

eq-fo(inst-formula(consequent(conclusion(ax)),in), consequent(goal)) A eq-fo(inst-formula(consequent(prem),in), consequent(concl usion(inf))) },

/ *== */

The operation apply-inf-modulo-axioms facilitates reasoning by allowing standard inferences such as transitivity to be applied automatically. I t works as follows: First an inference "axiom" is selected among the set generated by filter-and-instantiate. Among the premises of "axiom" a clause is selected the consequent of which is the same as the consequent of the conclusion of the given inference. The result of apply-inf-modulo-axioms then is a set of new goals composed of: - the premises of the given inference; - the non-selected premises of axiom, each extended by the antecedents of the given goal; - a set of new clauses, each constructed from the antecedents of the given goal as antecedents and

one of the antecedents of the conclusion of the given inf as consequent; - a set of new clauses, each constructed from the antecedents of the given goal as antecedents and

one of the antecedents of the conclusion of the selected axiom as consequent.

fumctiom I apply-inf-modul o-axioms I ( inf : i n f ~ ; goal : clause ; axioms : set-of-infemm~ce ; U

applicable-modulo-axioms(inf, goal, axioms) ) : set-of-clause , function I appl icabl e-modulo-axioms I

( inf : inference ; goal : clause ; axioms : set-of-iafev~-~e ) : ba}1 ,

l a m ~ applicable-modulo-axioms(inf, goal, axioms) = (is-instance(conclusion(inf), goal) V

is-emptyset-inf(filter-and-instantiate(inf, goal, axioms))) ,

apply-inf-modulo-axioms(inf, goal, axioms) = i f is-instance(conclusion(inf), goal )

i ~ {inst-clause(cl, in) II cl e premises(inf)} where conc : clause ~ conclusion(inf) ;

ante : set-of-fon,ula = antecedents(conc) ; cons : formula = consequent(conc) ; in : instamoe = arb-i({i : instance II instable-clause(conc, i ) A

non-redundant-i ( i , used-ops-set-fo(ante) U used-ops-fo(cons)) A eq-cl(inst-clause(conc, i ) , goal) })

else new-goal s where new-axs : s e t - o f - i n ~ ~ filter-and-instantiate(inf, goal, axioms) ;

axiom: ~ n i ~ ; arb-inf(new-axs) ; prem : clause = arb-cl({cl : clause II cl e premises(axiom) A

eq-fo(consequent(cl ), consequent(concl usion(inf)) ) } ) ; other-prems : set-of-clause - premises(axiom) \ {prem} ;

Page 151: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 8 Inferences: Type INFERENCE

143

/*

new-goal s : set-of-cla=~e pFemises(inf) U {extend-clause(cl, antecedents(goal ))

cl e other-prems} U {make-cl(antecedents(goal), f)

II f e antecc~tents(conclusion(inf))} U {make-cl (antecedents(goal), f)

II f e antecedents(conclusion(axiom))} endif

Im~vi(E~ applicable-modulo-axio~B(inf, goal, axioms) ,

*/

fumctiem lapply-rulel ( rule : i~-~-~e ; terms : i ~ ; env : sm~-~f-f~la II applicable(rule, ter~6, env) ) : im~-~:-~e ,

function I..applicable] ( rule : i ~ ; ternB : i ~ ; env : set-of-fom~ala) : boo1 , f~--L;em ~ ( inf : inference ) : b(~}1 , function add-env ( rule : i n f ~ ; env : set-of-fomula ) : inference,

lam~ is-rule(inf) = is-rule-formula(consequent(cl)) A is-e~tyset-fo(antecedents(cl )) where cl :clause = conclusion(inf),

applicable(rule, terms, env) is-rule(rule) A card-i(instances) > 0 w h e r e new-rule : inferm~e = add-env(rule, env) ;

instances : set-of-instance ~ match-ts(in-te~late(new-rule), terns) ,

apply-rule(rule, terms, env) ~ inst-inf(new-rule, arb-i(instances)) w~a new-rule : inference -- add-env(rule, env);

instances : set-of-ims'-~amce = match-ts(in-template(new-rule), terms) pmm~(k~ applicable(rule, terms, env) ,

laws add-env(rule, env) - make-inf(new-prems, conclusion(rule)) whBre new-p~ms : ~-v~f-cl_~__me -- {extend-clause(cl, ~v) IIc] ~ pFemises(rule)} ,

* _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - * /

fum~-ti~ lin-templatel ( rule : i ~ ~ is-rule(rule) ) : ~, ,b ,

lam in-te~late(rule) ~ lhs(consequent(conclusion(rule))) provided is-rule(rule) ,

Page 152: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

144

I l l . 2 Formal specif ication of the system core

function l out-te~iatel ( rule : inferenc~ II is-rule(rule) ) : Imms ,

l~out-template(rule) ~ rhs(consequent(conclusion(rule))) provided is-rule(rule) ,

fLmction F - ~ ( rule : i n i ~ mI is-rule(rule) ) : pFed-~B~ ,

laws rel-symb(rule) • pred-symb(consequent(conclusion(rule))) provicbd is-rule(rule) ,

function l construct-infl ( sc : set-of-clause ; sf : set-of-fnula ; fo : fonmla ) : inrm~e,

law6 construct-inf(sc, sf, fo) ~ make-inf(sc, make-cl(sf, fo))

e n d a b ~

Page 153: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 8 Inferences: Type CLAUSE

145

A clause (cf. 11.2.2.) is a pair constructed by m~ke-cl. Its constituents are a set of formulas called its antecedents, and a formula called its consequent. Additional operations are: - is-instance tests whether a clause is an instance of another clause; - inst-clause instantiates the constituents of a clause with a given instance.

/* */

b, ed

/* ........ / /* DATA TYPES */ /*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

record [~tecedentsl : set-of-fomula (eq-set-fo) ; J~nsequentJ : fomula (eq-fo)

e ~ ,

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

( Iset-of-cla~eJ, ~ , len1~tyset-cll ~ (~, lis-~ptyset-c11, ~ , l is-me~r-cl! s~m. e. , F~---~Q, I - ~ - - ~ , Imk-sing-ciI, ~ , l i n t e ~ - c l l , ~ , [is-subset-clJ )

l ~ SET(clause, eq-cl) ,

/ * mERATIONB * / /*- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

funct ion Jhas-no-indeterminates-clJ ( ci : clause ) : I ~ I ,

laws has-no-indeterminates-cl (cl) = has-no-indeterminates-set-fo(antecedents(cl ) U consequent(cl )) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

f ~ m lis-instance] ( c11, c12 : clause ) : I~oI ,

l a~ is-instance(cll, cl2) = (is : instance II instable-clause(cll, is)) II eq-cl(inst-clause(cll, is), cl2) ,

Page 154: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

146

111.2 Formal specif ica~on of the system core

function l inst-clausel ( cl : clause ; i : instance ) : clamm. function linst-set-clausel ( cls : se t -o f -c lm ; i : i,~b=-~e ) : ~ -~ f - c l a~e .

I ~ inst-clause(cl, i) - make-cl(new-antecedents, inst-formula(consequent(cl), i)) where new-antecedents : set-of-fonula i inst-set-formula(antecedents(cl), i) .

inst-set-clause(cls, i ) = {inst-clause(cl. i ) Ic l e cls } .

v~_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .@¢/

Bm~io. Iex~nd-clau~i ( cl : ¢la~e ; sf : ~t-of-fonmla ) : c la~e,

I ~ extend-clause(cl, sf) - make-cl(antecedents(cl) U sf. consequent(cl)) .

g(_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~ /

f ~ c m Icontext-conditions-tl ( t : ten, ) : set-of-c|ause.

<<the axioms for this operation are language dependent>> .

/*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

f-wLt;~ [~text-conditions-tsl ( ts : ~-,.~, ) : set-of-clause .

lam~ context-conditions-ts(<>) -: 0 . context-conditions-ts(<t> & ts) = context-conditions-t(t) U context-conditions-ts(ts) .

f ~ c m Icontext-conditions-asl ( as : a ~ ) : set-of-clause .

]aws context-conditions-as(<>) -: (~ . context-conditions-as(<ts> & as) ~ context-conditions-ts(ts) U context-conditions-as(as) .

function Icontext-conditions-cl i ( cl : cla~e ) : set-of-cla_~ .

lak~ context-conditions-cl (cl) U { context-conditions-as(args(ante)) llante e antecedents(cl) }

U context-conditions-as (args (consequent (cl) ) )

Page 155: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 8 Inferences: Type FORMULA 147

A forrmla (cf. II.2.1.2.) is a pair constructed by make-fo. Its constituents are a predicate symbol pred-symb and a sequence args of aroJments which are term sequences. Additional operations are: - lhs yields for a binary predicate the f i rst argument; - rhs yields for a binary predicate the second argument; - inst-formula instantiates the arg~mmts of a formula acco~ng to a given instance; - inst-set-formula instantiates a set of formulas according to a given instance; - eq-fo tests the equality of two formulas.

/.., */

*/ / * DATA TYPES * / /*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , /

record : (eq-m) ; : ~ (eq-as)

II makable-fo(pred-symb, args) en(Irec~,

~ o n Imakable-fol ( ps : im~l-s~Ib ; as : arabs ) : boo] ,

l a~ makable-fo(ps, as) ~ compatible-ps(ps, as) ,

base(Ion( I set-of-fommlal, ~ , l emptyset-fo], l is-emptyset-fo , ~ , l is~,uiber-fol slm • e. , F~ -T~ , [T~-z~61, lnk-sing-fol, ~ , I inter~c-fo], ]-~--ffzT61, l is-subset-fol ) from SET(for~la, eq-fo) ,

/ * .*/ /* OP~ATIONS */

flmction l has-no-indeterminates-set-foI ( sf : set-of-formula ) : bool , f~m-~tion has-no-indeterminates-fo ( f : fomula ) : boo1 ,

Page 156: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

148

111.2 Formal specif ication of the system core

la~s has-no-indeterminates-set-fo(sf) - V (f : forllula II f e sf) ii has-no-indeterminates-fo(f) .

has-no-indeterminates-fo(f) -: has-no-indeterminates-as(args(f)) .

5%_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . @c/

f%mctio, lused-ops-fol ( f : formJla ) : set-of-q~ralmr. function l used-ops-set~f61 ( sf : set-of-fon~la ) : set-of-operalmr.

lares used-ops-fo(f) - used-ops-as(args(f)) .

used-ops-set-fo(sf) = U { used-ops-fo(f) II f e sf } .

function l is-rule-formulal ( f : fomula ) : bool .

lares is-rule-formula(f) - is-rule-ps(pred-syBi)(f)).

fu,ctiem ~ ( f : formula II is-rule-fon,Jla(f) ) : la.,6 .

laws lhs(f) - args(f)[1] l ~ d e ( l bi nary(pred-s3~b(f) ) .

fuBction I - ~ ( f : f(~nmJ1a ~ is-rule-fonnJla(f) ) : b~.1.b .

1~ rhs ( f ) = args(f)[2] pn}vi(t~l bi nary(p,~d-symb(f)) .

5%_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -~%/

f, mction l inst-formulal ( f : fom~la ; i : im~iAm~e ) : fon~ula . function l inst-set-for,uia'l ( sf : set-of-f~mu]a ; i : instance ) : set-of-formula.

laws inst-formula(f, i ) - make-fo(pred-symb(f), inst-as(args(f), i ) ) .

inst-set-formula(sf, i) ~ {inst-for, ula(f, i) II f e sf }

e ~

Page 157: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.2.8 Inferences: Type PRED-SYMB 149

The type PRED-SYMB summarizes another part of the langaage dependence of the system by specifying the available syntactic and semantic predicates. Since these predicates frequently are of a generic character (e.g. OCCURS should work for expressions, declarations, statem(mts, etc.), we only require fixed arities for them; the sorts of the arguments may vary. Note that therefore the language definition needs to impose context conditions on formulas as well.

PRED-SYMB provides the following operations: - eorps - id-prsymb - binary - is-rule-ps - compatible-ps - is-monotonic

tests the equality of two predicate symbols; is a constant representing an identity relation; tests whether a predicate symbol takes exactly Imm a r ~ t s ; tests whether a predicate symbol is legal for a transformation rule; tests whether a prL=~icate symbol may be composed with givm arg~nents; tests whether an operator is monotonic in all arguments wrt. a binary predicate symbol.

P * /

b a s ~ I I ~ , NAT,

/ * DATA TYPES * / /*_ . . . . . . . . . . . . . . . . . . . . . . * /

* . . . . . . . . . _*/

: pned-id,

/* . . . . . . . . . . . . . . . . . . . _*!

<<definition of the concrete operator identifiers>>

function ~ ( l~id, pned-id ) : bool ,

i~lude E~IW~.ENCE(Rred-id, ~-pid)

record name-ps : pred-id (eq-pid) ; arity-ps : pnat (eq-n)

Page 158: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

150

I l l . 2 Formal specif icat ion of the system core

lid-prsymbI : p ~ .

I ~ i d - p r s y ~ -- prsymb(id-pid, 2 ) ,

fu,cLim F6T~-~] ( ps : p m d - ~ ) : Ixml .

]av~binary(ps) = eq-n(arii~(I~), 2 ) ,

function l is-rule-ps.l ( ps : p~S~m~ ) : boo] ,

laws is-rule-ps(ps) ~ binary(ps) , is-rule-ps(id-prsymb) -z t rue,

<<all other axioms for is-rule-ps are language-dependent>> ,

/*- . . . . . . . . . . . . . . . . . . . . . . . . . . -* I

functim Icompatibl~i ! ( ps : pred-~m~ ; as : mrgs ) : bool ,

|a~ compatible-ps(ps, as) eq-n(arii~(ps), l as l )A (is-rule-ps(ps)~ sort-equal(as[i], as[2]) ,

/ ~ . . . . . . . . . . . . . . . . . . . . . . . . . . - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - * /

function lis-monotonicl ( o : ~ ; ps : p r e d - ~ II binary(ps) ) : bool ,

<<the axioms for this operation are language dependent>>

Page 159: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.2.9 Terms

151

2.9. Terms

The hierarchical structuFe of the types in this chapter is as follows:

MAP NAT SET SEQU PNAT

Page 160: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

152

I l l . 2 Formal specif ication of the system core

An instance is a partial mapping from variables to term sequences that respects the sorts. To avoid a new sort for variables and the corresponding d~lication of operations, we use in fact mappings from operators to term secNences and guarantee by the available operations that only operators which are variables become associated with term sequences. 0nly a variable x of sequence sort may be associated with the empty sequence or with a term secRence longer than one; in this case, all elements of the sequence must either be terms of the element sort of x or again variables or indeterminates for sequences of the same sort as x.

Instances may be constructed from the empty instance void by suocessively adding variables together with their associated term sequences; note that a variable must not be "redefined" once i t has been added to an instance.

The following operations on instances are provided:

Basic Operations:

- void - add

- addable

- f i t s

- isdef - get - domain-i - eq-i - j o l n - l - i

- joinable

Instantiation:

- inst-t

- inst-ts - inst-as

Matching:

- match-ts

generates the empty instance; adds a proper element to an instance provided its operator is not yet a defined key of that instance; tests definedness of add; (variable/terms consistency) tests whether a given pair consisting of an operator and a sequence of terms form a proper element for instance construction, i.e. whether the sorts and copy indications of the terms within the sequence all agree with the sort and copy indication of the operator (which must be a variable); tests ~hether an operator is a defined key of a given instance; yields the sequence of terms corresponding to a defined key; yields the set of keys (i.e "left-side-variables") of an instance; is the equality test for instances; yields the (not necessarily disjoint) union of two instances; tests definedness of join-i-i, i.e. whether those pairs being elements of both instances are compatible.

instantiates a term t according to a certain instance that associates terms with the variables in t; exiz~ds inst-t to sequences of terms (i.e. to argum~ts); extends inst-t to sequences of arguments.

- match-t

- non-redundant-i

yields the set of instances that "specialize" a sequence of terms to another one by replacing certain variables by terms, where instances containing variables that do not occur within at least one of the given terms are excluded (cf. the side-condition non-rv=dundant-i); specialization of match-ts to singleton terms; tests whether the domain of an instance equals a given set of operators.

Since matching yields sets of instances, the sort m t - o f - i , s m together with equali~ test and a couple of corresponding set operations are provided, too.

Page 161: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 9 Terms: Type INSTANCE 153

/* :..=*/

b a ~ [-~--~, PNAT,

/* _.=-_-./ /* DATAIYPES */

~ -z i: inst II V (o: o p e ~ U isdef(i, o)) II fits(o, get(i, o)) ,

/ * ' - - - ~ * 1 BASIC ~ { ~ */

f~tlm~ (o:~i~; i~ :t~) :l~ol ,

l~ fii~(o, i~) --

is-v~-o(o) A a~(r~(o), i~) A all-fit(c~-o(o), ~),

function ~ ( i : i ~ ; o : operator ; ts : ~,,b (I ~le(i, o, ts) ) : instance, f ~ o n F ~ - ~ ( i : instance ; o : q~ra~or ; ts : tern~ ) : bool ,

laws addable(i, o, ts) - fits(o, ts) A ~ isdef(i, o) ,

add(i, o, ts) - put(i, o, ts) provided addable(i, o, ts) ,

/*- . . . . . . . . . . . . . . . . . . . . -*I

f ~ o n ~ ( i : instance ) : set-of-opera~,

la~ domain-i(i) - {o : ~ ~ isdef(i, o)} ,

fIB.i.lon ~ ( i l , i2 : instance ) : bool ,

laws eq-i(i l , i2) = V o : o p e r ~ ) ( isc~f(il, o) ~ isdef(i2, o) ) A

( isdef(il, o) ~ eq-ts(get(il, o), get(J2, o)) ) ,

Page 162: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

154 I I I . 2 Formal specification of the system core

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f-~mction ~ ( i l , i2 : i~bm~e ~ joinable(il, i2)) : i~E~m~:, f ~ o m ~ ( i l , i2 : i~ - ,~e ) : bool ,

laws joinable(il, i2) = V o : ~ a b ~ r U (isdef(i, o) A isdef(j, o)) ~ eq-ts(get(i, o), get(j, o)) ,

join-i- i( i l , i2) =- Ulat in : instance II V o : (¥eTub~r II

(isdef(in, o) <=~ (isdef(i, o) V isdef(j, o))) /~ (isdef(i, o) ~ eq-ts(get(in, o), get(i, o))) /~ (isdef(j, o) ~ eq-ts(get(in, o), get(j, o)))

provided joinable(il, i2) ,

*/

/* IWST#~TIATION */ . . . . . . . . . . . . . . . . . . . . . . . . . . . */

f u m c t i ~ ( t : b ~ n ; i :imtamce) : ~ , f l ~ o n ~ ( t s : ~ . b ; i : i n s - ~ ) : i ~ , functi~ ~ ( as : args ; i : i n s ~ ) : mrgs ,

la~s inst-t(t, i) i let o : operaimr = optor(t) in i f is-var-o(o) ~ i f isdef(i, o) ~ get(i, o) else <t> endif

else <make-t(o, inst-as(args(t), i))> emdif,

inst-ts(ts, i) - i f isempty-ts(ts) b~, ts

else pmefix-ts(inst-t(first-ts(ts), i), inst-ts(rest-ts(ts), i-)) emtif,

inst-as(as, i) = i f isempty-as(as) then as

else prefix-as(inst-ts(first-as(as), i), inst-as(rest-as(as), i ) )endi f ,

Page 163: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 9 Terms: Type INSTANCE 155

/* */ /* m ~ c ~ */ /*_ . . . . . . . . . . . . _./

basedon (I ~ - ' J n s l ~ 7 , ~ , ~ , l is--m~ber:il, Jis-sub~t-il, ~ , ~ , ~ , F~-~TI) fTum SETCinsi~nce, eq-i) ,

base~ (set-of-IQem, emptyset-t, is-sub-t ~fn. ~-., union-t) from SET(t~m) ,

~-- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _@c/

f~LLion I non-redundant-il ( i : i n s ~ e ; so : set-of-q~rai~r ) : bool ,

]a~s non-redundant-i(i, so) = V o : o p e ~ IIisdef(i, o) ~ o ~ so ,

function ~ ( as1, as2 : anjs) : setter-instance, function ~ ( ts l , is2 : tenm6 ) : s e t - o f - i ~ & ~ , function ~ ( t l , t2 : ~m ) : set-of-instanoe,

]aws match-as(as1, as2) i {(i : instance IIi e Fel-insts-as(asl, as2)) II equal-as(inst-as(asl, i ) , as2)} ,

match-ts(tsl, ts2) = match-as(<tsl>, <ts2>) , match-t(tl, t2) ~ match-ts(<t1>, <t2>)

function rel-insts-as ( asl, as2 : args ) : s e t - o f - i ~ ,

laws rel-insts-as(asl, as2) = {i : instanoe II non-redundant-i(i, used-ops-as(asl)) A in-range-i(i, all-subterms-as(as2))} ,

/*_ . . . . . . . . . . . . . . . . . . _.i

fw~.ion in-range-i ( i : inst~-~:~ ; st : set-of-b~m ) : bool ,

laws in-range-i(i, st) - range-i(i) ~- st ,

function range-i ( i : i r ~ ) : set-of-i~m,

Ia~6 range-i(i) = {t: ~ U ~ (o: q ~ ~ o e d0main-i(i))

(k: pr~t llk ~ Iget(i, o)I) ~equal-t(t, get(i, o)[k])} ,

Page 164: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

156

I I I . 2 Formal specif icat ion of the system core

, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _* /

fl~Ictim all-subterms-t ( t : ~ ) : set-of-b:1,, . flmctim all-subterms-ts ( ts : ~ ) : s~-(}f-imm. fu.ct i~ all-subtems-as ( as : args ) : set-of-i~m.

laws all-subterm~-t(t) m { t t : ~ ~ has-subterm-t(t, t t)} .

al I -subterms-ts (ts) i f isemp~-ts(ts)

emptyset-t else union-t(all-subterm~-t(first-ts(ts)), all-subterms-ts(rest-ts(ts))) emJif.

al l-subterms-as(as) = i f isempty-ts(as)

emptyset-t e|se union-t(all-subterms-ts(first-as(as)), all-subterms-as(rest-as(as))) e.~if

Page 165: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.2.9 Terms: Type TERM

157

A t e r m consists of an operator together with a sequence of arguments which themselves are sequences of terms. The following operations are defined on terms:

Constructors/Selectors:

- make-t - optor - args

composes an operator with a sequence of arg~ents yielding a new term; selects the operator of a term; selects the sequence of arguments of a term.

Consistency Checking Operations:

- makable-t

- agree

- al l - f i t

- sort-equal

checks whether the sorts of a sequence of arguments agree with the functionality of an

operator; checks v~ether the elements of a sequence of terms agree with a given sort and a given

cow; subcase of agree: checks whether the elem~ts of a sequence of terms agree with a given sort of kind sequ and a given copy; checks whether t~o term sequences consist of terms of equal sort.

Full-Term Oriented Operations:

- eq-t - equal-t - used-ops-t - used-ops-ts - used-ops-as

is the "weak" equality test on terms disregarding cow indications; is the "strong" equality test on terms distinguishing different copy indications; yields the set of operators occurring in a term; generalization of used-ops-t to sequences of terms; generalization of used-ops-ts to sequences of arguments.

Main-Operator Oriented Operations:

- range-t - is-prop-t

yields the result sort of (the outermost operator of) a term; checks whether the outermost operator of a term is a proper operator, i.e. whether the term is neither a variable nor an indeterminate.

Position Oriented Operations:

- is-in-t - get-op - subterm-t - subterms-t - are-in-t

- has-subterm-t - replace-t

- replaceable-t

-up

checks whether a position lies within a given term; yields the operator in a given position; yields the subterm corresponding to a given position (definedmess test: is-in-t); yields a sequence of subtems indicated by a given start position and a length; tests definedness of subterms-t, i.e. whether all affected positions lie within the givm term; checks whether a given term is contained as subterm within another term; replaces a sequence of subterms (with given length) starting at a certain position by another (possibly empty) sequence of terms; tests definedness of replace-t, i.e. whether all affected positions lie within the term and, i f so, whether the new terms f i t into the respective environment; gives the position of the father of a given subterm;

Page 166: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

158 111.2 Formal specification of the system core

- up-ok -down - down-ok - right - right~k - le f t - left-ok - set-copy-t - has-copy-t

tests definedness of up; gives the position of the leftmost child of a given subterm; tests definedness of down; gives the position of the nearest right neighbouring subterm of a given subterm; tests definedness of right; gives the position of the nearest le f t neighbouring subterm of a given subterm; tests definedness of lef t ; sets a given copy indication to the operator designated by a position in a term; tests whether a certain copy indication is present at a given position in a term.

Auxlliary Operations:

- concat concatenates t~o giwn sequences of terms yielding a sequence of arguments; - has-no-indeterminates-as checks whether a sequence of argL~ents does not contain any indeterminates.

Moreover, besides the standard operations on sequences of terms or argents we have the weak and strong (in the above sense) equali~ tests eq-ts and equal-ts as well as eq-as and equal-as for such sequences.

*/

b a ~ base~

I ~ f - ~ x ~ l ) f~m TPOS ,

/* DATATYPES */

~ ~ : ~ m r (e~al~) ; : a ~ (equal-as)

makabl e-t(optor, args) e ~ ,

F ~ , nat, F - ~ , F ~ ~ <>, I is-empty-as[, ~ , ~ , F ~ , F~--~-~l ~m <.>,

~m .&., [iength-asl sam I . I , s~m .[.3, /change--asl ) SEQU(terms, equal-ts) ,

Page 167: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.2.9 Terms: Type TERM 159

( ts~, nat, ~ , ~ ~n o , l i s ~ t y - t s l , ~ , ~ , ~ , ~ ~.<.>, ~ ~m .~., ~ ~m I.I,

from SE~(imrm, e ~ l - t ) ,

, _ . . . . . . = . /

/* CONSISIE~ CIEI~ING 0PERATIOI~ */ /* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

fimction ~ ( o : operalmr ; as : args ) : Imol ,

laws makable-t(o, as) - I f is-prp-o(o)

then eq-n(larg-sorts-p(o)l, lasl) A V (k : pmat lJ k ~ lasl) II agree(arg-sorts-p(o)[k], as[k])

El is-var-o(o) then eq-n(lasl, 0) El is-ind-o(o) then eq-n(lasl, 0) II is-mop-o(o) them eq-n(lasl, ari~-m(o)) m~lif,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ . . /

f ~ L i o n FaFaFT~] ( s : s o r t ; t s : ~ ) : Imol ,

laws agree(s, ts) = i f Is-sequ-s(s)

~tmm eq-ts(ts, <>) V agree-s(s, range-t(ts[1])) else eq-n(Itsl, I) A eq-s(range-t(ts[1]), s)

emdif,

*_ . . . . . . . . . . . . . . .

fvLL i (m ~ ( C : re ly ; ts : terms ) : bin1 ,

I ~ all-fit(c, ts) E V (k : pnat IIk ~ Itsl) II fit-c(c, copy-o(optor(ts[k]))) ,

Page 168: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

160 111.2 Formal specif icat ion of the system core

@c_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

function Isort-equall ( tsl : i~rms ; ts2 : ~,,,b ) : boo] .

laws sort-equal(tsl, ts2) ~ ho, Dgeneous(tsl & ts2) .

'k_ ........................................................................................ _W/

~mctio. h~ogeneous ( ts : ~ ) : b~l ,

l~s homogeneous(is) -

eq-ts(ts, <>) V (V (k : p ~ IIk ~ Itsl) ~ agree-s(overall-sort, range-t(ts[k])) where overall-sort : sort = sequ-made(range-t(ts[1])) ) ,

/ , * /

/ * FULL-I~0R~0PEMTISWS * / 5%_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~ . . . . . . . _ * /

function FG~ ( t l : ~, , , ; t2 : Iz.m ) : bool , functio, eq-ts ( is1 : i ~ ; ts2 : ImrBs) : bool , function eq-as ( as1 : args ; as2 : args ) : b~}l ,

la, s eq-t(t l , t2) -: eq-o(optor(tl), optor(t2)) A eq-as(args(U), args(t2)) ,

eq-ts(tsl, ts2) = i f ise~pty-ts (tsl)

ise~ty-ts(ts2) else ~ iseBpty-ts(ts2) /L

eq-t(f irst-ts(tsl), first-ts(ts2)) A eq-ts(rest-ts(tsl), rest-ts(ts2)) e .d i f ,

eq-as(asl, as2) - i f isempty-as(asl)

isempty-as(as2) else ~ isempty-as(as2) /~

eq-ts(first-as(asl), first-as(as2)) A eq-as(rest-as(asl), rest-as(as2)) eBdif,

,_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - * /

f ~ o . l used-ops-tl ( t : term ) : set-of-opsralmr, f ~ = ~ l ~ d ~ - ~ _ l ( ~ : ~=,,~ ) : ~ t ~ f ~ r a W r , f~.ctio, l used-ops-asl ( as : a ~ ) : s e t - o f - q ~ .

Page 169: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I .2 .9 Terms: Type TERM 161

laws used-ops-t(t) = { get-op(t,p) ~ is-in-t(t, p) } ,

used-ops-ts(ts) - i f isempty-ts(ts)

then B~ptyset-o else union-o(used-ops-t(first-ts(ts)), used-ops-ts(rest-ts(ts))) endif,

used-ops-as{as) = i f isempty-as(as)

emptyset-o else union-o(used-ops-ts(first-as(as)), used-ops-as(Fest-as(as))) endif,

/.=•---=---== , :~=./

/* M~B~0ERATOR CR~BIn~ OP~ATIO~ */

f u m c t i o n ~ ( t : ~= rm) : s ( r t ,

la~range-t(t) = range-o(optor(t)),

function ~ ( t : ~em) : bonl ,

laws is-prop-t(t) ~ is-prp-o(optor(t)),

/* k/ /* ~SmOX0RIEwn~OPERATmNS */

---*/

f ~ ~ ( t : ~ e m ; p : t ~ ) : b o o l ,

laks i s - in - t { t , <>) • true ,

i s - in - t { t , <pair(pa, ps)> & p) =

pa ~ largs(t)l Xk ps ~ largs(t)[pa]l /L is-in-t(args(t)[pa][ps], p) ,

function F ~ ( t : ~ ; p : t l ~ JJ is-in-t(t, p) ) : q ~ ,

la~ get-op(t, p) - optor(subterm-t{t, p)) pmmdcL=d is-in-t(t, p) ,

Page 170: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

162 I I I . 2 Formal specif icat ion of the system core

, . . . . . . . . . . . . . . . . . . . . _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

functiom ~ ( t : ~ ; p : tpos II is- in- t( t , p) ) : term.

la~ subtera~t(t, <>) ~ t ,

subter~t(t, <pair(pa, ps)> & p) = subtern~t(args(t)[pa][ps], p) provided is- in-t( t , <pair(pa, ps)> & p) ,

/ * . . . . . . . . . . . . . /

fimlctiom I subterms-tl ( t : ~,, , ; p : tpos ; k : pint II are-in-t(t, p, k) ) : Et~,,m , f l ~ i ~ ~ ( t : l : m l n ; p : t p o s ; k : p n a t ) : l x ~ l ,

lamws ar~in-t ( t , p. k) =- is- in- t ( t , p) i f eq-tp(p, <>)

then eq-n(k, 1) else is- in-t( t , new-pos)

where old-pair : pp -- new-pair : pp ~',_~-pos : tpos =

enctif,

/L

last-tp(p) ; pair(args-pos(old-pair), sequ-pos(old-pair) + k - I) ; lead-tp(p) & <ne~pair>

subterms-t(t, p, k) = i f eq-tp(p, <>)

th~ <t> else le t father : term - subtenn-t(t, lead-ll)(p)) ;

pair : pp ~ last-tp(p) ; terms : t e ~ - args(father)[args-pos(pair)]

in terms[seq,~-pos(pair) .. se~#-pos(pair) + k - i ] ~ f

provided are-in-t(t, p, k) ,

. . . . . . . . . . . . . . * /

function [has-subterm-t]( ( t , st : ~ ) : boo) ,

lam~ has-subtern~t(t, st) - 3 (P : tpo~ Ul is- in- t ( t , p)) )( eq-t{subtermt(t, p), st) ,

function F ~ ( t : i ~ ; p : tpos ; k : prklt ; ts : ~ II replaceable-t(t, p, k, ts) ) : term, function [~=placeable-t I ( t : b:~., ; p : ipos ; k : pnat ; ts : te~,','m ) : bool ,

lak~ replaceabl~t(t, p. k. ts) ar~in-t( t , p. k) A i f eq-tp(p, <>)

Page 171: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I , 2 . 9 Terms: Type TERM

163

then eq-n(Itsl, 1) A eq-s(range-t(t), range-t(ts[1])) else sort-equal(subterms-t(t, p, k), ts) A

makable-t(optor(st), change(as[pal, ps, k, ts)) st : ~ -= subterm-t(t, lead-tp(p)) ; as : args • args(st) ; pa : I ~ = args-pos-tp(p) ; ps : I ~ ; sequ-pos-tp(p)

mxl i f ,

replace-t(t, <>, k, ts) = ts[1] I ~ (E~ I replaceable-t(t, <>, k, is) ,

replace-t(t, <pair(pa, ps)>, k, ts) ~ ~ke-t(optor(t), change(args(t)[pa], ps, k, ts)) provided replaceable-t(t, <pair(pa, ps)>, k, ts) ,

replace-t(t, <pair(pa, ps)> & <e> & p, k, ts) - make-t(optor(t), change-as(args(t), pa, new-arg)) where new-tern : ten, -- replace-t(args(t)[pa][ps], <e> & p, k, ts) ;

new-arg : terms - change-ts(args(t)[pa], ps, new-term) pr~(L~l replaceable-t(t, <pair(pa, ps)> & <e> & p, k, ts) ,

._ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

function change ( ts : ~ ; kl, k2 : I}~at ; tts : ~ II kl + k2 - 1 < Itsl /k sort-equal(ts, tts) ) : ~ , . b ,

3awschange(ts, kl, k2, tts) ~ ts[1 .. k l - 1 ] & t t s & t [ k l + k 2 - 1 .. I ts l ] provided kl + k2 - 1 < Itsl /~ sor t -e~l ( ts , tts) ,

/* ,*/ /* AI~ILI~Y OPERATIONS FOR B l ~ IN I I ~ * /

The following auxlliary operations are introduced for improving the readability. The semantics of the i~D functionals rain and max is given by unfolding their definitions.

function mqu-pos-tp ( tp : tins II ~ eq-tp(~. <>) ) : m a t , f .mt im args-pos-m ( ~p : tins II ~ eortp(tp, o ) ) : m a t ,

law~sequ-pos-tp(tp) -: sequ-pos(last-tp(tp)) prm~ ~ eq-tp(~, o ) ,

args-pos-tp(tp) = args-pos(last-tp(tp)) provided ~ eq-tp(tp, o ) ,

Page 172: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

164 111.2 Formal specification of the system core

function children ( t : ~ ; tp : ~ ]( up-ok(t, tp) ) : ~i,~,

law~ children(t, tp) ~ args(subterm-t(t, lead-tp(tp))) p m ~ up~k(t, tp),

f~mct ionmin(m,n: l~ la t ;p : funct ion( l~) :ba)l (( 3 (k :pnatl]m ( k A k ~ n) ()p(k)) : I ~ ,

funct ionmax(m,n: l~ ;p : f im~t ion(pnat ) :boo1 U (k :prlat[[m ~ k A k ~ n ) Up(k) ) :pmat,

la~ rain(m, n, p) - (~atk:pnat]]m ~ k A k ( n ) ~ p(k)A ( V l :pnat][m ~ l A l < k ) U ~ p(1)

provided ~ (k : pmat ]]m ( k AR ~ n ) ]]p(k) ,

max(m, n, p) = (JJ~atk:pnatI[m ~ k A k ~ n) [] p(k) A ( V I :pmat[[k<l A l ~ n) ] ]~p(1),

I ~ l 3 ( k :pnat ~m ( k A k ( n ) ~p(k) ,

function has-args ( as : args ; k : pmat ) : boo1 ,

laws has-args(as, k) = k < ]as] /~ ~ eq-ts(as[k], <>) ,

/* */

/* 0PERATIONSFORMD~ ~ T E ~ */

f m i m F ~ 7 ( t : i ~ m ; t p : t r m s ) ) up-ok(t, t p ) ) : t l X ~ , flmw:t(m ~ ( t : ~ ; tp : ~ ) : Ix~ol ,

laws up-ok(t, tp) = is-in-t(t, tp) A ~ eq-tp(tp, <>) ,

up(t, tp) - lead-tp(tp) p r ~ i ~ up~k(t, tp),

f u n c t i ~ F ~ ( t : i ~ m ; tp:tlms: ) : Imo l ,

Page 173: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 9 Terms: Type TERM 165

|aks down-ok(t, tp) - is-in(t, tp) /~ ~ k : pnat II has-args(as, k) w~,~e as : args -- args(subterm-t(t, tp)) ,

down(t, tp) ~ tp & <pair(k, 1)> where as : args ~ args(subterm-t(t, tp)) ;

k : pnat ; rain(l, lasl, has-args(as, -)) p m ~ down-ok(t, t p ) ,

Moving to the right means either moving to a right neighbouring term within the actual marked a r~en t or otherwise moving to the f irst term of the f irst non-empty argument to the right of the actual marked arsument:

as as ~ empty

fm:L;(m ~ ( t : teT.i; tp : i ~ ~ right-ok(t, tp) ) : t ~ , f lmlcti~F-~--~'~ ~ ( t : 8~ rm; tp : tpos ) : boo] ,

l ~ right-ok(t, tp) - q~-ok(t, tp) A sp< las[ap]l V (3 k : pnat Hap<R A has-args(as, k)) where sp : Imat ~ ~qu-pos-tp(tp) ;

ap : Imat ~ args-pos-tp(tp) ; as : args -- children(t, tp) ,

right(t, tp) - lead-~p(~) a <new-pair> ~ sp : Imat • se~-pos-tp(~p) ;

ap : pnat =- args-pos-tp(tp) ; as : args = children(t, tp) ; new-pair : pp

i f sp < las[ap]l then pair(ap, sp+l) else pair(nap, I)

where nap : Imat ; ~ f

provided right-ok(t, tp) ,

min(ap+l, lasl, has-args(as, -))

Moving to the left means either moving to the left neighbouring term within the actual marked argument or otherwise moving to the last term of the next non-empty argument left of the actual marked argument:

Page 174: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

166 111.2 Formal spec i f i ca t ion of the system core

as as ~ o ~

/Sk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~/

function [ l ~ ( t : term ; If> : tIx)s II left-ok(t, tp) ) : tpos , function ~ ( t : Iz, m ; tp : tpos ) :b~o l ,

laws left-ok(t, tp) - up-ok(t, tp) /~ i <sp V ( ] k : pnat ()k <ap A has-args(as, k)) where ~ : pnat -- sequ-pos-tp(tp) ;

ap : Imat - args-pos-tp(tp) ; as : args = children(t, tp) ,

le f t ( t , tp) ~ lead-tp(tp) & <new-pair> w~,~e sp : pnat ~ seqJ-pos-tl)(tp) ;

ap : pnat ~ args-pos-tp(tp) ; as : args ~ childFen(t, tp) ; new-pair : pp =-

i f 1 <sp then pair(ap, sp-1) else pair(nap, ]as[nap]I)

14~sre nap : pnat ~ max(l, ap-1, has-args(as, -)) endif

provided left-ok(t, ~ ) ,

. ........ ........... /

~on ]mt~o~-t) (t : m; p : ~ ; c : copy I) is-in-t(t, p) ) : ~,

laws set-copy-t(t, <>, c) -z make-t(set-copy-o(optor(t), c), args(t)) ,

set-copy-t(t, <pair(pa, ps)> & p, c) le t newterms : terms ~ change-ts(args(t)[pa], ps, set-copy-t(args(t)[pa][ps], p, c)) in m~e-t(optor(t), change-as(args(t), pa, newterms))

provided is-in-t(t , <pair(pa, ps)> & p) ,

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

function J has-copy-tl ( c : copy ; t : ~ ; p : tpos ) : bool ,

lak~ has-copy-t(c, t, p) is- in-t( t , p) /L eq-c(c, copy-o(optor(subterm-t(t, p)))) ,

Page 175: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 9 Terms: Type TERM

167

/ * F t ~ A ~ O P ~ T I O W S * /

function F ~ ( ts l . ts2 : ~mlTS ) : args,

laws concat(tsl, ts2) -- <tsl> & <ts2> ,

funct i~ has-no-indeterminates-t ( t : term ) : boo] . function has-no-indeterminalms-ts ( ts : ~mnm; ) : boo] . function ("has-~indeterminates-asl ( as : mrgs ) : boo] .

laws has-no-indeterminates-t(t) -- has-no-indeterminates-as(args(t)) .

has-no-indeterminates-ts (ts) --

is-Bmty-ts(ts) V (has-no-indeterminates-t(first-ts(ts)) A has-no-indeten,inates-ts(rest-ts(ts))) .

has-no-indeterminates-as (as) - is -~ty-as(as) V (has-no-indeterminates-ts(first-as(as)) A has-no-indeterminates-as(rest-as(as)))

e ~

Page 176: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

168

I I I . 2 Formal specification of the system core

A ~ position is a sequence of pairs of positive integers that indicates the path from the root of the tree that corresponds to a term to the root of the subtree that corresponds to the subterm to be marked; the numbers in the sequence are the indices of the arguments through which the path passes.

/ * */

basedom PNAT ,

*/

/* DATAI~ES */ 9~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ik/

~m F~ ( F~-~l ) -- rem~ ~ : mat (eq-n) ;

: mat (e~n) endmBcomd ;

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

~ ( ~ , F~--~l, ~ , F~--~-~l, Gu. SEQU(~. eq-pp) ,

( iset-of-i@osl. Teq-set'~i. )mk-sing-tpl. i is-mmt~r-tpl, i is-subset'tpl, ~ , ~ ) from SET(4xm, eq-~)

e , d a b ~

Page 177: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 9 Terms: Type LANGUAGE

169

The type LANGUAGE summarizes the central part of the language dependence of the system. In an instantiation i t vall l ist the actual sorts and operators making up the concrete language under consideration.

*/

<<definition of the concrete sorts and operators>>

--=*/

Page 178: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

170

I I I . 2 Formal specif ication of the system core

The type OPERATOR provides the functions for constructing ~ as a basis for the i ~ LANGUAGE. According to Part II there are four kinds of ( ~ : - variables for terms, - indeterminates which stand for arbitrary but fixed terms, - proper operators each with fixed number and sorts of arguments, - meta-operators each with a fixed number of arguments. Since meta-operators (such as SUBST),

like prt~icates, frequently are generic, the sorts of their arguments may vary. Again this causes context conditions in the language definition.

Only variables may be instantiated (cf. the i ~ INSTANCE).

I t is possible to distinguish several copies of an operator. This serves for more re f ined possibilities of matching, in particular in connection with sequence variables, as well as for naming and associative search of subterms by considering the copy indications of their leading operators.

The ~ OPERATOR

- prp

- var

- ind

- mop

- e q - o

- equal-o

- name-o

- range-o

- copy-o

- i s -p rp -o

- i s - v a r - o

- i s - i nd -o

- isomop-o

- set-copy-o

provides the following operations:

constructs a proper operator out of an operator identifier name-p, a sequence arg-sorts-p of sorts for the arguments of the operator, a plain result sort sort-p, and a copy indication copy-p; constructs a variable from a variable identifier name-v, a sort sort-v indicating the sort of elements the variable stands for, and a copy indication copy-v; constructs an indeterminate from an indeterminate identifier name-i, a sort sort-i indicating the sort of elements the indeterminate stands for, and a copy indication copy- i ;

constructs a meta-operator out of an meta-operator identifier name-m, a sequence arg-sorts-m of sorts for the arguments of the operator, a sort result sort-m, and a copy indication copy-m; "weak" equality of operators disregarding copies; "strong" equality of operators distinguishing operators with different copies; yields the name of an operator; yields the result sort of an operator; yields the copy indication of an operator; checks whether an operator is a proper one; checks vlaether an operator is a variable; checks whether an operator is an indeterminate; checks whether an operator is a meta-operator; replaces the copy indication of an operator by another one.

Page 179: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I , 2 .9 Terms: Type OPERATOR 171

/* */

~ m F~-~l,

/* DA~TYPES */

~ ( F ~ - - - - I , F ~ , L - ~ , ~ I :- ~T,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

s o r t orln ,

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f ~ c i ; i o n eq-onm ( ore ; one ) : boo1 ,

include EQUIVALENCE(ohm, eq-onm),

*__ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , /

<<definition of the concrete operator names>>

.= ~===~=_--_~___=_-==_-= . /

~ ~ ( F ~ - ~ ~ ~ FE61 ~ ~ ~ mm~p : n (e~mm) ;

larg-~r~-pI : sorts (eq-ss) ; sort-p : sort (eq-s) ; copy-p : ~ (eq-c) n is-plain-s(sort-p)

F ~ test ~ record n~m-v : ~nm (eq-onm) ; sort-v : sort (eq-s) ; copy-v : copy (ec~c)

~ ~ mco~ ~m-i : mm (eq-onm) ; sort-i : sort (eq-s) ; copy-i : c ~ (eq-c)

Page 180: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

172 111.2 Formal specification of the system core

~ test ~ mo~d nam~m : n (eqRmm) ; F ~ : nat (eq-n) ; sort-m : sort (eq-s) ; copy-m : c ~ (eq-c)

e ~ ,

b a ~ ( Iset-of-opera~I, ~ , le~tyset-oI, [is-emptyset-ol, ~ , l i s~m~r~) ~m .e . , lis-subsetJl, ~ , l in ter~-o l , ~ ) from SET(~eralmr, eq-o) ,

*=== ===___:= . . . . . ::___ ==_~__=====./

/* OPERATIONS */

fum~im ~ ( o : operaWr ) : mm,

laws name-o(o) - i f o is prp then name-p(o) D o is var then nmne-v(o) 0 o is ind then name-i (o) n o is mop then name-m(o) endif,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -*/

function ~ ( o : operalmr ) : sort .

laws range-o(o) i f o is prp then sort-p(o) D o is var t ~ sort-v(o) [l o is ind then sort-i(o) {] o is mop then sort-m(o) emdif,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .* /

f~nction FE6-~] ( o : operaWr ) : copy,

la~ copy-o(o) i i f o is prp ~ copy-p(o) D o is vat thin copy-v(o) n o is ind then copy-i(o) D o is mop ~ copy-re(o) emdif,

Page 181: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 .9 Terms: Type OPERATOR

173

. .................................................................................................. _*/

fimc%i(m ~ ( oi, o2 : ( ~ ) : b(m] ,

]a~ eq-o(ol, o2) --

eq-onm(name-o(ol), namo-o(o2)) A eq-as(arg-sorts-o(ol), arg-sorts-o(o2)) A eq-s(range-o(ol), range-o(o2)) ,

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f l ~ i o l l I set-co~-ol ( o : operal]]r ; c : cow ) : operator ,

laws set-copy-o(o, c) -

i f o is prp the, prp(name-p(o), arg-sorts-p(o), sort-p(o), c) 0 o is var then var(name-v(o), sort-v(o), c) [l o is ind then ind(name-i(o), sort-i(o), c) [] o is mop then mop(name-m(o), ari~-m(o), sort-re(o), c) endif,

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /

f ~ o m F~-~-l ( c l : c ~ ; c2 : c ~ ) :boo] ,

laws fit-c(cl, c2) = eq-c(cl, anonymous) k/eq-c(cl, c2)

Page 182: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

174

111.2 Formal spec i f ica t ion of the system core

The type SORT provides the functions for constructing sorts corresponding to nonterminals of an abstract grammar for use in the type LANGUAGE. The type SORT provides the following operations:

- plain - p-snm -sequ - s - s n m

- is-plain-s - is-sequ-s - plain-made - sequ-made

makes a non-sequence sort out of a sort identifier; yields the sort identifier of a plain sort; makes a sequence sort out of a sort identifier; yields the sort identifier of a sequence sort; tests whether a sort is a plain sort; tests whether a sort is a sequence sort; yields the corresponding plain sort for a given sort; yields t~e corresponding sequence sort for a givm sort.

*/

/~ D A T A T Y P E S * /

s o l ~ s l i m ,

/ A j k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ ~ /

f-unctian eq-sr~ ( sm ; s~m) : boo1 ,

iml~ EQUIVALENCE(smm, eq-snm) ,

<<definition of the concrete sort names>>

/* ~*/

~pe ~ ( ~ ) , ~ ~ J is-plain-sl record ~ : smm (eq-snm) ~ J test ~ reo~d ~ : sm (eq-snm) m d ~ o ~ .

, , ~ . . [ . ] . ~ , ~ , lis-elem-ssl s3m .~ . ) from SECU(s(~, eq-s),

. ! ,~-of-sort. ~ . ~ sy. {.}. [is-mm~r-sl syn .e . , Jis-subset-sl, ~ syn .U. , ~ , I i~ tyset-s l syn 0 ) from SET(sort, eq-s) ,

Page 183: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 9 Terms: Type SORT 175

* = = _____-*/ /*OPERATIONS*/

function I-s(3~-'-~a-c~] ( s : s o r t ) : sart,

laws sew-made(s) i f is-plain-s(s) ~ sequ(p-snm(s)) rl is-sequ-s(s) then s endif,

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _./

function ~ ( sl : sort ; s2 : sort ) : boo] ,

laws agree-s(sl, s2) - i f is-sequ-s(sl) ~ eq-snm(srea-s(sl), snm-s(s2)) {] is-plain-s(sl) ~ eq-s(sl, s2) en~f ,

*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _./

function snm-s ( s : sort) : snm,

l ~s s m - s ( s ) - i f s is plain t~En p-snm(s) D s is sequ ~ s-sr~(s) E~lif

e ~

Page 184: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

176

I I I . 2 Formal speci f icat ion of the system core

2.10. Basic t~l~S

/ , ..*/

base(kin NAT ,

sort I - ~ ,

~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _@c/

lempty~qu-ml : sequin,

fimctim ~ ( se~Hm, se~Fm) : sequin,

laws r : sequ-m ; s : s e ~ ; t : sequ-m Jl conc-m(emptysequ-m, r) = r . conc-m(r, emp~ysequ-m) - r . conc-m(r, conc-m(s, t ) ) ~ conc-m(conc-m(r, s). t ) .

functim ~ - - ] (~mqu-m):Imol .

lawsr : s e ~ ; s : s e ~ ; x : m is-y-m(emptysequ-m) ~ t rue. is-y~,(m~ke-m(x)) - f a l m . is-y-m(conc-m(r, s)) - (is-y-m(r) A is-y-m(s)) .

laws r : sequ-m ; s : s e ~ ; x : m ; y : m I) eq-sequ-m(e~tysequ-m, emptysequ-m) = t rue. eq-sequ-m(conc-m(make-m(x), r) . conc-m(mm~e-m(y), s)) = (eq-m(x. y) A eq-sequ-m(r, s)) .

eq-sequ-m(emptysequ-m, s) - is-y-m(s). eq-secN-m(r, s) ~ eq-sequ-m(s, r) .

Page 185: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I l l . 2 . 1 0 Basic types

177

i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * I

r-u,~-ion ~ ( s : s e q H II ~ is-y-re(s) ) : , i , , f ~ , ~ ~ ( s : sequ-m II ~ is-y-.re(s) ) : sequ- - . . f i m c t i ( ~ ~ - - - ' 6 6 ~ ( secp-m ; m ) : se (p .m.

lawsr : s ~ ; x : m II aI~d-m(r, x) - conc-m(m~e-m(x), r) , f i r s t - m ( ~ - m ( r , x ) ) i x , rest-m(append-m(r, x)) - r ,

._ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f ~ c t i a n ~ ( s : sequ-m II ~ is -y -m(s) ) : m ,

f~m,:tian ~ ( s : sequ-m II ~ is-y-re(s) ) : sequ-m, f-~-tion F~'E-~ ( ~ N - m ; m) : seq=-m,

laws r : s e ~ ; x : m II

stock-m(r, x) = conc-m(r, make-re(x)) , last-re(stock-re(r, x)) = x , lead-m(stock-m(r, x)) - r ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f l m ~ i o . ~ ( ~ ) : n a t ,

lawsr : s ~ ; s : s e ( ~ ; x : m

leng~-m(emptysequ-m) ~ 0 , length-m(m~e-m(x)) ~ 1 , leng~-m(conc-m(r, s)) - (length-m(r) + leng~-m(s)) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

ftmcti~m F - ~ ( r : sequ-m; i : nat I11 ~ i A i ~ leng~h-m(r) ) : m ,

lawsr : sequ-m;i :na t II (1 ~ length-m(r)) ~ sel-m(r, i ) = first-re(r) , ((1 < i+1) A (i+I < length-m(r))) ~ sel-m(r, i+i) = sel-m(rest-m(r), i ) ,

*_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f m c L i m ~ ( ~ ; m ) : m ,

laws r : s e ~ ; s : seq~-m ; x : m ; y : m N

del-m(emptysequ-m, x) - B~ptyse~-m, del-m(make-m(y), x) - i f eq-m(x, y) then emptysequ-m else ma~e-m(y) B~if , del-m(conc-m(r, s), x) ~ conc-m(del-m(r, x), del-m(s, x)) ,

Page 186: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

178

I l l . 2 Formal specif ication of the system core

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f u n c t i m F T ~ ( s e q u - m ; m ) : b o o l ,

laws r : sequHm ; s : sequ-m ; x : m ; y : m is-elem(emptysequ-m, x) -: false, is-elem(make-m(y), x) m eq-m(x, y) , is-elem(conc-m(r, s), x) = is-eIBn(r, x) V is-elem(s, x) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

f~Lt;on ~ ( r : sequ-m; i : n a t ; x :m U 1 ( i A i ~ lengbh-m(r) ) : ~ ,

lamer : seq~-m; i : n a t ; x : m U 1 ~ length-re(r) ~ change-m(r, 1, x) - append-m(rest-m(r), x) , (1 < i+1 A i+1 ~ length-m(r))

change-re(r, i+1, x) = append-m(change-m(rest-m(r), i , x), first-re(r)) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /

function[-s~)-m-------I ( s : s e q u - m ; i : n a t ; j :nat ~ i ~ j ~ j (length-re(s)) :sequ-m,

laws sub-re(s, i , j ) i f j < i V eq-n(j, 0)

~mn B~'ysequ-m elm i f eq-n(i, i) then get-front-re(s, j)

else sub-re(s, i-1, j - l ) endif provided i ~ j ~ j ~ length-re(s) ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . */

functionlget-front-mI( ~ ; nat ) : sequ-m ,

lak6r : sequ-m; x : m ; i :nat II get-front-m(r, 0) = emptysequ-m, get-front-m(emptysequ-m, i ) - emptysequ-m, get-fFont-m(append-m(r, x), i+1) =- append-m(get-front-m(r, i ) , x) ,

/* . . . . . . . . . . . * /

fiJ:t;on[del-front-mJ( sequ-m ; nat) : sequ-m,

l a w s r : s e q u - m ; x : m ; i :nat [J del-front-m(r, 0) = r , del-front-m(emptysecN-m, i ) = del-front-m(append-m(r, x), i+1)

emptysequ-m , -- del-front-m(r, i ) ,

Page 187: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I . 2 . 1 0 Basic types

179

, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * /

~ m m t - ~ ~ ( , ~ , ; . a t ) : ~ ,

]aesr : sequ-m;x :m; i :nat II get-rearm(r, O) - ~mptysequ-m, get-rear-m(BTptyseqJ-m, i ) - enp~sequ-m , get-rear-m(stock-m(r, x), i+1) ~ stock-m(get-rear-m(r, i ) , x) ,

. _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ _ _ , /

f i m c t i o n ~ ( sequ-m ; nat) : sequ-m,

| a ~ s r : s e q u - m ; x : m ; i :nat II del-rear-m(r, O) = emptysequ-m, del-rear-m(emptysequ-m, i ) = Bnptysequ-m , del-rear-m(stock-m(r, x), i+1) = del-rear-m(r, i )

e ~

Page 188: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

180

I I I . 2 Formal speci~ca~on of the system core

a b s q r a c t ~ ~ - (sortm,fumctio. eq-m(m;m):bool I[ i . c l ~ E~IVALENCE(m, eq-m) ) ;

/* - : * /

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _*/

l emptyset-m) : set-of-m,

._ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _./

function ~ ( m ; set-of-m ) : set-of-m, function ~ ( m ; set-of-m ) : bool , f%mcticm [ - ~ ( m ; set-of-m ) : set-of-m,

laws s : set-of-m ; x : m ; y : m U is-msn-m(x, emptyset-m) ~ false. is-mem-m(x, add-re(y, s)) =- (eq-m(x, y) V i s ~ ( x , s)) .

del-m(x, emptyset-m) = sii)tyset-m , del-m(x, add-m(y, s)) = i f eq-m(x, y) then del-m(x, s) else add-re(y, del-m(x, s)) (Mi f

e.dabstract~

Page 189: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I l l . 2 . 1 0 Basic types

abstract l~ ~ ~ ( sort m, f~mction eq-m ( m ; m ) : bool II include EQUIVALENCE (m, eq-m) ) ;

/*

181

*/

IPRIMSET(m~ eq-m)l ! ,

f~mction ~ ( set-of-m ; set-of-m ) : bool , ~ o n ~ ( set-of-m ) : boo1 , function ~ ( s : set-of-m ~ ~ isempt~set-m(s) ) : m, fimction ~ ( m ) : set-of~m, function ~ ( set-of-m ; set-of-m ) : set-of-m, fimction ~ ( set-of-m ; set-of-m ) : set-of-m, function ~ ( set-of-m ; set-of-m ) : set-of-m, function ~ ( set-of-m ; set-of-m ) : boo1 ;

la~s l : set-of-m ; r : set-of-m ; x : m II

is-y-m(emptyset-m) -: true , is-y-m(add-m(x, s)) - false ,

nk-sing-m(x) ~ add-re(x, emptyset-m) ,

is-sub-m(empt~set-rn, r) ~ true, is-sub-m(add-m(x, l ) , r) - (is-mBn-m(x, r) /~ is-sub-re(l, r)) ,

eq-set-m(l, r) m (is-sub-re(l, r) A is-sub-m(r, l )) ,

union-m(emp~set-m, r) - r , union-re(add-re(x, l ) , r) =- add-m(x, union-re(l, r)) ,

diff-m(l, enlpi~set-m) ~ l ,

diff-m(l, add-m(x, r)) -- i f is-nen-m(x, l) then del-m(x, diff-m(l, r)) else diff-m(l, r) endif ,

isec-m(l, r) i cliff-re(l, diff-m(l, r)) ,

arb-m(nk-sing-m(x)) =- x ,

is-y-re(r) ~ is-nem-m(arb-m(r), r)

e ~

Page 190: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

182

111.3 Validation of the specification: Example revisited

3. Val idat ion of the Speci f icat ion: Example rev is i ted

As one example for the validation of the specification, we show how the fictitious session, discussed in 1.3., can be expFessed in terms of operations of the system core. In addition to the "horizontal" view givm by the hierarchic specification of the system, this also provides "vertical" views by tracing how individual tasks are accomplished by the operations specified.

3.1. ~nBral remarks

Due to the state-oriented view of the system specification and the general desigm decision to have only totally defined functions in the system core, each of the functions defined there produces an effect consisting of a (possibly new) state, a (proper or improper) result and some output, mainly for indicating success or failure of the respective function. Tec~mically, combining a state, a result and an output into an effect is denoted by an operator .+.+.:

~ e eFf~t =- make-effect r~c~m~ s : s i ~ ; r : re~41t ; o : m ~ t

function .+.+. ( state : state ; result : ~ l t ; output : output ) : effect,

1 ~ state + result + output -- m~e-effect(state, result, output)

The system state is a triple, consisting of a "current" activity, a stack of "nested" activities, and a knowledge base. The stack records pending activities together with their corresponding catalogs of inferences and assumptions. The knowledge base is a catalog base, i.e., a collection of catalogs, which, in par~cular, contains two catalogs for the "current" inferences and assumptions. The catalogs are accessible by name.

~B~e stalm make-state record actual-activity : act ivi~ ; stack : stack ; cat-base : cat-base H admissibl e(cat-base)

An activity is either neutral, or a derivation, or a reduction.

~ e act iv i~ - neutral I der-to-act record deriv : (k-rivati~ e ~ I red-to-act Fec~ reduc : Fe(~ctiom :~T~wd

Page 191: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I l l . 3 .1 General remarks 183

The stack of nested activities also records the catalogs of inferences and assumptions that belong to these activities.

t~e si~ckemmry -- triple mecomd act : act iv i~ ;

assu-cat : catalog ; inf-cat : cai~Iog lJ eq-grp(group(assu-cat), cl s-grp) A eq-grp(group(inf-cat), inf-grp)

endrecomd,

basedon ( stack, empty-stack, is-B~p~stack, push, pop, top, leng~) ~,UII STACK(si~ck:,~)

Catalogs are specified as triples <group, named, anonymous>. The "group" characterizes the kind of entries in the catalog; "named" is a map from names to elements, and "anonymous" is a set of anonymous elements:

~e calzlog -- ~e-ca t Feo~ group : ~ , nard : map , anonymous : sequ-of-en~mj II compatible-map(nard, group) A compatible-sequ(anonymous, group)

e m ~

3.2. The sample session in b~ms of safs~n fu.ctions

The informal treatment of our fictitions sample session consisted of sevan individual steps. Of course, not each of these steps is directly reflected by a single ~stem function, but rather consists of a (simple) composition of several system functions. Before dealing with each of those conceptual steps individually, we f i rst give an overview on how they might be realized by means of the ~stem functions specified above. In order to simpli~ the presentation, we assume that no errors occur, i.e. that each of the state transitions given below results in a defined new state. Sim~Tarly we assume the definedness of all access functions used.

(1) Initialization of the system and installation of an appropriate knowledge base:

let z o : ~ -- s(start-system);

le t Cll : catalog - << convert f i le f l l to catalog } ;

le t Zll : state = s(load-catalog(elem-rules, c11, zo)); le t c12 : catalGg ~ << convert f i le f12 to catalog >>; le t z12 : state - s(load-catalog(set-rules, c12, z11)); le t c13 : catalog ; << convert f i le f13 to catalog >>;

le t z13 : slate = s(load-catalog(set-specs, c13, z12));

We have assumed that an external f i le f l l contains a catalog of elementary transformation rules which is made accessible in the system's knowledge base under the name "elem-rules".

Page 192: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

184 111.3 Validation of the specification: Example revisited

Similiarly, f12 and f13 are supposed to contain catalogs of (further) rules and program schemes that are made available under the names "set-rules" and "set-specs", respectively.

(2) Start derivation with program scheme "enumerate"

let t I : term - tem(ent(r(get-entry(set-specs, enumerate, z13)))); |et z 2 : sltaibe = s(start-derivation(tl, z13));

(3) MovB~mt of markings and application of rules:

let p : t ~ = << appropriate marking } ; let z31 : ~ - s(set-mark(p, z2)); let i31 : inference = inference(ent(r(get-entry(elem-rules, rule1, z31)))); let k I : pmat - << appropriate length of subterm-sequence >>;

let z32 : ~ - s(perform-rule-application(i31 , kl, z31));

Here we have chosen to mark the f i r s t subterm to be transformed by "set-mark" rather by moving the ini t ia l marking of the entire program scheme (as installed by the previous step) to the appropriate subterm. Furthermore, we have decided to apply the rule "rulel" from the catalog "elem-rules" to the indicated subterm.

|et Z3n : stalin ~ s(perform-move( I , Z3(n.l))); let i3n : imf~i=-~e = inference(ent(r(get-entry(set-rules, rule n, Z3n)))); let k n : pnat = << appropriate length of subterm-sequence ~> ;

let z3(n+l) : stalin = s(perform-rule-application(i3n , kn, Z3n));

For this last step of our sample derivation, i t was assumed that the respective subterm to be transformed was the directly enclosing one of that of the previous step, and that the last rule applied was rule "rulen" from the catalog "set-rules".

(4) Deduction of an inference

let t : m ~ -z mlm(r(get-contract(z3(n+1)))); fete 4 : effect = perform-inference-cL~:k~ion(t, Z3(n+l)); let new-rule : inference ~ inf(r(e4));

let z 4 : sita~ : s(e4);

The operation perform-inference-deduction extracts the inference consisting of the initial program scheme as the input template, the actual scheme as the output template, the semantic relation calculated from the individual relations according to the function rel-comp from the type REL-COMP, and the union of all intermediate applicability conditions, and records i t in the actual catalog of inferences•

Page 193: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I .3.2 The sample session in terms of system functions 185

(5) Simplification of the applicability conditions:

let c51

l e t z51 l e t i51 let axs

let zsz

: clause - << select a suitable p~mnise from the p~=mises of ne~-rule ~;

: s i ~ = s(start-reduction(c51 , z4)); : im#em~e - inference(ent(r(get-ontry(set-rules, rule51 , z51)))); : s e t - o f - i . F ~ = << convert f i le faxs to set-~f-i.~:L~: >>;

: s i ~ = s(perform-goal-~=duction(c51, i51, axs, z51));

let ZSn : state let esn : effect let i52 : inference

l e t e5(n+l) : ef fect l e t ZS(n+2) : si:at~

l e t Z5(n+3) : stai~

= s(perfonn-goal-reduction(cs(n_1) , i5(n_1), axs, ZS(n_l))); = perform-inference.extraction(ZSn);

= inf(r(esn)); = return_inference(i52, s(esn));

=- s(end-reduction(s(eSn+l)));

s(perform-cut(i52, new-rule, ZS(n+2)));

The simplification of applicability conditions proceeds in the following way: one of the premises of an inference is selected; a reduction with the selected clause as the goal is initialized; this goal is reduced to a set of "simpler" subgoals using an inference (here "rule51" from the catalog "set-rules") and a set of axiomatic inferences (which here are assumed to be available in an external f i le faxs); after a number of goal reductions and/or applications of meta-inferences, the current reduction is made into an inference which is recorded in the actual catalog; this inference is passed to the "pending" derivation activity, and the current reduction activity is finished; in the derivation activity, with this inference "new-inf" the inference obtained by our previous derivation is simplified using the meta-inference "cut".

(6) Conservation of the developed rule

I f we assume that the system has finished step (5) with effect e5, the next steps are as follows:

let i : jnferemce • inf(r(e5)); |et z 6 : si~alm = s(insert-ontry(set-rules, enum, conv-inf(i), zs)); << write set-rules onto f i le f12 >>;

The developed rule is added to the catalog "set-rules" under the name "enum". The "updated" catalog then is written onto the external f i le "f12"-

(7) Finishing the session:

let z 7 = s(end-derivation(z6))

in quit(z7).

Page 194: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

186 I l l . 3 Validation of the specification: Example revisited

Of course, we have not only made a number of assumptions within this sample session, but also taken quite a lot of particular design decisions. Therefore, in the sequel, we want to comment on possible alternatives.

(a) In step 3 we have followed the strategy of postponing the simplification of applicability conditions. Instead, after each application of a transformation rule we also could have tried immediate simplification by a series of steps of the form

let i j : infemence - inference(ent(r(get-entry{cat-name, rule-name, z3j))));

let z3(j+1) : state - s(perform-condition-reduction(ij, z3j));

This means that the applicability condition leading to the actual term in state z3j would have been

simplified using an inference available in the catalog cat-name under the identifier rule-name. (b) In step 4 and 5 we have first deduced an inference from the current derivation and then tried to

simplify the premises of this inference. Due to our ultimate goal of just deducing a new transformation rule rather than focusing on the derivation as such, a different pFoceeding could have been first to compactify the development and then to modify the conditions of the compactified development again using condition-reduction with a suitable inference (either from some catalog or developed as examplified in step 5 above).

(c) Another alternative with respect to step 5 could have been to try first simplification of the inference obtained by step 4 using inferences from one of the available catalogs and a suitable meta-inference. Proceeding this way is particularly advisable i f some of the premises of the inference in step 4 immediately coincide with conclusions of available rules.

3.3. Tectm~cal ~b~,'lizatJon of the sB~tem f~cUans used in the sample session

(I) Initialization of the system and installation of an appropriate knowledge base

(a) start-system

Starting the system means to establish an initial state and to tell the user to go on:

start-system : effect,

Ia~ start-system ~ init-state + no-result + answer(ready)

The initial state consists of a "neutral" activii&,, an empty stack of pending activities and a catalog-base containing an empty catalog of inferences and an empi~, catalog of assumptions which are accessible by the (reserved) names "inf-actual" and "cls-actual".

init-state : stai~ ,

la~ init-state -- make-state(neutral, empty-stack, init-cat-base)

(b) load-catalog

function load-catalog ( n : name ; c : cat ; z : state ) : effect, f ~ m cat-loadable ( n : ~ ; c : cat ; z ; si~Im ) : bool ,

Page 195: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I .3 .3 Technical detailization of the sample session 187

]am cat-loadable(n, c, z) -- loadable(n, c, carCase(z)) ,

load-catalog(n, c, z) = i f cat-loadable(n, c, z)

t ~ replace-cat-base(rmw-base, z) + no-result + answer(done)

where new-base : cat-base - load(n, c, cat-base(z)) fl ~ cat-loadable(n, c, z)

them id(z) + ne-result + answer(not-loadable) endif

load-catalog (n, c, z) adds a catalog c to the knowledge base in the current state z and makes i t accessible under the name n. Of course, i t has to be checked, whether the catalog is loadable, i.e. whether the name n is not yet associated with a catalog in the current knowledge base.

fanction load ( cn : nmm ; cat : catalog ; cat-base : cat-base II loadable(cn, cat, cat-base) ) : cat-base ,

fLmction Ioadable (cn : ~ ; cat : catalog ; cat-base : cat-base ) • bool ,

]am Ioadable(cn, cat, cat-base) = ~ has-cat(cn, cat-base) ,

load(cn, cat, cat-base) • put(cat-base, cn, cat) provided Ioadable(cn, cat, cat-base)

Here, has-cat checks whether a catalog with the name cn exists in the catalog-base, and put adds the catalog cat to the catalog-base under the name cn.

(2) Start derivation with program scheme "enumerate"

(a) fetch entry

f i lct ion get-entry ( cn, en : name ; z : state ) : e f fect , function fetchable-from-cat ( cn, en : name ; z : state ) : bool ,

la~s fetchable-fFom-cat(cn, en, z) = fetchable-from(cn, en, cat-base(z)) ,

get-entry(on, en, z) = i f fetchable-from-cat(cn, en, z)

then id(z) + ent-res(fetch-from(cn, en, cat-base(z))) + answer(done) D ~ fetchable-from-cat(cn, en, z)

id(z) + no-result + answer(not-fetchable) endif

get-entry yields the entry named en from the catalog named cn provided that the entry and the respective catalog exist, and an error-message otherwise.

Page 196: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

188 I l l . 3 Validation of the specification: Example revisited

f~mctim fetch-from ( cn, en : ~ ; cat-base : cat-base II fetchable-from(cn, en, cat-base) ) : enibry ,

funct im fetchable-frm ( cn, en : mine ; cat-base : cat-base ) : boo] ,

] ~ fetchable-from(cn, en, cat-base) - has-cat(cn, cat-base) /L contains(cn, en, cat-base) ,

fetch-from(cn, en, cat-base) = select(select-cat(cat-base, cn), en) provided fetchable-from(cn, en, cat-base)

(b) start-derivation

fmL't im start-derivation ( tern : ~ ; z : state ) : effect,

laws start-derivation(term, z) - start-deriv(term, z) + no-result + answer(dene)

start-derivation initializes a derivation activity starting with the program scheme term. The initialized derivation is added as a new activity to the stack of activities.

fmctim start-deriv ( term : ~ ; z : sta~ ) : s-ta~e,

]a~ start-deriv(t, z) • add-activity(new-act, context-conditions-t(tem), z) new-act : act iv i~ ~ der-to-act(init-derivation(tem))

der-to-act simply converts the derivation obtained by init-derivation into an aci~vii~ which is then added to the stack. The previous activity together with its actual catalogs is saved on the stack. Additionally, the information in the actual catalogs of the pending activities is passed on to the actual catalogs for the new activity.

A derivation is a tuple consisting of the "actual" program scheme and a particular "tree" that reflects the development so far. Of course, the actual program itself has to be contained in the tree.

dmivati~ ( eq-der ) - make-tier record actual-term : mb~m (eq-mt);

dev-tree : dev-i:ree (eq-dev) ~ is-in-devtree(actual-term, dev-tree) emdm~ord

The actual program scheme is represented as a marked term, i.e. as a program scheme (type tern) and a position indicating the subterm of interest.

m~mm (eq~.t) -- mark record term : ~ (equal-t) ;

tp~ : ~x~ (e~tp) II is-in-t(term, tpos)

i . . . . . J

Page 197: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.3.3 Technical detailization of the sample session

189

The condition is-in-t guarantees definecb~s of the indicated position. The development tree in a derivation is simply a set of development units of the form

deV~lit (eq-dvu) = init-devunit record post : m ~ (eq-mt) emlkec(~ I proper-devunit record pre : m ~ (eq-mt) ;

post : mbmm (eq-mt) ; prenm : set-of-clause (eq-set-cl) ; info : info (eq-info) ; re] : p r e ¢ ~ (eq-ps)

e ~

where init-devunit reflects the case of a development tree just consisting of a (marked) program scheme as its a Foot; and proper-devunit reflects the "usual" case of a quintuple consisting of - pre, the program scheme that has been transformed, - post, the result of applying a transformation to pre, - prems, the instantiated applicability conditions of the rule that has been applied,

info, additional information about the transition (e.g. the name of the rule that has been applied), rel, the semantic relation that holds between pre and post.

init-derivation then simply constructs a derivation consisting of the program scheme term (vlaich is marked as a whole) and a derivation tree consisting of the (initial) development unit i ni t-devuni t( mark-root( term ) ).

function init-derivation ( t : ~ ) : (L~-ivation ,

laws init-derivation(t) = make-der(~ark-root(t), init-tree(mark-root(t)))

(3) Movement of markings and application of rules

(a) set-mark

f ~ o n set-mark ( pos : t ~ ; z : state ) : effect, fum-tim legal-mark ( pos : t ~ ; z : slal~ ) : Ixml ,

]a~ legal-mark(Ix)s, z) = deriv-mode(z) /L legal-position(pos, derivation(z)) ,

set-mark(pos, z) = i f legal-mark(Ix)s, z)

1~Blupdate-deriv(new-deriv, z) + no-result + anm~er(dene) whmm new-deriv : (E~ivatiom -z set-pos(pos, derivation(z))

0 ~ deriv-mode(z) id(z) + no-result + answer(not-deriv-mode)

[] deriv-mode(z) /L ~ legal-mark(pos, z) id(z) + no-result + answer(illegal-mark)

e ~ f

Page 198: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

190 I I I . 3 Validation of the specification: Example revisited

Marking a subterm for rule application is only meaningful within a derivation activity. Additionally, the indicated position (of the subterm) has to be defined. I f both conditions are fulfilled, the subterm characterized by the respective position is marked in the "actual" term. Furthermore, the change in the marking is recorded in the development tree by adding a suitable development unit.

flmction set-pos ( p : ~ ; dor : (k~rivatiom II legal-position(p, der) ) : derivation , function legal-position ( p : tpos ; der : derivation ) : bool,

laws legal-position(p, tier) = legal-pos(p, old-term) A is-in-devtree(set-mark(p, ol d-term), dev-tree(der)) ,

where old-term : mbmm - actual-tem(der) ,

set-pos(p, der) - make-tier(new-tern, new-tree) where old-tern : m ~ =- actual-tern(tier) ;

old-pos : tpos =- i~os(old-term) ; new-term : mbmrm - set-mark(p, old-term) ; new-tree : dev-lm~e m add-to-tree(old-term, new-term, 0, move-info(old-pos, p),

id-prsymb, dev-tree(der) ) pmovided legal-position(p, der)

The change in the marking itself simply means replacing the "old" marking by the new one.

flmction set-mark ( p : tpos ; m : mb~m JJ legal-pos(p, m) ) : mbmrm, function legal-pos ( p : i ~ ; m : ~ m ) : boo1 ,

laws legal-pos(p, m) = is-in-t(tem(m), p) ,

set-mark(p, m) = mark(term(m), p) pruvi(k~l 7egal-pos(p, m)

(b) perform-move

A different way of indicating a new subterm for rule application is by "moving" the "old" mmldng relative to the respective ~erm. This requires to indicate a "direction" ( I , 4, -->, <--).

function perform-move ( dir : d ir ; z : sN~b~ ) : effect, function legal-mDve ( dir : d ir ; z : s l ~ ) : bool ,

la~6 legal-move(dir, z) = deriv-mode(z) A movable(dir, derivation(z)) ,

perfom-move(dir, z) -z i f legal-move(dir, z)

~date-deriv(new~riv, z) + no-result + answer(done) •heme new-deriv : derivation = move(dir, derivation(z))

{] ~ deriv-mode(z) bL~, id(z) + no-result + answer(not-derivation-mode)

{] deriv-mode(z) A ~ legal-move(dir, z) them id(z) + no-result + angler(illegal-move)

em~f

Page 199: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.3.3 Technical detailization of the sample session

191

Of course, this kind of indicating a new subterm also requires define(bess of the respective movement. The movement i tself is done by computing from the current position of the marking in the "actual" term and from the direction a new position which then replaces the old position in the "actual term". Again, this movemBnt is recorded in the development tree.

f ~ i o m move ( d : dir ; der : dedvatiom ~ movable(d, der) ) : derivation, fimctim movable ( d : dir ; der : dmivation ) : boo1 ,

1 ~ movable(d, der) - movable-rot(d, old-term) A is-in-devtree(move-mt(d, old-term), dev-tree(der)) ,

Where old-term : m ~ - actual-tem(der) ;

move(d, der) = make-der(new-tem, new-tree) Where old-term : m ~ = actual-tem(der) ;

old-pos : tpos • tpos(old-term) ; new-tern : m ~ - move-rot(d, old-term) ; new-pos : tpos ~ tpes(new-term) ; new-tree : ~ - t r e e -- add-to-tree(old-term, new-term, 0, move-info(old-pos, new-pos),

id-prsymb, dev-tree(der)) provided movable(d, der)

(c) Perform-rule-application

Transformation rules are particular inferences.

i n f ~ : ~ : ( eq-inf ) - mk-inf record premises : set-of-claJse (eq-set-cl) ;

conclusion : clamse (eq-cl) e ~ ,

fanctim make-inf ( prems : set--of--clame ; concl :clame ) : i i , f~-~-~e,

l a~ make-inf(prems, concl) -= normalize-inf(mk-inf(new-prems, concl )) MiBre ne~prems : set-of-clause

pre~ U context-conditions-cl (concl) U { context-conditions-el (cl) II cl e prems }

An I n f e ~ consists of a set of clauses, its premises (which are the applicablqi~ conditions in case of a transfomation rule), and a clause as its conclusion (which, in case of a transformation rule, characterizes the transformation proper, i.e., states a semantic relation bergen two program schemes). The operation normalize-inf is language-dependent; i t simplifies the premises as far as possible.

A cla~e, defined by

~ c l ~ e ( eq-cl ) m~e-cl = anteced~ts : ~ t -o f - f~n~la (eq-set-fo) ;

consequent : fonm|a (eq-fo) emdmmrd

Page 200: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

192 I l l . 3 Validation of the specification: Example revisited

consists of a set of formulas, its antecedents, and a formula as its consequent, where a formula is defined by

formula ( eq-fo ) make-fo record pred-symb : pnBd-~ (eq-ps) ;

args : args (eq-as) II makable-fo(pred-symb, args)

em(Wec~d

function ma~able-fo ( ps : p r e d - ~ ; as : args ) : Imol ,

la~s makable-fo(ps, as) • compatible-ps(ps, as)

i.e. by some predicate symbol together with a sequence of arg~B(mts.

An inference is a b-ansfomalJ(m rule i f the consequent of its conclusion has exactly t~o arguments, and i f its conclusion has no antecedents.

f~mcti(m perform-rule-application ( rule : i~fev~-~ze ; k : pnat ; z : sl;ai~e ) : effect, f ~ c m applicable (rule : i ~ ; k : imat ; z : state ) : boo1 ,

la~ applicable(rule, k, z) = deriv-mode(z) A is-applicable(rule, k, derivation(z)) ,

perform-rule-application(rule, k, z) i f applicable(rule, k, z)

update-deriv(new-deriv, z) + no-result + amswer(done) where new-deriv : (km-ivation ~ rule-application(rule, k, derivation(z)) ;

D ~ deriv-mode(z) i~hem id(z) + no-result + answer(not-derivation-mode)

D deriv-mode(z) /k ~ applicable{rule, k, z) tlmm id(z) + no-result + answer(rule-not-applicable)

en~f

perform-role-application(rule, k, z) checks whether applying the inference "rule" is a legal command, i.e. whether the system is in derivation mode and, i f so, whether the rule is applicable to the indicated subterm of the actual term of the derivation. I f these conditions are fulfilled, the rule is applied, thus producing a new actual term. Additionally, the successful transition is recorded in the development tree.

function rule-application ( rule : Jnfen~-Le ; k : pnat ; der : derivation II is-applicable(rule, k, der) ) : (ferivatiom ,

function is-applicable ( rule : infmremce ; k : pnat ; der : derivati~ ) : b(x}l ,

l a~ is-applicable(rule, k, der) = is-rule(rule) /~ (( V (k: nat H k ~ leng~tp(pos))

is-monotonic(get-op(terms(oldterm), sub-tp(pos, 1, k)), rel-symb(rule))) A (has-marked-part(old-term, k) /~

Page 201: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I .3 .3 Technical detailization of the sample session 193

(applicable(rule, marked-part(old-tern, k), environmmt(old-term)) A term-replaceable(old-term, k, out-template(new-inf)) )) /L

is-in-d~vi~ee(replace-marked-part(old-term, k, out-template(new-inf)), dev-tree(der)))

where old-term : mb~ = actual-term(d~r) ; pos : t I ~ = tpos(old-term) ; new-inf : i n f ~ =

apply-rule(rule, marked-part(ol d-term, k), environm~t(ol d-term)),

rule-application(rule, k, der) - m~ke-der(new-term, new-tree) w~ere old-term : mbmll ~ actual-term(tier) ;

new-inf : infermce = apply-rule(rule, marked-part(old-term, k), environmmt(old-term)) ;

new-subterms : ~ ~ out-te~l)late(new-inf) ; new-conditions: set-of-clause

extend-set-clause(premises(new-inf), environm~t(ol d-term)) ; new-term : m ~ = replace-marked-part(old-term, k, new-subterms) ; new-tree : (L=v-~n~e - add-to-tree(old-tern, new-term, new-conditions,

rule-info(rule), rel-sy~(rule), dev-tree(der)) provided is-applicable(rule, k, der)

A transformation rule is applicable to a term, i f its "in-template", i.e., the left argument of the consequent of its conclusion, matches the given term. Matching means that there exists an instance, i.e. an association of scheme variables with terms, such that instantiation, i.e. replacement of the scheme variables in the in-template by their associated terms, yields the giv~ term.

ftmcti~ apply-rule ( rule : i . F : : ¢ e ; terms : ~ ; env : set-of-fomJla [] applicable(rule, terms, env) ) : inference ,

function applicable ( rule : inft~-~-~ ; terms : terms ; env : set-of-fml~la) : boo] , f~mctiem is-rule ( inf : inference ) : boo] , function add-env ( rule : inference ; env : set-of-f~mu|a ) : im~m~moe ,

]a~ is-rule(inf) - is-rule-formula(consequent(cl )) A is-Bnpi~set-fo(antecedents(cl )) whmrecl :c]aume - conclusion(inf) ,

applicable(rule, terms, env) - is-rule(rule) A card-i(instances) > 0 where new-rule : i~e~-~e = add-env(rule, env) ;

instances : se t -o f - i ns i~ ~ match-ts(in-tB~plate(new-rule), terms) ,

apply-rule(rule, terms, env) • inst-inf(new-rule, arb-i(instances)) new-rule : iaf~-ence ~ add-env(rule, env); instances : s e t - o f - i n s ~ • match-ts(in-i~late(new-rule), terms)

p rov i~ applicable(rule, term6, env) ,

Page 202: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

194 111.3 Validation of the specification: Example revisited

add-env(rule, env) - m~<e-inf(new-prems, conclusion(rule)) mnew-prems : se t -o f -c lm ~ {extend-clause(cl, env) ~cl e premises(rule)}

Application of a rule to a term yields a new rule as its result. This rule essentially consists of the given rule instantiated by the instance computed by the matching process.

function inst-inf ( inf : i,,FeT~-m~e ; inst : if~w-m~e ) : i n ~ ,

l a~ inst-inf(inf, inst) m normalize-inf(m~ke-inf(new-premises, new-conclusion)) wheme new-premises : set-of-clau~e m inst-set-clause(premises(inf), inst) ;

new-conclusion : clau6e = inst-clause(conclusion(inf), inst) ,

function inst-clause ( cl : clause ; i : in~-~e ) : clamme,

la~s inst-clause(cl, i) m make-cl(new-antecedents, inst-formJla(consequent(cl), i)) wheme new-antecedents : set-of-fonmla = inst-set-formula(antecedents(cl), i) ,

function inst-fomula ( f : fonmla ; i : i n s ~ ) : fommla,

l a~ inst-formula(f, i ) ~ make-fo(pred-symb(f), inst-as(args(f), i))

The out-template of the new rule, i.e., the right argument in the consequent of its conclusion, is the new subterm ~btained by the rule application. The old subterm is replaced by the new one in order to yield a new overall term:

function replace-marked-part ( m : mb~m ; k : pnat ; ts : ~ II term-replaceable(m, k, ts)) : mbmln ,

flmction term-replaceable ( m : m ~ ; k : pnat ; ts : ~ ) : b~}l ,

laws term-replaceable(m, k, ts) ~ replaceable-t(term(m), tpos(m), k, ts) ,

replace-marked-part(m, k, ts) ~ mark(replace-t(term{m), tpos(m), k, is), tpos(m)) provided term-replaceable(m, k, ts)

(4) Deduction of an inference

(a) get-contract

get-contract(z) yields the contract of a derivation, i.e. the initial program scheme from which the derivation started (recorded as the "root" in the development tree), provided the system is in derivation mode.

function get-contract ( z : slaim ) : effect,

laws get--tract(z) =

if deriv~(z) then id(z) + nron-~s(contract(derivatlon(z))) + ans~(~)

Page 203: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I .3 .3 Technical detailization of the sample session

195

fl - deriv-mode(z) id(z) + no-result + answer(not-~rivation-mode)

m~dif,

ftmction contract ( der : d~rivation ) : ~ ,

I ~ contract(der) - root(dev-tree(dor))

function root ( t : dev-tree ) : ~ ,

law6 root(t) - 1~at n : mbmrm ~ is-root(n, t)

(b) get-actual-tern

Similarly, get-actual-term yields the actual term of a derivation, provided the system is in derivation mode:

function get-actual-tern ( z : sltalm ) : effect,

laws get-actual-term(z) i f deriv-mode(z)

id(z) + mbn-res(actual-term(derivation(z))) + answer(done) n ~ deriv-mode(z)

id(z) + no-result + answer(not-derivation-mode) endif

where actual-term is just one of the nodes of a derivation tree.

(c) perform-inference-~on

function perform-inference-deduction ( t : nd~rm ; z : sta~e ) : effect, function deducible ( t : mlmm ; z : ~bJb: ) : Imol ,

la~s deducible(t, z) -: deriv-mode(z) /~ is-deducible(t, derivation(z)) ,

perform-inferenoe-deducti on( t, z ) i f deducible(t, z)

them add-to-inf-actual(new-inf, z) + inf-res(new-inf) + answer(done) Where new-inf : i , ~ : ~ e m inference-deduction(t, derivation(z))

[l ~ deriv-mode(z) id(z) + no-result + answer(not-dorivation-mode)

deriv-mode(z) /L ~ deducible(t, z) id(z) + no-result + answer(not-deducible)

endif

perform-inference-deduction(t, z) extracts from the docum(mtation of a developm~t the "subderivation" leading from t to the actual tern and m~es this development into a new inference which is added to actual catalog of inferences. In order to be defined, the operation requires "deducibilil~/' of the

Page 204: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

196 111.3 Validation of the specification: Example revisited

respective "subderivation": A subderivation is deducible i f the system is in derivation mode and the actual derivation allows deducib17ity of the subderivation between t l and t2:

function is-deducible ( t : m ~ ; der : derivation ) : Imol ,

laws is-deducible(t, der) m deducible-inf(t, actual-term(tier), dev-tree(der)) ,

function deducible-inf ( nl, n2 : mb~m ; t : dev-tree ) : boo] .

| a ~ deducible-inf(nl, n2. t) - compactable(nl, n2, t) .

f~mction compactable ( nl, n2 : m ~ ; t : (L=v-tree) : boo] ,

laws conl)actable(nl, n2, t) - eq-mt(nl, n2) A (ispred(nl, n2, t) /L composable(nl, father, relsymbol(n2, t), t))

w ~ father : m ~ = pred(n2, I, t)

This in turn means i~at both mi~ms are contained in the developm~t tree, that there exists a "development path" from that t I to t 2 (i.e. t I is a "predecessor" of t 2 with respect to the development history), and that the elementary relations contained in this path are composable into a new relation by means of the given set sr of composition rules.

function c(mlposable ( nl, n2 : mb~rm ; ps : pred-s~ul) ; t : ~:v-tree II ispr~d(nl, n2, t) ) : boo] ,

laws c o ~ l e { n l , 112, ps, t) eq-mt(nl, n2) ~/ ( rel-compable(rels~mbol(n2, t) , ps) /L

composable(nl, father, rel-ccmp(relsymbol(n2, t), ps), t) ) where father : m ~ - pred(n2, 1, t) provided ispred(nl, n2, t)

The deduction of the inference then is performed by

function inference-deduction ( t : m ~ ; der : derivation II is-deducible(t, der) ) : inference , function is-deducible ( t : =E~., ; der : derivation ) : bool ,

laws is-deducible(t, der) - deducible-inf(t, actual-tern(tier), dev-tree(der)) ,

inference-deduction(t, der) - deduce-inf(t, actual-term(der), dev-tree(der)) provided is-deducible(t, der) .

~ o n deduce-inf ( nl, n2 : mtmm ; t : dm/-Izee U deducible-inf(nl, n2, t) ) : inference, function deducible-inf ( nl, n2 : m ~ ; t : dev-tree ) : boo] ,

Page 205: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I .3 .3 Technical detailization of the sample session 197

laws deducible-inf(nl, n2, t) ~ compactable(nl, n2, t) ,

deduce-inf(nl, n2, t) = construct-inf(new-prems, ~, new-fo) W~eme new-prems : set-of-clause - collect-premises(n1, n2, t) ;

new-rel-symb : p r t~ I -~ - rel-compose(nl, n2, t) ; new-fo : fonlula ~ make-fo(new-rel-symb, concat(<term(nl)>, <~nn(n2)>))

pm~vi(L~l deducible-inf(nl, n2, t)

where the essential parts are the collection of the respective premises, i.e. the union of the (instantiated) applicability conditions,

function collect-prenises ( nl, n2 : ~ ; t : (L=v-b~me II compactable(nl, n2, t) ) : set-of-clause ,

laws collect-premises(n1, n2, t) i f eq-mt(nl, pred(n2, 1, t))

t~em conditions(t, n2) else collect-premises(nl, pred(n2, 1, t ) , t) g conditions(n2, t)

endif provided compactable(nl, n2, t )

and the co~r$~tation of the "combined" semantic relation:

functian compose ( nl, n2 : mberm ; ps : pred-~mb ; t : dev-bree II ispred(nl, n2, t) A composable(nl, n2, ps, t)) : pred-~BJ~ ,

function composable ( nl, n2 : mbBm ; ps : pred-S~ ; t : (L=v-tmBe II ispFed(nl, n2, t) ) : b¢ol ,

function rel-compose ( nl, n2 : mbBrm ; t : (L=v-i~ee II compactable(nl, n2, t) ) : IImBd-~ ,

laws composable(nl, n2, ps, t) = eq-mt(nl, n2) V ( rel-compable(rel~)mbol(n2, t) , ps) A

composable(nl, father, rel-comp(relsymbol(n2, t) , ps), t) ) where father : mbem = pred(n2, 1, t) l ~ d e d ispred(nl, n2, t) ,

compose(n1, n2, ps, t) - i f eq-mt(nl, n2)

then ps else compose(nl, father, rel-comp(relsymbol(n2, t ) , ps), t)

endif ~ father : mlmrm = pred(n2, 1, t) pmmcided ispred(nl, n2, t) A composable(nl, n2, ps, t) ,

rel-compose(nl, n2, t) - com~(nl, father, relsymbol(n2, t) , t) where father : ~ = pred(n2, 1, t) pmmrided compactable(nl, n2, t)

Page 206: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

198 I I I . 3 Validation of the specification: Example revisited

Here, rel-compose simply compJtes the result of combining two semantic relations with respect to the language-dependent function rel-comp (from type REL-COMP) for elementary compositions of semantic relations.

(5) Simplification of applicabi!i~ conditions

(a) start reduction

"Reduction" means reducing a given goal to a (possibly empty) set of "simpler" subgoals. The operation start-reduction adds a new activity to the stack; its argument is the goal to be reduced:

f~mcti~ start-reduction ( goal : clause ; z : sla~ ) : e f f ~ ,

l a ~ start-reduction(goal, z) m add-red(init-reduction(goal), z) + m-result + answer(done)

A reduction reflects the current status of a verification effort: - the initial goal, - the set of subgoals to which the initial goal has been reduced so far, - a record of the proof steps that led to the current status.

1~e m ~ m ( eq-red ) - make-red record urgoal : c']a_~ (eq-cl);

subgoals : set-of-clmme (eq-set-cl); chain : pmm}f-cPain (eq-ch)

I ~ ( pra)f-d~ain, is-B~ptychain, eq-ch, empty-chain, <.>, .&., f i rs t , rest ) t,u,, SEQU(pmof-slmp, eq-pst)

A pmof -dmn is a sequence of proof-steps each consisting of - the subgoal ~=duced in the step, - the set of subgoals to which i t has been reduced, - the inference used, - the axioms modulo which the inference was applied (cf. the operation apply-inf-modulo-axioms in the

INFERENCE).

pmm~f-sibep ( eq-pst ) make-proof-step record gl : clause (eq-cl);

sbgl s : set-of-clause (eq-set-cl); inf : inference (eq-inf); axs : set-of-i,~,~e~: (eq-set-inf)

endreom~

The operation init-reduction then sets up a reduction for a given goal. Initially, the set of subgoals to ~ich this goal has been reduced consists just of the given goal itself; this amo~ts to a trivially valid tautoloc~.

Page 207: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I .3 .3 Technical detailization of the sample session 199

function init-reduction ( goal : claume ) : reduction,

laws init-reduction(goal) - make-red(goal, {goal}, empty-chain)

(b) perform-goal-reduction

function perform-goal-reduction ( goal : clause ; inf : inference ; axioms: set-of-inferenoe ; z : stalin ) : effect ,

function reducible ( goal : clause ; inf : inference ; axioms : set-of-inference ; z : ~ ) : b m l ,

laws reducible(goal, inf , axioms, z) = red-mode(z) /L goal-reducible(goal, inf, axioms, reduction(z)) ,

perform-goal-reduction(goal, inf, axioms, z) - i f reducible(goal, inf, axion~, z)

them qodate-red(new-vt:d, z) + no-result + answer(done) where new-red : reduction = goal-reduction(goal, inf, axioms, reduction(z))

n ~ red-mode(z) then id(z) + no-result + ans~ver(net-reduction-mode)

D red-node /~ ~ reducible(goal, inf , axioms, z) then id(z) + no-result + answer(goal-net-reducible)

endif

Reduction of a goal with the help of some inference is only allowed i f the system is in reduction mode. Futhermore, reducibility of the respective goal has to be checked.

~on (~)al-reduction ( goal red

function goal-reducible ( goal red

: clause ; inf : i . ~ e ; axioms : set-of-lnflenmce ;

: n~uction II goal-reducible(goal, inf, axion~, red) ) : reduction,

: clause ; inf : infenmce ; axioms : set-of-iafe~-~-m~e ; :reduction) :bin1,

lm6 goal-reducible(goal, inf, axioms, red) -= goal @ subgoals(red) /~ applicable-m0dulo-axioms(inf, goal, axioms) ,

goal-reduction(goal, inf, axioms, red) = make-red(urgoal (red), rew-subgoal s, new-chain) •here new-clauses : set-of-clause -- apply-inf-modulo-axioms(inf, goal, axion~) ;

new-subgoals : set-of-clause = (subgoals(red) \ {goal}) U new-clauses ; pronf-step : pmof-slmp ~ make-proof-step(goal, new-clauses, inf , axioms) ; new-chain : proof-chain -- chain(red) & <proof-step>

l ~ d e d goal-reducible(goal, inf, axioms, red)

The operation goal-reduction essentially applies an infere~e to a given goal in order to produce a set of new subgoals. The corresponding proof step is recorded. As an additional convenience, a further set of inferences (such as transitivity, commutat~vity, associativity, etc.) can be utilized in this process.

Page 208: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

200 I I I . 3 Validation of the specification: Example revisited

The details are described in the specification of the operation "apply-inf-modulo-axioms" in the INFERENCE.

(c) perform-inference-extraction

The goal reduction in the previous step has generated a set of subgoals for a given goal. By perform-inference-extraction, the goal and the subgoals can be made into a (new) inference that is added to the actual inference catalog.

function perform-inference-extraction ( z : s i ~ ) : effect,

1 ~ perform-inference-extraction(z) - i f red-mode(z)

~add-to-inf-actual(new-inf, z) + inf-res(new-inf) + an~er(done) vhmre new-inf : inference - inference-extraction(reduction(z))

D ~ red~mde(z) then id(z) + no-result + answer(not-reduction-mode)

e ~ i f ,

function inference-extraction ( red : reduction ) : infmrence,

laws inference-extraction(red) = make-inf(subgoals(red), urgoal(red))

(d) return-inference

function return-inference ( inf : i m ~ ; z : ~ ) : effect,

la~ retum-inference(inf, z) - i f number-of-acts(z) > 2

add-to-prev-act(inf, z) + inf-res(inf) + answer(done) (] number-of-acts(z) = 1

8~:, id(z) + no-result + answer(no-previous-activity) endif

return-inference allows passing an inference from the current activity to the "previous" pending one, provided, that there is one.

(e) end-reduction

function end-reduction ( z : stai~ ) : effect,

laws end-reduction(z) = i f ~mode(z)

~-., remove-activity(z) + no-result + answer(done) 0 ~ ~-m~e(z)

id(z) + no-result + answer(not-reduction-mode) endif

Page 209: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I I I .3 .3 Technical detailization of the sample session

201

The current reduction activity is popped from the stack of activities, and the previous (pending) activity becomes the new actual one.

(f) Perform-cut

f~.t;~m perform-cut ( i l , i2 : iafeT-emoe ; z : sitai~ ) : ~ f ~ t ,

laws perform-cut(il, i2, z) = i f cutable(il, i2)

add-to-inf-actual(new-inf, z) + inf-res(new-inf) + answer(done) where new-inf : im:ef-~-Le = cut(il, i2)

{] ~ cutable(il, i2) id(z) + no-result + answer(not-cutable)

emdif

Perform-cut yields a new inference by applying the meta-inferences cut to two given inferences. The result is stored in the actual catalog of inferences. The operation cut ("modus ponens") applies the meta-inference "CUt" to two given inferences:

From m,~ ~,~

and infer

functien cut ( i l , i2 : infmren~e H cutable(il, i2) ) : iaf~-~-,~e, function cutable ( i l , i2 : infev~-~e ) : bcol ,

lain cutable(il, i2) ~ conclusion(il) e premises(i2) ,

cut(il, i2) - make-inf(new-premises, conclusion(i2)) where new-pr~mises : ~ t - o f - c l ~ -- pFemises(il) U (premises(i2) \ {conclusion(il)}) provided cutable(il, i2)

(6) Conservation of the developed rule

(a) insert-entry

fwmliqam insert-entry ( cn, en : name ; e : entry ; z : sta~ ) : effect, functi~ insertable-into-cat ( cn, en : name ; e : : ,~y ; z : state ) : boo] ,

laws insertable-into-cat(cn, en, e, z) = insertable-into(cn, en, e, cat-base(z)) ,

insert-entry(cn, en, e, z) i f insertable-into-cat(cn, en, e, z)

then replace-cat-base(new-base, z) + no-result + answer(done) wheme new-base : cat-base ; insert-into(cn, en, e, cat-base(z))

Page 210: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

202 I l l . 3 Validation of the specif ication: Example revisi ted

n ~ insertable-into-cat(cn, en, e, z) then id(z) + no-result + answer(not-insertable)

end i f ,

f ~ I c t i ~ insert-into ( cn, en : ~ ; e : ~,t~y ; cat-base : cat-base II

insertable-into(cn, en, e, cat-base) ) : cat-base , fLmcti~ insertable-into ( cn, en : ~ ; e : entry ; cat-base : cat-base ) : Ix~l ,

laws insertable-into(cn, en, e, cat-base) = has-cat(cn, cat-base) /L insertion-possible(select-cat(cat-base, cn), en, e) ,

insert-into(cn, en, e, cat-base) = replace-cat(cn, new-cat, cat-base) where new-cat : cata1(xj ~ insert(select-cat(cat-base, cn), en, e)

provided insertable-into(cn, en, e, cat-base)

insert-entry(cn, en, e, z) adds a new entry e under the name en to a catalog with name cn.

(7) Finishing the session

(a) end-derivation

fumcti~ end-derivation ( z : stai~ ) : e f fec t ,

laws end-derivation(z) -- i f deriv-mode(z)

them remove-activity(z) + no-~sult + answer(dene) n ~ deriv-mode(z)

then id(z) + no-result + answer(net-derivation-mode) em~f

Similarly to end-reduction above, the cun~ent activity - which is supposed to be a derivation - is popped from the activity stack, and the previous pending activity becomes the new actual one.

(b) q~t

f lmlcti~ quit ( z : stai~ ) : aUtlmJt ,

l a ~ quit(z) ~ end-message

quit just informs the user about the end of his session.

Page 211: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.4 Experiences 203

4. Experiences

Establishing and validating the formal specification of the core of the CIP transformation system have been two of the major steps in the CIP system project. They ended in an algebraic specification that quantitatively can be characterized as follows:

- approx. 120 elementary system functions - approx. 20 new types (in addition to some basic ones) - approx. 40 new object kinds - altogether, approx. 61]0 operations.

Due to the size of this algebraic specification in particular, but also with respect to formal specifications in general, i t may be interesting for others to learn about the experiences that were made in giving this formal specification.

4.1. ExI~iences in using a ~ ] speciF~ation

Some of our experiences are not tied to the algebraic specification technique, but seem to be valid for any formal specification method.

A formal specification as a base for communication

The discussions in the early phase of the system project were centered around debates initiated by provocative questions of the kind ' ~a t is to happen, i f ...?". These debates were heavily influenced and often hampered by the well-known difficulty of conveying a semantics that only exists in someone's head. In this way, quite a number of "artificial" problems were created, merely by the fact that technical details were discussed - often in nearly endless cycles - on the basis of different, individual pragmatics. As soon as we had created at least the skeleton of a formal specification - consisting of the global system structure, functionalities of the essential system functions - and a first draft of an axiomatization, things improved considerably: "technical" discussions then became really technical (and thus more fruitful); any discovered "problem" either could be clearly identified on the basis of the skeletal specification (and sometimes even be solved) or mecognized not to be a real problem at all. Thus the final specification could grow very rapidly on the gro~s of the early formalization attempt. In fact, writing the first (nearly) complete draft of the specification took about 3 man-months.

A formal specification as a yardstick for design decisions

Sinnlarly as with the unintended vagueness of technical discussions, the early phases of the system project also were characterized by the extreme difficulty of making decisions, both w.r.t, conceptual issues of the overall design and also w.r.t, mere representational ~#estions. Again, here the skeleton of the formal specification (which, of course, already required some fundamental design decisions) provided an excellent basis for setting different possibllities for a solution against each other and thus for deciding for the best of those possibilities that were found to be consistent with the skeletal specification. In later phases of the formalization process, when the formal specification was nearly completed, questions about the behaviour of the system under particular circumstances even could be answered by the specification itself, viz. by simply "calculating" the respective answer. This in turn occasionally caused changes in the specification, i f the "calculated" answer was not "consistent" with the original intuitive intention. But even in the case of such a change, the availability of the specification was of great help, since the change could be done in such a way that the overall consistency of the system specification was not destroyed.

Page 212: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

204 I I I .4 Experiences

Clarity and precision enforced by formalization

Since some of us have more than ten years experience with the transformational methodology and know a lot about the existing experimental transformation systems (cf. [Partsch, Steinbr~ggen 83]), in the beginning we were pretty sure to know what we were talking about when we discussed technicalities of the CIP transformation system. On the surface this was certainly true; however, we had to discover that as soon as we started the formalization, we were confronted with a lot of problems we never had thought of, since we had net yet been forced to be precise in all technical details. Formalization of a problem leaves no room for solutions by handwaving, not even for problems that some people disqualify as "~yntactic issues". Already the obligation by the formal approach to give concrete functionalities of operations contributed to conceptual clarity and thus, indirectly, to semantic precision.

The possibility of formal validation

The aspects mentioned in the previous paragraphs can be carried further: I t was possible to validate the specification formally ~n a number of respects. First, the internal consistency of the whole specification is checkable mechanically; this includes the correctness of actual parameter lists, interface correctness, as well as syntactic completeness. Second, semantic coB~Dleteness and consistency can be validated by trying to express conceivable user requests to the system in terms of the functions specified, and, i f this suoceeds, then calculating the system's answer using the axioms of the specification. In the example of section 3 i t is shown how a fictitious session with the system is modelled by the available operations. Attempts of this kind for earlier versions of the specification revealed certain lacks and inconsistencies; as mentioned above, the way for fixing them was guided by the need to stay within the safe and precise formalism. Of course, with an advanced prototyping tool for algobraic specifications, the calculations which now had to be done by hand could have been performed both more safely and more conveniently.

Clear modularization by strict hierarchical top-down design

The formal specification of section 2 has a strictly hierarchical structure which is the result of a consequent top-down design. In this way, any type only uses operations from a directly sub-ordinate t~De, but - except for standard primitive types - never of a type that is further below in the hierarchy. By this a lot of operations had to be introduced v~ose only purpose is to pass information to and from lower l~pes. Although this form of description certainly inflated the specification and also caused a certain frustration when writing the respective axioms, i t was extremely valuable mainly with respect to clarity and understanding, but also for modifications of the specification. Whenever some operation had to be changed (either its name or its semantics), this could be done locally. And also adding further ~stem functions, as was proved necessary by the validation of the specification, only influenced the "outermost" type in the hierarchy. We consider this aspect particularly important, since when specifying a system, one cannot exclude later modification caused by experience with the implemented version of the system.

A system to support formal specifications

In addition to all the positive experiences we made in connection with the formal specification of the system, there also was a negative one, viz. the absence of system support for writing formal, algebraic specifications. An apprepriate system could have helped in many different tasks, ranging from purely syntactic checks over examination of context-correctness and interface consistency of the i ~ hierarchy to comfortable syntax-oriented editing of types or even verification of sufficient completeness according to criteria like the one in [Guttag 75]. I t would also have been very useful to have support for modifications of the system such as consistent renaming or additions of parameters or operations with automatic interface

Page 213: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

111.4.2 Technical experiences with algebraic specifications 205

adaptation. Motivated by these negative experiences, the development of such a system, possibly to be integrated with the CIP transformation system, is a current side-activi~ of the group.

4.2. Technical experiences with algebraic specifications

In addition to these more general experiences w.r.t, formal specification, we also made son conceptually less relevant but practically rather in~x)rtant (technical) experiences that, although primarily caused by the algebraic specification technique, also may be transferrable to other specification methods.

Functional versus operator notation

Although the language CIP-L (cf. [Bauer et al. 85]) we have used as our specification language allo~s operator notation rather than only the usual functional notation, we only have made limited use of i t . Whereas for the basic ~rpes such as sets, sequences, maps, etc., widely accepted operator notation seems superior due to its brevi~, we preferred to have the usual functional notation for nearly all ne~y introduced types, since this allows, i f the names are carefully chosen, to convey at least some basic intuition for understanding the meaning of a new operation. For exactly the same reason we did not hesitate to frequently use rather long identifiers, sometimes even consisting of several words.

Naming ~nventions

In a strict hierarchical specification like the one in section 2, i t happens that types on different layers in the hierarchy have to provide functions with essentially the same semantics ('qifting of operations"). Although this would have been legal in our language frame, we did not use "overloading" of function identifiers, since in some cases, this might have led to axioms of the form

f(x) - f(g(x)) where the identification of the different "f"s would have needed an analysis of their functionalities. Instead we have used the same basic name (to stress the s i~lar i~) , augmented with additional pre- or postfixes (indicating to which i~ype the respective function belongs). Although a comparatively trivial issue, more care in this respect, right from the beginning, could have saved much clerical (typing) work.

Layout of the specification

A complex formal specification without any optical structuring of i ts constituents is an intellectually unmanageable mass. Apart from generous use of blank lines and empty space, in particular groqoing functionalities and axioms together and separating them optically (by horizontal lines), as well as marking the defining occurrences of visible operations, turned out to be valuable alrea~ in formulating the specification.

Use of comments

Ideally, a formal specification should be readable without any further infomation. However, often the understanding is increased by having further (redundant) information. Therefore we inserted comments whenever we fe l t i t appropriate.

Page 214: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

206 I I I . 4 Experiences

Formulation of interfaces

The language CIP-L requires to indicate type hierarchies by giving for every type the names of i ts (immediately) subordinate types as a minimal information. However, in order to decrease the amount of searching for a particular definition, and also to allow simpler checks of interface consistency, we gave the full interfaces consisting of collections of sort and operation names and the types where they are defined.

Structured formulation of axioms

Also in order to enhance readability and understandability, we have structured the axioms of the types by (sometimes excessive) use of auxiliary identifiers abbreviating certain subterms. This not only supports modular understanding, but also provides additional (redundant) information by the obligation to supply each identifier with its type.

Notational extensions

In the specification of section 2 we made use of the extensib13ity of the language CIP-L (cf. [Bauer et al. 85]); this means we have introduced appropriate shorthand notations which can be reduced to the original set of language constructs given in [Bauer et al. 85] via definitional transformations (cf. section 2.2).

Page 215: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

PART IV

FORMAL DEVELOPI/ENT OF SELECTED SYSTEN F~IOI~S

This part shows how selected operations of the ~stem specified in Part I I I are developed formally with the CIP prototype system, using the transformation rules given in Part V, to a level that allows immediate transliteration into PASCAL-like languages. We have concentrated on the difficult and interesting development steps and omitted steps like applying tedious sequences of laws of Boolean algebra; however, the names of the rules for these steps are indicated to allow the user a complete replay of the developments. We have also omitted the developments of functions that only pass information between levels of the type hierarchy, since these can be treated by simple unfold-steps.

Page 216: The Munich Project CIP: Volume II: The Program Transformation System CIP-S
Page 217: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.1 Preliminaries

209

1. Preliminaries

1.1. S ~

This part is organized as follows: First we give the rules according to which we pass from the algebraic i~ypes used in the specification in Part I l l to computation structures, stil l at the descriptive level, that implement these types. Since this step is not supported by the prototype system, i t can only be dealt with on paper but still formally; i t is explained in Section 1.2, The remaining sections of this part then contain developments actually carried out with the prototype, starting from descriptive computation structures and ending at the level of iterative formulations. These developments concern the main system components as represented by the types DEVTREE (Section 2), INFERENCE, CLAUSE, and FORMULA (Section 3), and TERM (Section 4). Finally, Section 5 describes the experiences we have made in connection with the formal development of the system.

1.2. From algebraic ~ to compubd~om

In Part I l l , the system was specified in a descriptive way using the algebraic types of CIP-L. Since the target of the program developments lies within the executable sublanguage of CIP-L, we have to pass sooner or later from algebraic types to formulations within the scheme language. Whereas in a type the operations usually are specified only implicitly via the respective axioms, they have to be given explicitly defined bodies in the scheme language. This transition is most easily done at the applicative level, viz. using computation structures (cf. [Bauer et al. 85], pp. 146-150). Second, transformations are far better understood at the level of explicit function definitions in the scheme language than at the level of algebraic specifications. Therefore, for the following developments we have decided to perform this transition step f irst.

1.2.1. Structures and algebras

We f irst consider con~tation structures with determinate object and function declarations; such computation structures are again called determinate.

Consider a determinate computation structume CS that is based on a primitive type P. Let CS have the signature ~ = (S, F, C). Further, assume a model D of the primitive type P of CS. By DOM D and B D we denote the semantic functions introduced in [Bauer et al. 85] that assign to a sort symbol a semantic domain and to an expression a set of possible values, both relative to D. The algebra ACS D associated with CS is defined by setting for s e S, f e F, c e C

sACSD =def DOMD I] sll

fACSD =def g where B D {[ f l l = {h} and g(x) = h(x) i f h(x) # ± and g(x) is undefined i f h(x) = .

cACSD =defu ifBD[FC~ = {u} andu ~ ±

cACSD is undefined i f BD[[C~ = {_L} •

Page 218: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

210

IV.1 Preliminaries

We say now that a formula is valid in a determinate computation structure CS i f i t is valid in ACS D.

An equality predicate eq for a sort m in a determinate computation structure CS is a function fLmcti~m eq ( m ; m ) :booI

for which the formula Vx:m,y:m,z:m II

eq(x~) ~ ~ A eq(x#) i eq(y,x) A eq(x#) -: true A eq(y,z) ~ true ~eq(x#) = true

is valid in CS. Note that the identi~ predicate id m given by

BD I[idm]] = { {(x, x, l~-ae) : x ~ DOMDEm~} il {(x,y, false) : x# e DOMD~m]], x ~ y} }

is an equality predicate for m. The property of an operation eq of being an equality predicate for a sort m is expressed in the applicabili~ conditions of transformation rules by the predicate

IS-EQUAL-PRE ITeq, roll

Let CS have the signature ~ = (S, F, C) and let S be the set of sorts of CS. A congruence on CS is a fa~n3y eq = (eqm)me S of equali~ predicates for the sorts m in S such that for each operation

f i ~ c t i ~ f ( m ~ ;... ; ~ ) : n

in F the formula

V x 1,yl : In1 . . . . . Xn, Yn :mn II n

( /~ equ~(xi# i) - i~ue) ~ eqn(f(x I . . . . . Xn), f(Yl . . . . #n)) - true i=l

is valid in CS. In this case, a congruence ~eq on ACS D may be defined by

x ~eqY i f f eqm(x #) ; ~ (x# e DOMD[[m~). Accordingly, the quotient ACSD/~eq is well-defined.

1.2.2. Implementation of types by structures

In this section we discuss the implementation relation bet~n ~ypes and structures following [Bauer et al. 85]. A computation structure CS is called a syntactically correct implementation of a type T i f the respective lists of visible constituents together with their sorts and functionalities coincide after consistent renaming (also involving primitive t3~s or structures that directly define constituents of T or CS). Note that, since the algebraic types of CIP-L do not provide general sets or higher-order operations, only "first-order" objects and functions, i.e. objects that are neither descriptive sets nor functions that have descriptive sets or functions as parameters or results, can be treated in this way. Thus con~tation structures defining visible higher-order functions cannot be viewed as implementations of algebraic ~ s . The same holds for functions with mere than one result, since the operation ~mbols of types have only one result sort. Note, however, that both higher-order and tuple-valued functions as well as descriptive sets may be used as hidden constituents in CS; they may be introduced as au~o3ia~ entities during the transformational development.

A model of a ~ associates an unambigJous object with every constant symbol and a mapping in the mathematical sense with every operation symbol. Therefore we f i rs t consider the case of determinate computation structures.

Page 219: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.1.2 From algebraic types to computation structures

211

A determinate syntactically correct implementation CS of a type T is called semantically correct, i f there is a congruence eq on CS such that for all models D of the primitive tilde P of CS the corresponding quotient ACSD/~eq as defined in Section 1.2.1 is a model of T in the sense of [Bauer et al. 85]. Note that semantic correctness must not depend on a particular choice of n~el for the primitive ~q0e.

Although models of a type have to be determinate, computation structures with non-determinate operations correspond naturally to Wpes in which the behaviour of certain operations is not completely specified. Therefore we want to extend the notion of a semantically correct implemmtation to non-determinate co~tation structures. We call a computation structure CS' a descendant of a computation structure CS i f CS and CS' are based on the same primitive type, the signatures of CS and CS' coincide, and every constituent of CS' is a desoendant of the corresponding one in CS. For sorts s, s' we define that s' is a descendant of s i f f the declarations of s and s' are identical.

Now we call a (non-determinate) computation structume CS a semantically correct implen~ntation of the type T i f ever), determinate descendant of CS is a semantically correct implementation of T. The following sections give rules for obtaining such implementations.

1.2.3. The transition from i~o-valued to three-valued logic

Although most of the laws of the fomal specification in Part I I I look as i f they could immediately be rewritten into function declarations, some care has to be taken in this step. The reason for this is the following: The algebraic specification employs the "strong" equality ; in which t ; t ' holds also i f the value of t is undefined. Thus the logic in algebraic specifications is "two-valued": An equality t I = t 2

holds or does not hold. In addition, the existence quantifiers are "non-strict" ("angelic") in that e.g.

3 x : [] llp(x) -: trim holds i f there is a term t of sort [] for which p(t) = true holds, even i f p(t') may be undefined for other terms t ' . On the contra~, to make all constructs monotonic (which is necessary for the fixpoint-semantics of recursive definitions) even in the presence of non-determinism, the scheme language uses only the "weak" equality = (or equality predicates) in which t = t is undefined i f the evaluation of t is undefined. Hence, the scheme language employs a "three-valued" logic with the values true, false, and ±. Moreover, again for monotonicity reasons the existence quantifiers are "strict" ( "de~c" ) in that e.g. the "evaluation" of

3 x : [] II p(x) yields ]_ i f there is an object u e DOME•]I such that p(u) evaluates to ~ even i f p(u') m~ evaluate to

for other elements u' e DOMITmlI.

As an example, consider a tj~pe T based on the type N/~T of natural n~rnbers which contains the following specification:

laws one ~ that x : nat )liszero(pred(x)) . This is well-defined, setting one equal to succ(zero) . However, the naive translation into the scheme language,

one : nat ; that x : nat )Iiszero(pred(x)) , would result in BI~one) = ~} according to sections II.2.1.3(c,d) in [Bauer et al. 85], since pred is a partial function. Instead, the domain of "quantification" has to be restricted, for instance

one : nat = bhat( x : nat II ~ iszero(x)) (liszero(pred(x)) .

Page 220: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

212

IV.1 Preliminaries

Being aware of this situation, we have already been careful in the formal specification to state in a prided-clause for every law explicitly the conditions ( i f any) for definedness of the operations involved.

1.2.4. Nondeterminate s t r ~ as implementations

In the present section we ass~ae that all laws of the type T to be implemented are safeguarded in the way described in the previous section. We give a nuTnber of rules of the form

FC

- ~ A C ,

De v~ch means that the facet(s) FC of T are implemented in a semantically correct way by the declaration(s) DC of the implementing computation structure CS, provided that condition AC holds. For the si~.~cification of

Part III the rules given suffice to obtain computation structures for the abstract types in Part III. In general, however, they ~nll not be complete.

(a) f u n c t i o n f ( x : m ; y : n ) : r ; la~ p(f(x#)) = true

f - ~ f ( x : m ; y : n ) : r ; some z : r Ii p(z)

~ z : r I I ~ p(z) z r lip(z) " b~e

~ OCCURS{Zz in p(f(x~v))~

The condition ~ z : r II p(z) ~ true is necessary, since otherwise the type to be implemented would be inconsistent; for such a ~ there can be no "implemonting" structure whatsoever, and thus the rule fails in this case. The condition V z : r lldef p(z) is needed for reasons similar to those given in section 1.2.3.

(b) f ~ t i o n f ( x : m ; y : n ) : r ; laws p(f(x~v)) = true

f ~ . % i o n f ( x : m ; y : n ) : r ; t

p(t) - true

(c)

This rule is a specialized variant of (a).

f l ~ t i ~ f ( x : m ; y : n) : r ; |a~ f(x#) ~ t

_ Y $

f ~ i ~ f ( X : m ; y : n ) : r ; t

/70CCURSEf in t~ \

Page 221: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.1.2 From algebraic types to computation structures

213

(d) functi(m f ( x :m IIC ) : r ; lawsx : m II f(x) -: tprovidedC

%/

f ~ ' t i o n f ( x : m llc ) : r ;

t

Note that (c) and (d) are valid even i f f occurs in t. I f t is an unconditional term, then f is correctly implemented by the everywhere undefined function.

1.2.5. Implementation of standard recursions

For functions on sequences we have the following c6vious rule:

fLmct iomf(s:sequ) : r ; la i~ f(<>) ; t l ,

f(<x> & s) ; t2

f t m ~ o n f ( s : s ~ ) : r ; i f isempty(s) then t l

else t2ITtop(s),rest(s) for x,s~ e~ i f

1.2.6. Implementation of descriptive operations

In order ~ get implem~tatiens of the descriptive operations 1~atx : m llp , {x:m lip}, { f(x~v) lip }, V (x : m llx e s) l lp,and 3 ( x : i l l x e s) llp,

the first three of which were introduced by definitional transformations in Section III.2.2, we give definitions of generic computation structures providing hi~her-order functions for i~ese constructs. Note that the descriptive constructs used in the bodies of the computation structures are the ones provided by the scheme language and not the ones introduced as notational extensions in section I I I .2.2.

From these first pre-algorithmic implementations we then develop, once for all occurrences, more efficient ones on the procedurel level.

Page 222: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

214

IV. I Preliminaries

s i ~ FILTER = ( sort m, f ~ o n eq-m ( m ; m ) : bool II include EQUIVALENCE(m, eq-m) ) set-of-m, m, fi lter-m :

basedon SET(m, eq-m);

function filter-m ( p : f ~ o n ( m ) : bool ) : f ~ o n ( set-of-m ) set-of-m ; ( s : set-of-m ) : set-of-m;

somet : set-of-m II ( V x :m llx e t <=> (x e s) /~ p(x))

e n ~

s t ~ FAP = ( sort m, sort n, f~mction eq-m ( m ; m ) : bool, ~on~-n(n;n):l~ol (( incl~ EQUIVALENCE(m, ~-m); include EQUIVAUZ)E(n, R-n) )

~-of-m, set4-n, m, n, fap-m-n :

SEF(m, eq-m);

%EF(n, eq-n);

~onfap-m-n (p : function (m) : bool ; f : ~ ( m ) : n) : ~on ( ~-of-m ) ~-of-n ;

( s : ~-m) : ~-n ; some t : set~-n )i

(Vy : n fly e t ~ (~ (x :m Hx e s) )p(x) AR-n(y, f(x)) ))

e n ~

s t ~ L~JION : ( sort m, sort n, fumction eq-m ( m ; m ) : bool, f ~ o n eq-n ( n ; n ) : bool II include EQUIVALENCE(m, eq-m); include EQUIVALENCE(n, eq-n) )

set-of-m, set-of-n, m, n, union-m-n :

base~ SET(m, eq-m); base~ SET(n, eq-n);

function union-m-n ( p : f:nction ( m ) : bool ; f : function ( m ) : set-of-n ) : f ~ o n ( set-of-m ) set-of-n ;

( s : set-of-m ) : set-of-n ;

t : ~t~-n l)

( V Y : n flY e t ~ (3 (x :m )Ix e s) llp(x) A Y e f(x) ))

e ~

Page 223: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I V . l , 2 From algebraic types to computation structures

215

SC = ( sort m, f ~ o n eq-m ( m ; m ) : b(ml ~I include E~IVALENCE(m, eq-m) ) set-of-m, m, sc-m :

based0n SET(m, eq-m);

fimction sc-m ( p : function ( m ) : boo1 ) : set-of-m ; some t : set-of-m II ( V x : m II x e t ~=> p(x) )

e ~

s t n ~ SCAP = ( sort m, sort n, fwlction eq-m ( m ; m) : bool, function eq-n ( n ; n ) : bool II include E~IVALENCE(m, eq-m); include EQJIVALENCE(n, eq-n) )

set-of-m, set-of-n, m, n, scap-m-n :

basedbn SET(m, eq-m); SET(n, eq-n);

function scap-m-n ( p : function ( m ) : bool ; f : function ( m ) : n ) : set-of-n ; some t : set-of-n II

( V Y : n ~y e t <=~ ( 3 x :m Ilp(x) Aeq-n(Y, f(x)) ))

e n ~

FT = ( sort m, function eq-m ( m ; m ) : bool 11 include EQUIVALENCE(m, eq-m) ) sEe-of-m, m, ft-m :

basedon SET(m, eq-m);

function ft-m ( p : f ~ o n ( m ) : Ix3ol ) : function ( set-of-m ) m ; ( s : se t -o f -m) :m ;

that x : m II x e s A p(x)

e n ~

THAT = ( sort m, ~ t l o n eq-m ( m ; m ) : baol m, that-m :

fumction that-m ( p : f~ tJon ( m ) : baoI ) : m ; that x : m II p(x)

II include EqUIVALENCE(m, eq-m) )

e ~

Page 224: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

216

IV.1 Preliminaries

s ~ ALL = ( sort m, f~mction eq-m ( m ; m ) : boo1 II include E~IVALENCE(m, eq-m) ) set-of-m, m, all-m :

base~m SET(m, eq-m);

fLmction all-m ( p : fumction ( m ) : b~)l ;q : f ~ o n (m) : bool ) : fumcti~ ( set-of-m ) set-of-m ;

( s : set-of-m ) : set-of-m;

y ( x : m 11 x e s A p(x) ) II q(x)

B~strucb~e

s ~ EX = ( sort m, f~mcti~ eq-m ( m ; m ) : bool l{ include EC~IVALENCE(m, eq-m) ) set-of-m, m, ex-m :

basedon SET(m, eq-m);

fumctiom ex-m ( p : function(m) : bool ;q : fumction (m) : bool ) : f l ~ m ( set-of-m ) set-of-m ;

( s : set-of-m ) : set-of-m ;

3 ( x : m II x e s A p(x) ) II q(x)

e m ~

Using these computation structures the following implementation rules can be given.

(a) { x e S I p(x) } Y $

structure FIL'r~(~, eq-m); fil ter.-m(p)(S)

~ I m: S(]RTIF x]] S-E~AL-PRE IT eq-m, mTI

(b) { f(x) I x e S /~ p(x) } I /KIND,F]] = fimlction (m) n

~S-EOJAL-PRE rFeq-m, m~ A IS-E~AL-PRE ~eq-n, n~ s t r u c ~ FAP(m, n, eq-m, eq-n); fap-m-n(p, f)(S)

Page 225: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.1.2 From algebraic types to computation structures 217

(c)

(d)

(e)

(f)

(g)

(h)

U {f(x) I x e SAp(x)} i //KIND[If]} = f~mction (m) set-of-n

~S-EQUAL-PRE [Feq-m, m~ A IS-EQUAL-PRE Eeq-n, n~ s i ~ UNI~(m, n, eq-m, eq-n); union-m-n(p, f)(S)

{ x : m I p(x) }

SC(m, eq-m); sc-m(p)

{ f(x) I p(x) } f /KIND[[f~

~ IS-E~AL-PRE[Feorm, m]] /k IS-E~AL-PRE[[eq-n, n~ f ~ o m (m) n

s i ~ SCAP(m, n, eq-m, eq-n); \ scap-m-n(p, f)

thatx:m IIxe S A p(x) ~IS-E~AL-PRE ~ eq-m, roll

s i ~ FT(m, eq-m); ft-m(p)(S)

thatx : m II p(x)

IHAT(m, eq-m); that-m(p)

IS-E~AL-PRE {[eq-m, m~

V ( x : m I xe s A p(x)) Ji q(x)

ALL(m, eq-m); all-m(p, q)(S)

(i) ~ (x : m II x e S A p(x) ) II q(x)

I structure EX(m, eq-m); ex-m(p, q)(S)

---~IS-E~AL-PRE {[eq-m, roll

~ S-EQJAL-PRE [Feq-m, roll

1.2.7. Implementation of nxxles w~th equality pFL:dicates

In section 11.2.2 we have introduced abbreviations for modes with equali~ predicates. We now give the rules

Page 226: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

218

IV.1 Preliminaries

for implementing these within computation structuFes

(a) m(eq-m) - c m ~ s I : m I (eq-m 1) ; ... ;

s k : m K (eq-n~) en(Weo~

~ e m -- c r e c k s I :m I ; ... ;

s k :m k e n ( ~ ;

f~mction eq-m ( x : m ; y : m ) : bool ;

eq-m1(sl(x), sl(Y)) A ... A eq-~k(Sk(X), sk(Y))

V i e [1 , . . . , k } : S-EQUAL-PRE n'eq-mi, m i ]]

A similar rule holds for a sum of product modes:

(b) m (eq-m) = c I record Sll : roll (eq-mll) ; ... ;

Slk : talk (eq-ml k) e m ~

I . . . I c I r ec~ Sll : roll (eq-mll) ; ... ;

Slj :mlj (eq-mlj) e ~

~ e m (eq--m) = ¢1 r e c o r d S l l : roll ; . . . ;

Slk : talk

I . . . I c 1 ~ S l l : r o l l ; . . . ;

Slj : mlj

flmcti~eq-m ( x : m ; y : m) :bool ; begin ~ e m I (eq-m I) - c I record Sll : m11 (eq-m11) ; ... ;

Slk : talk (eq-ml k) e ~ ;

~pe~ (eq-ml) = c] record Sll : rail (eq-mll) ; ... ;

Slj : mlj (eq-mlj) e n d ~ ;

( ( x i sc 1 A y i s c 1) A eq-ml(x#)) V ... V

((x is c I A y is c I) A eq-ml(x#))

/V r~ s:

Page 227: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.I .3 From computation structures to modules

219

1.3. From computation ~ to modules

After the computation structures resulting from the step described in the previous section have been developed to the desired degree of efficiency, one wants to pass to procedural versions of these structures. To this end, the modules of CIP-L (cf. [Bauer et al. 85]. pp. 154-155) are used. Essentially this proceeds in the following steps:

Assume a computation structure CSo First a module MCS is defined by introducing for every function f l m c t i e n f ( c : m ; y : r ) : r ; E

of CS a corresponding procedure (,) p F e c e d u r e p f ( c : m ; v A R x : r ) :

x : = f ( c , x ) • Now every assignment of the form

x := f(c, x) can be folded into a call to pf. Subsequently, the module MCS can be further transformed by replacing the "procedure specifications" of the form (*) by more efficient ones using again transformation rules for the scheme language. In particular, selective qDdating of large data structures can be introduced in this way.

1.4. T ~ I remarks

In the formal specification of Part I I I we have deliberately chosen meaningful and explanatory identifiers for sorts, operations and so forth and did not confine them to a maximal length. Since the CIP prototM~e system restricts identifiers to the maximal length of 12 characters, suitable abbreviations have been used in ~ developments of the following three sections.

As mentioned earlier, we have omitted uninteresting steps of the development like application of simple laws of Boolean algebra. The corresponding command to the prototype system, containing the name of the respective rule, is still shown, such that a completion of the omitted steps is possible. Moreover, we have replaced some keywords and operators of the language CIP-L, such as exist, orif, not, DESCENDANT, by the better readable mathematical symbols ~, [], 9, _]D, respectively. But apart from these changes, the developments given here are original summaries produced by the prototype system.

For the explanation of the system commands we refer to [Riethmayer et al. 85].

Page 228: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

220 IV.2 DEVTREE

2. DEVTREE

In this section, selected functions out of the type DEVTREE are developed. We start from the computation structure which is obtained from the type DEVTREE as described in section 1.2.

2.1. Developments

START SKERN

~comment<

I UNIT DEVTREE

I LEVEL structure ( making use of set-functionals

GOAL removal o f t he p r e a l g o r i t h m i c c o n s t r u c t s where p o s s i b l e and improvement I n

of e f f i c i e n c y o f t h e a l g o r i t h m i c v e r s i o n s I >4

*install unit <devtree: devtree>-

. copy < s t r u c t u r e d e v t r e e > .

s t r u c t u r e DEVTREE = d e v _ t r e e , mterm, s e t o f c l , i n f o , p r e d symb, s e t o f mr, s e t o f rp , i n f e r e n c e , n a t , c l a u s e , INIT_TREE, IS_ROOT, ROOT, IS_PROPER_NO, ADD_TO_TREE, IS_IN, DELETE_SUBTR, PRED, HAS_PRED, SONS, LEAVES, CONDITIONS, UPDATE_COND, UPDATE_ALL_C, COMPACTIFY, COMPACTABLE, DEDUCIBLE_IN, DEDUCE_INF:

structure INFERENCE ; s t r u c t u r e INFO; structure REL_COMP; structure MTERM; structure CLAUSE; structure FORMULA; structure TERM; structure NAT; type devunit -- INIT record POST: mterm endrecord I

PROPER record PRE: mterm; POST: mterm; PREMS: set of cl; INFO info; REL: pred symb endrecord;

f u n c t i o n EQ_DVU (Dh d e v u n i t ; D2: d e v u n i t ) : boo l ; (DI is INIT A D2 is INIT A EQ_MT(POST(DI), POST(D2))) v (DI is PROPER A D2 is PROPER A EQ_MT(PRE(DI), PRE(D2)) A EQ_MT(POST(D1), POST(D2)) A EQ_SET_CL(PREMS(D1), PREMS(D2)) A EO_INFO(INFO(D1), INFO(D2)) A EO_PS(REL(DI), REL(D2)));

structure(dev tree, . , EMPTYSET_DVU, . , ADD_DVU, IS_MEM_DVU, DEL_DVU, ., . , . , . , ., .) = SETWUKEY(mterm, devunit, EQ_MT, EQ_DVU, POST);

structure(dev tree, FT_DVU) = FIL_THAT(devunit, EQ_DVU); structure(set of mr, THAT_MT) = THAT(mterm, EO_MT); structure(dev tree, FILTER_DVU) = FILTER(devunit, EQ_J)VU); s t r u c t u r e ( s e t o f mt, SC_MT) = SC(mterm, EQ_MT); s t r u c t u r e ( t i e r _ t r e e , d e v _ t r e e , FAP~VU~VU) = FAP(devuni t , d e v u n i t , EQ_DVU, EQ~VU); s t r u c t u r e ( d e v t r e e , ALL~VU) = ALL(devuni t , EQ~VU); f u n c t i o n IS_IN (N: mterm; T: d e v _ t r e e ) : boo l ;

3 D: d e v u n i t II IS_MEM_DVU(D, T) A EQ_MT(POST(D), N),

Page 229: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 221

func t ion GET_DEVUNIT (N: mterm; T: dev t r ee 1! IS_IN(N, T)): devunit ; FT_DVU((D: devuni t ) : bool; EQ_MT(POST(D), N))(T),

func t ion PATH (NI: mterm; N2: mterm; K: nat; T: dev_tree): bool; 3 D: devuni t II IS_F~M_DVU(D, T) A EQ_MT(POST(D), N2) A i f EO_N(K, 0)

then E0_MT(N1, N2)

e l se D is PROPER A PATH(N1, PRE(D), K - i, T)

endi f , funct ion ISPRED (Nl: mterm; N2: mterm; T: dev_tree): bool;

3 K: nat tt PATH(N1, N2, K, T), funct ion INIT_TREE (ROOT: mterm): dev t ree ;

ADD_DVU(INIT (ROOT), EMPTYSET_DVU( ) ), function IS_ROOT (N: mterm; T: dev_tree): bool;

IS_MEM_DVU(INIT(N), T), func t ion ROOT (T: dev t ree ) : mterm;

THAT_MT((N: mterm): bool; IS_ROOT(N, T)), funct ion IS_PROPER_NO (N: mterm; T: dev t ree ) : bool;

IS_IN(N, T) A ~IS_ROOT(N, T), func t ion ADD_TO_TP~E (NI: mterm; N2: mterm; PREMISES: se t_of c l ; INFO: info; REL:

pred_symb; T: dev_tree I! IS_IN(N1, T) A ~IS_IN(N2, T)): dev t ree ; ADD_DVU(PROPER(N1, N2, PREMISES, INFO, EEL), T),

funct ion DELETE_SUBTR (N: mterm; T: dev t r ee II IS_PROPER_NO(N, T)): dev t ree; FILTER_DVU((D: devuni t ) : bool; -ISPRED(N, POST(D), T)) (T),

func t ion PRED (N: mterm; K: nat ; T: dev t r ee tl HAS_FRED(N, K, T)): mterm; THAT_MT((NI: mterm): bool; PATH(N1, N, K, T)),

funct ion HAS_PRED (N: mterm; K: nat ; T: dev_tree): bool; 3 NI: mterm Jl PATH(N1, N, K, T),

funct ion SONS (N: mterm; T: dev t ree I! IS_IN(N, T)): se t_of rot; SC_MT((NI: mterm): bool;

IS_IN(N1, T) A (HAS_PRED(NI, l, T) A EO_MT(N, PRED(NI, i, T)))), funct ion LEAVES (T: dev_tree): se t of mr;

SC_MT((N: mterm) : bool; IS_IN(N, T) A IS_Y_MT(SONS(N, T))) , funct ion CONDITIONS (N: mterm; T: dev t r ee I! IS_PROPER_NO(N, T)): s e t of c l ;

PREMS(GET_DEVUNIT(N, T) ), funct ion UPDATE_COND (N: mterm; CL: clause; NEWCLS: se t of c l ; T: dev t r ee II

IS_IN(N, T)) : dev_tree; begin

ADD_DVU(UPDATE_DVU(D, CL, NEWCLS), DEL_I)VU(D, r ) ) where const D: devunit = GET_DEVUNIT(N, T)

end, function UPDATE_ALL_C (CL: clause; NEWCLS: set of cl; T: dev_tree): dev_tree;

FAP_DVU_DVU((D: devunit): bool; true, (D: devunit): devunit; UPDATE_DVU(D, CL, NEWCLS))(T),

function UPDATE_DVU (D: devunit; CL: clause; NEWCLS: set_of cl): devunit; if D is PROPER A IS_MEM_CL(CL, PREMS(D)) then

PROPEH(PRE(D), POST(D), UNION_CL(DEL_CL(CL, PREMS(D)), NEWCLS), INFO(D), REL(D)) e l se

D endif ,

funct ion RELSYMBOL (N: mterm; T: dev_tree II IS_PROPER_NO(N, T)): pred symb; REL(GET_DEVUNIT(N, T) ),

funct ion CINFO (N: mterm; T: dev_tree 1t IS_PROPER_NO(N, T)): info; INFO(GET_DEVUNIT(N, T) ),

function DEL_~SPATH (Nl: mterm; N2: mterm; T: dev tree II ISPRED(N1, N2, T)): dev_tree; begin

i f EO_MT(N1, N2) then

Page 230: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

222 IV.2 DEVTREE

T e l s e

i f -IS_Y_MT(DEL_MT(N2, SONS(PRE(D), T))) then

DEL_DVU(D, T) e l s e

DEL_SPATH(N1, PRE(D), DEL_DVU(D, T)) end i f

end i f where const D: devuni t = GET_DEVUNIT(N2, T)

end, func t ion COLLECT_PREM (NI: mterm; N2: mterm; T: dev_tree II

COMPACTABLE(N1, N2, T)): s e t o f c l ; i f EQ_MT(N1, FRED(N2, 2, T)) then

CONDITIONS (N2, T) e l s e

UNION_CL(COLLECT_PREM(NI, PRED(N2, 1, T), T), CONDITIONS(N2, T)) endi f ,

funct ion COLLECT_INFO (NI: mterm; N2: mterm; T: t ie r_ t ree II COMPACTABLE(N1, N2, T)): info; i f EQ_MT(Nt, PRED(N2, 1, T)) then

CINFO(N2, T) e l s e

ADD_INFO(COLLECT_INFO(N1, PRED(N2, I, T), T), CINF0(N2, T)) endi f ,

funct ion REL_COMPOSE (NI: mterm; N2: mterm; T: dev_tree II COMPACTABLE(N1, N2, T)): pred_symb; begin

funct ion COMPOSE (NI: mterm; N2: mterm; PS: pred symb; T: dev_tree {I ISPRED(NI, N2, T) A COMPOSABLE(N1, N2, PS, T)): pred_symb; i f EO_MT(N1, N2) then

PS e l s e

COMPOSE(N1, PRE(GET_DEVUNIT(N2, T)), REL_COMP(RELSYMBOL(N2, T), PS), T) endif ;

COMPOSE(N1, PRE(GET_gEVUNIT(N2, T)) , RELSYMBOL(N2, T), T) end,

func t ion COMPACTABLE (NI: mterm; N2: mterm; T: dev_t ree) : bool ; ~EQ_MT(NI, N2) A (ISPRED(NI, N2, T) COMPOSABLE(NI, PRE(GET_DEVUNIT(N2, T)), RELSYMBOL(N2, T), T)),

function COMPACTIFY (NI: mterm; N2: mterm; T: dev_tree II COMPACTABLE(NI, N2, T)): dev_tree; begin

ADD_DVU(PROPER(NI, N2, NEW__PREMS, NEW_INFO, NEW_REL_SYMB), NEW_TREE) where const (NEW_PREMS: set_of el, NEW_INFO: info,

NEW_REL_SYMB: pred symb, NEW_TREE: tier_tree) = (COLLECT_PREM(N1, N2, T), COLLECT_INFO(N1, N2, T),

REL_COMPOSE(N1, N2, T), DEL_SPATH(N1, N2, T)) end,

func t ion DEDUCIBLE_IN (NI: mterm; N2: mterm; T: dev_t ree) : bool ; COMPACTABLE(N1, N2, T),

funct ion DEDUCE_INF (NI: mterm; N2: mterm; T: dev_tree II DEDUCIBLE_/NF(N1, N2, T)): in ference ; begin

CONSTRUCT_IN(NEW_PREMS, EMPTYSET_FO, MAKE_FO(NEW_REL_SYMB, CONCAT(MAKE_TS (TEI~M(NI)), MAKE_TS (TERM(N2)) ) ) )

where const (NEW_PREMS: set of el, NEW_REL_SYMB: pred symb) =

Page 231: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 223

(COLLECT_PNEM(NI, N2, T), REL_COMPOSE(NI, N2, T)) end

endstruct

~comment<

I UNIT

LEVEL

I GOAL

path

a l g o r i t h m i c , r e c u r s i v e , f i n i t e e x i s t e n t i a l q u a n t i f i c a t i o n

removal o f the e x i s t e n t i a l q u a n t i f i e r

ACTIONS - d i s t r i b u t i o n o f the e x i s t e n t i a l q u a n t i f i e r i n t o the branches o f t he conditional

- fold of is_in - fold of get_devunit using a special fold rule for functions built

with the ft-functional

>4

-transf in <funct path> with rule <b: ch_a_sa>.

function PATH (NI: mterm; N2: mterm; K: nat; T: dev_tree): hool; 3 D: devunit II (IS_MEM_DVU(D, T) A EQ_MT(POST(D), N2)) A

if EQ_N(K, 0) then

EQ_MT(NI, N2) else

D is PROPER A PATH(N1, PRE(D), K - i, T) endif

CONDITION FULFILLED? false ~D IS_MEM_DVU(D, T) :=) DEFINED[EQ_MT(POST(D), N2)]

.y4

~transf in <funct path> with rule <p: edy_sac>4

~transf in <funct path> with rule <p: eno_sar>4

function PATH (NI: mterm; N2: mterm; K: nat; T: dev_tree): bool; if EQ_N(K, 0) then

~3 D: devun i t tl IS_MEM_DVU(D, T) A EQ_MT(POST(D), N2) A EQ_MT(N1j N2)~ e l s e

3 D: devunit II IS_MEM_DVU(D, T) A EQ_MT(POST(D), N2) A (D is PROPER A PATH(N1, PRE(D), K- i, T))

endif

CONDITION FULFILLED? IS_EMPTYSORT[devunit] J-n4

~transf in <funct path> with rule <f: ff2>4

f u n c t i o n PATH (NI: mterm; N2: mterm; K: na t ; T: dew_tree) : boo l ; if EQ_N(K, O) then

((q D: devunit II IS_MEM_DVU(D, T) a EQ_MT(POST(D), N2))) /~ EQ_MT(NI, N2)

Page 232: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

224 IV.2 DEVTREE

else 3 D: devunit II IS_MEM_DVU(D, T) A EO_MT(POST(D), N2) A

(D is PROPER A PATH(NI, PRE(D), K - l, T)) e n d i f

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD_FF ~funct is_in~ CONDITION FULFILLED? DEFINED[~ D: devnit II IS_MEM_DVU(D, T) A EO~(POST(D), N2)] ~ DEFINED[IS_IN(N2, T)] ~y4

~transf in <funct path> with rule <u_dvu: ein_t2sa>4

function PATH (NI: mterm; N2: mterm; K: nat; T: dev_tree): bool; if EQ_N(K, O) then

IS_IN(N2, T) A EO_MT(NI, N2) e l s e

43 D: d e v u n i t II IS_MEM_DVU(D, T) A EQ_MT(POST(D), N2) A (D i s PROPER A PATH(N1, PRE(D), K - 1, T ) )~

e n d i f

GIVE NAMED/MARKED UNIT FOR PARAMETER: P CC ~ f u n c t i s _ l n ~ GIVE NAMED/MARKED UNIT FOR PARAMETER: F ~ f u n c t g e t _ d e v u n i t ~ CONDITION FULFILLED? DEFINED[D i s PROPER A PATH(N1, PRE(D), K - 1, T), GET_DEVUNIT(N2, T) ] ~y4

~transf in <funct path> with rule <b: id_sacl> inverted4

~copy <funct path>~

function PATH (NI: mterm; N2: mterm; K: nat; T: dev_tree): bool; IS_IN(N2, T) A i f EQ_N(K, O) t h e n

EQAMT(NI, N2) e l s e

D is PROPER A PATH(N1, PRE(D), K - i, T) where const D: devunit = GET_DEVUNIT(N2, T)

endif

~comment<

I UNIT i s p r e d ,,, ' ..... 1

I LEVEL pre-algorithmic, infinite existential quantification I

GOAL recursive version without existential quantification I I

i i

I ACTIONS

>4

- u n f o l d o f p a t h - s h i f t o f t h e e x i s t e n t i a l q u a n t i f i e r - f o l d o f i s p r e d

. t r a u s f in < func t i s p r ed> w i t h r u l e <f: u f f4>4

Page 233: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV .2 .1 Developments 225

f u n c t i o n ISPRED (NI: mterm; N2: mterm; T: d e v _ t r e e ) : b o o l ; 3 K: n e t II ~PATH(N1, N2, K, T)~

CONDITION FULFILLED? DEF_DET[NI, N2, K, T~ ~y~

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD_[F ~funct path4

~transf in <funct ispred> with rule <p: eno_.sal>.

~transf in <ftmct ispred> with rule <n: esi_eq>4

function ISPRED (NI: mterm; N2: mterm; T: dev tree): bool; IS_IN(N2, T) A ((3 K: net {{

if EO_N(K, O) then

EQ_MT(NI, N2) else

D is PROPER A PATH(NI, PRE(D), K - i, T) where const D: devunit = GET_DEVUNIT(N2, T)

e n d i f ) )

~ t r a n s f in < fune t i sp r ed> w i t h r u l e <f: ufco_w)4

~ t r a n s f in < f u n c t i sp red> w i t h r u l e <n: e s i _ p n ) 4

f u n c t i o n ISPRED (NI: mterm; N2: mterm; T: d e v _ t r e e ) : b o o l ; IS_IN(N2, T) A EQ_MT(N1, N2) V ~(q K: n a t tl -EO_N(K, O) A

(GET_DEVUNIT(N2, T) i s PROPER A PATH(N1, PRE(GET_I)EVUNIT(N2, T ) ) , K - 1, T ) ) ) ~

~ t r a n s f in < f u n c t ispredY w i t h r u l e <p: eno_salY4 ~ t r a n s f in < f u n e t i sp red> w i t h r u l e <n: ar_pomo)4

~ i n s t a l l ( f u n c t sp i spredY u n i t <dev t r ee : i s p r e d > ~

~ t r a n s f in < f u n c t i sp red> w i t h r u l e <f: f f3>4

f u n c t i o n ISPRED (NI: mterm; N2: mterm; T: d e v _ t r e e ) : b o o l ; IS_IN(N2, T) A EO_MT(NI, N2) V (GET_/)EVUNIT(N2, T) is PROPER A

((3 K: net il PATH(N1, PRE(GET~EVUNIT(N2, T)), K, T))) )

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD_~F ~funct spispred. CONDITION FULFILLED? DEFINED[3 K: net H PATH(N1, PRE(GET_DEVUNIT(N2, T)), K, T)]

DEFINED[ISPRED(NI, PRE(GET_DEVUNIT(N2, T)), T) I my~

~copy <funct ispred>4

function ISPRED (NI: mterm; N2: mterm; T: dev_tree): bool; IS_IN(N2, T) A EO_MT(NI, N2) V (GET_DEVUNIT(N2, T) is PROPER

ISPRED(NI, PRE(GET_DEVUNIT(N2, T)), T))

~copy into file <dldevtre> <structure devtree> <dlldevtree>.

~stop4

END SKERN START SKERN

Page 234: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

226 IV.2 DEVTREE

~comment<

LEVEL

GOAL

ACTIONS

>4

delete_subtree ] algorithmic I ( using the filter-functional )

!

an efficient version of delete_subtree without a repeated computation of the complex predicate ispred for every member of a development tree I

!

- introduction of a sc-functional application I abstraction of the function descendants, i.e. the set of all nodes in I a development tree which are reachable by a path starting at a given node

L - development of descendants

~install unit <dldevtre: dlldevtree>4

~install <expr e>: <post(d)>4

~transf in <funct delete_subtr> with rule <u_mt: in_s>*

function DELETE_SUBTR (N: mterm; T: dev tree I| IS_PROPER_NO(N, T)): tier_tree; FILTER_.DVU((D: devunit) : bool; - (ISPRED(N, POST(D), T)) ) (T)

GIVE NAMED/MARKED UNIT FOR PARAMETER: E ~expr e4 CONDITION FULFILLED? POST(D) isofmsubmode mterm by~

CONDITION FULFILLED? DEFINED[POST(D) ] ~y4

CONDITION FULFILLED? DETEI~IINATE~POST(D)] ~y~

GIVE NAME FOR PARAMETER: _X ~n24

CONDITION FULFILLED? KIND[ISPRED(N, POST(D), T)] = bool ~y4

~insert in <structure devtree>*

..°

function ADD_TO_TREE (NI: mterm; N2: mterm; PREMISES: set_of_cl; INFO: info; REL: pred symb; T: dev_tree II IS_IN(N1, T)A-IS_IN(N2, T)): dev tree; ADD_DVU(PHOPER(NI, N2, PREMISES, INFO, REL), T)? ,

function DELETE__SUBTR (N: mterm; T: dev tree II IS_PROPER_NO(N, T)): tier_tree; FILTER_DVU((D: devunit) : hool;

-IS_MEM_~T(POST(D), SC_MT((N2: mterm): bool; ISPRED(N, N2, T))))(T), GIVE NEXT UNIT TO BE INSERTED: ~unit <devtree: descendants>4

~transf in <funct delete_subtr> with rule <f: fpf2>-

Page 235: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 227

function DELETE_SUBTE (N: mterm; T: dev_tree II IS_PROPER_NO(N, T)): dev_tree; FILTER.j)VU((D: devunit): bool;

~IS_MEM_MT(POST(D), (SC_MT((N2: mterm): bool ; ISPRED(N, N2, T))) ))(T)

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF .funct descendants4 CONDITION FULFILLED? ASSERT[IS_IN(N, T)] .y4

CONDITION FULFILLED? DEFINED[SC_MT((N2: mterm): bool; ISPRED(N, N2, T))] =0 DEFINED[DESCENDANTS(N, T)]

~copy <funct delete_subtr>4

function DELETE_SUBTR (N: mterm; T: devtree li IS_PROPER_NO(N, T)): dev_tree; FILTER_DVU((D: devunit): bool; ~IS_JqEM_MT(POST(D), DESCENDANTS(N, T)))(T)

.copy into file <dldevtre> <structure devtree> <dl2devtree>-

~stop4

END SKERN START SKERN

.coment<

, UNIT

LEVEL

descendants

prealgorithmic ( making use of the sc-functional )

GOAL algorithmic, recursive

ACTIONS - reversion of the 'direction' of recursion in path - deriving an algorithmic version of ispred taking the derived version

of path as specification of path - unfold of ispred - distribution of the sc-functional over a disjunction - applying the law of commutativity for so- and ex-functionals, thus

generating an union-functional application - fold of descendants

>4

.install unit <dldevtre: dl2devtree>4

~install <funct d2path> unit <devtree: path>4

~transf in <ftmct d2path> with rule <p: edy_sac>4

~transf in <ftmct d2path> with rule <p: ein_esa>~

f u n c t i o n PATH (NI: mterm; N2: mterm; K: na t ; T: d e v _ t r e e ) : boo l ; if EQ_N(K, O) then

3 D: devunit II IS_MEM_DVU(D, T) ^ EO_MT(POST(D), N2) A EO_MT(NI, N2) else

Page 236: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

228 IV.2 DEVTREE

(3 D: d e v u n i t I1 IS_MEM_DVU(D, T) A EQ_Frr(POST(D), N2) A (D is PROPER , PATH(N1, PRE(D), K - I, T))~

e n d i f

GIVE NAME FOR PARAMETER: Y ~dl~

CO~ITION FULFILLED? -([DI] = IDa) ~ (-DI in IS_MEM_DVU(D, T) A EO_MT(POST(D), N2) A

~D1 in D is PROPER A PATH(N1, PRE(D), K - i, T)) ~y~

~transf in <funct d2path> with rule <p: edy_sac> inverted4 ~transf in <funct d2path> with rule <b: ay_sasal> inverted4 ~transf in <ftmct d2path> with rule <b: ch_sa_a>4 ~transf in <funct d2path> with rule <b: ay_aal>4 ~transf in <ftmct d2path> with rule <b: cy_a>4 ~transf in <funct d2path> with rule <b: ay_aal> inverted4

~eopy <funct d2path>~

function PATH (Nl: raters; N2: raters; K: nat; T: dev tree): bool; 3 D: devunit II IS_MEM_DVU(D, T) ^ EO_MT(POST(D), N2) A if EO_~(K, O)

t hen E0_MT(NI, N2)

e l s e 3 DI: devunit II IS_MEM_DVU(DI, T) A DI is PROPER A

EQ_MT(POST(D1), N2) ~ PATH(N1, PRE(D1), K- l, T) e n d i f

. t r a n s f <funct d2path> wi th r u l e <mm_dvu: f r>~

• t r a n s f in <funct d2path> w i t h r u l e <p: eno_sar>4

f u n c t i o n PATH (NI: raters ; P2: ra ters ; K: na t ; T: d e v _ t r e e ) : boo l ; (3 D: devunit II IS_MEM~VU(D, T) A EQ_MT(POST(D), NI) A

i f EQ_N(K, O) then

EO_MT(NI, N2) else

3 DI: devunit II IS_MEM_DVU(DI, T) A D1 is PROPER A EO_MT(PRE(DI), NI) A PATH(POST(D1), N2, K- l, T)

e n d i f ~

CONDITION FULFILLED? IS_EMPTYSORT[devunit] ~n~

• t r a n s f in <funct d2path> wi th r u l e <b: ch_sa_a>4 • t r a n s f in <func t d2path> w i t h r u l e <b: ac_asa l>4 . t r a n s f in <funct d2path> w i t h r u l e <b: ch_a_sa>~ . t r a n s f in <funct d2path> w i t h r u l e <b: ay_sasa l> i n v e r t e d 4

~copy <funct d2path>4

f u n c t i o n PATH (NI: ra ters ; P2: ra ters ; K: na t ; T: d e v _ t r e e ) : boo l ; (3 D: devunit il IS_MEM_DVU(D, T) A EQ_MT(POST(D), NI)) A i f EO_N(K, O) then

EQ~(NI, N2) e l s e

3 DI: d e v u n i t II IS_MEM_DVU(D1, T) A D1 i s PROPER A EQ_MT(PRE(D1), N1) A

Page 237: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 229

PATH(POST(D1), N2, K - 1, T) e n d i f

~copy into file <dldevtre> <funct d2path>4

~co~aent<

IUNIT i s p r e d . . . . . . . . . 1

GOAL d e r i v i n g a r e c u r s i v e v e r s i o n o f i s p r e d t a k i n g t h e ' r e v e r s e d ' v e r s i o n o f I f f

p a t h as s p e c i f i c a t i o n o f p a t h I ACTIONS - u n f o l d o f p a t h

- distribution of the existential quantifier over a conjunction - fold of is_in - applying the colmnutativity of existential guantifiers - shift of an existential quantifier - converting the existential quantification into a call of the

functional ex

>4

~ i n s t a l l < f u n c t d2 i sp red> u n i t <dev t r ee : i s p r e d > 4

~ t r a n s f in < f t m c t d2 i sp red> w i t h r u l e <f: u f f4>~

f u n c t i o n ISPRED (NI: mterm; N2: mterm; T: d e v _ t r e e ) : boo l ; 3 K: n a t II ~PATH(N1, N2, K, T)~

CONDITION FULFILLED? DEF_DET[N1, N2, K, T]

GIVE NAbiED/MARKED UNIT FOR PARAbIETER: s t a t D F * f u n c t d2pa th4

~ t r a n s f in < f u n c t d2 i sp red> w i t h r u l e <p: edy_a>~

~ t r a n s f in < f u n c t d2 i spred> w i t h r u l e <p: erm_ne>4

f u n c t i o n ISPRED (NI: mterm; N2: mterm; T: dev t r e e ) : boo l ; 4 (3 K: n a t II 3 D: d e v u n i t , IS_MEM_DVU(D, T) A EQ_MT(POST(D), N1))~ ^ (3 K: n a t II

i f EQ_N(K, 0) t h e n

EQ_MT(N1, N2) e l s e

3 DI: d e v u n i t I} I S ~ V U ( D 1 , T) A Vl i s PROPER A EO_MT(PRE(D1), N1) A PATH(POST(D1), N2, K- i, T)

endif)

CONDITION FULFILLED? IS_EbtPTYSORT[nat] mn4

. t r a n s f in < f u n c t d2 i sp red> w i t h r u l e in : e s i_cq>4

f u n c t i o n ISPRED (Nl: mterm; N2: mterm; T: d e v _ t r e e ) : boo l ; (q D: d e v u n i t II I S ~ _ D V U ( D , T) A EQ_btT(POST(D), N1)) A ( ( 3 K: n a t l!

i f EQ_N(K, 0) t h e n

EQ_MT(NI, N2)

Page 238: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

230 IV.2 DEVI~EE

e l s e 3 DI: devunit II IS_MEM_DVU(DI, T) A D1 is PROPER A EQ_MT(PRE(DI), NI) A

PATH(POST(D1), N2, K- l, T) e n d i f )

~ t r a n s f in <funct d2ispred> with rule <n: esi_pn>1

.transf in <funct d2ispred> with rule <f: ff2>4

function ISPRED (NI: raters; N2: raters; T: dev_tree): bool; ((3 D: devunit II IS_MEM_DVU(D, T) A EQ_MT(POST(D), NI))~ A

(EQ_MT(NI, N2) V (3 K: nat II 3 DI: devunit II IS_MEM_DVU(D1, T) A D1 is PROPER

EQ_MT(PRE(D1), NI) A PATH(POST(D1), N2, K + 1 - l, T)))

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF .funct is_in4 CONDITION FULFILLED? DEFINED[3 D: devunit Ii IS_MEM_DVU(D, T) A EQ_MT(POST(D), NI)~ ::~ DEFINED[IS_IN(NI, T)~ ~y4

.transf in <funct d2ispred> with rule <n: ar_pomo>4

.transf in <ruDer d2ispred> with rule <p: ecy>~

.transf in <funct d2ispred> with rule <p: eno_sal>4

function ISPRED (NI: mterm; N2: mterm; T: dev_tree): bool; IS_IN(N1, T) ^ (EQ_MT(NI, N2) V (3 Dh devunit II

(3 K: nat II IS_MEM_DVU(DI, T) A D1 is PROPER A EQ_MT(PRE(D1), NI) A PATH(POST(D1), N2, K, T)~ ))

CONDITION FULFILLED? IS_EMPTYSORT[nat~ .n4

.transf in <funct dZispred> with rule <p: eno_al>~

f u n c t i o n ISPRED (NI: ra ters ; N2: ra te rs ; T: d e v _ t r e e ) : boo l ; IS_IN(N1, T) A (EQ_MT(NI, N2) v (3 DI: devunit II IS_MEM_DVU(DI, T) A DI is PROPER A

((q K: nat II EQ_MT(PRE(DI), NI) A PATH(POST(D1), N2, K, T))) ))

CONDITION FULFILLED? IS_EMPTYSORT[nat] .n.

-install <funct spispred> unit <devtree: ispred>4

.transf in <funct dZispred> with rule <f: ff3>.a

f u n c t i o n ISPRED (NI: ra ters ; N2: ra ters ; T: d e v _ t r e e ) : boo l ; IS_IN(N1, T) A (EQ_MT(N1, N2) V (3 Dh d e v u n i t II IS_MEM_DVU(D1, T) ~ D1 i s PROPER

EQ_MT(PRE(D1), N1) A ( ( 3 K: n a t II PATH(POST(D1), N2, K, T ) ) ) ) )

GIVE NAMED/MARKED UNIT FOR PARAMETER: s t a t D F . f u n c t s p i s p r e d . CONDITION FULFILLED? DEFINED[3 K: n a t il PATH(POST(D1), N2, K, T) ] ~ DEFINED[ISPRED(POST(D1), S2, T) ]

, t r a n s f in <funct d2ispred> with rule <b: ay_sasal>4 ,transf in <funct d2ispred> with rule <b: ch_a__sa>4 -transf in <funct d2ispred> with rule <b: ay_sasal> inverted.

Page 239: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 231

~transf in <funct d2ispred> with rule <u_dvu: ecv_ek> inverted~

function ISPRED (NI: mterm; N2: mterm; T: dev_tree): bool; IS_IN(N1, T) A (EQ_MT(NI, N2) v ((3 DI: devunit II IS_MEM_DVU(DI, T) A

(D1 i s PROPER A EQ_MT(PRE(D1), Nt) A ISPRED(POST(D1), N2, T ) ) ) ) )

CONDITION FULFILLED? DETEBMINATE[T] ~y4

~copy <funct d2ispred>~

function ISPRED (NI: mterm; N2: mterm; T: dev_tree): bool; IS_IN(N1, T) A (EQ_MT(NI, N2) V EX_DVU((DI: devunit): hool;

D1 is PROPER A EQ_MT(PRE(DI), NI), (DI: devunit): bool; ISPRED(POST(DI), N2, T))(T))

~copy into file <dldevtre> <funct dZispred>.

~transf in <funct descendants> with rule <f: uffD>4

function DESCENDANTS (N: mterm; T: dev tree II IS_IN(N, T)): set of mr; SC_MT((N2: mterm): bool; (ISPRED(N, N2, T)) )

CONDITION FULFILLED? DEF_J)ET[N, N2, T]

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD__FF ~funct d2ispred*

bcopy <funct descendants>.

function DESCENDANTS (N: mterm; T: dev_tree II IS_IN(N, T)): set_of mt; SC_MT((N2: mterm): bool;

IS..IN(N, T) A (EQ_MT(N, N2) v EX_DVU((Dh devunit): bool; D1 is PROPER A EQ_MT(PRE(DI), N), (DI: devunit): bool; ISPRED(POST(DI), N2, T))(T)))

~transf <funct descendants> with rule <f: sp2>q ~transf in <funct descendants> with rule <h: si_tra>.

.transf in <funct descendants> with rule <u_rat: sdp_o>4

function DESCENDANTS (N: mterm; T: dev_tree It IS_IN(N, T)): set of mr; (SC_MT((N2: mterm): bool;

EO_MT(N, N2) V EX_DVU((DI: devunit): bool; D1 is PROPER A EQ_MT(PRE(DI), N), (DI: devunit): bool; ISPRED(POST(DI), N2, T))(T))~

~transf in <funct descendants> with rule <u_mt: ssp_q>4

function DESCENDANTS (N: mterm; T: devtree II IS_IN(N, T)): set_ofmt; UNION_MT((SC_MT((N2: mterm): bool;

EQ_MT(N, N2))) , SC_MT((N2: mterm): bool; EX_J)VU((DI: devunit): bool;

D1 is PROPER A EQ_MT(PRE(DI), N), (DI: devunit): bool; ISPRED(POST(D1), N2, T))(T)))

~insert in <structure devtree>4

° . °

s t ruc ture(dev t ree , ALL_DVU) = ALL(devunit, EQ_J)VU)? ;

Page 240: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

232 IV.2 DEVTREE

function IS_/N (N: mterm; T: dev_tree): bool; 3 D: devunit il IS_MEM_DVU(D, T) A EQ_MT(POST(D), N),

GIVE NEXT UNIT TO BE INSERTED: ~unit <devtree: u_dv_mt_inst>~

~transf in <funct descendants> with rule <u_mt_dvu: scy_e>~

function DESCENDANTS (N: mterm; T: dev_tree il IS_IN(N, T)): set of mt; UNION_MT(MK_SING_MT(N), (SC_MT((N2: mterm): bool;

EX_DVU((DI: devunit): bool; DI is PROPER A EQ_MT(PRE(DI), N), (DI: devunit): bool; ISPRED(POST(DI), N2, T))(T))> )

CONDITION FULFILLED? IS_EMPTYSORT[mterm~ ~ DEFINED[T~ my4

~install <funct spdescendants> unit <devtree: descendants>4

~transf in <funct descendants> with rule <f: fpf2>4

function DESCENDANTS (N: mterm; T: dev tree I! IS_IN(N, T)): set of mt; UNION_MT(MK_SING_MT(N), UNION_DVU_MT((DI: devunit): bool;

D1 is PROPER A EQ~T(PRE(DI), N), (DI: devunit): set_of_mr; (SC_MT((N2: mterm): bool; ISPRED(POST(DI), N2, T))> )(T))

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD_[F ~funct spdescendants4 CONDITION FULFILLED? ASSERT[IS_IN(POST(D1), T)] ~y4

CONDITION FULFILLED? DEFINED[SC_MT((N2: mterm): bool; ISPRED(POST(DI), N2, T))] =¢

DEFINED[DESCENDANTS(POST(D1), T)] my4

~copy <funct descendants>~

function DESCENDANTS (N: mterm; T: dev tree II IS_IN(N, T)): set of mt; UNION_MT(MK_ZING_MT(N), UNION_DVU_MT~(DI: devunit): bool;

D1 is PROPER A EQ_MT(PRE(DI), N), (DI: devunit): set of mt; DESCENDANTS(POST(D1), T))(T))

~copy into file <dldevtre> <structure devtree> <dl3devtree>4

~s top4

END SKERN START SKERN

.comment<

I GOAL improvement of efficiency of descendants

I LEVEL linear recursion

I ACTIONS - abstraction of the function des (it computes the set of all descendants of a given set)

- deriving a version of des working with linear recursion

>4

Page 241: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 233

~comment<

I UNIT

I LEVEL

I GOAL

des

algorithmic ( making use of the union-functional )

removal of the complex computation of descendants for every member of the given set

ACTIONS introducing a condition for termination - unfold of descendants - distribution of the union-functional over a set-union - applying the coDm~utativity of union-functionals - shifting the inner one of two nested union-functionals

introduction of an union-functional - shifting the outer one of two nested union-functionals - folding des - converting the union-functional into a set-comprehension - fold of is_in und get_devunit - abstraction of the function nodes, i.e. the set of all nodes of a

development tree, and deriving a transformation rule to convert the test for is_in into a test of the membership in nodes

- converting a set-comprehension into a filtering over nodes

>4

~install unit <dldevtre: dl3devtree>~

~insert in <structure devtree>4

°.,

s t ruc tu re (dev_ t r ee , s e t o f mt, UNION_DVU_MT) -- UNION(devunit, mterm, EQ_DVU, EQ_MT)? ; funct ion IS_~N (N: mterm; T: dev_tree) : bool;

3 D: devunit II IS_MEM_DVU(D, T) A EQ_MT(POST(D), N), ,..

function ADDTO_TREE (Nl: mterm; N2: mterm; PREMISES: set of cl; INFO: info; REL: pred_symb; T: dev_tree II IS_IN(N1, T) A ~IS_JN(N2, T)): dev_tree; ADD_DVU(PROPER(NI, N2, PREMISES, INFO, REL), T)? ,

function DESCENDANTS (N: mterm; T: dev tree II IS_IN(N, T)): set of mr; UNION_MT(MK_SING_MT(N), UNION_DVU_MT((DI: devunit): bool;

Dl is PROPER A EQ_MT(PRE(D1), N), (DI: devunit): set of mt; DESCENDANTS(POST(D1), T)) (T)),

GIVE NEXT UNIT TO BE INSERTED: ~unit <devtree: u_mt_mt_inst>~

GIVE NEXT UNIT TO BE INSERTED: ~unit <devtree: des>4

~install <expr e>: <is_.v_mt(s)>~

~transf in <funct des> with rule <c: csi_qb> inverted~

funct ion DES (S: se t_of mr; T: dev t r e e ) : s e t o f mt; %~NION_MT_MT((N: mterm): bool; t rue , (N: mterm): se t of mr; DESCENDANTS(N, T))(S)~

Page 242: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

234 IV.2 DEVTREE

GIVE NAMED/MARKED UNIT FOR PARAMETER: C ~expr e4 CONDITION FULFILLED? KIND[IS_Y_MT(S)] = bool my4

CONDITION FULFILLED? DEFINED[IS_Y_MT(S)~ ~y~

~transf in <funct des> with rule <m_mt: csi_y>4

func t ion DES (S: se t of mr; T: dev_tree): se t of mt; ~ i f IS_Y_MT(S) then

UNION_MT_MT((N: mterm): bool; t rue , (N: mterm): se t of mt; DESCENDANTS(N, T))(S) e l s e

UNION_MT_MT((N: mterm): bool; t rue , (N: mterm): se t o f m t ; DESCENDANTS(N, T))(S) e n d i f )

~transf in (funct des> with rule <u_mt_mt: uss_e>~

func t ion DES (S: se t of mt; T: dev_tree): s e t _ o f m t ; i f IS_Y_MT(S) then

(UNION_MT_MT((N: mterm): bool; true, (N: mterm): set of mt; DESCENDANTS(N, T))(EMPTYSET_MT))

else UNION_MT_MT((N: mterm): bool; true, (N: mterm): set of mt; DESCENDANTS(N, T))(S)

endif

~transf in <funct des> with rule <f: ufpf2>4

func t ion DES (S: se t_of mt; T: dev_tree): se t of mt; i f ISZY_MT(S) then

EbIPTYSET_MT e l se

UNION_btT_MT((N: mterm): bool; t rue , (N: mterm): se t of mt; (DESCENDANTS(N, T)) )(S)

endi f

CONDITION FULFILLED? DEF_DET[N, T]

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct descendants~ CONDITION FULFILLED? ASSERT[IS_IN(N, T)] my4

~t rans f in <funct des> with ru le <u_~t_mt: udm_v>4

func t ion DES (S: se t of mr; T: dev_tree): se t of mt; i f IS_Y_MT(S) then

EMPTYSET_MT e l se

~q~NION_MT_MT((N: mterm): bool; t rue , (N: mterm): se t_of rot; UNION_MT(MK_SING_MT(N), UNION_DVU_MT( (DI: devunit) : bool;

D1 i s PROPER a EO_MT(PRE(D1), N), (Dl: devuni t ) : s e t of rot; DESCENDANTS(POST(D1), T) ) (T)) ) (S)~

end i f

Page 243: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 235

CONDITION FULFILLED? DETERMINATE[true]

CONDITION FULFILLED? DETERMINATE[S] my~

~transf in <funct des> with rule <u_~tjt: usm_k>4

funct ion DES (S: se t of mt; T: dev_tree): set_of_mt; if IS_Y_MT(S) then

EMPTYSET_MT e l se

UNION_MT(~UNION_MT_MT((N: mterm): bool; t rue , (N: mterm): se t of mr; MK_SING_MT(N))(S)~ , UNION_MT_MT((N: mterm): hool; t rue , (S: mterm): se t of mr; UNION_DVU_MT((DI: devuni t ) : bool;

D1 i s PROPER A EQ_MT(PRE(D1), N), (Dl: devuni t ) : se t of mr; DESCENDANTS(POST(D1), T))(T))(S))

endi f

CONDITION FULFILLED? DETERMINATE[S] ~y4

~transf in <funct des> with rule <u_mtmtdv: ucy_u>4

~transf in <funct des> with rule <u_dvmtmt: usi_u>4

funct ion DES (S: set_of_mt; T: dev_tree): se t of mt; i f IS_Y_MT(S) then

EMPTYSET_MT e l se

UNION_MT(S, ~UNION_DVU_MT((Dt: devuni t ) : bool; D1 i s PROPER, (Dl: devunit) : se t of mt; UNION_MT_MT((N: mterm): bool;

t rue A EQ_MT(PRE(D1), N), (N: mterm): se t of mt; DESCENDANTS(POST(D1), T) ) (S) ) (T) ) )

endi f

~transf in <funct des> with rule <b: si_trsa>4

~transf in <funct des> with rule <q: eqt_sy>4

func t ion DES (S: se t_of_st ; T: t ier_tree): se t of s t ; i f IS_Y_MT(S) then

EMPTYSET_MT e lse

UNION_MT(S, UNION_DVU_MT((DI: devuni t ) : bool; D1 i s PROPER A EX_MT((N: raters): bool; t rue , (N: raters): bool;

~EQ_MT(PRE(D1), N)~ )(S), (DI: devuni t ) : se t of mt; DESCENDANTS(POST(D1), T)) (T))

endi f

GIVE NAME FOR PARAMETER: m ~mterm4

CONDITION FULFILLED? KIND[PRE(DI)] = raters ~y4

Page 244: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

236 IV. 2 DEVTNEE

CONDITION FULFILLED? IS_EQUAL_PRE[EQ_MT, mterm]

~transf in <funct des> with rule <u_mt: esm_q>4

function DES (S: set of mr; T: dev_tree): set of mt; i f IS_Y_MTfS) then

EMPTYSET_MT else

UNION_MT(S, UNION_I)VU_MT((DI: devunit): bool; DI is PROPER A ~EX_MT((N: mterm): bool; true, (N: mterm): bool;

EO_MT(N, PRE(DI)))(S)) , (DI: devunit): set of rot; DESCENDANTS(FOST(D1), T)) (T))

endif

CONDITION FULFILLED? DEFINED[true, PRE(DI)] .y4

CONDITION FULFILLED? ASSERT[begin function PP (N: mterm): bool; true;

%/ (A: mterm; B: mterm II EO_MT(A, B)) il PP(A) ¢~ PP(B) end]

.transf in <funct des> with rule <b: si_satr>4

.install <expr f>: <post(dl)>4

.transf in <funct des> with rule <u_mt_mt: in_u>~

function DES (S: set of rot; T: dev_tree): set of mr; if IS_Y_MT (S) then

EMPTYSET_MT else

UNION_MT(S, UNION_DVU_MT((DI: devunit) : bool; D1 is PROPER A IS_MEM_MT(PRE(DI), S), (DI: devunit): set of_mt; ~DESCENDANTS(POST(D1), T)) ) (T))

endif

GIVE NAMED/MARKED UNIT FOR PARAMETER: C .expr f~ CONDITION FULFILLED? POST(D1) isof_~submode mterm .y4

CONDITION FULFILLED? DEFINED[POST(D1) ] ,y9

CONDITION FULFILLED? DETERMINATE[POST(D1) my4

GIVE NAME FOR PARAMETER: X ~n14

CONDITION FULFILLED? KIND[DESCENDANTS(POST(D1), T)] = set of mt

~install <expr f>: <post(dl)>4

.transf in <funct des> with rule <u_/nt_mt: in_u>.

function DES (S: set of mt; T: dev_tree): set of mt;

Page 245: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 237

i f IS_Y..~T (S) then

E~PTYSET_MT else

UNION_MT(S, UNION_DVU_MT((DI: devunlt) : boo1; D1 is PROPER A IS_MEM_MT(PP~(D1), S), (DI: devunit): set of rot; ~DESCENDANTS(POST(D1), T)~ ) (T))

end i f

GIVE NAMED/MARKED UNIT FOR PARAMETER: C_ ~expr f~ CONDITION FULFILLED? POST(D1) isof_~submode mterm I.y4

CONDITION FULFILLED? DEFINED[POST(DI) ,y4

CONDITION FULFILLED? DETERMINATE[POST(D1) ~y~

GIVE NAME FOR PARAMETER: _X ~n4

CONDITION FULFILLED? KIND[DESCENDANTS(POST(D1), T)~ = set of_mt i.y4

~transf in <funct des> with rule <u_dvmtmt: use_u>4

function DES (S: set of mt; T: dev_tree): set of mt; i f IS_Y_MT(S) then

EMPTYSET_MT else

UNION_MT(S, ~dNION_DVU_MT( (DI: devunit) : boo1; D1 is PROPER A IS_MEM_MT(PRE(DI), S), (Dl: devunit): set of_mr; UNION_MT_MT((N: mterm): bee1; true, (N: mterm): set_of_rot;

DESCENDANTS(N, T) ) (MK_SING_MT(POST(DI)) ) ) (T)~) end i f

~install <funct spdes> unit <devtree: des>~

~transf in <funct des> with rule <f: ff2>4

ftmction DES (S: set of mt; T: dev_tree): set of mt; if IS_Y_MT(S) then

EMPTYSET_MT else

UNION_MT(S, (UNION_MT_MT((N: mterm): bool; true, (N: mterm): set of rot; DESCENDANTS(N, T)) (UNION_DVU_MT((DI: devtmit) : hool; D1 is PROPER A IS_MEM_MT(PRE(DI), S), (DI: devtmit): set of mt; MK_SING_MT(POST(DI) ) ) (T))) )

endif

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD_[ ~funct spdes4 CONDITION FULFILLED? DEFINED[UNION_MT_MT((N: mterm): bool; true, (N: mterm): set_of_mr;

DESCENDANTS(N, T)) (UNION_DVU_MT((DI: devunif) : bool; D1 is PROPER A IS_MEMjMT(PRE(DI), S), (DI: devunit): set_of mt; MK_~SING_MT(POST(DI) ) ) (T)) ] =~ DEFINED[DES(UNION_DVU_MT((DI: devunit) : bool;

D1 is PROPER A IS_MEM_MT(PRE(DI), S), (Dl: devunit): set of rot; MK_SING_MT(POST(DI) ) ) (T), T) ]

Page 246: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

238 IV.2 DEVTREE

.transf in <funct des> with rule <u_dvu_mt: ucv__s>.

f u n c t i o n DES (S: s e t _ o f _ m t ; T: d e v _ t r e e ) : s e t o f mt; i f IS_Y_MT(S) then

EMPTYSET_MT else

UNION_MT(S, DES(~UNION_DVU_MT((DI: devunit): bool; D1 is PROPER A IS_MEM_MT(PRE(DI), S), (DI: devunit): set of mr; MK__S ING_MT (POST (D i) ) ) (T)) , T))

endif

GIVE NAME FOR PARAMETER: Y ~n4

CONDITION FULFILLED? DETERMINATE[T~

.transf in <funct des> with rule <b: cy_.sa>4

.transf in <funct des> with rule <b: ay_sasal> inverted4

.transf in <funct des> with rule <f: al_e>4

.transf in <funct des> with rule <q: eqt_sy>.

.transf in <funct des> with rule <u_dvu: ein_t2sa>4

function DES (S: set of mr; T: dev_tree): set of mr; i f IS_Y_/qT(S) t h e n

EMPTYSET_MT else

UNION_MT(S, DES(SCAMT((N: mterm): boo1; 43 D: devunit I[ IS_MEM_DVU(D, T) A EQ_MT(POST(D), N) A

(D is PROPER A IS_MEM_MT(PRE(D), S))) ), T)) endif

GIVE NAMED/MARKED UNIT FOR PARAMETER: P__CC .funct is_in4 GIVE NAMED/MARKED UNIT FOR PARAMETER: F .funct get_devunit4 CONDITION FULFILLED? DEFINED[D is PROPER A IS_MEM_JMT(PRE(D), S), GET_DEVUNIT(N, T)] .y4

~ i n s e r t in < s t r u c t u r e d e v t r e e > .

, . °

structure(devtree, set of mt, UNION_A)VU_MT) = UNION(devtmit, mterm, EQ_DVU, EQ_MT)? ; structure(set_ofmt, set of mt, UNION_MT_MT) = UNION(mterm, mterm, EQ_MT, EQ_MT)? ; function IS_IN (N: mterm; T: dev_tree): bool;

3 D: devunit il IS_MEM_DVU(D, T) A EQ_MT(POST(D), N) GIVE NEXT UNIT TO BE INSERTED: ~unit <devtree: fap_dv_mt_in>~

GIVE NEXT UNIT TO BE INSERTED: .unit <devtree: nodes>4

-install <rule ttmem_nodes> unit <devtree: ttmem_.nodes>~

.transf in <rule ttmem_nodes> with rule <f: uffl>4

IS_MEM_MT(N, ~NODES(T)~ ) <->

IS_MEM_MT(_N, NODES(I) )

Page 247: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2 .1 Developments 239

>-<

DEF_DET[N, _T] ^ KIND[_N] = mterm A KIND[T] -- d e v t r e e

CONDITION FULFILLED7 DEF_DET[!] . y4

GIVE NAMED/MARKED UNIT FOR PARAMETER: s ta tDF . f u n e t nodes*

. t r a n s f in < ru l e ttmem_nodes> wi th r u l e <u_dvu_mt: racy_g>4

(IS_MEM_MT(N, FAP_DVU_MT((D: d e v u n i t ) : boo l ; t r u e , (D: d e v u n i t ) : mterm; POST(D) ) (T))~

<-> IS_ME~L.MT(__N, NODES(I) ) >-< DEF_DET[N, T] A KIND[N] = mterm ^ KIND[T] = devtree

CONDITION FULFILLED? DETERmINATE[N] . y4

.transf in <rule ttmem_nodes> with rule <u_dvu: ecv_ek>4

~EX_DVU(fD: d e v u n i t ) : bool ; t r u e , (D: d e v u n i t ) : boo l ; EO_/~(N_, POST(D)))(T)~ <-> IS_MEM_MT(_N, NODES(I) ) >-<

DEF_.DET[N, T] A KIND[N] = mterm A KIND[T] = devtree

CONDITION FULFILLED? DETERMINATE[T] .y4

.transf in <rule ttmem_nodes> with rule <h: si_trsa>4 btransf in <rule ttmem_nodes> with rule <q: eqt_sy>~

-transf in <rule ttmem_nodes> with rule <f: ff2>4

(3 D: devunit {{ IS_MEM_DVU(D, T) A EO_MT(FOST(D), _N)) <->

IS_MEM_MT(_N, NODES(T) ) >-<

DEF_DET[N, T] A KIND[N] = mterm A KIND[T] = devtree

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF .funet is_in4 CONDITION FULFILLED? DEFINED[3 D: devunit J{ IS_MEM_DVU(D, T) A EQ_MT(POST(D), N)]

DEFINED[IS_IN(N, T) ] .y4

.copy <rule ttmem..nodes>~

IS_IN(N, I) <->

IS_MEM_MT(N, NODES(T) ) >-<

DEF_DET[N, T] A KIND[N] = mterm ^ KIND[T] = devtree

-copy into file <irl> <rule ttmem_nodes> <mem_nodes>4

.transf in <funct des> with rule <irl: mem_.nodes>~

Page 248: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

240 IV.2 DEVTREE

. i n s e r t in < s t r u c t u r e dev t ree>4

. ° °

s t r u c t u r e ( s e t o f mr, s e t o f mt, UNION_MT_MT) = UNION(mterm, mterm, EQ_MT, EO_MT)? ; f u n c t i o n NODES (T: d e v _ t r e e ) : s e t o f mr;

FAP_DVU_MT((D: d e v u n i t ) : bool ; t r u e , (D: d e v u n i t ) : mterm; POST(D))(T); GIVE NEXT UNIT TO BE INSERTED: . u n i t <dev t ree : f i l _ m t _ i n s t > 4

. t r a n s f in <funct des> w i t h r u l e <u_mt: scv_f>4

f u n c t i o n DES (S: s e t o f mr; T: d e v _ t r e e ) : s e t o f mr; if IS_Y_MT(S) then

EMPTYSET_MT else

UNION_MT(S, DES((SC_MT((N: mterm): bool; IS_MEM_MT(N, NODES(T)) /~ b e g i n

D i s PROPER A IS_MEM_MT(PRE(D), S) where c o n s t D: devun i t = GET_DEVUNIT(N, T)

e n d ) ) , T)) e n d i f

CONDITION FULFILLED? DETEI~MINATE[NODES(T)] .y4

. c o p y <funet des>*

f u n c t i o n DES (S: s e t o f mr; T: dev t r e e ) : s e t o f mr; i f IS_Y_MT(S) then

EMPTYSET_MT e l s e

UNION_MT(S, DES(FILTER_MT((N: mterm): boo l ; b e g i n

D is PROPER A IS_MEM_MT(PRE(D), S) where const D: devunit = GET_DEVUNIT(N, T)

end) (NODES(T)), T) ) endif

,copy into file <dldevtre> <structure devtree> <dl4devtree>4

.stop4

END SKERN START SKERN

.comment<

GOAL embedding of descendants into des

ACTIONS - deriving a transformation rule by abstraction of a tautology, introduction of a call of the union functional, and fold of des application of the derived rule

>4

* i n s t a l l u n i t <d ldev t r e : d l4dev t r ee>4

Page 249: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I V . 2 . 1 Developments 241

~install <rule ttd> unit <devtree: ttd>*

~install <expr e>: <n>.

~transf in <rule ttd> with rule <u_mt_mt: in_u>.

DESCENDANTS (g, T) -->

(DESCENDANTS(N, T)> >-<

DEF~ET[N, _T~ A N isof_submode mterm A KIND[T~ = devtree

GIVE NAMED/MARKED UNIT FOR PARAMETER: C ~expr e4 CONDITION FULFILLED? N isof_submode mterm ~ya

CONDITION FULFILLED? DEFINED[NI ~y~

CONDITION FULFILLED? DETENMINATE[N] by4

GIVE NAME FOR PARAMETER: X ~n4

CONDITION FULFILLED? KIND[DESCENDANTS(N, T)~ = set of mt my4

~install <funct spdes> unit <devtree: des>*

~transf in <rule ttd> with rule <f: ff2>.

DESCENDANTS(N, T) -->

(UNION_MT_MT((N: mterm): bool; true, (N: mterm): set of mr; DESCENDANTS(N, T)) (MK_SING_MT(N)))

>-<

DEF_DET[N, T] A _N isof_submode mterm A KIND[T] = devtree

GIVE NAMED/MARKED UNIT FOE PARAMETER: statDF ~funct spdes4 CONDITION FULFILLED? DEFINED[UNION_MT_MT((N: mterm): bool; true, (N: mterm): set of mt;

DESCENDANTS(N, T))(MK_SING_MT(N)) ] =~ DEFINED[DES(MK_ZING_MT(N), Z)] ~y4

~copy <rule ttd>4

DESCENDANTS(N, T) -->

DES (MK_ZING_MT (N), T) >-<

DEF~ET[_N, T] A N isof_submode mterm A KIND[T] = devtree

~copy into file <irl> <rule ttd> <dlttd>~

~transf in <funct delete_subtr> with rule <irl: dlttd>*

function DELETE_SUBTR (N: mterm; T: dev tree II IS_PROPER_NO(N, T)): dev_tree; FILTER_DVU((D: devunit) : bool; ~IS_MEM_MT(POST(D), (DESCENDANTS(N, T)~ )) (T)

Page 250: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

242 IV.2 DEVTREE

CONDITION FULFILLED? DEF_DET[N, T]

CONDITION FULFILLED? N isof_~ubmode mterm by~

CONDITION FULFILLED? KIND[T] = devtree ~y4

~insert in <structure devtree>*

. . .

function ADD_TO_TREE (NI: mterm; N2: mterm; PREMISES: set_ofcl; INFO: info; REL: pred_symb; T: dev_tree II IS_IN(N1, T) ^ -IS_IN(N2, T)): dev_tree; ADD_DVU(PROPER(NI, N2, PREMISES, INFO, REL), T)? ,

f u n c t i o n DES (S: s e t o f mt; T: d e v _ t r e e ) : s e t _ o f mr; i f IS_Y_MT(S) then

EMPTYSET_MT else

UNION_MT(S, DES(FILTER_MT((N: mterm): hool; begin

D is PROPER A IS_MEM_MT(PRE(D), S) where const D: devunit = GET_DEVUNIT(N, T)

end)(NODES(T)), T)) endif,

GIVE NEXT UNIT TO BE INSERTED: ~unit <devtree: edes>4

.install <rule ttedes> unit <devtree: ttedes>.

~transf in <rule ttedes> with rule <f: uff3>4

~EDES(EMPTYSET_MT, S, T)~ <->

EDES(EMPTYSET_MT, S, T) >-<

KIND[S_] = s e t o f mt ^ KIND[T~ = d e v _ t r e e A DEF_DET[S, _T]

CONDITION FULFILLED? DEF_DET[EMPTYSET_MT, S-, T] ~y~

GIVE NAMED/MARKED UNIT FOR PARAMETER: s t a tDF ~func t edes~

btransf in <rule ttedes> with rule <m_mt: usi_el>~

~JNION_MT(EMPTYSET_MT, DES(S_, T))~ <->

EDES(EMPTYSET_MT, S_, Z) >-<

KIND[S] = set of mt A KIND[_T] -- dev_tree A DEF_DET[S, T]

~copy <rule ttedes>4

DES(S_, T) <->

EDES(EMPTYSET_MT, _S, T) >-<

KIND[S_] = set_of mt A KIND[T] = dev_tree A DEF_DET[S_, T]

Page 251: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 243

~copy into file <Irl> <rule ttedes> <dlttedes>4

~trs_nsf in <funct edes> with rule <f: uff2>4

funct ion EDES (R: s e t of_mt; S: s e t o f mt; T: dev_tree) : s e t of_mr; UNION_MT(R, (DES(S, T)> )

CONDITION FULFILLED? DEF_DET[S, T]

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD__FF ~funct des4

~transf in <funct edes> with rule <c: cdy_f22>4 ~transf in <funct edes> with rule <m_mt: usi_er>~

~transf in <funct edes> with rule <m_mt: uay_u> inverted~

funct ion EDES (R: s e t_o f mt; S: se t of mt; T: dev_tree) : s e t of mt; i f IS_Y_MT(S) then

R e l s e

~UNION_J~T(R, UNION_MT(S, DES(FILTER_/~T((N: mterm): bool; begin

D is PROPER A IS_MEM_MT(PRE(D), S) where const D: devunit = GET_gEVUNIT(N, T)

end) (NODES(T)), T)) )> endif

~install <funct spedes> unit <devtree: edes>~

~transf in <funct edes> with rule <f: ff3>4

function EDES (R: set of mr; S: set of mt; T: dev tree): set of mr; if IS_Y_MT (S) then

R e l s e

(UNION_MT(UNION_MT(R, S), DES(FILTER_MT((N: mterm) : bool; begin

D is PROPER A IS.jMEM_MT(PRE(D), S) where const D: devunit = GET_DEVUNIT(N, T)

end) (NODES(T)), T))) end i f

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct spedes~ CONDITION FULFILLED? DEFINED[UNION_MT(UNION_MT(R, S), DES(FILTER_ffr((N: mterm): bool;

begin D is PROPER A IS_MEM_MT(PRE(D), S) where const D: devunit = GET_DEVUNIT(N, T) end)(NODES(T)), T))]

DEFINED[EDES(UNION_MT(R, S), FILTER_MT((N: mterm): bool; begin

D is PROPER A IS_MEM_MT(PRE(D), S) where eonst D: devunit = GET_DEVUNIT(N, T)

end) (NODES(T)), T) ] by~

~copy <funct edes>~

Page 252: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

244 IV.2 DEVTREE

f u n c t i o n EDES (R: s e t _ o f m t ; S: s e t _ o f _ m r ; T: d e v _ t r e e ) : s e t o f mr; i f IS_Y_MT (s) then

R else

EDES(UNION_MT(R, S), FILTER_MT((N: mterm): bool; begin

D is PROPER A IS_MEM_MT(PRE(D), S) where const D: devunit = GET~EVUNIT(N, T)

end)(NODES(T)), T) endif

. t r a n s f in < f u n c t d e l e t e _ s u b t r > w i t h r u l e < l r l : d l t t e d e s > ~

f u n c t i o n DELETE_SUBTR (N: mterm; T: d e v _ t r e e II IS_PROPER_NO(N, W)): d e v t r e e ; FILTER_J)VU((D: devunit): bool; -IS_MEM_MT(POST(D), ~DES(MK_SING_MT(N), T)~ ))(T)

CONDITION FULFILLED? KIND[MK_SING_MT(N)] = set of mt

CONDITION FULFILLED? KIND[T] = dev_tree

CONDITION FULFILLED? DEF_DET[MK_SING_MT(N), T~ ~y4

~transf in <funct delete_subtr> with rule <a: in_stat>4

~copy <ftmet delete_subtr>~

function DELETE_SUBTR (N: mterm; T: devtree II IS_PROPER_NO(N, T)): devtree; begin

function EDES (R: set of mt; S: set of mt; T: dev tree): set of mt; if IS_Y_MT(S) then

R else

EDES(UNION_MT(R, S), FILTE}[_MT((N: mterm): bool; begin

D is PROPER A IS_MEM_MT(PRE(D), S) where const D: devunit = GET_DEVI~JIT(N, T)

end)(NODES(T)), T) endif;

FILTER_DVU((D: devunit) : bool; ~IS_MEM_MT(POST(D), EDES(EMPTYSET_MT, MK_SING_MT(N), T))) (T)

end

~copy into file <dldevtre> <structure devtree> <dl5devtree>4

~stop*

END SKERN START SKERN

~copy <structure devtree>~

structure DEVTREE = dev_tree, mterm, set of cl, info, predsymb, set_ofmt, set_ofrp, inference, nat, clause, INIT_TREE, IS_ROOT, ROOT, IS~ROPER_NO, ADD_TO_TREE, IS_IN, DELETE_SUBTR, PRED, HAS_PRED, SONS, LEAVES, CONDITIONS, UPDATE_COND, UPDATE_ALL_C, COMPACTIFY, COMPACTABLE, DEDUCIBLE_IN, DEDUCE_INF:

Page 253: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 245

structure INFERENCE; structure INFO; structure REL_COMP; structure MTERM; structure CLAUSE; structure FORMULA; structure TERM; structure NAT; type devunit -- INIT record POST: mterm endrecord I PROPER

record PRE: mterm; POST: mterm; PREMS: set of cl; INFO: info; REL: pred_symb endrecord;

function EO_DVU (Dl: devunit; D2: devunit): bool; (DI is INIT A D2 is INIT A EO_MT(POST(DI), POST(D2))) V (DI is PROPER ^ D2 is PROPER A EO_MT(PRE(DI), PRE(D2)) A EO_MT(POST(DI), POST(D2))

A EQ_SET_CL(PREMS(DI), PREMS(D2)) A EQ_INFO(INFO(DI), INFO(D2)) ^ EO_PS(REL(DI), REL(D2) )) ;

structure(dev tree, VOID,., PUT, GET, REM, ISA) = MAP(mterm, devunit, EQ_MT); structure(dev tree, MFILTER) = MFILTER(mterm, devunit, EO_MT); structure(dev_tree, set of mr, MFIL_KEYS) = MFIL_KEYS(mterm, devunit, EQ_MT); structure(dev_tree, MFAP) = MFAP(mterm, devunit, EQ_MT); structure(tier_tree, set of rot, MFAP_KEYS) = MFAP_KEYS(mterm, devunit, EQ_MT); structure(dev tree, MFT_KEYS) = MFT_KEYS(mterm, devunit, EQ_MT); structure(dev_tree, MALL) --MALL(mterm, devunit, EO_MT); type edge_label = CEL record PREMS: set of cl; INFO: info; REL: pred_symb endrecord; function IS_IN (N: mterm; T: dev_tree): bool;

ISA(N, T), f u n c t i o n PATH (Nl: mterm; N2: mterm; K: na t ; T: dev_ t r ee ) : bool ;

ISA(N2, T) A if EO_N(K, 0) then

EO_MT(NI, N2) else

D i s PROPER A PATH(N1, PRE(D), K - i, T) where const D: devtmit = GET(N2, T)

endif, func t i on ISPRED (NI: mterm; N2: mterm; T: dev_ t r ee ) : bool;

ISA(N2, T) A EQ_MT(NI, N2) v (GET(N2, T) is PROPER A ISPRED(N1, PRE(GET(N2, T)), T)),

function INIT_TREE (ROOT: mterm): dev tree; PUT(ROOT, INIT(ROOT), VOID()),

function IS_ROOT (N: mterm; T: dev tree): bool; ISA(N, T) A GET(N, T) is INIT,

function ROOT (T: dev_tree): mterm; MFT_KEYS((N: mterm): bool; GET(N, T) is INIT)(T),

function IS_PROPER_NO (N: mterm; T: dev_tree): bool; ISA(N, T) ^ ~IS_ROOT(N, T),

function ADD_TOTREE (NI: mterm; N2: mterm; PREMISES: set of cl; INFO: info; REL: pred symb; T: dev_tree I[ ISA(NI, T) A ~ISA(N2, T)): dev_tree; PUT(N2, PROPER(N1, N2, PREMISES, INFO, REL), T),

function DELETE_SUBTR (N: mterm; T: dev_tree II IS_PROPER_NO(N, T)): dev tree; begin

f u n c t i o n EDES (R: s e t of mr; S: s e t of mt; T: dev_ t r ee ) : s e t of mt; i f IS_Y_MT(S) then

R e l s e

EDES(UNION_MT(R, S), MFIL_KEYS((N: mterm): bool ; beg in

D is PROPER A IS_MEMjqT(PRE(D), S) where const D: devunit = GET(N, T)

Page 254: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

246 IV.2 DEVTREE

end)(T), T) endif;

MFILTER((D: devunit): bool; -IS_MEM_MT(POST(D), EDES(EMPTYSET_MT, MK_SING_MT(N), T))) (T)

end, function PRED (N: mterm; K: nat; T: dev tree I[ HAS_PRED(N, K, T)): mterm;

if EO_N(K, 0) then

N else

PRED(PRE(GET(N, T)), K - i, T) endif ,

func t ion HAS_PRED (N: mterm; K: nat ; T: d e v t r e e ) : bool; ISA(N, T) A i f EQ_N(K, 0) then

t rue e l se

GET(N, T) i s PROPER A HAS_PRED(PRE(GET(N, T)), K - l , T) endif ,

funct ion SONS (N: mterm; T: dev_tree II ISA(N, T)): se t of mt; MFIL_KEYS((NI: mterm): bool;

GET(N1, T) is PROPER A EO_MT(N, PRE(GET(N1, T)) ) ) (T) , func t ion LEAVES (T: dev_tree): se t of mt;

MFIL_KEYS((N: mterm): bool; ~IS_ME~L~4T(N, MFAP_KEYS((NI: mterm): bool;

GET(N1, T) i s PROPER, (NI: mterm): mterm; PRE(GET(N1, T) ) ) (T) ) ) (T) , funct ion CONDITIONS (N: mterm; T: dev_tree II IS_PROPER_NO(N, T)): se t of c l ;

PREMS(GET(N, T)), function UPDATE_COND (N: mterm; CL: clause; NEWCLS: set of cl; T: dev_tree II

ISA(N, T)): dev_tree; if GET(N, T) is PROPER A IS_j~EM_CL(CL, PREMS(GET(N, T))) then

PUT(N, PROPER(PRE(GET(N, T)), POST(GET(N, T)), UNION_CL(DEL_CL(CL, PREbtS(GET(N, T))) , NEWCLS), INFO(GET(N, T)), REL(GET(N, T))) , T)

e l s e T

endif , funct ion UPDATE_ALL_C (CL: clause; ~#CLS: se t of c l ; T: d e v t r e e ) : d e v t r e e ;

MFAP((D: devuni t ) : bool; t rue , (V: devuni t ) : devunit ; UPDATE_DVU(D, CL, NEWCLS))(T),

funct ion UPDATE_DVU (V: devunit ; CL: clause; NEWCLS: se t of c l ) : devunit ; if D is PROPER A IS_MEM_CL(CL, PREMS(D)) then

PROPER(PRE(D), POST(D), UNION_CL(DEL_CL(CL, PREMS(D)), NEWCLS), INFO(D), REL(D)) e lse

D endi f ,

funct ion RELSYMBOL (N: mterm; T: dev_tree It IS_PROPER_NO(N, T)): pred_symb; REL(GET(N, T)),

func t ion CINFO (N: mterm; T: dev_tree H IS_PROPER~O(N, T)): info; INFO(GET(N, T)),

func t ion DEL_SPATH (NI: mterm; N2: mterm; T: d e v t r e e it ISPRED(N1, N2, T)): dev_tree; begin

i f EQ_bIT(N1, N2) then

T else

Page 255: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 247

if ~IS_Y_MT(DEL_MT(N2, SONS(PRE(D), T))) then

REM(POST(D), T) e l se

DEL_SPATH(NI, PHE(D), HEM(POST(D), T)) endif

endif where const D: devunit = GET(N2, T)

end, funct ion COMPOSABLE (NI: mterm; N2: mterm; PS: predsymb; T:

dev_tree II ISPRED(NI, N2, T)): bool; EQ_MT(N1, N2) V REL_COMPABLE(RELSYMBOL(N2, T), PS) A

COMPOSABLE(N1, PRE(GET(N2, T)), REL_COMP(RELSYMBOL(N2, T), PS), T), funct ion ISPR_COMP (NI: mterm; N2: mterm; PS: pred_symb; T:

dev_tree): bool; ISA(N2, T) A (EO_MT(NI, N2) V GET(N2, T) is PROPER A REL_COMPABLE(RELSYMBOL(N2, T), PS) A ISPR_COMP(NI, PRE(GET(N2, T)), REL_COMP(RELSYMBOL(N2, T), PS), T)),

func t ion COMPACTABLE (NI: mterm; N2: mterm; T: dev_tree): bool; ~EQ_MT(N1, N2) A (ISA(N2, T) A GET(N2, T) is PROPER A

ISPR_COMP(N1, PRE(GET(N2, T)), RELSY~OL(N2, T), T)), funct ion COLL (NI: mterm; N2: mterm; SC: se t of c l ; I: info; PS: pred symb; T:

dev_tree): edge_label; if EQ_MT(NI, N2) then

CEL(SC, I, PS) e l se

COLL(N1, PRE(GET(N2, T)), UNION_CL(CONDITIONS(N2, T), SC), ADD_INFO(CINFO(N2, T), I ) , REL_COMP(RELSWdBOL(N2, T), PS), T)

endif ; funct ion COLLECT (NI: mterm; N2: mterm; T: dev_tree ii

COMPACTABLE(N1, N2, T)): edge label ; COLL(N1, PRE(GET(N2, T)), CONDITIONS(N2, T), CINFO(N2, T), RELSYMBOL(N2, T),

T), funct ion COb~ACTIFY (NI: mterm; N2: mterm; T: d e v t r e e li

COMPACTABLE(N1, N2, T)): dev_tree; begin

PUT(N2, PROPER(N1, N2, NEW_PREMS, NEW_INFO, NEW_REL_SYMB), NEW_TREE) where const (NEW_PREMS: se t of c l , NEW_INPO: info,

NEW_j~EL_SYMB: pred_symb, NEW_TREE: dev_tree) = (PREMS(C), INFO(C), REL(C), DEL_SPATH(N1, N2, T))

where const C: edge_label = COLLECT(N1, N2, T) end,

function DEDUCIBLE_IN (NI: mterm; N2: mterm; T: dev_tree): bool; -EQ_MT(NI, N2) A (IS_/N(N2, T) A GET_DEVUNIT(N2, T) is PROPER A

ISPR_COMP(NI, PRE(GET_DEVUNIT(N2, T)), RELSYMBOL(N2, T), T)), funct ion DEDUCE_INF (NI: mterm; N2: mterm; T: d e v t r e e [I

DEDUCIBLE_~NF(N1, N2, T)): inference; begin

CONSTRUCT_/N(NEW_PREMS, EMPTYSET_FO, MAKE_FO(NEW_REL_SYMB, CONCAT(MAKE_TS(TEI~M(NI)), MAKE_TS(TEHM(N2)))))

where const (NEW_PREMS: set of cl, NEW_BEL_SYMB: pred_symb) : (PREMS(C), REL(C)) where const C: edge label = COLLECT(N1, N2, T)

end endstruct

.copy into file <d2devtre> <structure devtree> <d23devtree>~

~stop*

END SKERN

Page 256: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

248 IV.2 DEVTREE

START SKERN

~comment <

I UNIT

LEVEL

MDEVTREE

module ( s p e c i f i e d wi th the he lp o f ass ignments and f u n c t i o n c a l l s )

GOAL rep lacement o f t he f u n c t i o n c a l l s by c a l l s o f t h e cor responding procedures which implement s e l e c t i v e upda t ing

>4

.install unit <mdevtree: mdevtree>4

*install unit <d2devtre: d23devtree>4

bcopy <module mdevtree>.

module MDEVTREE = dev_tree, mterm, set of cl, info, pred_symb, set_of_rp, clause, operator, id, ssort, P_ADD_TO_TRE, P_DELETE_SUB, PUPDATE_CON, P_UPDATE_ALL, P_COMPACTIFY:

structure DEVTREE; procedure P_ADD_TO_TRE (NI: mterm; N2: mterm; PREMISES: set of cl; INFO: info; REL:

pred symb; var T: dev_tree H IS_IN(N1, T) A -IS_IN(N2, T)); T := ADD_TO_T~E(NI, N2, PREMISES, INFO, REL, T), procedure P_DELETE_SUB (N: mterm; var T: dev_tree li IS_PROPER_NO(N, T)); T := DELETE_SUBTR(N, T), procedure P_UPDATE_CON (N: mterm; CL: clause; NEWCLS: set of cl; var T: dev_tree H

ISA(N, T)) ; T := UPDATE_COND(N, CL, NEWCLS, T), procedure P_UPDATE_ALL (CL: clause; NEWCLS: set of cl; var T: dev_tree); T := UPDATE_ALL_C(CL, NEWCLS, T), procedure P_DEL_SPATH (NI: mterm; N2: mterm; var T: dev_tree {{ ISPRED(NI, N2, T)); T := DEL_SPATH(NI, N2, T), procedure P_COMPACTIFY (NI: mterm; N2: mterm; vat T: dev_tree {{

COMPACTABLE(NI, N2, T)); T := COMPACTIFY(NI, N2, T)

endmodule

~comment<

UNIT p_update_cond

LEVEL procedure

GOAL !

a c a l l o f the h i g h e r - o r d e r p rocedure p_hput which updates the va lue of [ a g iven index of a map {

Page 257: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I V . 2 . 1 Developments 2 4 9

ACTIONS - u n f o l d of upda te_cond - moving an a s s ignmen t i n s i d e a c o n d i t i o n a l - i n t r o d u c t i o n o f an a u x i l i a r y v a r i a b l e - f o l d o f t h e p r o c e d u r e a l t _ p r e m s which u p d a t e s t h e component prems o f a

devunit - fold of p_.hput

>4

~transf in (proc p_update_cond> with rule <f: ufpf4>4

procedure P_UPDATE_CON (N: mterm; CL: clause; NEWCLS: set_of_cl; var T: dev_tree II ISA(N, T) ) ;

T := ~JPDATE_COND(N, CL, NEWCLS, T)~

CONDITION FULFILLED? DEF_DET[N, CL, NEWCLS, T] ~y4

GIVE NAMED/MARKED UNIT FOR PARAMETER: s t a t D F ~ f u n c t upda te_cond4 CONDITION FULFILLED? ASSERT[ISA(N, T ) ] ~y4

~ t r a n s f in <proc p_update_cond> w i t h r u l e (v : ma_c>4

~ i n s e r t in <module mdevt ree>4

° . °

s t r u c t u r e DEVTREE? ; p r o c e d u r e P_ADD_TO_TRE (NI: mterm; N2: mterm; PREMISES: s e t o f c l ; INFO: i n f o ;

REL: p r e d symb; v a r T: d e v _ t r e e II IS_IN(N1, T) A -IS_IN(N2, T) ) ; GIVE NEXT UNIT TO BE INSERTED: ~ u n i t <mdevtree: p_mapins t>4

~ t r a n s f in <proc p_update_cond> w i t h r u l e <v: ia_wa>4

p r o c e d u r e P_UPDATE_CON (N: mterm; CL: c l a u s e ; NEWCLS: s e t _ o f c l ; v~ r T" t i e r _ t r e e II ISA(N, T) ) ;

i f GET(N, T) i s PROPER A IS_MEM_CL(CL, PREMS(GET(N, T) ) ) t h e n

~T := PUT(N, PROPER(PRE(GET(N, T ) ) , POST(GET(N, T ) ) , UNION_CL(DEL_CL(CL, PREMS(GET(N, T ) ) ) , NEWCLS), INFO(GET(N, T ) ) , REL(GET(N, T ) ) ) , T)~

e l s e T : = T

e n d i f

GIVE NAME FOR PARAMETER: X ~e~

GIVE NAME FOR PARAMETER: m ~devunit4

GIVE NAMED/MARKED UNIT FOR PARAMETER: F ~in <proc p_update_cond>~

p r o c e d u r e P_UPDATE_CON (N: mterm; CL: c l a u s e ; NEWCLS: s e t o f c l ; v a r T: d e v _ t r e e It ISA(N, T ) ) ;

i f GET(N, T) i s PROPER A IS_MEM_CL(CL, PREMS(GET(N, T) ) ) t h e n

T := PUT(N, ~PROPER(PRE(GET(N, T ) ) , POST(GET(N, T ) ) , UNION_CL(DEL_CL(CL, PREMS(GET(N, T ) ) ) , NEWCLS), INFO(GET(N, T) ) , REL(GET(N, T ) ) ) ~ , T)

e l s e T : = T

e n d i f

Page 258: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

250 IV.2 DEVTREE

CONDITION FULFILLED? DEFINED[PROPER(PRE(GET(N, T)), POST(GET(N, T)), UNION_CL(

DEL_CL(CL, PREMS(GET(N, T))) , NEWCLS), INFO(GET(N, T)), REL(GET(N, T)) ) ] by~

CONDITION FULFILLED? PROPER(PRE(GET(N, T)), POST(GET(N, T)), UNION_CL(DEL_CL(CL, PREMS(GET(N, T))) , NEWCLS), INFO(GET(N, T)), EEL(GET(N, T))) isof_submode devunit

~ t ransf in <proc p_update_cond> with ru le <v: ia_a_b32>4

procedure P_UPDATE_CON (N: mterm; CL: c lause; NEWCLS: se t o f c l ; var T: d e v t r e e II ISA(N, T));

if GET(N, T) i s PROPER A IS_MEM_CL(CL, PREMS(fiET(N, T))) then

~begin va t E: devunit ; E :: PROPER(PRE(GET(N, T)), POST(GET(N, T)), UNION_CL(

DEL_CL(CL, PREMS(GET(N, T))), NEWCLS), INFO(OET(N, T)), REL(GET(N, r))); T := PUT(N, E, T)

end) e l s e

T := T end i f

GIVE NAMED/MARKED UNIT FOR PARAMETER: F ~in <proc p_update_cond>4

procedure P_UPDATE_CON (N: mterm; CL: c lause; NEWCLS: se t o f c l ; var T: dev_tree If ISA(N, T));

if GET(N, T) is PROPER A IS_MEM_CL(CL, PREMS(GET(N, T))) then

begin var E: devunit; E := PROPER(PRE((GET(N, T)~ ), POST(GET(N, T)), UNION_CL(

DEL_CL(CL, PREMS(GET(N, T))), NEWCLS), INFO(GET(N, T)), REL(GET(N, T))); T := PUT(N, E, T)

end else

T := T end i f

CONDITION FULFILLED? GET(N, T) isof_submode KIND[El ~y4

CONDITION FULFILLED? DEFINED[GET(N, T)] .y4

GIVE NAME FOR PARAMETER: NEW ~h.

CONDITION FULFILLED? NEW[HI

~insert in <module mdevtree>*

module MDEVTREE = dev_tree, mterm, set_of_cl, info, pred_symb, set_of_rp, clause, operator, id, ssort, P_ADD_TO_TRE, P_DELETE_SUB, P_UPDATE_CON, P_UPDATE_ALL, P_COMPACTIFY: structure DEVTREE;

Page 259: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 251

module(dev_tree, P_PUT, P_HEM) = P_MAP(mterm, devunit, EO_MT); module(dev_tree, P__HPUT, P_REM) = P_J~4AP(mterm, devunit, EO_MT)? ; procedure P_ADD_TO_TRE (NI: mterm; N2: mterm; PREMISES: set of cl; INFO: info;

REL: pred_symb; var T: dev tree II IS_/N(NI, T) A ~IS_IN(N2, T)); GIVE NEXT UNIT TO BE INSERTED: ~unit <mdevtree: p_mpdvuinst>~

~install unit <mdevtree: alt_prems>.

~copy <proc alt_prems>4

procedure ALT_.PREMS (vat D: devunit; CLS: set of cl); D := PROPER(PRE(D), POST(D), CLS, INFO(D), REL(D))

~trsnsf in <proc p_update_cond> with rule <f: fp2_/>~

procedure P_UPDATE_CON (N: mterm; CL: clause; NEWCLS: set of cl; var T: dev_tree |l ISA(N, T));

if GET(N, T) is PROPER A IS_MEM_CL(CL, PREMS(GET(N, T))) then

begin vat E: devunit; E := GET(N, T); (E := PROPER(PRE(E), POST(E), UNION_CL(DEL_CL(CL, PREMS(E)), NEWCLS), INFO(E),

REL(E))) ; T := PUT(N, E, T)

end else

T := T e n d i f

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDP ~proc alt_prems~ CONDITION FULFILLED? IS_VAR_KIND[E] my.

CONDITION FULFILLED? DEFINED[E := PROPER(PRE(E), POST(E), UNION_CL(DEL_CL(CL,

PREMS(E)), NEWCLS), INFO(E), REL(E))] =~ DEFINED[cell ALT_PREMS(E, UNION_CL(DEL_CL(CL, PREMS(E)), NEWCLS))~

~transf in <proe p_update_cond> with rule <v: cv_wa_v>.

procedure P_UPDATE_CON (N: mterm; CL: clause; NEWCLS: set of cl; vat T: dev tree II ISA(N, T)) ;

if GET(N, T) is PROPER A IS_MEM_CL(CL, PREMS(GET(N, T))) then

begin (vat E: devunit; E := GET(N, T ) ) ; c a l l ALT_PREMS(E, UNION_CL(DEL_CL(CL, PREMS(E)), NEWCLS)); T := PUT(N, E, T)

end e l s e

T :: T e n d i f

~install unit <mdevtree: p_hput>~

~copy <proc p_hput>4

Page 260: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

252 IV.2 DEVTREE

procedure P_HPUT (I: mterm; P: procedure (var devunit); var M: dev_tree); b e g i n

v a r E: d e v u n i t := GET(I, M); c a l l P(E); M := PUT(I, E, M)

end

. i n s t a l l u n i t <mdevtree: eal t_.prems>4

~ t r a n s f in <proc p_update_cond> w i t h r u l e <a: i n _ s t a r > .

. t r a n s f in <proc p_update_cond> w i t h r u l e <f: f p l _ l > 4

p r o c e d u r e P_UPDATE_CON (N: mterm; CL: c l a u s e ; NEWCLS: s e t o f c l ; v a r T: d e v t r e e II ISA(N, T)) ;

if GET(N, T) is PROPER A IS_MEM_CL(CL, PREMS(GET(N, T))) t h e n

b e g i n p r o c e d u r e EALT_FREMS ( v a t D: d e v t m i t ) ; c a l l ALT_PB/hMS(D, UNION_CL(DEL_CL(CL, PREMS(D)), NEWCLS)); b e g i n

v a r E: d e v t m i t := GET(N, T); ~ c a l l ALT_PREbIS(E, UNION_CL(DEL_CL(CL, PREMS(E)), NEWCLS))~ ; T := PUT(N, E, T)

end end

e l s e T :: T

endif

GIVE NArD/MARKED UNIT FOR PARAMETER: statDP ~proc ealt_.Drems4 CONDITION FULFILLED? IS_VAR_KIND[E] ~y~

CONDITION FULFILLED? DEFINED[call ALT_PREMS(E, UNION_CL(DEL_CL(CL, PREMZ(E)), NEWCLS))]

DEFINED[call EALT_PREMS(E)~ *y*

.transf in <proc p_update_cond> with rule <f: fhp3_oplv>4

procedure P_UPDATE_CON (N: mterm; CL: clause; NEWCLS: set of cl; var T: dev_tree II ISA(N, T));

i f GET(N, T) is PROPER A IS_MEM_CL(CL, PREMS(GET(N, T))) then

begin procedure EALT_PREMS (var D: devunit); call ALT_PREMS(D, UNION_CL(DEL_CL(CL, PREMS(D)), NEWCLS)); ~ b e g i n

v a r E: d e v u n i t := GET(N, T); c a l l EALT_PREMS(E); T := PUT(N, E, T)

end) end

else T := T

e n d i f

GIVE NAMED/M~KED UNIT FOR PARAMETER: statD__PP ~proc p_hput4 CONDITION FULFILLED? IS_VAR_/4IND[T]

Page 261: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 253

, y 4

CONDITION FULFILLED? DEFINED[begin var E: devunit := GET(N, T); call EALT_J~EMS(E); T := PUT(N, E, T) end]

~DEFINED[call P_~UT(N, EALT_PREMS, T)] .Y~

~transf in <proc p_update_cond> with rule <v: sa>4

~ t r a n s f in <proc p_update_cond> with rule <a: in_const>4

-copy <proc p_update__cond>4

procedure P_UPDATE_CON (N: mterm; CL: clause; NEWCLS: set of cl; var T: devtree II ISA(N, T) ) ;

begin const E: devunit = GET(N, T); if E is PROPER a IS_MEM_CL(CL, PREMS(E)) then

begin procedure EALT_PREMS (var D: devunit); call ALT_PREMS(D, UNION_CL(DEL_CL(CL, PREMS(D)), NEWCLS)); call P_HPUT(N, EALT_PREMS, T)

end e l s e

s k i p e n d i f

end

~comment<

I UNIT

f LEVEL

GOAL

p _ d e l e t e _ s u b t r e e

p r o c e d u r e

- a c a l l o f p _ m f i l t e r which f i l t e r s a l l t h e v a l u e s o f a map w i t h a g i v e n p r e d i c a t e

- an e f f i c i e n t c o m p u t a t i o n o f t h i s p r e d i c a t e

ACTIONS - u n f o l d o f d e l e t e _ s u b t r e e moving an a s s i g n m e n t i n s i d e a c o n d i t i o n a l f o l d o f t h e p r o c e d u r e p ~ m f i l t e r i n t r o d u c t i o n o f an a u x i l i a r y v a r i a b l e r on which t h e v a l u e o f an e x p r e s s i o n o c c u r i n g in t h e f i l t e r p r e d i c a t e s h o u l d be computed a b s t r a c t i o n o f t h e c o r r e s p o n d i n g p r o c e d u r e p_edes to t h e f u n c t i o n e d e s f o l d i n g p_edes to g e t a c a l l o f p_edes w i t h a rgument r f u r t h e r development o f p_edes w i t h t h e goa l t o g e t a c a l l o f t h e p r o c e d u r e which a s s i g n s to r t h e u n i o n o f r and t h e v a l u e o f a g i v e n e x p r e s s i o n

> 4

~ i n s e r t i n <module mdevt ree>4

. . .

module(dev t r e e , P_MFAP) = P_bIFAP(mterm, d e v u n i t , EO_MT)? ; p r o c e d u r e P_ADD_TO_TRE (NI: mterm; N2: mterm; PREMISES: s e t o f c l ; INFO: i n f o ; REL:

Page 262: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

254 IV. 2 DEVTREE

pred_symb; var T: dev tree I[ IS_IN(NI, T) A -IS_IN(N2, T)); call P_PUT(N2, PROPER(N1, N2, PREMISES, INFO, REL), T),

GIVE NEXT UNIT TO BE INSERTED: ~unit <mdevtree: p_mfilterins>4

btransf in <proc p_delete_suhtr> with rule <f: ufpf2>4

procedure P_DELETE_SUB (N: mterm; vat T: dev_tree II IS_PROPER_.NO(N, T)); T := (DELETE_SUBTR(N, T))

CONDITION FULFILLED? DEF_DET[N, T] ~y~

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct delete_subtr4 CONDITION FULFILLED? ASSERT[IS_PROPER_NO(N, T)] my4

.... WARNING: UNIT ALREADY DEFINED: phrases EDES NAME NOT INCORPORATED

~transf in <proc p_delete_subtr> with rule <v: ma_s2>~

~install unit <mdevtree: p_mfilter>4

bcopy <proc p_mfilter>4

procedure P_MFILTER (Q: function (devunit) bool; var M: dev_tree); M := MFILTER(O) (M)

~transf in <proc p_delete_subtr> with rule <f: fhp2_alv>~

procedure P_DELETE_.SUB (N: mterm; var T: tier_tree II IS_PROPER_NO(N, T)); b e g i n

f u n c t i o n EDES (R: s e t o f mt; S: s e t o f mt; T: d e v _ t r e e ) : s e t o f mr; if IS_Y_MT(S) then

R else

EDES(UNION_MT(R, S), MFIL_KEYS((N: mterm) : bool; b e g i n

D is PROPER A IS_MEM_jMT(PRE(D), S) where const D: devunit = GET(N, T)

end) (T), T) endif;

(T := MFILTER((D: devunit): bool; -IS_MEM_MT(POST(D), EDES(EMPTYSET_MT, MK_SING_MT(N), T))) (T))

end

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDP ~proc p_mfilter4 CONDITION FULFILLED? IS_VAR_KIND[T~ my4

CONDITION FULFILLED? DEFINED[T := MFILTER((D: devunit): bool;

-IS_3MEM_MT(POST(D), EDES(EMPTYSET_MT, MK_SING_MT(N), T))) (T) ] =~ DEFINED[call P_MFILTER((D: devunit) : bool;

~IS_MEM_MT(POST(D), EDES(EMPTYSET_MT, MK_SING_MT(N), T)), T)] my4

Page 263: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 255

. t r a n s f in <proc p_delete_subtr> with rule <v: in__wa>4

procedure P_DELETE_SUB (N: mterm; var T: dev_tree l{ IS_PROPER_NO(N, T)); begin

funct ion EDES (R: set_of_mt; S: s e t o f mt; T: dev_tree) : set_of_mt; if IS_Y_MT(S) then

R e l se

EDES(UNION_MT(R, S), MFIL_KEYS((N: mterm): bool; begin

D is PROPER A IS_MEM_MT(PRE(D), S) where const D: devunit = GET(N, T)

end)(T), T) endif;

(call P_MFILTER((D: devunit): bool; ~IS_MEM_MT(POST(D), EDES(EMPTYSET_MT, MK_SING_J~T(N), T)), T))

end

GIVE NAME FOR PARAMETER: X ~r4

GIVE NAME FOR PARAMETER: m . s e t of mt~

GIVE NAMED/[~RKED UNIT FOR PARAMETER: E ~in <proc p_delete_subtr>*

procedure P_DELETE_SUB (N: mterm; vat T: dev_tree {[ IS_PROPER_NO(N, T)); begin

function EDES (R: set_of mt; S: set of mt; T: dev_tree): set of mt; i f IS_Y_MT(S) then

R e l s e

EDES(UNION_MT(R, S), MFIL_KEYS((N: mterm): bool; begin

D i s PROPER A IS_MEM_MT(PRE(D), S) where const D: devunit = GET(N, T)

end)(T), T) endif ;

c a l l P_MFILTER((D: devuni t ) : bool; ~IS_MEM_MT(POST(D), ~EDES(EMPTYSET_MT, MK_SING~(N), T)~ ), T)

end

CONDITION FULFILLED? DEFINED[EDES(EMPTYSET_MT, MK_SING_MT(N), T)] ,y4

CONDITION FULFILLED? EDES(EMPTYSET_MT, ME_SING_MT(N), T) isof_submode set_of_mt

.y4

. i n s e r t in <proc p_delete_subtr>~

procedure P_DELETE_SUB (N: mterm; var T: dev_tree ]{ IS_PROPER_NO(N, T)); begin

funct ion EDES (R: s e t of mt; S: s e t _ o f m t ; T: dev_tree) : s e t of mt; i f IS_Y_MT(S) then

R e l s e

EDES(UNION_MT(R, S), MFIL_KEYS((N: mterm): bool; begin

Page 264: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

256 IV.2 DEVTREE

D i s PROPER ~ IS_MSM_MT(PNE(D), S) where c o n s t D: devun i t = GET(N, T)

end) (T), T) endif? ;

begin var R: set of mr; R := EDES(EbIPTYSET_jMT, bIK_SING_bIT(N), T) ; call P_MFILTER((D: devunit) : bool; ~IS_bIEM_MT(POST(D), R), T)

end end

GIVE NEXT UNIT TO BE INSERTED: .unit <mdevtree: del_sub>4

.transf in <proc p_delete_subtr> with rule <f: fal>4

procedure P_DELETE_SUB (N: mterm; vat T: dev_tree [[ IS_PROPER_NO(N, T)); b e g i n

f u n c t i o n EDES (R: s e t o f mt; S: s e t o f mt; T: d e v _ t r e e ) : s e t o f mt; if IS_Y_MT (S) then

R else

EDES(UNION_MT(R, S), MFIL_KEYS((N: mterm) : bool; begin

D is PROPER A IS_MEM_MT(PNE(D), S) where const D: devtmit = GET(N, T)

end) (T) , T) e n d i f ;

f u n c t i o n DEL_SUB (D: devun i t ) : bool ; -IS_MEM_MT(POST(D), R) ; b e g i n

v a t R: s e t o f mt; R : = EDES(EMPTYSET_MT, MK_SING_MT(N), T) ; c a l l P_MFILTER(((D: d e v u n i t ) : bool ; -IS_MEM_MT(POST(D), R)) , T)

end end

GIVE NAMED/MAPJ(ED UNIT FOR PARAMETER: statD_FF .funct del_sub4

.transf in <proc p_delete_subtr> with rule <v: ia__a>4

procedure P_DELETE_SUB (N: mterm; vat T: dev_tree II IS_PROPER_NO(N, T)); begin

function EDES (R: set of mt; S: set of mt; T: dev_tree): set of mr; i f IS_Y_J~T (S) then

R e l s e

EDES(UNION_J~T(R, S) , MFIL_KEYS((N: mterm) : bool ; begin

D is PROPER A IS_MEM_J~IT(PRE(D), S) where const D: devunit = GET(N, T)

end) (T), T) endif;

function DEL_SUB (D: devunit): bool; -IS_MEM_MT(POST(D), R) ;

beg in v a t R: s e t o f rot;

:= EDES(EMPTYSET_MT, MK_ZING_MT(N), T)) ; c a l l P_MFILTER(DEL_ZUB, T)

end

Page 265: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 257

end

GIVE NAMED/MARKED UNIT FOR PARAMETER: F ~in <proc p_delete_subtr>4

procedure P-DELETE_SUB (N: mterm; v a t T: d e v _ t r e e {I IS_FROPER_~NO(N, T)) ; beg in

f u n c t i o n EDES (R: s e t o f m t ; S: s e t o f mr; T: d e v _ t r e e ) : s e t o f mr; if IS_Y_MT (S) then

R e l s e

EDES(UNION_MT(R, S), MFIL_KEYS((N: mterm): boo l ; beg in

D is PROPER a IS.MEM_MT(FRE(D), S) where const D: devunit = GET(N, T)

end) (T), T) e n d i f ;

f u n c t i o n DEL_SUB (D: devun i t ) : boo l ; ~IS_MEM_jMT(POST(D), R) ;

beg in v a t R: s e t o f mr; R := EDES((EMPTYSET_MT) , MK_SING_MT(N), T); call P_aMFILTER(DEL_SUB, T)

end end

CONDITION FULFILLED? EMPTYSET_MT isof_submode KIND[R] my4

CONDITION FULFILLED? DEFINED[EMPTYSET_MT] ~y4

GIVE NAME FOR PARAMETER: NEW ~h4

CONDITION FULFILLED? NEW[HI ~y4

~insert in <proc p_delete_subtr>.

procedure P-D.DELETE_SUB (N: mterm; var T: dev tree [I IS_PROPER_~NO(N, T)); beg in

. . ,

f u n c t i o n DEL_SUB (D: d e v u n i t ) : boo l ; ~IS_MEM_MT(POST(D), R)? ;

beg in v a r R: s e t _ o f rot; beg in

R := EMPTYSET_MT; R : = EDES(R, MK_SING_MT(N), T)

end; c e l l P_MFILTER(DEL_SUB, T)

end end

GIVE NEXT UNIT TO BE INSERTED: ~unit <mdevtree: p_edes>4

~transf in <proc p_delete_.subtr> with rule <f: fp3_/>.

procedure P_DELETE_SUB (N: mterm; var T: dev tree {| IS_PROPER_NO(N, T)); beg in

Page 266: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

258 IV.2 DEVTREE

function EDES (R: set of mt; S: set of mt; T: dev tree): set of mt; if IS_Y_MT(S) then

R else

EDES(UNION_MT(R, S), MFIL_KEYS((N: mterm): bool; begin

D is PROPER A IS_MEM_MT(PNE(D), S) where const D: devunit = GET(N, T)

end)(T), T) endif;

function DEL_SUB (D: devunit): bool; ~IS_MEM_MT(POST(D), R);

p r o c e d u r e P_EDES ( v a r R: s e t o f mt; S: s e t o f mt; T: d e v _ t r e e ) ; R := EDES(R, S, T); begin

var R: set of mt; begin

R := EMPTYSET_MT; ~R := EDES(R, MK_SING_MT(N), T)~

end; call P_MFILTER(DEL_SUB, T)

end end

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDP ~proc p_edes~ CONDITION FULFILLED? IS_VAR_KIND[R] ~y4

CONDITION FULFILLED? DEFINED[R := EDES(R, MK_SING_MT(N), T)~ DEFINED[call P~DES(R, MK_SING_MT(N), T)]

~y4

~transf in <proc p_edes> with rule <f: uff3>*

p r o c e d u r e P_EDES ( v a r R: s e t o f mr; S: s e t o f mr; T: dev t r e e ) ; R : : ~EDES(R, S, T)~

CONDITION FULFILLED? DEF_DET[R, S, T] ~y4

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct edes~

~transf in <proc p_edes> with rule <v: ma_c>~

~transf in <proc p_edes> with rule <v: sa>~

~transf in <proc p_edes> with rule <v: iv_a>4

p r o c e d u r e P_EDES ( v a r R: s e t o f mr; S: s e t o f mr; T: dev t r e e ) ; i f IS_Y_MT(S) t h e n

skip e l s e

~R := EDES(UNION_MT(R, S) , MFIL_~EYS((N: mterm): boo l ; b e g i n

D is PROPER A IS_MEM_MT(PRE(D), S) where const D: devunit : GET(N, T)

e n d ) ( T ) , T)~ endif

Page 267: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 259

GIVE NAMED/MARKED UNIT FOR PARAMETER: F ~in <proc p_edes>.

procedure P._EDES (var R: set of mt; S: set of mr; T: dev_tree); if IS_Y_MT(S) then

skip else

R := EDES((UNION_MT(R, S)) , MFIL_KEYS((N: mterm): bool; begin

D is PROPER A IS_MEM_MT(PRE(D), S) where const D: devunit = GET(N, T)

end)(T), T) e n d i f

CONDITION FULFILLED? UNION_MT(R, S) isof__submode KIND[R~ .y4

CONDITION FULFILLED? DEFINED[UNION_MT(R, S)] .y4

GIVE NAME FOR PARAMETER: NE___WW ~h-

CONDITION FULFILLED? NEW[HI my4

~install unit <mdevtree: sedes>4

~transf in <proc p_edes> with rule <a: in_star>4 ~transf in <proc p_edes> with rule <i: pp_cdl> inverted.

~transf in <proc p_edes> with rule <f: fal>*

procedure P_EDES (vat R: set of mt; S: set_of mt; T: dev_tree); begin

function SEDES (N: mterm): bool; begin

const D: devunit = GET(N, T); D is PROPER A IS_MEM_MT(PRE(D), S)

end; if IS_Y.MT(S) t h e n

skip else

begin R := UNION_MT(R, S); R := EDES(R, MFIL_KEYS(((N: mterm): bool;

b e g i n c o n s t D: d e v u n i t = GET(N, T); D is PROPER A IS_MEM_MT(PRE(D), S)

e n d ) ) ( T ) , T) end

e n d i f end

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD£F ~funct sedes4

~insert in <module mdevtree>*

Page 268: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

260 IV.2 DEVTREE

module (dev_ t ree , P_MFILTER) = P_MFILTER(mterm, d e v u n i t , E O ~ ) ? ; p rocedure P_ADD_TO_TRE (NI: mterm; N2: mterm; PREMISES: s e t o f c l ; INFO: in fo ; REL:

pred_symb; v a r T: dev t r e e I! IS_IN(N1, T ) A - I S _ I N ( N 2 , T)) ; c a l l P_PUT(N2, PROPER(N1, N2, PREMISES, INFO, REL), T),

GIVE NEXT UNIT TO BE INSERTED: .unit <mdevtree: p_setinst>4

-install unit <mdevtree: pl union_rot>4

.copy <proc pl_union_mt>q

procedure PL_UNION_MT (var L: set of mt; R: set of mt); L := UNION_MT(L, R)

~transf in <proc p_edes> with rule <f: fp2_l>4

procedure P_EDES (vat R: set of mr; S: set of mr; T: dev_tree); begin

function SEDES (N: mterm): bool; beg in

cons t D: d e v u n i t = GET(N, T); D is PROPER A IS_MEM_MT(PRE(D), S)

end; if IS_Y_MT (S) then

sk ip else

begin := UNION_MT(R, S)) ;

R : = EDES(R, MFIL_KEYS(SEDES) (T), T) end

endif end

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD P ~proc pl_union_mt4 CONDITION FULFILLED? IS_VAR_KIND[R] .y4

CONDITION FULFILLED? DEFINED[R := UNION_MT(R, S)~ ~ DEFINED[call PL_UNION_MT(R, S)] .y4

-install <proc spp_edes> unit <mdevtree: p_edes>~

-transf in <proc p_edes> with rule <f: fp3_l>4

procedure P_EDES (var R: set of mr; S: set of mr; T: dev_tree); beg in

f u n c t i o n SEDES (N: mterm): boo l ; beg in

cons t D: devun i t = GET(N, T); D i s PROPER A IS_MEM_MT(PRE(D), S)

end; i f IS_Y_MT (S) then

sk ip e l s e

beg in c a l l PL_UNION_MT(R, S) ;

:= EDES(R, MFIL_KEYS(SEDES)(T), T)) end

Page 269: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV .2 .1 Developments 261

endif end

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDP ~proc spp_edes4 CONDITION FULFILLED? IS VAR_KIND[R~ ~y~

CONDITION FULFILLED? DEFINED[R := EDES(R, MFIL_KEYS(SEDES) (T), T)~ =~ DEFINED[call P_EDES(R, MFIL_KEYS(SEDES) (T), T)

~y~

~delete in <proc p_delete_subtr>4

procedure P_DELETE_SUB {N: mterm; var T: dev tree II IS_PROPER_NO(N, T)); b e g i n

~ f u n c t i o n EDES (R: s e t o f mt; S: s e t o f mt; T: dev t r e e ) : s e t o f mr; i f IS_Y_MT(S) t hen

R e l s e

EDES(UNION_MT(R, S) , MFIL_KEYS((N: mterm): b o o l ; b e g i n

D is PROPER /A IS_MEM_MT(PRE(D), S) where const D: devunit = GET(N, T)

end) (T), T) endif;

function DEL_SUB (D: devunit): bool; -IS_MEM_MT(POST(D), R) ;

p r o c e d u r e P_EDES ( v a r R: s e t o f mt; S: s e t o f mr; T: dev t r e e ) ; b e g i n

f u n c t i o n SEDES (N: mterm): b o o l ; b e g i n

c o n s t D: d e v u n i t = GET(N, T); D is PROPER A IS_MEM_MT(PRE(D), S)

end; i f IS_Y_MT (S) t h e n

skip else

b e g i n c a l l PL_UNION_~T(R, S) ; c a l l P_EDES(R, MFIL_KEYS(SEDES) (T), T)

end endif

end; b e g i n

v a r R: s e t _ o f mt; b e g i n

R : = EMPTYSET_J~T; call P_EDES(R, MK_SING_MT(N), T)

end; call P_MFILTER(DEL_SUB, T)

end end

*copy <module mdevtree>4

module MDEVTREE = d e v _ t r e e , mterm, s e t o f c l , i n f o , p r e d symb, s e t o f _ r p , c l a u s e , o p e r a t o r , i d , s s o r t , P_ADD_TO_TRE, P_DELETE_SUB, P_UPDATE_CON, P_UPDATE_ALL, P_C(IMPACTIFY:

Page 270: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

262 IV.2 DEVTREE

structure DEVTREE; module(dev_tree, P_PUT, P_REM) = P_MAP(mterm, devunit, EQ_MT); m o d u l e ( d e v _ t r e e , P_HPUT, P_REM) = P ~ ( m t e r m , d e v u n i t , EQ_MT); m o d u l e ( d e v u n i t , ALT_PREMS) = MPDEVUNIT(mterm, s e t o f c l , i n f o , pred_symb, d e v u n i t ,

PROPER, PRE, POST, PREMS, INFO, EEL); module(dev, tree, P_MFAP) = P_MFAP(mterm, devunit, EQ_MT); module(dev_tree, P_MFILTEE) = P_MFILTER(mterm, devunit, EQ_MT); module(set_of at, P_ADD_MT, P_DEL_MT, P_MK_~ING_MT, PL_UNION_MT, PR_UNION_MT,

PL_ISEC_MT, PR_ISEC_MT, PL_DIFF_MT, PR_DIFF_MT) = P_SET(mterm, EQ_MT); procedure P_AI)D_TO_TRE (NI: raters; N2: raters; PREMISES: set of cl; INFO: info; EEL:

pred aymb; var T: dev tree I[ IS_IN(N1, T) A -IS_IN(N2, T)); call P_PUT(N2, PROPER(N1, N2, PREMISES, INFO, EEL), T), procedure P_DELETE_SUB (N: raters; var T: dev tree l[ IS_PROPER_NO(N, T)); begin

function DEL_SUB (D: devunit): bool; -IS_MEM_MT(POST(D), R) ;

p r o c e d u r e P_EDES ( v a r R: s e t o f mt; S: s e t o f mt; T: d e v _ t r e e ) ; b e g i n

f u n c t i o n SEDES (N: mterm): b o o l ; b e g i n

c o n s t D: d e v u n i t = GET(N, T); D is PROPER A IS_MEM_MT(PEE(D), S)

end; if IS_Y_MT (S) then

skip e l s e

b e g i n c a l l PL_UNION_MT(R, S) ; call P_EDES(R, MFIL_KEYS(SEDES) (T), T)

end e n d i f

end; begin

var R: set of mr; b e g i n

R := EMPTYSET_MT; call P_EDES(R, MK_SING_MT(N), T)

end; call P_MFILTER(DEL_SUB, T)

end end, procedure P_UPDATE_CON (N: raters; CL: clause; NEWCLS: set of cl; var T: dev tree H

ISA(N, T)); b e g i n

c o n s t E: d e v u n i t = GET(N, T); if E is PROPER A IS_MEM_CL(CL, PREMS(E)) then

begin procedure EALT_PREMS (var D: devunit) ; call ALT~REMS(D, UNION_CL(DEL_CL(CL, PREMS(D) ), NEWCLS) ) ; call P_}{PUT(N, EALT_PREMS, T)

end else

skip endif

end, procedure P_UPDATE_ALL (CL: clause; NEWCLS: set of cl; var T: dev_tree); begin

procedure P_UPD (var D: devunit);

Page 271: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.1 Developments 263

if D is PROPER a IS_MEM_CL(CL, PREMS(D)) then

call ALT_PREMS(D, UNION_CL(DEL_CL(CL, PREMS(D)), NEWCLS)) else

skip endif ; c a l l P_MFAP((D: devuni t ) : bool; t rue , P UPD, T)

end, procedure P_DEL_SPATH (NI: mterm; N2: mterm; var T: dev t r e e II ISPRED(N1, N2, T)); if EO_MT(NI, N2) then

skip else

begin const D: devunit = GET(N2, T); if ~IS_Y_MT(DEL_MT(N2, SONS(PRE(D), T))) then

c a l l P_REM(POST(D), T) e l s e

begin call P_REM(POST(D), T) ; call P_DEL_SPATH(N1, PRE(D), T)

end endif

end endif, procedure P_COMPACTIFY (NI: mterm; N2: mterm; ver T: dev tree II

COMPACTABLE(NI, N2, T)) ; begin

const C: edge_label = COLLECT(N1, N2, T); begin

const (NEW_PREMS: set_of el, NEW_/NFO: info, NEW_REL_SYMB: pred_symb) = (PREMS(C), INFO(C), REL(C));

call P_DEL_SPATH(NI, N2, T); cell P_PUT(N2, PROPER(N1, N2, NEW_PREMS, NEW_/NFO, NEW_REL_SYMB), T)

end end

endm~ule

-copy into file <dlmdevtr> <module mdevtree> <dl2mdevtree>~

-s top~

END SKERN

Page 272: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

264 IV. 2 DEVTREE

2.2. Description of additional functions end modules

PRE functlon PRE: function(D: devunit II D is PROPER) mterm

NODES function NODES (T: dev_tree): set of mr;

FAP_DVU_MT((D: devunit): bool; true, (D: devunit) : mterm; POST(D)) (T) DESCENDANTS

funct ion DESCENDANTS (N: mterm; T: dev_tree II IS_IN(N, T)): se t of mt; SC_MT((N2: mterm): bool; ISPRED(N, N2, T))

DES funct ion DES (S: s e t of mt; T: dev_tree) : se t of mr;

UNION_MT_MT((N: mterm): bool; t rue , (N: mterm): s e t of rot; DESCENDANTS(N, T))(S) PRED

funct ion PRED (N: mterm; K: nat; T: dev_tree II HAS_PRED(N, K, T)): mterm; THAT_MT((NI: mterm): bool; PATH(N1, N, K, T))

HAS-.PRED funct ion HAS_FRED (N: mterm; K: nat; T: t ier_tree) : bool;

q NI: mterm II PATH(N1, N, K, T) IS--IN

function IS_IN (N: mterm; T: dev_tree): bool; 3 D: devunlt II IS_MEM_DVU(D, T) A EQ_MT(POST(D), N)

GET-.DEW.IN l T funct ion GET_DEVUNIT (N: mterm; T: dev t r e e II IS_IN(N, T)): devunit ;

FT_DVU((D: devunit) : bool; EQ_MT(POST(D), N)) (T) PATH

funct ion PATH (NI: mterm; N2: mterm; K: nat; T: dev_tree) : bool; 3 D: devunit I{ (IS_MEM_DVU(D, T) A EO_MT(POST(D), N2)) A i f EO_N(K, 0) then

EQ_MT(N1, N2) e l s e

D is PROPER A PATH(N1, PRE(D), K-l, T) endif

PATH2 funct ion PATH (NI: mterm;. N2: mterm; K: nat; T: dev_tree) : bool;

(3 D: devunit U IS_MEM_DVU(D, T) A EO_MT(POST(D), Sl)) A i f EQ_N(K, 0) then

EQ_MT(NI, N2) e l s e

3 DI: devunit II IS_MEM_DVU(DI, T) A D1 is PROPER A EQ_MT(N1, PRE(DI)) A PATH(POST(D1), N2, E-l, T)

endif 1SPRED

funct ion ISPRED (NI: mterm; N2: mterm; T: dev_tree) : bool; 3 K: nat II PATH(N1, N2, K, T)

IS-ROOT funct ion IS_ROOT (N: mterm; T: dev_t ree) : bool;

IS_MEM_DVU(INIT(N), T) EO-DWJ

funct ion EO_DVU (Vl: devunit ; 92: devuni t ) : bool; ((D1 i s INIT) A (D2 i s INIT) A EO_MT(POST(D1), POST(D2))) V ((D1 i s PROPER) A (D2 i s PROPER) A EO_MT(PRE(D1), PRE(D2)) A E0_MT(POST(D1), POST(D2)) A EQ_SET_CL(PREMS(D1), PREMS(D2)) A EQ_INFO(INFO(D1), INFO(D2) ) A EO_PS(REL(D1), REL(D2) ))

LEA V~S funct ion LEAVES (T: dev_tree) : se t o f mt;

SC_MT((N: mterm): bool; IS_IN(N, T) b IS_Y_MT(SONS(N, T)))

Page 273: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.2 Descr ipt ion of add i t iona l funct ions and modules 265

CO~PACTABLE funct ion COMPACTABLE (NI: mterm; N2: mterm; T: dev=tree) : bool;

-EQ_MT(NI, N2) A (ISPRED(NI, N2, T) A CObIPOSABLE(NI, PRE(GET_DEVUNIT(N2, T)), RELSYbIBOL(N2, T ), T))

ISPR-CO~P funct ion ISPR_COMP (Nl: mterm; N2: mterm; PS: pred symb; T:

dev t r ee ) : bool; ISPRED(NI, N2, T)A CObIPOSABLE(NI, N2, PS, T)

DELETE-SHBTR function DELETE_~UBTR (N: mterm; T: dev tree II IS_PROPER_NO(N, T)): dev_tree;

FILTER_DVU((D: devunit) : bool; -ISPRED(N, POST(D), T)) (T) SONS

funct ion SONS (N: mterm; T: dev_tree t[ IS_IN(N, T)): s e t o f rot; SC_MT((NI: mterm): bool;

IS_IN(N1, T) A (HAS_PRED(NI, i, T) A EQ_J~T(N, FRED(N1, i, T)))) COLLECT-,PP~I~I

function COLLECT_PREM (Nl: mterm; N2: mterm; T: dev tree il COMPACTABLE(NI, N2, T)): set of cl; if EQ_Frr(N1, PRED(N2, I, T)) then

CONDITIONS (N2, T) e l s e

UNION_CL(COLLECT_PREbI(NI, PRED(N2, i, T), T), CONDITIONS(N2, T)) endi f

C O L ~ - J ~ I F O funct ion COLLECT_INFO (NI: mterm; N2: mterm; T: dev_tree l[

CO~IPACTABLE(NI, N2, T)): info; i f EQ_bIT(NI, PRED(N2, 1, T)) then

CINFO(N2, T) e l s e

ADD_INFO(COLLECT_INFO(NI, PRED(N2, i, T), T), CINFO(N2, T)) endif

COLLECT function COLLECT (NI: mterm; N2: mterm; T: dev_tree II

CObIPACTADLE(NI, N2, T)): edge label; CEL(COLLECT_PREbI(NI, N2, T), COLLECT_INFO(NI, N2, T),

REL_CObIPOSE(NI, N2, T)) EDGE--LABEL

type edge_label = CEL record PREbIS: set of cl; INFO: info; REL: pred_symb endrecord P.EL-COMPOSE

function REL_COMPOSE (NI: mterm; N2: mterm; T: dev tree i{ COMPACTABLE(NI, N2, T)): pred symb; begin

function COMPOSE (NI: mterm; N2: mterm; PS: pred symb; T: dev tree I[ ISPRED(NI, N2, T) A COMPOSABLE(NI, N2, PS, T)): pred_symb; i f EO...MT(N1, N2) then

PS else

COMPOSE(N1, FRE(GET_DEVUNIT(N2, T)), REL_COMP(RELSYMBOL(N2, T), PS), T)

endif; CObIPOSE(NI, PRE(GET_DEVUNIT(N2, T)), RELSYbIBOL(N2, T), T)

end COHPACT I FY

funct ion ¢OMPACTIFY (Nt: mterm; N2: mterm; T: dev t r e e I! COMPACTABLE(N1, N2, T)): dev_tree;

begin ADD_DVU(PROPER(N1, N2, NEW_PREbIS, NEW_INFO, NEW_REL_SYMB), NEW_TREE)

Page 274: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

266 IV.2 DEVTREE

where c o n s t (NEW_PREMS: s e t o f c l , NEW_/NFO: i n f o , NEW_REL_SYMB: p red symb, NEW_TREE: dev t r e e ) = (COLLECT_PREM(N1, N2, T), COLLECT_INFO(N1, N2, T), REL_COMPOSE(NI, N2, T), DEL_SPATH(NI, N2, T))

end DEDUCE-J NF

function DEDUCE_INF (NI: mterm; N2: mterm; T:dev_tree II DEDUCIBLE_INF(NI, N2, T)): inference; begin

CONSTRUCT_~N(NEW_PP~MS, EMPTYSET_FO, MAKE__FO(NEW_REL_SYMB, CONCAT(MAKE_TS(TERM(NI) ), MAKE_TS (TEI~M(N2)) ) ) )

where const (NEW_PREMS: set of cl, NEW_REL_SYMB: pred_symb) = (COLLECT_PREM(NI, N2, T), REL_COMPOSE(NI, S2, T))

end UPDATE-COND

function UPDATE_COND (N: mterm; CL: clause; NEWCLS: set of cl; T: dev_tree I[ IS__IN(N, T)) : dev tree; begin

ADD_DVU(UPDATE._DVU(D, CL, NEWCLS), DEL_DVU(D, T)) where const D: devunit = GET_DEVUNIT(N, T)

end UPDATE-ALL-C

function UPDATE_ALL_C (CL: clause; NEWCLS: set of cl; T: dev tree): dev tree; FAP_DVU_DVU((D: devunit) : bool; true,

(D: devunit) : devunit; UPDATE_DVU(D, CL, NEWCLS)) (T) UPDATE--DVU

function UPDATE_DVU (D: devunit; CL: clause; NEWCLS: set of cl): devunit; if D is PROPER A IS_MEM_CL(CL, PREMS(D)) then

PROPER(PRE(D), POST(D), UNION_CL(DEL_CL(CL, PREMS(D)), NEWCLS), INFO(D), REL(D)) else

D endif

DEL-SPATH function DEL_SPATH (NI: mterm; N2: mterm; T: dev_tree II ISPRED(NI, N2, T)):

dev_t ree; begin

if EO_MT~NI, N2) t h e n

T e l s e

if -IS_Y_MT(DEL_MT(N2, SONS(PRE(D), T))) then

DEL_DVU(D, T) else

DEL_SPATH(NI, PRE(D), DEL_DVU(D, T)) endif

e n d i f where c o n s t D: d e v u n i t = GET_DEVUNIT(N2, T)

end DEDUC I BLE-J N

function DEDUCIBLE_INF (Nl: mterm; N2: mterm; T: dev_tree): bool; COMPACTABLE(N1, N2, T)

ROOT function ROOT (T: dev_tree): mterm;

THAT_MT((N: mterm) : bool; IS_ROOT(N, T)) COMPOSABLE

function COMPOSABLE (NI: mterm; N2: mterm; PS: pred_symb; T: dev tree II ISPRED(NI, N2, T)): b o o l ; EQ_MT(N1, N2) V (REL_COMPABLE(RELSYMBOL(N2, T), PS) a

COMPOSABLE(NI, PRE(GET_DEVUNIT(N2, T)), REL_COMP(RELSYMBOL(N2, T), PS), T))

Page 275: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.2 Description of additional functions and modules 267

EDES

function EDES (R: set of mt; S: set of mr; T: dev tree): set of mr; UNION_MT(R, DES(S, T))

U-.DV-MT-JNST

structure (dev_tree, set of rot, UNION_DVU_MT) = UNION(devunit, mterm, EQ_DVU, EQ_MT) U-MT-MT-J Iq S T

structure (set of at, set of at, UNION_MT_MT) = UNION(mterm, mterm, EQ_MT, EQ_MT) F I L-2ff -J NST

structure (set_of mr, FILTER_MT) = FILTER(mterm, EQ_MT) FT-MT-JNST structure (set of_mr, FT_MT) = FIL_THAT(mterm, EQ_MT) EX-MT-.[NST

structure (set_of mt, EX_MT) = EX(mterm, EQ_MT) FAP-MT-MT-JN structur~ (set_of rot, set of mr, FAP_MT_MT) = FAP(mterm, mterm, EQ__MT, EQ_MT) FAP-1) F-.MT--[ N s t r u c t u r e ( d e v _ t r e e , s e t _ o f rot, FAP_DVU_MT) = FAP(devuni t , mterm, EQ_DVU, EQ_MT) s t r u c t u r e SETWUKEY = ( s o r t i , s o r t m,

f u n c t i o n EQ..I ( i ; i ) : b o o l , f u n c t i o n EQ_M (m; a ) : b o o l , f u n c t i o n KEY (a ) : i II i n c l u d e EQUIVALENCE (a , EQ_M); i n c l u d e EQUIVALENCE ( i , EQ_I))

s e t o f re, m, EQ_SET_M, EMPTYSET_M, IS_Y_M, ADD_M, IS_MEM_M, DEL_M, ARB_M, MK_SING_M, UNION/M, ISEC_M, DIFF_M, IS_SUB_M: basedon (s, EQ_SET_M, EMPTYSET_M, IS_Y_M, ADD_M, IS_MEM_M, DEL_M, ARB_M, ME_SING_M,

UNION_M, ISEC/M, DIFF_M, IS_SUB/M) = SET(a, EQ_M); t y p e s e t o f m = T: s II

if V (V: a; W: m II IS_MEM_M(V, T) ^ IS_MEM_M(W, T)) II (EO_M(V, W) (=) EQj(KEY(V), KEY(W)))

then true else false endif

endstruct

MDEPTREE

module MDEVTREE = dev_tree, mterm, set of cl, info, pred symb, set of rp, clause, operator, id, ssort, P_ADD_TO_TREE, P_DELETE_SUBTR, P_UPDATE_CON]), P_UPDATE_ALL_C, p_COMPACTIFY:

s t r u c t u r e DEVTREE ; p r o c e d u r e P_ADD_TO_TREE (NI: a t e rm; N2: mterm; PREMISES: s e t o f c l ;

INFO: i n f o ; REL: pred_symb; va r T: d e v _ t r e e II IS_IN(N1, T) A ~IS_IN(N2, T ) ) ; T := ADD_TO_TREE(NI, N2, PREMISES, INFO, REL, T),

p r o c e d u r e P_DELETE_SUBTR (N: a t e rm; v a r T: d e v _ t r e e , IS_PROPER_NO(N, T) ) ; T := DELETE_SUBTR(N, T),

p r o c e d u r e P_UPDATE_COND (N: a te rm; CL: c l a u s e ; NEWCLS: s e t o f _ c l ; v a t T: d e v _ t r e e II ISA(N, T)); T := UPDATE_COND(N, CL, NEWCLS, T),

procedure P_UPDATE_ALL_C (CL: clause; NEWCLS: set of cl; var T: dev_tree); T := UPDATE_ALL_C(CL, NEWCLS, T),

p r o c e d u r e P_DEL_SPATH (NI: a t e rm; N2: mterm; v a r T: dev t r e e II ISPRED(N1, N2, T ) ) ; T := DEL_SPATH(NI, N2, T),

procedure P_COMPACTIFY (NI: aterm; N2: mterm; var T: dev tree 11 COMPACTABLE(NI, N2, T)) ; T := COMPACTIFY(NI, N2, T)

encbmodule

ALT-.PREMS p r o c e d u r e ALT_PREMS ( v a r D: d e v t m i t ; CLS: s e t o f c l ) ;

V := PROPER(PRE(D), POST(D), CLS, INFO(D), REL(D))

Page 276: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

268 IV.2 DEVTREE

EALT-.PREMS procedure EALT_PREMS (var D: devuni£) ;

call ALT_PREMS(D, UNION_CL(DEL_CL(CL, PREMS(D)), NEWCLS)) P-DEL-~PATH

procedure P_DEL_SPATH (NI: mterm; N2: mterm; var T: dev_tree [I ISPRED(N1, N2, T)); T := DEL_SPATH(N1, N2, T)

P-~IAPINST module (dev_tree, P_PUT, P_REM) = P_MAP(mterm, devunit, EQ_MT); module (dev tree, P_~UT, P_REM) = P_~AP(mterm, devunit, EQ_MT)

P-21PDVU INST module(devunit, ALT3REMS) = MPDEVUNIT(mterm, set of cl, info, pred symb, devunit,

PROPER, PRE, POST, PREMS, INFO, REL); P-I'IF I LTERI NS

module (dev_tree, P_MFILTER) = P_MFILTER(mterm, devunit, EQ_MT) P-21FAPINST

module (dev_tree, P_MFAP) = P_MFAP(mterm, devunit, EQ_MT) P-SETINST

module(set of rot, P_ADD_MT, P_DEL_MT, P_MK_SING_MT, PL_UNION_MT, PR_UNION_MT, PL~SEC_MT, PR_ISEC_MT, PL_DIFF_MT, PR_DIFF_MT) = P_SET(mterm, EQ_MT)

SEDES f u n c t i o n SEDES (N: mterm): boo l ;

b e g i n c o n s t D: d e v un i t = GET(N, T); D is PROPER A IS_MEM_MT(PRE(D), S)

end P-EDES

procedu re P_EDES (var R: s e t o f mt; S: s e t o f mr; T: dev t r e e ) ; R :: EDES(R, S, T)

P-PUT procedure P_PUT (I: mterm; V: devunit; var M: dev_tree);

M :: PUT(I, V, M) P-HPUT

procedure P_BPUT (I: mterm; P: procedure (var devunit); var M: dev_tree); beg in

var E: d e v u n i t := GET(I, M); call P(E) ; M := PUT(I, E, M)

end P-~EM

procedure P_REM (I: mterm; var M: dev tree); M := REM(I, M)

P-21F I LTER procedure P_MFILTER (Q: function (devunit) bool; vat M: dev_tree);

M : = MFILTER(Q) (M) P-MFAP

procedure P_MFAP (Q: function (devunit) bool; P_F: procedure (vat devunit); vat M: dev tree); M := MFAP(Q, (D: devunit): devunit;

begin vat E: devunit := D; call P_F(E); E end)(M) P-UPD

procedure P_UPD (var D: devunit); D := UPDATE_DVU(D, CL, NEWCLS)

DEL-SUB f u n c t i o n DEL_SUB (D: d e v u n i t ) : boo l ;

-IS_MEM_MT(POST(D), R) P-21K-.S I NG..21T

procedure P_MK_SING_MT (X: m; var S: set of mr); S := MK_~ING_MT(X, S)

PL-UNION~ procedure PL_UNION_MT (vat L: set of mr; R: set of mr);

Page 277: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.2 Description of additional functions and modules 269

L := UNION_MT(L, R) PR-UNION-A~

p r o c e d u r e PR_UNION_MT (L: s e t o f mt; v a t R: s e t o f m t ) ; R := UNION_MT(L, R)

PL-JSEC-ffr p r o c e d u r e PL._ISEC..MT ( v a r L: s e t o f mt; R: s e t o f mt ) ;

L := ISEC_MT(L, R) PR--ISEC-MT

p r o c e d u r e PR_ISEC_MT (L: s e t o f mr; v a r R: s e t o f mt ) ; R := ISEC_MT(L, R)

PL-~IFF . -MT p r o c e d u r e PL_DIFF_MT ( v a r L: s e t o f mt; R: s e t o f mr) ;

L := DIFF_MT(L, R) PR--DIFF_MT

procedure PR_DIFF_MT (L: set of mt; var R: set of mt); R := DIFF_MT(L, R)

MPDEVUNIT module MPDEVUNIT : ( s o r t mterm, s o r t s e t o f c l , s o r t i n f o , s o r t p r e d symb,

s o r t d e v u n i t , f u n c t i o n PROPER (mterm; mterm; s e t o f c l ; i n f o ; pred_symb):

d e v u n i t , f u n c t i o n PRE ( d e v u n i t ) : mterm, f u n c t i o n POST ( d e v u n i t ) : mterm, f u n c t i o n PHEMS ( d e v u n i t ) : s e t o f c l , f u n c t i o n INFO ( d e v u n i t ) : i n f o , function HEL (devunit): pred_symb)

devunit, ALT_PHEMS:

p r o c e d u r e ALT_PHEMS (va r D: d e v u n i t ; CLS: s e t o f c l ) ; V := PROPER(PRE(D), POST(D), CLS, INFO(D), HEL(D))

endmodule

THIS FILE CONTAINS THE DEFINITIONS OF SEVERAL STRUCTURES PROVIDING THE MAP FUNCTIONALS MFILTER, MFIL_KEYS, MFAP, MFAP_KEYS, MALL, AND MFT_KEYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MAP abstrtype MAP = (sort index, sort value, function EQI (index; index): bool II

include EOUIVALENCE (index, EOI)) map, VOID, ISVOID, PUT, GET, HEM, ISA: sort map, VOID: map; function ISVOID (map): bool; function PUT (index; value; map): map; function GET (I: index; M: map II ISA(I, M)): value; function HEM (index; map): map; function ISA (index; map): bool; laws M: map; I: index; J: index; X: value; Y: value II

ISVOID(VOID) = true, ISVOID(PUT(I, X, M)) = false, ISA(J, PUT(I, X, M)) =~

GET(J, PUT(I, X, M)) = if EQI(I, J) then X else GET(J, M) endif, ISA(J, REM(I, M)) ==)GET(J, HEM(I, M)) = GET(J, M), REM(I, VOID) = VOID, HEM(J, PUT(I, X, M)) :

if EQI(I, J) then HEM(J, M) else PUT(I, X, REM(J, M)) endif, PUT(J, Y, PUT(I, X, M)) =

Page 278: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

270 I V . 2 DEVTREE

if EQI(I, J) then PUT(I, Y, M) else PUT(I, X, PUT(J, Y, M)) endif, I S A ( I , VOID) = f a l s e , ISA(J, PUT(I, X, M)) = (EQI(I, J) v ISA(J, M)), ISA(J, REM(I, M)) = (~EQI(I, J) A ISA(J, M))

endtype

MFILTER structure MFILTER = (sort index, sort value, function EQI (index; index): bool [i

include EQUIVALENCE (index, EQI)) map, MFILTER:

basedon MAP(index, value, EQI);

function MFILTER (P: function (value) bool): function (map) map; (M: map): map; s o m e N: map I]

V I: index I[ (ISA(I, N) ¢~ ISA(I, M) A P(GET(I, M))) A (ISA(I, N) =~ (GET(I, N) = GET(I, M)))

endstruct

MFIL.-.KEYS structure MFIL_KEYS = (sort index, sort value, function EOI (index; index): bool II

include EQUIVALENCE (index, EQI)) map, set of i, MFIL_KEYS:

basedon MAP(index, value, EOl); basedon(set_of_i, ., EMPTYSET_I, IS_Y_I, ADD_I, IS_MEM_I, DEL_I, ., ., ., ., .,

.) = SET(index, EOl);

function MFIL_KEYS (P: function (index) bool): function (map) set_of_i; (M: map): set of_i; some S: set of i II V I: index II IS_MEM_I(I, S) ¢~ (ISA(I, M) A P(I))

endstruct

~FAP structure MFAP = (sort index, sort value, function EQI (index; index): bool II

include EQUIVALENCE (index, EQI)) map, MFAP:

b a s e d o n MAP(index, value, EQI);

function MFAP (P: function (value) bool; F: function (value) value): function (map) map; (M: map): map; some N: map ]I

V I: index II (ISA(I, N) ¢e~ ISA(I, M) A P(GET(I, M))) A (ISA(I, N) =~ (GET(I, N) = F(GET(I, M))))

endstruct

ffFAP.-.KEYS structure MFAP_KEYS = (sort index, sort value, function EQI (index; index): bool II

Page 279: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.2 Description of additional functions and modules 271

include EQUIVALENCE (index, EOI)) map, set_of_i, MFAP_KEYS:

basedon MAP(index, value, EQI); basedon(set_of_i, ., EMPTYSET_I, IS_Y_I, ADD_I, IS_MEM_I, DEL_I, ., ., ., ., .,

.) = SET(index, EQI);

function MFAP_KEYS (P: function (index) bool; F: function (index) index): function (map) set of i; (M: map): set_of_i; some S: set of i I!

V J: index l! IS_MEM_I(J, S) ¢=~ (~ I: index II ISA(I, M) A P(1) A EQI(J, F(1)))

endstruct

MALL structure MALL = (sort index, sort value, function EQI (index; index): bool II

include EQUIVALENCE (index, EQI)) map, MALL:

basedon MAP(index, value, EQI);

funct ion MALL (P: funct ion (value) bool) : funct ion (map) bool; (M: map): bool; V I: index II ISA(I, M) =~ P(GET(I, M))

endstruct

MFT-KEYS structure MFT_KEYS = (sort index, sort value, function EQI (index; index): bool II

include EQUIVALENCE (index, EQI)) map, MFT_KEYS:

basedon MAP(index, value, EQI);

function MFT_KEYS (P: function (value) bool): function (map) index; (M: map): index; that I: index II ISA(I, M) A P(I)

endstruct

THIS FILE CONTAINS THE DEFINITIONS OF SEVERAL MODULES PROVIDING THE PROCEDURES MFILTER, MFAP

P-MAP module P_MAP = (sort index, sort value, function EQI (index; index): bool II

include EQUIVALENCE (index, EQI)) map, P~UT, P_REM:

hasedon MAP(index, value, EQI);

procedure P_PUT (I: index; V: value; vat M: map); M := PUT(I, V, M); procedure P_HEM (I: index; var M: map); M := REM(I, M)

endmodule

Page 280: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

272 IV.2 DEVTREE

P...I'I~AP module P_t~AP = (sort index, sort value, function EOI (index; index): bool II

include EQUIVALENCE (index, EOI)) map, P_HPUT, P_REM:

basedon MAP(index, value, EOI);

procedure P_HPUT (I: index; P: procedure (var value); var M: map); begin var E: value := GET(I, M); call P(E); M := PUT(I, E, M) end;

procedure P_REM (I: index; var M: map); M := REM(I, M) endmodule

P....~FILTER module P_MFILTER = (sort index, sort value, function EQI (index; index): bool II

include EQUIVALENCE (index, EOI)) map, P_IqFILTER:

structure MFILTER(index, value, EQI);

p r o c e d u r e P_MFILTER (P: f u n c t i o n ( v a l u e ) b o o l ; v a r M: map); M := MFILTER(P)(M) endmodule

P-HFAP

module P_MFAP = (sort index, sort value, function EQI (index; index): bool II include EQUIVALENCE (index, EQI))

map, P_/qFAP:

structure MFAP(index, value, EQI);

p r o c e d u r e P_MFAP (Q: f u n c t i o n ( v a l u e ) boo l ; P_F: p r o c e d u r e ( v a r v a l u e ) ; va r M: map); M := MFAP(Q, (V: v a l u e ) : v a l u e ; b e g i n v a r V: v a l u e := V; P_F(V); V end, M)

endmodule

END FILE ~I~IAPFUNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

P.-PRIHSF.OU module P_PRIMSEQU = (sort m, function EQ_H (m; m): bool II include EQUIVALENCE(m, EQ_M))

sequ_m, m, PL_CONC_M, PR_CONC_J~: structure(sequ_m, m, EMPTYSEQU_H, MAKE_M, CONC_M) = PRIMSEQU(m, EQ_M); procedure PL_CONC_J~ (var L: sequ_m; R: sequ_m); L := CONC_M(L, R); procedure PR_CONC_)4 (L: sequ_m; var R: sequ_m); R := CONC_~4(L, R)

endmodule

P-SEOU module P_SEQU = (sort m, function EQ_/q (m; m): bool II include EQUIVALENCE(m, EQ_J~))

sequ_m, m, nat, PL_CONC_M, PR_CONC_bl, P_REST_M, P_APPEND_H, P_LEAD_M, P_STOCK_H, P_CHANGE_H, P_GET_FRONT_H, P_DEL_FRONT_M, P_GET_REAR_M, P_DEL_REAR_/d:

structure NAT;

Page 281: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.2 Description of additional functions and modules 273

structure SEQU(m, EQ_M); module (sequ_m, m, PL_CONC_M, PH_CONC_M) = P_PRIMSEQU(m, EQ_M);

procedure P_J~EST_M (var S: sequm II ~IS_Y_M(S)); S := REST_M(S); procedure P_APPEND_M (var S: sequ_m; X: m); S := APPEND_M(S, X); procedure P_LEAD_M (var S: sequm II -IS_Y_M(S)); S := LEAD_M(S); procedure P_STOCK_M (var S: sequ_m; X: m); S := STOCK_M(S, X); procedure P_CHANGE_M (var S: sequ_m; I: nat; X: m II (l le I) ^ (I le LENGTH_M(S)));

S := CHANGE_M(S, I , X); p r o c e d u r e P_GET_FHONT_M ( v a t S: s e q u m ; I : n a t ) ; S := GET_FRONT_M(S, I ) ; p r o c e d u r e P_DEL_FRONT_M ( v a r S: sequ_m; I : n a t ) ; S := DEL_FRONT_M(S, I ) ; p r o c e d u r e P_GET_REAR_M ( v a r S: s e q u m ; I : n a t ) ; S := GET~EAR_M(S, I ) ; p r o c e d u r e P_I)EL_~EAR_M ( v a r S: sequ_m; I : n a t ) ; S := DEL_REAR_M(S, I )

endmodule

THIS FILE CONTAINS THE DEFINITIONS OF SEVERAL MODULES PROVIDING THE PROCEDURES PFILTER, PFAPQ, PUNIONQ

P-.F I LTER module P_FILTER = (sort m, function EQ_M (m; m): bool U include EQUIVALENCE(m, EQ_M))

set_of re, m, P_FILTER_M:

s t r u c t u r e FILTER(m, EQ_M) ;

p r o c e d u r e P_FILTER_M (P: f u n c t i o n (m) b o o l ; v a r S: s e t of_m); S := FILTER_M(P)(S) enamodule

p_~vApQ module P_FAPQ = ( s o r t m, f u n c t i o n EQ_M (m; m): b o o l tl i n c l u d e EQUIVALENCE(m, EQ_M))

set_of_m, m, P_FAP_M_M:

structure FAP(m, m, EQ_M, EQ_.M);

procedure P_FAP_M_M (P: function (m) bool; F: function (m) m; var S: set_of_m); S := FAP_FI_M(P, F)(S)

endmodule

P-UN I ONQ module P_UNIONQ = ( s o r t m, f u n c t i o n EQ_M (m; m): b o o l II i n c l u d e EQUIVALENCE(m, EQ_M))

s e t _ o f re, m, P_UNION_M_M:

s t r u c t u r e UNION(m, m, EQ_M, EQ_M);

p r o c e d u r e P_UNION_M_M (P: f u n c t i o n (m) boo l ; F: f u n c t i o n (m) se t_of_m; v a r S: set_of_m) ; S := UNION_M_M(P, F)(S)

endmodule

Page 282: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

274 IV.2 DEVTREE

2 .3 . S p e c i f i c r u l e s

======================================================================================

s p e c i f i c a t i o n ( t t = t a u t o l o g y ) o f the r u l e s used in t he development o f d e v t r e e

TTD DESCENDANTS(N, T) ---->

DESCENDANTS(N, T) >-< DEF_DET[N_, T] A N isof_submode mterm A KIND[T~ = devtree

TTHP HAS_PRED(N, 0, T) <-> IiAS_PRED(N, 0, T) >-< DEF_DET[N, T~ A KIND[N] = mterm A KIND,IT] = devtree

TTIC INFO(COLLECT(PI, P22, P33, P4)) <-> INFO(COLLECT(PI, P_22, P__33, P4)) >-< DEF_DET[PI, P_22, P__33, P4] A ASSERT(COMPACTABLE(PI, P_/2, P_33, P4)]

TTMEM-NODES IS_MEM_MT(N, NODES(T) ) <-> IS_MEM_MT(_N, NODES (T)) >-< DEF_DET[_N, T] A KIND[N] = mterm A KIND[I] = devtree

TTPC PREMS(COLLECT(P1, P__22, P_33, P_~4)) <-> PREMS(COLLECT(PI, P__22, P_33, P4)) >-< DEF_DET[PI, P_22, P_33, P4] A ASSE~T~[COMPACTABLE(PI, P_/2, P__33, P4)]

TTP~D PRED(_N, I, T) <-> PRED(_N, I, T) >-< DEF_DET[_N, T] A KIND[N] = mterm A EIND[_T] = d e v t r e e A ASSERT[HAS_PRED(_N, 1, T)]

Page 283: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.2.3 Specific rules 275

TT~C REL(COLLECT(P1, P_22, p_33, P4)) <-> REL(COLLECT(P_!I, P Z, P_33, P__44)) >-<

DEF_DET[PI, P_~2, P__33, P_44] A ASSEET[COMPACTABLE(P__!I, P__22, P33, P_~4)]

TTEDES EDES(EMPTYSET_MT, _S, T) <->

EDES(EMPTYSET_MT, _S, T) >-<

KIND~] = set of mt ^ KIND[T] = dev tree ^ DEF_DET[S, T]

END CATALOG DEVTREE

FUNCTION REVERSAL FR

FR

function _H (PI: mterm; P2: mterm; K: nat; SN: dev_tree): bool; q _X: devunit , (IS_MEM_DVU(_X, SN) A EQ_MT(_T(_X), P2)) A if EQ_N(K, 0) then EQ_MT(PI, P2) else q Y: devunit 11 (IS_MEM_DVU(Y, SN) ^ P ^ EO_MT(T(Y), P2)) A

H(~, S_(Y), _K-l, SN) endif

<-> funct ion H (PI: mterm; P2: mterm; K: nat ; SN: dev_tree): bool;

3 _X: devunit [! (IS_MEM_DVU(_X, SN) A EO_MT(T(_X), PI)) A if EO_N(K, 0) then EO_MT(PI, P2) else 3 Y: devunit [I(IS_MEM_DVU(_Y, SN) ^ _P) A (EQ_MT(S(_Y), PI) ^

_~(T_(_Y), P2, K_-l, S~)) endif

======================================================================================

END CATALOG FR ======================================================================================

Page 284: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

276 IV.3 INFERENCE, CLAUSE, and FORMULA

3. INFERENCE, CLAUSE, and FOI~JLA

In this section, the algebraic types INFERENCE, CLAUSE, and FORMULA are treated. First, the transition from these types to computation structures (cf. 1.2) yields:

s t r u c t u r e INFERENCE = infe rence , s e t of i n f , c lause , se t o f c l , ins tance, s e t o f fo, terms, pred_symb, EQ_INF, MAKE_INF, PREMISES, CONCLUSION, EMPTYSET_INF, IS_Y_INF, ADD_INF, IS_24EM_INF, DEL_INF, ARB_INF, MK_SING_~NF, UNION_INF, ISEC_INF, DIFF_INF, IS_SUB_INF, MK_TAUT, MK_RULE, MKB.~ULE, INST_INF, CUT, CUTABLE, IMPORT, IMPORTABLE, EXPORT, EXPORTABLE, EXTEND_INF, ADD_ANTE, ADDABLE, A_IJd_A, AB_M_A, APPLY_RULE, APPLICABLE, IS_RULE, IN_TEMPLATE, OUT__TEMPLATE, REL_SYMB, CONSTR_INF:

s t r u c t u r e CLAUSE; s t r u c t u r e LANGUAGE; s t r u c t u r e PNAT; s t r u c t u r e FORMULA; s t r u c t u r e TERM; s t r u c t u r e PRED_SYMB; s t r u c t u r e INSTANCE;

type inference = MK_INF record PREMISES: set of cl; CONCLUSION: clause

endrecord;

structure (set_of_cl, set of cl, UNION_CL_CL) = UNION(clause, clause, EQ_CL, EQ_CL);

funct ion MAKE_INF (PREMS: se t_of_c l ; CONCL: c lause) : inference; MK_/NF(UNION_CL(UNION_CL(CONT_COND_CL(CONCL),

UNION_CL_CL((CL: c lause) : bool; t rue , (CL: c lause) : se t_of_c l ; CONT_COND_CL(CL)) (PREMS)), PREMS), CONCL),

funct ion EQ_~INF ( I i : inference; I2: in fe rence) : bool; EQ_SET_CL(PREMISES(I1), PREMISES(I2)) ^ EQ_CL(CONCLUSION(I1), CONCLUSION(I2));

s t r u c t u r e SET( inference , EQ_INF) ; s t r u c t u r e ( se t o f in f , s e t o f in f , FAP_INF_INF) =

FAP(inference, in ference , EO_INF, EO_INF) ; s t r u c t u r e (se t_of_fo , se t of c l , FAP_FO_CL) = FAP(formula, c lause , EQ_FO, EQ_CL); s t r u c t u r e ( se t o f_c l , s e t of c l , FAP_CL_CL) = FAP(clause, c lause , EQ_CL, EO_CL); s t r u c t u r e ( se t of in f , SC_INF) = SC(inference, EQ_INF); s t r u c t u r e ( se t_of_ i , SC_/) = SC(instance, Eq_/); s t r u c t u r e ( se t of c l , FILTER_CL) = FILTER(clause, EQ_CL); s t r u c t u r e ( se t_of_ /n f , ALL_INF) = ALL(inference, EO_/NF);

funct ion MK_TAUT (CL: c lause) : inference; MAKE_INF(blK_SING_CL(CL), CL),

funct ion MK_R~LE (CL: c lause tl bIKB_RULE(CL) ) : inference; begin

MAKE_/NF ( NEW_PREMISES, NEW_CONCLUSION) where const (NEW_PREMISES: set of cl, NEW_CONCLUSION: clause) =

(~ION_CL (~_SING_CL (CL), FAP_FO_CL((F: formula): bool; t rue , (F: formula): c lause;

MAKE_CL(EMPTYSET_FO, F) ) (ANTECENDENTS(CL)) ), MAKE_CL(EMPTYSET_FO, CONSEQUENT(CL) ) )

end,

Page 285: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3 INFERENCE, CLAUSE, and FORMULA 277

function ~4B_RULE (CL: c lause) : bool; IS_RULE_.PS(PRED_SYMB(CONSEQUENT(CL))),

function INST_INF (INF: inference; INST: instance): inference; begin

NOI~M_INF(MAKE_/NF(NEW_PREMISES, NEW_CONCLUSION)) where

const(NEW_PREMISES: set of cl, NEW_CONCLUSION: clause) = (INST_SET_CL(PREMISES(INF), INST), INST_CL(CONCLUSION(INF), INST))

end,

function NOEM INF (RULE: inference): inference; <<language-dependent>>,

funct ion CUT ( I I : inference; I2: in fe rence I I CUTABLE(I1, I2)) : inference; begin

MAKE~NF(NEW_PREMISES, CONCLUSION(12)) where const NEW_PREMISES: set of cl = UNION_CL(PREMISES(II),

DIFF_CL(PREMISES(I2), MK_SING_CL(CONCLUSION(II)))) end,

funct ion CUTABLE ( I I : inference; I2: in fe rence) : bool; IS_MEM_CL(CONCLUSION(I1), PREMISES(I2)),

funct ion IMPORT (CL: clause; INF: in fe rence I I IMFORTABLE(CL, INF)): inference; begin

const NEW_PREMISES: s e t of c l = DIFF_CL(PREMISES(INF), CL); const NEW_ANTECEDENTS: se t o f fo = UNION_CL(ANTECEDENTS(CL),

UNION_CL([~..SING_CL(CONSEQUENT(CL)), ANTECEDENTS(CONCLUSION(INF)))); const NEW_CONCLUSION: clause) =

biAEE_CL(NEW_ANTECEDENTS, CONSEQUENT(CONCLUSION(INF))); MAKE_INF(NEW_PREMISES, NEW_CONCLUSION)

end,

funct ion IMPORTABLE (CL: c lause; INF: in fe rence ) : bool ; IS_MEM_CL(CL, PREMISES(INF)) A NO_IN_CL(CL),

funct ion EXPORT (CL: clause; INF: in fe rence II EXPORTABLE(CL, INF)): inference; begin

const NEW_PREMISES: s e t o f c l = UNION_CL(PREMISES(INF), MIC_SING_CL(CL)); const NEW_ANTECEDENTS: s e t of fo =

DIFF_CL(ANTECEDENTS(CONCLUSION(INF)), MK_SING_CL(CONSEQUENT(CL))); const NEW_CONCLUSION: c lause =

MAKE_CL(NEW_ANTECEDENTS, CONSEQUENT(CONCLUSION(INF))); MAKE_INF(NEW._PREMISES, NEW_CONCLUSION)

end,

funct ion EXPORTABLE (CL: clause; INF: in fe rence) : bool; IS_SUB_CL(UNION_CL(ANTECEDENTS(CL), MK_SING_CL(CONSEQUENT(CL))),

ANTECEDENTS(CONCLUSION(INF))),

funct ion EXTEND_/NF (INF: inference; CLS: s e t o f c l ) : in fe rence ; begin

biAKE_INF(NEW_PREMISES, CONCLUSION(INF)) where const NEW_PREMISES: se t o f c l = UNION_CL(PREMISES(INF), CLS)

end,

funct ion ADD_ANTE (INF: inference; CLS: s e t o f c l ; SF: s e t o f fo I1 ADDABLE(INF, CLS, SF)): inference; begin

Page 286: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

278 IV.3 INFERENCE, CLAUSE, and FORMULA

cons t NEW_CLS: s e t of c l : FAP_CL_CL ((CL: c l ause ) : bool ; t r u e ,

(CL: c l ause ) : c lause ; EXTEND_CL(CL, SF)) (CLS); cons t NEW_PREMS: s e t of c l = UNION_CL(DIFF_CL(PNEMISES(INF), CLS), NEW_CLS); cons t NEW_CONCL: c lause) =

MAKE_CL(UNION_FO(SF, ANTECEDENTS(CONCLUSION(INF))), CONSEQUENT(CONCLUSION(INF)));

MAKE_INF (NEW_PREMS, NEW_CONCL) end,

f u n c t i o n ADDABLE (INF: in fe rence ; CLS: s e t of c l ; SF: s e t of fo ) : bool; IS_ZUB_CL(CLS, PREMISES(INF)),

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_/NF((NEW: inference): bool;

3 AX: inference; IN: instance; PHEM: clause II IS_MEM_INF(AX, AXIOMS) A EQ_INF(INST_INF(AX, IN), NEW) A IS_MEM_CL(PHEM, PREMISES(AX)) A NON_RED__I(IN, UNION_O(U_OPS_FO(CONSEQUENT(CONCLUSION(AX))),

U_OPS_FO(CONSEQUENT(PHEM)))) A EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), IN), CONSEQUENT(GOAL)) A EQ_FO(INST_FO(CONSEQUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF)))),

function A_I_M_~ (INF: inference; GOAL: clause; AXIOMS: set of inf il AB_M_A(INF, GOAL, AXIOMS)): set of cl; if IS_INSTANCE(CONCLUSION(INF), GOAL) then

begin cons t CONC: c l ause : CONCLUSION(INF); cons t ANTE: s e t of fo : ANTECEDENTS(CONC); cons t CONS: formula = CONSEQUENT(CONC); const IN: instance :

ARB__I(SC_I((I: instance): bool; NON_RED_I(I, UNION_O(U_OPS_SET_FO(ANTE), U_OPS_FO(CONS))) A EQ_CL(INST_CL(CONC,I), GOAL)));

FAP_CL_CL((CL: clause): bool; true, (CL: clause): clause; INST_CL(CL, IN)) (PREMISES(INF)

end else

begin cons t NEW_AXS: s e t of i n f = F_A_I(INF, GOAL, AXIOMS); cons t AXIOM: i n f e r e n c e = ANB__INF(NEW_AXS); cons t PNEM: c l ause =

ARB_CL(FILTER_CL((CL: c l ause ) : boo1; EQ_FO(CONSEQUENT(CL), CONSEQUENT(CONCLUSION(INF))))

(PHEMISES(AX))); const OTHEI~_PREM: set of el = DIFF_CL(PREMISES(AXIOM), MAKE_SING_CL(PREM)); const NEW_GOALS: set of cl =

UNION_CL(PREMISES(INF), UNION_CL(FAP_CL_CL((CL: c l a u s e ) : bool ; t r u e ,

(CL: c l a u s e ) : c lause ; EXTEND_CL(CL, ANTECEDENTS(GOAL))) (OTHER_PI~EMS),

UNION_CL(FAP_FO_CL((F: formula) : bool; t r ue , (F: formula) : c lause ; MAKE_CL(ANTECEDENTS(GOAL), F))

(ANTECEDENTS(CONCLUSION(INF))), FAP_FO_CL((F: formula) : bool; t r ue , (F: formula) : c lause ;

MAKE_CL(ANTECEDENTS(GOAL), F)) (ANTECEDENTS(CONCLUSION(AXIOM))))));

NEW_GOALS end

endif,

Page 287: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3 INFERENCE, CLAUSE, and FOI~JLA 279

function AB_M_A (INF: inference; GOAL: clause; AXIOMS: set of inf): bool; (IS_INSTANCE(CONCLUSION(INF), GOAL) V ~IS_Y_INF(F_ju_I(INF, GOAL, AXIOMS))),

f u n c t i o n APPLY_RULE (RULE: i n f e r e n c e ; TEI~4S: t e rms II APPLICABLE(RULE, TERMS)): i n f e r e n c e ; b e g i n

c o n s t INSTANCES: s e t o f i = MATCH_TS(IN_TEMPLATE(RULE), TERMS); c o n s t IN_TEMPLATE: t e rms = LHS(CONSEOUENT(CONCLUSION(RULE))); INST_INF(RULE, ARB__I(INSTANCES))

end,

f u n c t i o n APPLICABLE (RULE: i n f e r e n c e ; TERMS: t e r m s ) : b o o l ; IS_~ULE(INF),

function IS_RULE (INF: inference): bool; begin

IS_RULE_FOI~MULA(CONSEQUENT(CL)) A IS_Y_FO(ANTECEDENTS(CL)) where const CL: clause = CONCLUSION(INF)

end,

function IN_TEMPLATE (RULE: inference II IS_RULE(RULE)): terms; LHS(CONSEOUENT(CONCLUSION(RULE))),

function OUT_TEMPLATE (RULE: inference II IS_RULE(RULE)): terms; RHS(CONSEOUENT(CONCLUSION(RULE))),

f u n c t i o n REL_SYMB (RULE: i n f e r e n c e II IS_RULE(RULE)): pred_symb; PRED_SYMB(CONSEQUENT(CONCLUSION(RULE))),

function CONSTR_INF (SC: set of_cl; SF: set offo; F: formula): inference; MAKE_INF(SC, MAKE_CL(SF, F))

e n d s t r u c t s t r u c t u r e CLAUSE = c l a u s e , s e t o f c l , f o rmu la , s e t o f fo , i n s t a n c e , EO_CL, MAKE_CL, ANTECEDENTS, CONSEQUENT, EQ_SET_CL, EMPTYSET_CL, IS_Y_CL, ADD_CL, IS__MEM_CL, DEL_CL, ARB_CL, MK_SING_CL, UNION_CL, ISEC_CL, DIFF_CL, IS_SUB_CL, NO_IN_CL, IS_INSTANCE, INST_CL, INST_SET_CL, EXTEND_CL, CONT_COND_T, CONT_COND_TS, CONT_COND_AS, CONT_COND_CL:

s t r u c t u r e FORMULA; s t r u c t u r e TERM; s t r u c t u r e PRED-SYMB; s t r u c t u r e INSTANCE;

t y p e c l a u s e = t~KE_CL r e c o r d ANTECEDENTS: s e t o f fo ;

CONSEQUENT: fo rmula e n d r e c o r d ;

function EQ_CL (CI: clause; C2: clause): bool; EO_SET_FO(ANTECEDENTS(CI), ANTECEDENTS(C2)) A EO_FO(CONSEOUENT(CI), CONSEQUENT(C2)) ;

s t r u c t u r e SET(c lause , EO_CL) ; s t r u c t u r e ( s e t _ o f _ c l , s e t _ o f c l , FAP_CL_CL) = FAP(c lause , c l a u s e , EO_CL, EO_CL); s t r u c t u r e ( s e t _ o f _ c l , ALL_CL) = ALL(clause , EO_CL); s t r u c t u r e ( s e t o f c l , s e t o f c l , UNION_CL_CL) = UNION(clause, c l a u s e , EO_CL, EO_CL);

Page 288: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

280 IV.3 INFERENCE, CLAUSE, and FORMULA

function NO_IN_CL (CL: clause): bool; NO_/N_SET_FO(UNION_FO(ANTECEDENTS(CL), CONSEOUENT(CL))),

function IS_INSTANCE (CLI: clause; CL2: clause): bool; 3 IS: instance II EQ_CL(INST_CL(CLI, IS), CL2),

function INST_CL (CL:clause; I: instance): clause; begin

MAKE_CL(NEW__ANTECEDENTS, INST_FO(CONSEQUENT(CL), I)) where const NEW_ANTECEDENTS: set of fo = INST_SET_FO(ANTECEDENTS(CL), I)

end,

function INST_SET_CL (CLS: set of cl; I: instance): set of cl; FAP_CL_CL((CL: clause): bool; true,

(CL: clause): clause; INST_CL(CL, I)) (CLS),

funct ion EXTEND_CL (CL: clause; SF: s e t o f fo) : c lause; MAKE_CL(UNION_FO(ANTECEDENTS(CL), SF),CONSEQUENT(CL)),

funct ion CONT_COND_T (T: term): se t_of_c l ; << language dependent>>,

function CONT_COND_TS (TS: terms): set_of_~l; if IS_Y_TS(TS) then EMPTYSET_CL else UNION_CL(CONT_COND_T(FIRST_TS(TS)), CONT_COND_TS(REST_TS(TS))) endif,

funct ion CONT_COND_AS (AS: args) : se t_of_c l ; i f IS_Y_AS(AS) then EMPTYSET_CL e l s e UNION_CL(CONT_CONDTS(FIRST_TS(AS)), CONT_COND_AS(REST_AS(AS))) endi f ,

funct ion CONT_COND_CL (CL: c lause) : se t_of_c l ; UNION_CL(CONT_COND_AS(ARGS(CONSEOUENT(CL))),

UNION_CL_CL((CL: clause): bool; true, (CL: clause): set_of__cl; CONT_COND__AS(AI~GS(CL))) (ANTECEDENTS(CL)))

ends t ruc t s t r u c t u r e FOI~IULA = formula, se t of fo, pred_symb, args, terms, ins tance , se t of_o, EO_.FO, MAKE_FO, MAKABLE__FO, PRED_SYMB, ARGS, EO_SET_FO, EMPTYSET_FO, IS_Y_FO, ADD_FO, IS_MEM_FO, DEL_/D, ARB_FO, MK_SING__FO, UNION_FO, ISEC_FO, DIFF_FO, IS_SUB_FO, NO__IN_SET_FO, U_OPS_FO, U_OPS_SET_FO, IS_RULE_FO, LHS, RHS, INST_.FO, INST__SET_FO:

structure TERM; structure PRED_SYMB; structure INSTANCE;

funct ion MAKABLE_FO (PRED_SYMB: pred_symb; ARGS: args) : boo1; COMPATIBLE_PS ( PRED_SYMB, ARGS),

type formula : MAKE_FO record PRED__SYMB: pred_symb;

ARGS: args I~ MAKABLE_FO(PRED_SYMB, ARGS) endrecord;

funct ion EO_FO (FI: formula; F2: formula): bool; EO_PS(PRED_SYMB(FI), PRED_SYMB(F2)) A EQ_AS(ARGS(FI), ARGS(F2)) ;

Page 289: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3 INFERENCE, CLAUSE, and FORMULA 281

structure SET(formula, EQ_FO) ; structure (set_of_fo, set_of_fo, UNION_FO_FO) = UNION(formula, formula, EO_FO, EO_FO); structure (set_of fo, set_of_o, UNION_FO_O) = UNION(formula, operator, EO_FO, EO_O); structure (set_of_fo, set_of_fo, FAP_FO_FO) = FAP(formula, formula, EQ_20, EQ_20); structure (set_of_fo, ALL_FO) = ALL(formula, EQ_FO);

function NO_IN_FO (F: formula): bool; NO_IN_AS(~aaS(F)),

function NO_IN_SET_FO (FS: set_of_fo): bool; ALL_FO((F: formula): bool; true, (F: formula): bool; NO_IN_riO(F)),

func t ion U_OPS_FO (F: formula): se t_of o; U_OPS_AS(ARGS(F)),

function U_OPS_SET30 (FS: set of_fo): set_of_o; UNION_FO_O((F: formula): bool; true,

(F: formula): set_of_o; U_OPS_FO(F)) (FS),

function IS_BULE_FO (F: formula) : bool; IS_RULE~S (P~D~'~-~B (F) ),

function LHS (F: formula II IS_RULE_FO(F)): terms; SEL_AS(ARGS(F), 1),

function P, HS (F: formula II IS_RULE_FO(F)): terms; SEL_AS(A~S(F), 2),

function INST_FO (F: formula; I: ins tance) : formula; MAKE_FO(P~EV~SgS(F), INST_AS(ARCS(F), I)),

func t ion INST_SET_FO (FS: set_of_fo; I: ins tance) : s e t _ o f f o ; FAP_FO_FO((F: formula): bool; t rue ,

(F: formula): formula; INST_FO(F, I ) ) (FS)

endstruct The operations which require special individual development are "is_instance" in CLAUSE, and "filter_and_instantiate" and "apply_inf_modulo_axioms" in INFERENCE. In their development several new functions (for matching formulas, set of formulas and clause) are introduced. Their dependence structure is shown by the following graph

apply_inf_modulo_axioms

match_cl f i l t e r _ a n d _ ~ n s t a n t i a t e

m a t c ~ ~ /

match_fo

match_as

The development of match_as, their common base, is given in Section 4. All other operations are either non-recursive or expressed in terms of the functionals given in Section 1.2. They can be developed schematically.

Page 290: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

282 IV.3 INFERENCE, CLAUSE, and FOI~MULA

3.1. Description of auxiliary functions

In the development of the above-mentioned operations, which lift the matching operation from arguments to formulas, clauses, and inferences, a few further auxiliary functions are introduced.

THIS CATALOG CONTAINS AUXILIARY UNITS WHICH ARE NEEDED IN THE DEVELOPMENTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MATCH-EL funct ion MATCH_CL (CLI: clause; CL2: clause) : se t_of_i ;

SC_/((I: ins tance) : bool; NON_BED_I(I, U_OPS_CL(CL1)) ^ EO_CL(INST_CL(CL1, I ) , CL2))

MATCH-SET-.FO function MATCH_SET_FO (FSI: set of fo; FSZ: set_offo): set_of_i;

SC_/((I: instance): bool; NON_RED_I(I, U_OPS_SET_F0(FSI)) A EQ_SET_FO(INST_SET_FO(FSI, I), FS2))

SUB-MATCH funct ion SUB_MATCH (FSI: set_of_fo; FS2: set_of_fo): se t_of i ;

SC_/((IN: ins tance) : bool; NON_~ED-/(IN, U_OPS_SET_FO(FSI)) A IS_SUB_FO(INST_.SET_FO(FSI, IN), FS2))

MATCH-FO function MATCK_FO (FI: formula; F2: formula): set_of_i;

SC_/((I: instance): bool; NON_RED_/(I, U_OPS_FO(FI)) A EQ_FO(INST_FO(FI, I), F2))

MATCH-AS funct ion MATCH_AS (ASI: args; AS2: args) : set_of i ;

SC_/((I: ins tance) : bool; NON_RED_I(I, U_OPS_AS(AS1)) A EQ_AS(INST_AS(AS1, I ) , AS2))

JOINABLE function JOINABLE (I: instance; J: instance): bool;

V O: operator H ISDEF(I, O) A ISDEF(J, O) ~) EQ_TS(GET(I, 0), GET(J, O))

JOIN--[--I funct ion JOIN_/_/ (I : ins tance; J: ins tance li JOINABLE(I, J ) ) : ins tance;

tha t IN: ins tance , V O: operator II (ISDEF(IN, O) ¢~ ISDEF(I, O) V ISDEF(J, O)) A (ISDEF(I, O) ~EQ_TS(GET(IN, O), GET(I, O))) A (ISDEF(J, O) ~ EQ_TS(GET(IN, O)~ GET(J, O)))

JOIN--I -S~T function JOIN_I_SET (I: instance; IS: set_of_i): set of_i;

FAP_I_I((J: instance): bool; JOINABLE(I~ J), (J: instance): instance; JOIN_I_/(I~ J)) (IS)

JOIN--S~-S~ function JOIN_SET_~ET (IS: set of_i; J5: set of_i): set_of_i;

UNION-/-/((I: instance): bool; true, (I: instance): set_of_i; JOIN_I_SET(I, JS)) (IS)

U-OPS-CL func t ion U_OPS_CL (CL: c lause) : se t_of o;

UNION_O(U~OPS_SET_FO(ANTECEDENTS(CL) ), U_OPS_FO(CONSEQUENT(CL) ) )

Page 291: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3,1 Description of auxiliary functions 283

BASE-SET-FO function BASE_SET_FO (FSI: set of fo; FS2: set of fo): set_of_i;

some R: set of i [[ V Z: instance [I IS_MEM_I(Z, R) ¢:) V O: operator II ISDEF(Z, O) :~

IS_MEM_O(O, U_OPS_SET_FO(FSI)) A B (F2: formula II IS.MEM_FO(F2, FS2)) il HAS_SUBT(F2, GET(Z, O))

BASE-$D function BASE_FO (FI: formula; F2: formula): set_of_i;

BASE_SET_FO (MK_S ING_FO (FI), MK_S ING_FO (F2))

BASE.EL function BASE_CL (CL: clause; D: clause): set of i;

BASE_SET_.FO(ADD_.FO(CONSEQUENT(C), ANTECEDENTS(C)), ADD_FO(CONSEQUENT(D), ANTECEDENTS(D)))

ALL-.PO function ALL_FO (P: function (formula) bool; Q: function (formula) bool):

function (set of_fo) bool; (S: set_of fo): bool; V (X: formula II IS_MEM_/O(X, S) a P(X)) II Q(X)

ALL.L) funct ion ALL_O (P: funct ion (operator) bool; Q: funct ion (operator) bool) :

funct ion (set_of_o) bool; (S: se t_of_o): bool; V (X: opera tor II IS_MEM_O(X, S) A P(X)) il Q(X)

EX--INF funct ion EX_INF (P: funct ion ( inference) bool; Q: funct ion ( inference) bool) :

funct ion (set of inf ) bool; (S: s e t o f i n f ) : bool; 3 (×: in fe rence II IS_MEbtINF(X, S) A P(X)) II Q(X)

EX-C L function EX_CL (P: function (clause) bool; Q: function (clause) bool):

function (set of cl) bool; (S: s e t_o f_c l ) : bool; 3 (X: c lause II IS_J~EM_CL(X, S) A P(X)) II Q(X)

EX--I function EX_I (P: function (instance)bool; Q: function (instance)bool):

function (set_of_i) bool; (S: set_of_i): bool; 3 (X: instance II IS_MEM_I(X, S) A P(X)) li Q(X)

FAP..CL-CL

function FAP_CL_CL (P: function (clause) bool; F: function (clause) clause): function (set_of_cl) set of cl; (S: set_of_cl): set of cl;

begin (vat VR: s e t of c l , var PS: set_of_c1) := (EMPTYSET_CL, S); var VZ: clause; while -IS_Y_CL(VS) loop

vz : = ARB_CL(VS) ; if P(VZ)

then VR := ADD_CL(F(VZ), VR) else skip

endif ; VS := DEL_CL(VZ, VS)

endl oop; VR

end

Page 292: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

284 IV.3 INFERENCE, CLAUSE, and FORMULA

FAP-FO-CL f u n c t i o n FAP_FO_CL (P: f u n c t i o n ( f o r m u l a ) b o o l ; F: f u n c t i o n ( formula) c l a u s e ) :

f u n c t i o n ( s e t o f fo) s e t o f c l ; (S: s e t _ o f f o ) : s e t o f _ c l ;

beg in (va t VR: s e t o f c l , v a t VS: s e t o f_ fo ) := (EMPTYSET_CL, S); v a t VZ: formula; while -IS_Y_FO(VS) loop

vz := A~_YO(VS) ; i f P(VZ)

then VR : : ADD_CL(F(VZ), VR) e l s e s k i p

end£ f ; VS :--DEL_FO(VZ, VS)

endloop; VR

end

FAP--?/--M f u n c t i o n FAP_N_M (P: f u n c t i o n (m) boo l ; F: f u n c t i o n (m) m):

f u n c t i o n ( s e t _ o f m) set_of_m; (S: set_of_m): set_of_m;

beg in (var VR: set_of_m, v a r VS: s e t _ o f m) := (EMPTYSET_M, S); var VZ: m; while ~IS_Y_M ( VS ) loop

vz : = ARB_M(VS) ; i f P(VZ)

then VR := ADD._.M(F(VZ), VR) else skip

end i f ; VS := DEL_~I(VZ, VS)

endloop; VR

end

EQ-/ f u n c t i o n EQ_I ( I i : i n s t a n c e ; I2: i n s t a n c e ) : boo l ;

V O: o p e r a t o r It (ISDEF(I1, O) ¢~ ISDEF(I2, 0) ) A (ISDEF(I1, O) ~ EO...TS(GET(I1, 0 ) , GET(I2, 0 ) ) )

NON-.~D--I f u n c t i o n NON_RED_I ( I : i n s t a n c e ; SO: s e t _ o f _ o ) : boo l ;

V O: o p e r a t o r [I ISDEF(I, O) ¢~ IS_MEM_O(O, SO)

IS-.IN.ST function IS_INSTANCE (CLI: clause; CL2: clause): bool;

~ IS_Y_I ( MATCH_CL (CL1, CL2))

END CATALOG UNITS

Page 293: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of functions 285

3 .2 . Developments o f f u n c t i o n s

START SKERN

~com~ent<

Development of function

MATCII_FO

>4

~install unit <units aux al: match_fo>~

~copy <funct match__fo>~

function MATC~ (FI: formula; F2: formula): set of i; SC_I((I: instance): bool; NON_RED__I(I, U_OPS__FO(FI)) A EQ_FO(INST_.FO(FI, I), F2))

~comm~ent<

L UNIT match_fo .........

LEVEL descriptive, pre-algorithmic, set-comprehension over infinite domain instance

GOAL removal of the set-comprehension over infinite domain, reduction of match_fo to match__as (cf. Section 4)

>4

~install <structure formula> unit <formula structural: formula>.

~co~maent<

GOAL r e d u c t i o n o f m a t c h _ f o ( f l , f2) to emp tyse t_ i in t h e ca se where t he p r e d i c a t e symbols o f f l and f2 d i f f e r

ACTIONS - unfold of inst_fo and eq_fo - simplifications - introduction of case distinction - simplifications of then- and else-branch - distribution of set-comprehension over if__-then-else

>4

~transf in <funct match_fo> with rule <f: uff2>*

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD_FF .funct inst_fo.

~transf in <flmct match_fo> with rule <f: uff2>4

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD__FF ~funct eq_fo4

Page 294: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

286 IV.3 INFERENCE, CLAUSE, and FOI~MULA

. t r a n s f in <funct match_fo> with rule <formula: psi_m>~

func t ion MATCH_20 (Fh formula; F2: formula): se t_of i ; SC_I((I: ins tance) : bool;

NON_RED_I(I, U_OPS_J~O(FI)) A (EQ_PS(~PRED_SYMB(MAEE_FO(PEED_SYMB(F1), INST_AS(ARGS(F1), I)))~ , PRED_SYMB(F2)) A EQ_AS(ARGS(MAKE_FO(PRED_SYMB(FI), INST_AS(ARGS(F1), I))), ARGS(F2))))

CONDITION FULFILLED? DEFINED[INST_AS(ARGS(FI), I)~ ~y4

~transf in <funct match_fo> with rule <formula: asi_m>4

function MATCH_FO (FI: formula; F2: formula): set_of i; SC_I((I: instance): bool;

NON_RED_I(I, U_OPS_FO(FI)) A (EQ_PS(PRED_SYMB(FI), PRED_SYMB(F2)) ^ EQ_AS(~AEGS(MAKE_FO(PRED_SYMB(FI), INST_AS(ARGS(F1), I ) ) )> , ARGS(F2))))

CONDITION FULFILLED? DEFINED[PRED_SYMB(FI)~ ~y4

~transf in <fanct match_fo> with rule <f: uffl>~

GIVE NAMED/MAWEED UNIT FOR PARAMETER: statD F ~funct u_ops_fo.

.transf in <fanct match_fo> with rule <c: csi_qb> inverted4

function MATCH_FO (FI: formula; F2: formula): set_of_i; SC_I((I: instance): bool;

NON_~ED_I(I, U_OPS_AS(ARGS(FI))) A ~(EQ_PS(PRED_SYMB(FI), PRED_SYMB(F2)) A EQ_AS(INST_AS(ARGS(FI), I), ARGS(F2)))) )

GIVE NAMED/MARKED UNIT FOR PARAMETER: C -in <funct match_fo>4

func t ion MATCH_FO (FI: formula; F2: formula): se t_of_i ; SC_I((I: ins tance) : bool;

NON~D_I(I, U_OPS_AS(ARGS(FI))) A (~EO_PS(PRED_SYMB(FI), PRED_SYMB(F2))> A EQ_AS(INST_AS(ARGS(FI), I), ARGS(F2))))

CONDITION FULFILLED? EIND[EQ_PS(PRED_SYMB(FI), PRED_SYMB(F2))~ = bool

CONDITION FULFILLED? DEFINED~EQ_.PS(PRED_SYMB(FI), PRED_SYMB(F2) ) ~y4

~transf in <funct match_fo> with rule <c: csu_ttr_efl>~

function MATCH_FO (Fl: formula; F2: formula): set_of i; SC_/((I: instance): bool;

NON_RED_I(I, U_OPS_AS(ARGS(FI))) ^ ~if EO_PS(PRED_,SYMB(F1), PRED_SYMB(F2)) then

EQ__PS(PRED_SYMB(FI), PRED_.SYMB(F2)) A EQ_AS(INST_AS(ARGS(FI), I), ARGS(F2)) else

EQ_PS(PRED_SYMB(FI), PRED_SYMB(F2)) ^ EQ_AS(INST_AS(ARGS(FI), I), ARGS(F2)) endif~ )

Page 295: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of funct ions 287

.transf in <funct match_fo> with rule <b: si_tra>4 *transf in <funct match_fo> with rule <b: si_fla>~

.transf in <funct match..fo> with rule <b: id_ac_te>4

funct ion btATCtI_FO (FI: formula; F2: formula): se t_of_i ; SC_I((I: instance) : bool;

.~ON_.RED_I(I, U_OPS_AS(ARGS(F1))) ^ i f EQ_PS(PRED_SYMB(FI), PRED_SYMB(F2)) then

EQ_AS(INST_AS(ARGS(F1), I ) , ARGS(F2)) e lse

fa l se endif~ )

~transf in <funct match_fo> with rule (u_i: sdp_c>*

funct ion MATCH_FO (FI: formula; F2: formula): se t of i ; (SC__I((I: ins tance) : bool;

if EO_PS(PRED_SYMB(FI), FRED_SYMB(F2)) then

NON_RED_I(I, U_OPS_AS(ARGS(FI))) ^ EO__AS(INST_AS(ARGS(FI), I), ARGS(F2)) else

NON_RED_I(I, U_OPS_AS(ARGS(FI))) A false endif))

CONDITION FULFILLED? DETERMINATE[EO_PS(PRED_SYMB(FI), PRED_ZYMB(F2))] ~y4

~transf in <funct match_fo> with rule <b: si_afl>4

~transf in <funct match_fo> with rule <u_i: ssp_.fl>4

funct ion blATCH_FO (FI: formula; F2: formula): se t of i; if EO_~PS(PRED_SYMB(FI), PRED_SYMB(F2)) then

SC_I((I: instance): bool; NON_RED_I(I, U_OPS_AS(ARGS(FI))) A EQ_.AS(INST_AS(ARGS(FI), I), ARGS(F2)))

else (SC_/((I: instance): bool; false))

endif

~conmaent< j : ...... GOAL reduction of match_fo to match_as in case both predicate symbols of the

agree

I AcTI°Ns - f°Id by match-as I

>4

~transf in <funct match._fo> with rule <b: ch_a_sa>*

~install unit <units aux al: match_as>4

~transf in <funct match_fo> with rule <f: ff2>*

Page 296: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

288 IV.3 INFERENCE, CLAUSE, and FORMULA

function MATCH_FO (FI: formula; F2: formula): set_of_i; i f EQ_PS(PRED_SYMB(F1), PRED_SYMB(F2)) then

(SC_/((I: instance): bool; NON_RED_/(I, U_OPS_AS(ARGS(FI))) A EQ_AS(INST_AS(ARGS(FI), I), ARGS(F2))))

else EMPTYSET_I

endif

GIVE NAMED/MAI~KED UNIT FOR PARAMETER: statDF ~funct match_as4 CONDITION FULFILLED? DEFINED[SC_I ( ( I: instmlce) : bool;

NON_~ED..I(I, U_OPS_AS(ARGS(FI))) A EQ_AS(INST_AS(AI~GS(FI), I), ABGS(F2)))~ =~ DEFINEDEMATCH_AS(AHGS (F1), AHGS(F2) ) ]

~y4

~copy <funct match_fo>4

function MATCH_FO (FI: formula; F2: formula): set_of_i; if EQ_PS(PRED_SYMB(FI), PRED_SYMB(F2)) then

MATCH_AS(ARGS(FI), ARGS(F2) ) else

EMPTYSET_/ endif

~stop4

END SKEP~ START S KE P~N

~con~ment<

Development of function

SUB_MATCH

>4

~install unit <units aux al: sub_match>~

~copy <funct sub_match>4

function SUB_MATCH (FSI: set_offo; FS2: set of fo): set_of_i; SC_I((IN: instance): bool;

NON_RED_I(IN, U_OPS_SET_FO(FSI)) A IS_SUB_FO(INST_SET_FO(FSI, IN), FS2))

~comment<

I UNIT sub_match

I LEVEL descriptive, pre-algorithmic, set-comprehension over infinite domain instance

Page 297: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of functions 289

GOAL removal of the set-comprehension over infinite domain, reduction of sub_match to match_to by expressing the instances specified by suh_match(fsl, fs2) as the (appropriate) finite join of instances under which members fl and f2 of fsl and fs2, respectively, match

>4

.comment<

GOAL r e d u c t i o n o f s u b _ m a t c h ( f s l , f s 2 ) to e s s e n t i a l l y m k _ s i n g _ i ( v o i d ) i n t h e I c a s e where f s l i s t h e empty s e t f

ACTIONS - introduction of case-distinction - unfold of inst_set_fo - algebraic simplifications - unfold of non_red_i and u_ops_set_f0 - algebraic simplifications - fold by eq_i

>4

*transf in <funct sub_match> with rule <m/o: in_c>4

f u n c t i o n SUB_MATCH (FSI: s e t o f t o ; FS2: s e t o f t o ) : s e t _ o f _ i ; (SC_I ( ( IN: i n s t a n c e ) : boo l ;

NON_BED_I(IN, U_OPS_SET_FO(FSI)) A IS_SUB_FO(INST_SET_FO(FSI, IN), FS2)))

GIVE NAMED/MARKED UNIT FOR PARAMETER: S .in <funct sub_match>4

function SUB_MATCH (FSI: set of to; FS2: set of to): set of_i; SC~((IN: instance): bool;

NON_RED_I(IN, U_OPS_SET_FO((FSI) )) A IS_SUB_FO(INST_SET_FO(FSI, IN), FS2))

CONDITION FULFILLED? DEFINED[FSI] my4

CONDITION FULFILLED? KIND[FSI] = set of fo my4

~ i n s t a l l < s t r u c t u r e formula> u n i t < formula s t r u c t u r a l : formula>~

~name in <funct sub_match> with4

f u n c t i o n SUB_.MATCH (FSI: s e t o f to ; FS2: s e t _ o f _ t o ) : s e t _ o f _ i ; i f IS_Y_FO(FS1) t h e n

(SC_I((IN: instance): b o o l ; NON_RED_/(IN, U_OPS_SET_FO(EMPTYSET_FO) ) A IS_ZUB_FO(INST_SET_FO(EMPTYSET_FO,

IN), FS2))) e l s e

SC_/( ( IN: i n s t a n c e ) : boo l ; NON_BED_I(IN, U_OPS_SET_FO(FSI)) ^ IS_SUB_FO(INST_SET_FO(FSI, IN), FS2))

e n d i f

GIVE NAME FOR NEXT UNIT: ~tb4

* t r a n s f in <expr tb> w i t h r u l e <f: u f f2>~

Page 298: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

290 IV.3 INFERENCE, CLAUSE, and FORMULA

SC_I((IN: instance): bool; NON_~ED_I(IN, U_OPS_SET_FO(EMPTYSET_FO) ) ^ IS_SUB_FO(~INST_SET_FO(E~PPTYSET30,

IN)>, FS2) )

CONDITION FULFILLED? DEF_DET~EMPTYSET_FO, IN] i.y.

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~ftmct inst_set_.fo-

~transf in <expr tb> with rule <u_.fo__fo: gss_e>~

SC_~((IN: instance) : bool; NON_RED_l( IN, U_OPS_SET_FO(EbIPTYSET_FO) ) A IS_.SUB_FO( ~FAP_FO_FO( (F: formula) : bool;

true, (F: formula): formula; INST_FO(F, IN))(EMPTYSET_FO)>, FS2))

~transf in <expr tb> with rule <m_fo: ssi_el>,

SC_I((IN: instance): bool; NON_RED_l( IN, U_OPS_SET_.FO(EMPTYSET_FO) ) A ~IS_SUB_FO(EbIPTYSET_FO, FS2)> )

CONDITION FULFILLED? KIND[FS2] = set of fo ~y~

CONDITION FULFILLED? DEFINED[FS2~ ~y4

~transf in <expr tb> with rule <b: si_atr>,

~install unit <units aux al: non_red_i>4

~transf in <expr tb> with rule <f: uff2>4

SC_I((IN: instance): bool; ~NON_RED_I(IN, U_OPS_SET_FO(EMPTYSET_FO))> )

CONDITION FULFILLED? DEF_DET[IN, U_OPS_SET_FO(EbIPTYSET_FO)~

GIVE NAMED/MARKED UNIT FOR pARAMETER: statDF ~funct non_red_i.

~transf in <expr tb> with rule <f: uffl>4

SC_I((IN: instance); bool; V O: operator I| ISDEF(IN, O) ¢0 IS_MEbI_O(O, ~U_OPS_SET_~O(EMPTYSET_FO)> ))

CONDITION FULFILLED? DEF_DET[E~PTYSET_FO]

GIVE Nb24ED/~RKED UNIT FOR PARAMETER: statDF ~funct u_ops_set_fo,

~transf in <expr tb> with rule <u_fo_o: uss_e>,

SC_I((IN: instance) : bool; V O: operator H ISDEF(IN, O) ¢=~ IS_MEbI_O(O, ~qJNION_FO_O((F: formula): bool; true,

(F: formula) : set of o; U_OPS_FO(F)) (~qPTYSET_FO)>))

~transf in <expr tb> with rule <m_o: msi_e>4

SC__I((IN: instance): bool; %/ O: operator H ISDEF(IN, O) ¢~ (IS_MEM_O(O, EMPTYSET_O)))

Page 299: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV .3 .2 Developments o f functions 291

CONDITION FULFILLED? DEFIeD[O] ~y4

CONDITION FULFILLED? KIND[O] = operator ~y4

~treunsf in <expr tb> with rule <b: si_~atr> inverted4

~install <expr e>: <eq_ts(get(in, o), get(void, 0))>4

~transf in <expr tb> with rule <b: si_flsi> inverted4

SC_I((IN: instance): bool; V O: operator {I ISDEF(IN, O) ¢~ false A (true))

GIVE NAMED/MARKED UNIT FOR PARAMETER: P ~expr e4 CONDITION FULFILLED? KIND~EO_TS(GET(IN, 0), GET(VOID, 0))] = bool ~y4

~transf in <expr tb> with rule <instance: dsi_v> inverted4

SC_I((IN: instance): bool; V O: operator {I ISDEF(IN, O) ¢~ (false)A ((false) :~ EQ_TS(GET(IN, 0), GET(VOID,

0))))

GIVE NAMED/MARKED UNIT FOR PARAMETER: 0 ~in <expr tb>~

SC_/((IN: instance): bool; V O: operator II ISDEF(IN, (0)) ¢~ false A (false ~ EO_TS(GET(IN, 0), GET(VOID,

o))))

CONDITION FULFILLED? DEFINED[O~ ~y4

CONDITION FULFILLED? KIND,O, operator] ~y4

GIVE NAMED/MARKED UNIT FOR PARAMETER: 0 ~in <expr tb>4

SC_I((IN: instance): bool; V O: operator I{ ISDEF(IN, (0)) ¢~ false A (false ~ EQ_TS(GET(IN, 0), GET(VOID,

o))))

CONDITION FULFILLED? DEFINED[O~ ~y4

CONDITION FULFILLED? KIND[O, operator] my4

~transf in <expr tb> with rule <b: su_eqsar>4

SC_I((IN: instance): bool; V O: operator H (ISDEF(IN, O) ¢~ ISDEF(VOID, O) ~ (ISDEF(VOID, O) :~ EQ_TS(GET(IN,

0), GET(VOID, 0)))) )

CONDITION FULFILLED? DETEI~MINATE[ISDEF(VOID, 0), ISDEF(IN, 0)2 my4

~install unit <units aux al: eq_i>-

Page 300: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

292 IV.3 INFERENCE, CLAUSE, and FORMULA

.transf i n <expr tb> with r u l e <f: ff2>4

SC_I((IN: i n s t a n c e ) : bool; O: o p e r a t o r {{ ISDEF(IN, O) ¢~ ISDEF(VOID, O) A (ISDEF(IN, O) =~ EO_TS(GET(IN, 0),

GET(VOID, O ) ) ) ) )

GIVE NAMED/MAIT_KED UNIT FOR PARAMETER: s t a t D F - f u n c t e q _ i . CONDITION FULFILLED? DEFINED~4 O: operator II ISDEF(IN, O) ¢:) ISDEF(VOID, O) A (ISDEF(IN, O) =~

EO_TS(GET(IN, 0), GET(VOID, 0)))] =:) DEFINED[EQ_I(IN, VOID)]

.transf in <expr tb> with rule <m_i: msi_k> inverted4

SC_I((IN: instance): bool; (EQ_I(IN, VOID)) )

-copy <expr tb>*

SC__I((IN: instance): bool; IS_MEM_I(IN, MK_ZING_I(VOID)))

.comment<

GOAL in case that fsl is not empty (then-branch), the instances specified by sub_match can be expressed as the join of two instances, where some element fl of fsl matches some element f2 of fs2 under the first instance and the second instance satisfies the specification of sub_match on arguments fsl without fl and fs2; this will lead to a recursive version of sub_match

ACTIONS - application of decomposition lemma for sets (transformation rule m_fo: ysa_t)

- application of theorem 16 - algebraic simplifications - r e v e r s e a p p l i c a t i o n o f theorem 16

>4

. t r a n s f in < f u n c t sub_match> w i t h r u l e <m_fo: ysu_ t>*

f u n c t i o n SUB_MATCH (FSI: s e t _ o f _ f o ; FS2: s e t o f _ f o ) : s e t o f i ; { i f IS_Y_FO(FS 1) t h e n

SC_I((IN: instance): bool; IS_MEM_I(IN, MK_SING_I(VOID))) else

SC_I((IN: i n s t a n c e ) : boo l ; NON_HED_I(IN, U_OPS_SET_FO(FSI)) ^ IS_SUB_FO(INST_SET_FO(FSI, IN), FS2))

e n d i f ~

CONDITION FULFILLED? DETERMINATE[FS1] , y 4

.name in < f u n c t sub_match> w i t h .

f u n c t i o n SUB_MATCH (FSI: s e t _ o f _ f o ; FS2: s e t _ o f _ f o ) : s e t o f i ; if IS_Y_FO(FS i) then

SC_I((IN: instance) : bool; IS_MEbi_I(IN, MK__SING_I(VOID))) else

(SC_I((IN: instance) : hool;

Page 301: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3 .2 Developments o f f u n c t i o n s 293

NON_RED_I(IN, U_OPS_.SET_FO(UNION_FO(MK_SING_FO(ARB_FO(FSI)), DEL_FO(ARB_FO(FSI), FSI)))) A IS_SUB_FO(INST_SET_FO(UNION_FO(MK_SING_FO(ARB_FO(FSI)), DEL_FO(ARB_FO(FSI), FSI)), IN), FS2))>

endif

GIVE NAME FOR NEXT UNIT: .eb~

.transf in <expr eb> with rule <theorems: th16>4

SC_I((IN: instance): bool; NON_RED_I(IN, U_OPS_SET_FO(UNION_FO(MK_SING_FO(ARB_FO(FSI)), DEL_FO(ARB_FO(FSI),

FSI)))) A ~IS_~UB_FO(INST_SET_FO(UNION_FO(MK__SING_FO(ARB_FO(FSI)), DEL_FO(ARB_FO(FSI), FSI)), IN), FS2)> )

GIVE NAME FOR PARAMETER: F ~fl~

GIVE NAME FOR PARAMETER: G *f24

, t r a n s f in <expr eb> wi th r u l e <u_fo: ads_a> i n v e r t e d ~

SC_I((IN: instance): bool; NON_~ED_I(IN, U_OPS_SET_FO(UNION_FO(MK_SING_FO(ARB_FO(FSI)),

DEL_FO(ARB_FO(FSI), FSI)))) A ~ALL_FO((FI: formula): bool; true, (FI: formula): bool; EX_FO((F2: formula): bool; true, (F2: formula): bool; EQ30(INST_FO(FI, IN), F2))(FSZ))(UNION_FO(MK__SING_FO(ARB_FO(FSI)), DEL_FO(ARB_FO(FS1), FSI)))) )

~transf in <expr eb> with rule <u_fo: in_a> inverted4

SC_I((IN: instance): bool; NON_RED_I(IN, U_OPS_SET_FO(UNION_FO(MK_SING_FO(ARB_FO(FSI)),

DEL_FO(ARB_FO(FSI), FSI)))) A (~ALL__FO((FI: formula): boo1; true, (FI: formula): bool; EX__FO((F2: formula): bool; true, (F2: formula): bool; EQ_FO(INST_FO(FI, IN), F2))(FS2))(MK_SING_FO(ARB_FO(FSI)))> A ALL_FO((FI: formula): boo1; true, (FI: formula): bool; EX_FO((F2: formula): bool; true, (F2: formula): bool; EQ_FO(INST_FO(FI, IN), F2))(FS2))(DEL_FO(ARB_FO(FSI), FSI))))

CONDITION FULFILLED? AI~B_FO(FSI) isof__submode formula ~y~

CONDITION FULFILLED? DEFINED[ARB_FO(FSI)] ~y~

CONDITION FULFILLED? DETERMINATE~ARB_FO(FSI)~

CONDITION FULFILLED? KIND[EX_FO((F2: formula): bool; true, (F2: formula): bool;

EQ_FO(INST_FO(ARB_FO(FSI), IN), F2))(FS2)~ = boo1

.transf in <expr eb> with rule <theorems: thl6> inverted~

SC_I((IN: instance) : bool; NON_RED_I(IN, U_OPS_SET_FO(UNION_FO(MK_SING_FO(ARB_FO(FSI)), DEL_FO(ARB_FO(FSI),

FSI)))) A (EX_FO((F2: formula): bool; true, (F2: formula): bool; EQ_FO(INST_FO(ARB_FO(FSI), IN), F2)) (FS2) A ~ALL_FO((FI: formula): bool; true, (FI: formula): bool; EX_FO((F2: formula): bool; true, (F2: formula): bool; EQ_FO(INST_FO(FI, IN), F2)) (FS2)) (DEL_FO(ARB_FO(FSI), FSI) )> ) )

Page 302: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

294 IV.3 INFERENCE, CLAUSE, and FORMULA

~comment< !

the predicate non_rect_i(in .... ) is split into two predicates [ non_red_i(i, ...) and non_red_i(j, ...), where in is the join of i and j I

ACTIONS - unfold of non_red_i and u_ops__set_fo - distribution of is_memo over set_union (functional union_o) - representation of instance in as join of instances i and j by

application of theorem 6 - predicate logic transformations - application of theorems 5, 7, 18, 19 - 2 folds by non_red_i

>4

btransf in <expr eb> with rule <f: uff2>4

SC_I((IN: instance): bool; (NON_RED_/(IN, U_OPS_SET_FO(UNION_FO(MK_SING_FO(ARB_FO(FSI)),

DEL_FO(ARB_FO(FSI), FSI))))) A (EX_FO((F2: formula): bool; true, (F2: formula): bool; EQ_.FO(INST_FO(ARB_FO(FSI), IN), F2))(FS2) ^ IS_SUB_.FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2)))

CONDITION FULFILLED? DEF_DET[IN, U_OPS_SET_FO(UNION_FO(MK~SING_FO(ARB_FO(FSI)), DEL_FO(ARB_FO(FSI), FSI)))]

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD__F bfunct non_red_i4

*transf in <expr eb> with rule <f: uffl>4

SC_I((IN: instance) : bool; (V O: operator It ISDEF(IN, O) ¢~

IS_MEMO(O, ~U_OPS_SET_FO(UNION_FO(MK_SING_FO(ARB_FO(FSI)), DEL_FO(ARB_~O(FSI), FSI)))) )) A (EX_FO((F2: formula): bool; true, (F2: formula): bool; EQ_FO(INST_FO(ARB_FO(FSI), IN), F2)) (FS2) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI)~ FSI), IN), FS2)))

CONDITION FULFILLED? DEF_DET[UNION_.FO(MK__SING__FO(ARB_FO(FSI)), DEL_FO(ARB_FO(FSI), FSI)) ~y4

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~fanct u_ops_set_fo4

~transf in <expr eb> with rule <u_fo_o: uds_v>-

SC_/((IN: instance): bool; (Y O: operator il ISDEF(IN, O) ¢~

IS_MEM 0(0, (UNION_FO_O((F: formula) : bool; true, (F: formula) : set_of o; U_OPS_FO(F)) (UNION_FO(MK__SING_FO(ARB_/PO(FSI)), DEL__FO(ARB_FO(FSI), FSI)))9 )) A (EX_FO((F2: formula) : bool; true, (F2: formula) : bool; EQ_FO(INST_FO(ARB_FO(FSI), IN), F2)) (FS2) A IS_SUBJO(INST_SET_.FO(DEL_.FO(ARB_FO(FS1), FSI), IN), FS2)))

*transf in <expr eb> with rule <f: ffl>*

SC_I((IN: instance) : bool; (%/ O: operator II ISDEF(IN, O) ¢~

IS_MEMO(O, UNION_O(UNION_FO_O((F: formula): bool; true, (F: formula): set_of_o; U_OPS_FO(F)) (MK_SING_FO(ARB_FO(FSI))), (UNION_FO_O((F: formula) : bool; true,

Page 303: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3 .2 Developments of functions 295

(F: formula) : set_of o; U_OPS_FO(F)) (DEL_FO(ARB30(FSI), FSI))~ ))) A (EX_FO((F2: formula): bool; true, (F2: formula): bool; EQ_FO(INST30(ARB_FO(FSI), IN), F2)) (FS2) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2)))

GIVE NAMED/MARKED UNIT FOR PARAMETER" statD F bfunct u_ops_set_fo4 CONDITION FULFILLED? DEFINED[UNION_FO_O((F: formula): bool; true, (F: formula): set_of o;

U_OPS_FO(F)) (DEL_FO(ARB_FO(FSI), FSI)) ] ::) DEFINED[U_OPS_SET_FO(DEL_FO(ARB_FO(FS1), FS1))]

D.y~

*transf in <expr eb> with rule <u_fo_o: in_u> inverted4

SC_I((IN: instance): bool; (%/ O: operator I[ ISDEF(IN, O) ¢:)

IS_MEM_O(O, UNION_O((UNION_FO_O((F: formula): bool; true, (F: formula): set_of_o; U_OPS_FO(F) ) (MK_SING_FO(ARB_FO(FSI)) )~ , U_OPS_SET_FO(DEL_FO(ARB_FO(FSl), FS1))))) A (EX_FO((F2: formula): bool; true, (F2: formula): bool; EO_FO(INST_FO(ARB_FO(FS1), IN), F2)) (FS2) A IS_ZUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FS1), IN), FS2)))

CONDITION FULFILLED? ARB_FO(FSI) isof_submode formula ~y~

CONDITION FULFILLED? DEFI~D[ARB_FO(FS1)

CONDITION FULFILLED? DETEI~MINATE[ARB_FO(FS1) ] i.y.

CONDITION FULFILLED? EIND[U_OPS_FO(ARB_FO(FSI))] = set of o ~y4

~transf in <expr eb> with rule <m_o: mdy_u>4

SC_I((IN: instance) : bool; (%/ O: operator II ISDEF(IN, O) ¢:> (IS_MEMO(O, UNION_O(U_OPS_FO(ARB_FO(FSI)), U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), F S 1 ) ) ) ) ) ) A (EX_FO((F2: fo rmula) : boo l ; t r u e , (F2: fo rmula ) : boo l ; EO_FO<INST30(ARB_FO(FSI), IN), F2)) (FS2) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2)))

CONDITION FULFILLED? DETERMINATE[O] re.y4

*transf in <expr eb> with rule <u_fo: eno_ar> inverted.

SC_I((IN: instance) : bool; (%/ O: operator II ISDEF(IN, O) ¢~

IS_MEMO(O, U_OPS_FO(ARB_FO(FSI))) V IS_MEM_O(O, U_OPS_SET_FO(DEL_20(ARB_FO(FSI), FSI)))) A ((EX_FO((F2: formula): bool; true, (F2: formula): bool; EQ_FO(INST_FO(ARB_FO(FSI), IN), F2)) (FS2) A IS_SUB..FO(INST_SET_FO(DEL_FO(A~B_FO(FSI), FSI), IN), FS2))) )

CONDITION FULFILLED? DEF_DET[IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2)] my~

~transf in <expr eb> with rule <u_fo: eno_al> inverted4

Page 304: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

296 IV.3 INFERENCE, CLAUSE, and FOI&~ULA

SC_I((IN: instance) : bool; ~(V O: operator II ISDEF(IN, O) ¢~

IS_MEbI_0(O, U_OPS_FO(ARB_FO(FSI))) V IS_MEM_O(O, U_OPS_~ET_FO(DEL_FO(ARB_FO(FSI), FSI)))) A EX_FO((F2: formula): bool; true, (F2: formula): bool; EQ_FO(INST_FO(ARB_FO(FSI), IN), F2) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FS1), IN), FS2))(FS2)> )

CONDITION FULFILLED? DEF_DET~ O: operator II ISDEF(IN, O) ¢~ IS_MEM_O(O,

U_OPS_FO(ARB_FO(FSI))) V IS_h[EbLO(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FS1))) ~y4

~transf in <expr eb> with rule <theorems: th6>4

SC_I((IN: instance): bool; EX_FO((F2: formula): bool; true, (F2: formula): bool; ~(V O: operator II ISDEF(IN, O) ¢~ IS_MEM_O(0, U_OPS30(ARB_F0(FSI))) V IS_MEM_0(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FSI))))> A (EQ_FO(INST_FO(AP~_FO(FSI), IN), F2) A IS_SUB_FO(INST_SET_.FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2))) (FS2))

GIVE NAME FOR PARAMETER: I_ ~i4

GIVE NAME FOR PARAMETER: J ~j~

.transf in <expr eb> with rule <p: eno_ar> inverted4

SC_I((IN: instance): bool; EX_FO((F2: formula): bool; true, (F2: formula): bool; ~(3 I: instance II 3 J: instance II V O: operator ii (ISDEF(I, O) ¢~ IS_MEM_0(O, U_OPS_F0(ARB_F0(FSI)))) A (ISDEF(J, O) ¢~ IS_j~EM_0(O, U_OPS~SET_FO(DEL_FO(ARB30(FSI), FSI)))) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))) A (EQ_FO(INST_FO(ARB_FO(FSI), IN), F2) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_F0(FSI), FSI), IN), FS2))> ) (FS2))

CONDITION FULFILLED? IS_J~MPTYSORT[instance]

~transf in <expr eb> with rule <p: eno_ar> inverted4

SC._I((IN: instance) : bool; EX_FO((F2: formula): bool; true, (F2: formula) : bool; I: instance II ~(3 J: instance II V O: operator II (ISDEF(I, O) ¢~ IS_MEM_0(O,

U_OPS_FO(~B_FO(FSl)))) ^ (ISDEF(J, O) ¢~ IS_MEM_0(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FSI)))) A (JOINABLE(I, J) A EQ_I(IN, JQIN_I_I(I, J)))) A (EQ_FO(INST_FO(ARB_FO(FSI), IN), F2) A IS_SUB_FO(INST_SET_FO(DEL_F0(ARB_FO(FSI), FSI), IN), FS2))> ) (FS2))

CONDITION FULFILLED? IS_EMPTYSORT[instance] ~I]4

~transf in <expr eb> with rule <u_fo_i: eey_ek>~

SC_I((IN: instance): bool; ~EX_FO((F2: formula): bool; true, (F2: formula): bool; 3 I: instance II 3 J: instance II (V O: operator II (ÁSDEF(I, O) ¢=> IS_ME~i_0(O, U_OPS_FO(ARB_FO(FSI)))) A (ISDEF(J, O) ¢~ IS_MEM0(O, U_OPS_~ET_FO(DEL_FO(ARB_FO(FSI), FSI)))) A (JOINABLE(I, J) h EQ_I(IN, JOIN_I_I(I, J)))) A (EQ_FO(INST_FO(ARB_FO(FSI), IN), F2) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2))) (FS2)>)

~transf in <expr eb> with rule <b: cy_eq>4

~transf in <expr eb> with rule <u_fo_i: ecy_ek>4

Page 305: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of functions 297

SC_/((IN: instance): bool; 3 I: instance II (EX_FO((F2: formula): bool; true, (F2: formula): bool;

3 J: instance II (V O: operator II (IS_MEM_O(O, U_OPS_FO(ARB_FO(FSI))) ¢~ ISDEF(I, O)) A (IS_MEMO(O, U_OPS_SET_FO(DEL_/VO(ARB_/PO(FSI), FSI))) ¢~ ISDEF(J, O)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))) A (EQ_FO(INST_FO(ARB_FO(FSI), IN), F2) A IS_SUB__FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2)))(FS2)> )

btreLnsf in <expr eh> with rule <p: ano_sr>4

SC_I((IN: i n s t a n c e ) : bool ; 3 I : i n s t a n c e II 3 J : i n s t a n c e II EX_FO((F2: fo rmula ) : boo l ; t r u e , (F2: fo rmula) :

hool ; ~(V O: o p e r a t o r II (IS_MEM_O(O, U_OPS_FO(ARB_FO(FS1))) ¢~ ISDEF(I, 0)) A (IS_MEM_O(O, U_OPS_SET__FO(DEL__FO(ARB_FO(FSI), FSI))) ¢~ ISDEF(J, 0)) ^ (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J))))) A (EQ30(INST_.FO(ARB_FO(FSI), IN), F2) A IS__SUB__FO(INST_SET_FO(DEL_.FO(ARB_FO(FSI), FSI), IN), FS2)))(FS2))

CONDITION FULFILLED? IS_EMPTYSORT[operator] .n4

~transf in <expr eb> with rule <p: ady_a>~ btrsnsf in <expr eb> with rule <b: cy_a>. ~transf in <expr eb> with rule <b: ay__aal>.

~trsnsf in <expr eh> with rule <b: ca_aa>.

SC_I((IN: i n s t a n c e ) : bool ; 3 I: i n s t a n c e II 3 J : i n s t a n c e II EX_FO((F2: fo rmula) : boo l ; t r u e , (F2: fo rmula ) :

bool ; (JOINABLE(I, J) A EQ__I(IN, JOIN_I_I ( I , J ) ) ) A ~((V O: o p e r a t o r II IS_JqEM_O(O, U_OPS_FO(ARB_FO(FS1))) ¢:~ ISDEF(I, 0)) A (V O: o p e r a t o r tl IS_MEM_O(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FS1), FS1))) ¢~ ISDEF(J, 0)) A (EQ_FO(INST_FO(ARB_FO(FSI), IN), F2) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2)))) )(FS2))

~transf in <expr eb> with rule <b: cy_a>4 ,transf in <expr el)> with rule <b: cy_a>4

.transf in <expr eb> with rule <b: rd_aa>~

SC_I((IN: i n s t a n c e ) : bool ; 3 I : i n s t a n c e II 3 J : i n s t a n c e I[ EX_FO((F2: fo rmula ) : boo l ; t r u e , (F2: fo rmula ) :

bool ; ~EQ_FO(INST_FO(ARB_FO(FS1), IN), F2) A (V O: o p e r a t o r II IS..MEM_O(O, U_OPS30(ARB_FO(FSI))) <=> ISDEF(I, 0)) ^ (IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FS]), FSI), IN), FS2) A (V O: operator II IS_MEM_O(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FSI))) ¢=> ISDEF(J, O))) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))> )(FS2))

.transf in <expr eb> with rule <b: cy_a>4 ,transf in <expr eb> with rule <b: cv_eq_iai>, .transf in <expr eb> with rule <p: ady_a>. ~transf in <expr eb> with rule <b: cy_a>4 ~transf in <expr eb> with rule <b: ay_aal>4 ~transf in <expr eh> with rule <b: ay_aal>~ ,transf in <expr eb> with rule <b: cy_a>4

, t r a n s f in <expr eb> wi th r u l e <theorems: th5> i n v e r t e d 4

SC_I((IN: i n s t a n c e ) : bool ; 3 I : i n s t a n c e II 3 J : i n s t a n c e II EX_FO((F2: fo rmula ) : boo l ; t r u e , (F2: fo rmula ) :

bool ; (V O: o p e r a t o r II ISDEF(I, O) ~ IS_MEM_O(O, U_OPS_FO(ARB_FO(FS1)))) ^

Page 306: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

298 IV.3 INFERENCE, CLAUSE, and FOI~MULA

((EQ_FO(INST_FO(ARB_FO(FSI), IN), F2) A (V O: operator II IS_MEMO(O, U_OPS_FO(ARB_~O(FSI))) ~ ISDEF(I, 0)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J))))> A ((Y O: operator li ISDEF(J, O) IS_MEM_O(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FSI)))) A (IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2) A (Y O: operator II IS_MEM_O(O, U_OPS_SET_F0(DEL_FO(ARB_FO(FSI), FSI))) ISDEF(J, 0)) A (JOINABLE(I, J) A EQ__I(IN, JOIN_I_I(I, J))))))(FS2))

.transf in <expr eb> with rule <theorems: thl8>*

SC_I((IN: i n s t a n c e ) : boo l ; 3 I : i n s t a n c e li 3 J : i n s t a n c e It EX_FO((F2: fo rmula) : boo l ; t r u e , (F2: fo rmula) :

bool ; (Y O: o p e r a t o r U ISDEF(I, O) ~ IS_MEM_O(O, U_OPS_.FO(ARB_FO(FS1)))) A (EQ_FO(INST_FO(ARB_FO(FSt), I ) , F2) A (V O: o p e r a t o r II IS_MEM_O(O, U_OPS_FO(ARB_FO(FSI))) ~ ISDEF(I, 0)) A (JOINABLE(I, J) a EQ_I(IN, JOIN_I_/(I, J)))) A ((V O: operator II ISDEF(J, O) IS_MEM_O(O, U_OPS_SET30(DEL_FO(ARB_FO(FSI), FSI)))) A (IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2) A (V O: operator II IS_MEM_O(O, U_OPS_SET_FO(DEL_.FO(ARB_FO(FSI), FSI))) ::> ISDEF(J, O)) A (JOINABLE(I, J) A EQ_I(IN, (JOIN_I_I(I, J)) )))))(FS2))

.transf in <expr eb> with rule <theorems: thl9>.

SC_I((IN: i n s t a n c e ) : boo l ; 3 I : i n s t a n c e U 3 J : i n s t a n c e I1EX_FO((F2: fo rmula) : boo l ; t r u e , (F2: formula) :

bool ; (Y O: o p e r a t o r If ISDEF(I, O) ~ IS_MEMO(O, U_OPS_FO(ARB_FO(FS1)))) A (EQ~O(INST_FO(ARB__FO(FS1), I ) , F2) A (V 0: o p e r a t o r II IS_MEM_O(O, U_OPS_FO(ARB_FO(FSI))) ~ ISDEF(I, 0)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))) A ((V O: operator II ISDEF(J, O) IS_MEM_O(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FSI)))) A (IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2) A (V O: operator II IS_MEM_O(0, U_OPS_SET_FO(DEL_FO(AEB_FO(FSI), FSI))) ISDEF(J, 0)) A ((J01NABLE(I, J)) A EQ_I(IN, J01N_I_I(J, I))))))(FS2))

~transf in <expr eb> with rule <theorems: th7> inverted-

SC_I((IN: i n s t a n c e ) : bool ; 3 I : i n s t a n c e tl 3 J : i n s t a n c e tl EX_FO((F2: fo rmula ) : boo l ; t r u e , (F2: formula) :

bool ; (Y O: o p e r a t o r 111SDEF(I, O) =~ IS_MEM_O(O, U_OPS_FO(ARB_2D(FS1)))) A (EQ_FO(INST30(ARB_.FO(FS1), I ) , F2) A (V 0: o p e r a t o r II IS_MEM_O(O, U_OPS_FO(ARB_FO(FSI))) :=> ISDEF(I, O)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))) A ((Y O: operator II ISDEF(J, O) IS_MEMO(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FSI)))) A ((IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), IN), FS2) A (V O: operator II IS_MEM_O(O, U_OPS_SET_FO(DEL__FO(ARB_FO(FSI), FSI))) =:> ISDEF(J, O)) A (JOINABLE(J, I) A EQ_I(IN, JQIN_I_I(J, I))))) ))(FS2))

btransf in <expr eb> with rule <theorems: th18>4

SC_I ( ( IN: instance) : bool; 3 I: instance }I 3 J: instance II EX_FO((F2: formula): bool; true, (F2: formula):

bool ; (%/ O: o p e r a t o r II ISDEF(I, O) ~ IS_MEM_O(0, U_OPS_FO(ARB_FO(FS1)))) A (EO_FO(INST_FO(ARB30(FS1), I ) , F2) A (%/ O: o p e r a t o r 11 IS_MEM_O(O, U_OPS_FO(ARB30(FS1))) ~ ISDEF(I, 0)) A (JOINABLE(I, J ) A EQ_I(IN, JOIN_I_I(I, J)))) A ((Y O: operator II ISDEF(J, O) IS_MEM_O(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FS1), FSI)))) A (IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), J), FS2) A (V O: operator II IS_MEM_O(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FS1), FS1))) ISDEF(J, O)) A (JOINABLE(J, I) A EQ_I(IN, ~JOIN_I_I(J, I)~ )))))(FS2))

Page 307: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of functions 299

mtransf in <expr eb> with rule <theorems: thl9>~

SC_/((IN: ins tance) : bool; 3 I: ins tance II 3 J: ins tance II EX_FO((F2: formula): bool; t rue , (F2: formula):

bool; (V O: operator 1 1 1 S D E F ( I , O) ~ IS_MEM_O(O, U_OPS_FO(ARB_FO(FSI)))) A (EQ_FO(INST_FO(ARB_FO(FSI), I), F2) A (V O: operator II IS_MEMO(O, U_OPS_FO(ARB_FO(FSI))) =~ ISDEF(I , O)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))) A ((V O: operator II ISDEF(J, O) => IS_MEMO(O, U_OPS_SET_.FO(DEL_FO(ARB_FO(FSI), FSI)))) A (IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), J), FS2) A (V O: operator II IS_mM_O(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FSI))) ISDEF(J, O)) A ((JOINABLE(J, I)~ A EQ_I(IN, JOIN_I_I(I, J))))))(FS2))

mtransf in <expr eb> with rule <b: ay_aal> inverted.

mtransf in <expr eb> with rule <b: rd_aa> inverted-

SC_I((IN: instance): bool; 3 I: instance II 3 J: instance II EX_FO((F2: formula): bool; true, (F2: formula): bool; ((V O: operator II ISDEF(I, O) :=> IS_MEMO(O, U_OPS_.FO(ARB_FO(FSI)))) A (EQ_FO(INST_FO(ARB_.FO(FSI), I), F2) A (V O: operator II IS_MEM_O(O, U_OPS_FO(ARB_FO(FS1))) ~ ISDEF(I, 0))) A (JOINABLE(I, J) EO_/(IN, JOIN_I_I(I, J))) ^ ((Y O: operator II ISDEF(J, O) IS_MEM_9(O, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), mS1)))) A (IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), J), FS2) A (V O: operator II IS_MEM_O(O, U_OPS_~ET_FO(DEL_FO(ARB_FO(FSI), FSl))) ISDEF(J, O))) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J))))> )(FS2))

mtransf in <expr eb> with rule <b: cy_a>. mtransf in <expr eb> with rule <b: ay_aal> inverted. mtransf in <expr eb> with rule <p: ady_a> inverted. ~transf in <expr eb> with rule <b: cv_eq_iai> inverted.

mtransf in <expr eb> with rule <f: ff2>*

SC_I((IN: ins tance) : bool; 3 I: ins tance II 3 J: ins tance II EX_.FO((F2: formula): bool; t rue , (F2: formula):

bool; ((V O: operator II ISDEF(I, O) ~ IS_MEM_O(O, U_OPS_FO(ARB_FO(FS1))))) A EQ_FO(INST_FO(ARB_FO(FSI), I), F2) A (((V O: operator II ISDEF(J, O) ¢~ IS_MEMO(O, U_OPS_SET_F0(DEL_FO(ARB_FO(FSI), FSI))))) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), J), FS2)) A (JOINABLE(I, J) A EQ_.I(IN, JOIN_I_I(I, J))))(FS2))

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF mfunct non_red_/- CONDITION FULFILLED? DEFINED[V O: operator U ISDEF(I, O) ¢~ IS_MEM_O(O, U_OPS_.FO(ARB_FO(FSI)))]

DEFINED[NON_BED_I(I, U_OPS_FO(ARB_FO(FSI)))] by.

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF mfunct non_red_i- CONDITION FULFILLED? DEFINED[V O: operator il ISDEF(J, O) ¢:>

IS_MEM_O(O, U_OPS_SET30(DEL_FO(ARB_FO(FSI), FSI)))] =:) DEFINED[NON_RED_I(J, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FSI)))]

by.

mcomm~ent<

I GOAL the existential quantification of instances i and j can be removed since i can be obtained by match_fo and j by the specification of sub_match

Page 308: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

300 IV.3 INFERENCE, CLAUSE, and FORMULA

ACTIONS - twofold introduction of the functional union_i_i - conversion of union_i_i to set-comprehension functional sc_i - fold by match_.fo - fold by (specification of) sub_.match

>4

-transf in <expr eb> with r u l e <theorems: thl>4

SC_I((IN: instance): bool; 3 I: instance II 3 J: instance II EX_FO((F2: formula): bool; true, (F2: formula):

bool; NON~ED_I(I, U_OPS_YO(AI~B~O(FSI))) A EQ_FO(INST_FO(ARB_FO(FSI), I), F2) A ((NON_/~ED_I(J, U_OPS_SET_FO(DEL30(ARB_FO(FSI), FSI))) A IS_ZUB_FO( INST_SET_FO(DEL30(ARB_FO(FSI), FSI), J), FS2))) A (JOINABLE(I, J~ A EO_I(IN, JOIN_/_I(I, J))))(FS2))

~transf in <expr eb> with rule <theorems: th2>.

SC_I((IN: instance): bool; 3 I: instance II 3 J: instance II EX_FO((F2: formula): bool; true, (F2: formula):

bool; ~NON_RED_I(I, U_OPS_FO(ARB_FO(FSI))) ^ EO_FO(INST_FO(ARB_FO(FSI), I), F2)~ A (IS_MEM_I(J, BASE_SET_FO(DEL_FO(ARB_FO(FSI), FSI), FS2)) NON__RED_I(J, U_OPS__SET_FO(DEL_FO(ARB_FO(FSI), FSI))) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), J), FS2)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J))))(FS2))

*transf in <expr eb> with rule <u_i: uis_m>4

SC_I((IN: instance) : bool; 3 I: instance II q J: instance II EX_FO((F2: formula): bool; true, (F2: formula):

bool; ~(IS_MEM_I(I, BASE_FO(ARB_FO(FSI), F2)) A NON__RED_I(I, U_OPS_FO(ARB_FO(FSI))) A E(~_FO(INST_FO(ARB_.FO(FSI), I), F2) )) A ((IS_MEM__I(J, BASE_SET_FO(DEL._FO(ARB_.FO(FSI), FSI), FS2))A NON_RED_I(J, U_OPS_SET_FO(DEL_FO(ARB_.FO(FSI), FSI) )) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), J), FS2))) A (JOINABLE(I, J) Li EO__I(IN, JOIN_I_I(I, J))))(FS2))

GIVE NAME FOR PARAMETER: X ~ii~

CONDITION FULFILLED? DETEI~4INATE[NON_RED_I(II, U_OPS_FO(ARB_FO(FSI))) A EQ_FO(INST_FO(ARB30(FSI), II),

F2)] m-y~

CONDITION FULFILLED? false _c D IS_MEM_I(I, BASE30(ARB_FO(FSI), FP-)) =¢

DEFINED~NON_RED_I(II, U_OPS_FO(ARB_FO(FSI))) A EO__FO(INST__FO(ARB_FO(FSI), II), F2) ~y4

GIVE NAME FOR PARAMETER: X_ *jj4

CONDITION FULFILLED? DETERMINATE[NON_RED_I(JJ, U_OPS_SET__FO(DEL_FO(ARB_FO(FSI), FSI)))A

IS_SUB_FO(INST_.SET_FO(DEL_FO(ARB_FO(FSI), FSI), JJ), FS2) .y4

CONDITION FULFILLED? false c D IS_MEM_I(J, BASE_SET_FO(DEL_FO(ARB_FO(FSI), FSI), FS2)) ==>

Page 309: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV .3 .2 Developments o f functions 301

DEFINED[NON_RED_I(JJ, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FS1))) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), JJ), FS2)~

.y4

.transf in <expr eh> with rule <u_i: ucv_s_m>.

SC_/((IN: instance): bool; 3 I: instance II 3 J: instance II EX_FO((F2: formula): bool; true, (F2: formula): bool; IS_MEM./(I, (UNION_I_/((II: instance): bool; NON_RED_I(II, U_.OPS_FO(ARB_FO(FSI))) ^ EQ_FO(INST_FO(ARB_FO(FSI), II), F2), (If: instance): set_of i; MK_SING_I(II))(BASE_FO(ARB_FO(FSI), F2))) ) A IS_MEM_I(J, (UNION_I__I((JJ: instance): bool; NON_RED_/(JJ, U_OPS_SET_FO(DEL_.FO(ARB_FO(FSI), FSI))) A IS_SUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), JJ), FS2), (JJ: instance): set_of i; MK_SING_I(JJ))(BAsE_SET_FO(DEL_FO(ARB_FO(FSI), FSI), FS2))> ) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J))))(FS2))

CONDITION FULFILLED? DETERMINATE[BASE_FO(ARB_FO(FSI), F2)~ . y 4

CONDITION FULFILLED? DETENMINATE[BASE_SET_FO(DEL_FO(ARB_FO(FSI), FSI), FS2)] -y-

~transf in <expr eb> with rule <theorems: thl> inverted4

SC_/((IN: instance): bool; 3 I: instance II 3 J: instance U EX_FO((F2: formula): bool; true, (F2: formula):

bool; IS_MEM_I(I, SC_/((ll: instance): bool; IS_MEM_I(II, BASE_FO(ARB_FO(FSI), F2)) A NON__RED_I(II, U_OPS_FO(ARB_FO(FSI))) A EQ_F0(INST_FO(ARB_FO(FSI), II), F2))) A IS_MEM_I(J, SC_I((JJ: instance): hool; (IS_MEM_I(JJ, BASE_SET_F0(DEL_F0(ARB_FO(FSI), FSI), FS2)) A NON_RED_I(JJ, U_OPS_SET__FO(DEL_FO(AHB_FO(FSI), FSI))) A IS__SUB_FO(INST_SET_FO(DEL_F0(AHB_F0(FSI), FSI), JJ), FS2)) )) A (JOINABLE(I, J) A EQ__I(IN, JOIN_I_I(I, J))))(FS2))

~transf in <expr eh> with rule <theorems: th2> inverted~

SC_I((IN: instance): bool; 3 I: instance II 3 J: instance II EX_FO((F2: formula): bool; true, (F2: formula):

bool; IS_MEM_/(I, SC_I((II: instance): bool; (IS_MEM_I(II, BASE__FO(ARB_FO(FSI), F2)) A NON_RED_/(II, U_OPS_.FO(ARB_/PO(FSI))) A EQ30(INST_/D(ARB_FO(FSI), II), F2)) )) A IS_MEM_/(J, SC_I((JJ: instance): bool; NON_.RED_I(JJ, U_OPS__SET__FO(DEL__FO(ARB_FO(FSI), FSI))) A IS_SUB_F0(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), JJ), FS2))) A (JOINABLE(I, J) EQ_.I(IN, JOIN_I_I(I, J))))(FS2))

-install unit <units aux al: match_fo>4

.transf in <expr eb> with rule <f: al_ab>4

SC_I((IN: instance): bool; 3 I: instance II 3 J: instance il E~_FO((F2: formula): bool; true, (F2: formula): bool; IS_MEM_/(I, SC_I(((II: instance): bool; NON_RED_I(II, U_OPS_FO(ARB_FO(FSI))) A EQ_FO(INST_FO(ARB_FO(FSI), II), F2)) )) A IS_MEM_I(J, SC_I(((JJ: instance): bool; NON_RED_I(JJ, U_OPS_SET__FO(DEL_FO(ARB_FO(FSI), FSI))) A IS_SUB_FO(INST_~ET_FO(DEL__FO(ARB_FO(FSI), FSI), JJ), FS2)) )) A (JOINABLE(I, J) A EQ__I(IN, J01N_I_I(I, J))))(FS2))

GIVE NAME FOR PARAMETER: X ~i~

Page 310: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

302 IV.3 INFERENCE, CLAUSE, and FONMULA

CONDITION FULFILLED? NEW[I~

GIVE NAME FOR PARAMETER: Y .j.

CONDITION FULFILLED? NEW[J]

*transf in <expr eb> with rule <f: ff2>.

SC_I((IN: instance): bool; 3 I: instance II 3 J: instance II EX_FO((F2: formula): bool; true, (F2: formula): bool; IS_MEM_I(I, (SC_I((I: instance): bool; NON_RED_I(I, U_OPS_FO(ARB_FO(FSI))) A EQ_F0(INST_FO(ARB_FO(FSI), I), F2))) ) A IS_MEM_I(J, SC_I((J: instance): bool; NON_RED_I(J, U_OPS_SET_FO(DEL_FO(ARB30(FSI), FSI))) A IS_ZUB_FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), J), FS2))) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J))))(FS2))

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct match_fo. CONDITION FULFILLED? DEFINED[SC_I((I: instance): bool;

NON_RED__I(I, U_OPS_.FO(ARB_FO(FSI))) A EQ__FO(INST_FO(ARB_FO(FSI), I), F2))] =~ DEFINED[MATCH_FO(ARB_FO(FSI), F2)]

my.

-transf in <expr eb> with rule <b: ay_aal>.

~%ransf in <expr eh> with rule <u__fo: eno__ar>.

• SC_.I((IN: instance): bool; 3 I: instance II 3 J: instance II (EX30((F2: formula): bool; true, (F2: formula): bool; IS_MEM_I(I, MATCH_FO(ARB_.FO(FSI), F2)) A (IS_MEM__I(J, SC_I((J: instance): bool; NON_RED_I(J, U_OPS_SET_20(DEL_FO(ARB_FO(FSI), FSI))) A IS_SUB_FO(INST__SET_FO(DEL_FO(ARB_FO(FSI), FSI), J), FS2))) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))))(FS2)) )

CONDITION FULFILLED? DEF_/)ET[IS_MEM_I(J, SC_I((J: instance): bool;

NON_RED_I(J, U_OPS_SET_.FO(DEL_FO(ARB_.FO(FSI), FSI))) A IS_SUB_.FO(INST_SET_FO(DEL_FO(ARB_FO(FSI), FSI), J), FS2))) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_.I(I, J)))]

my.

*transf in <expr eb> with rule <u_fo_i: mcy_u> inverted4

SC_I((IN: instance): bool; 3 I: instance II 3 J: instance II (EX_FO((F2: formula): bool; true, (F2: formula): bool; IS_MEM_/(I, MATCH_.FO(ARB_FO(FSI), F2)))(FS2)) A (IS_MEM_I(J, SC_.I((J: instance): bool; NON_RED_I(J, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FSI))) A IS_SUB_FO(INST_SET__FO(DEL_FO(ARB_FO(FSI), FSI), J), FS2))) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_.I(I, 5)))))

CONDITION FULFILLED? DETENMINATE[I]

.transf in <expr eh> with rule <b: ay_aal> inverted4

-transf in <expr eb> with rule <theorems: th9>4

Page 311: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV .3 .2 Developments o f functions 303

SC_I((IN: instance): bool; (3 I: instance IIB J: instance II IS_MEM_I(I, UNION_FO_I((F2: formula): bool;

true, (F2: formula): set_of_i; MATCH_FO(ARB_FO(FSI), F 2 ) ) ( F S 2 ) ) A IS_MEM__I(J, SC__I((J: instance): bool; NON_RED_I(J, U_OPS_.SET_.FO(DEL_FO(ARB_FO(FSI), FSI))) A IS_SUB__FO(INST__SET_FO(DEL_FO(ARB_FO(FSI), FSI), J), FS2))) A (JOINABLE(I, J) A EQ__I(IN, JOINj__I(I, J)))) )

.install <funct sp_sub_match> unit <units aux a l : sub_match>~

~ t r a n s f in <expr eb> with rule <f: al_ab>4

SC_I((IN: instance): bool; IS_MEM_I(IN, JOIN_SET_SET(UNION_FO_I((F2: formula): bool; true, (F2: formula): set_of_i; MATCH_FO(ARB_FO(FSI), F2))(FS2), SC__I(((J: instance): bool;

NON_RED__I(J, U_OPS_SET__FO(DEL__FO(ARB_FO(FSI), FSI))) A IS_SUB_FO(INST__SET_.FO(DEL_FO(ARB__FO(FSI), FSI), J), FS2)) ))))

GIVE NAME FOR PARAMETER: Y ~in4

CONDITION FULFILLED? NEW[IN] my4

~transf in <expr eb> with rule <f: ff2>4

SC_.I((IN: instance): bool; IS_MEM_I(IN, JOIN_SET_SET(UNION_FO_I((F2: formula): bool; true, (F2: formula): set_of_i; MATCH_FO(ARB__FO(FSI), F2))(FS2), (SC__I((IN: instance): bool;

NON_RED_I(IN, U_OPS_SET__FO(DEL_FO(ARB_FO(FSI), FSI))) A IS_SUB_FO(INST_SET_FO(DEL_.FO(ARB_FO(FSI), FSI), IN), FS2))> )))

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD__FF ~funct sp_sub_match4 CONDITION FULFILLED? DEFINED[SC_I((IN: instance): bool;

NON_RED_/(IN, U_OPS_SET_FO(DEL_FO(ARB_FO(FSI), FSI))) A IS_ZUB_FO(INST_SET_/D(DEL_FO(ARB_FO(FSI), FSI), IN), FS2))] =~

DEFINED[SUB_MATCH(DEL_FO(ARB_FO(FSI), FSI), FS2)] ~y4

~transf in <funct sub__match> with rule <b: si_satr> inverted4

~comment<

I GOAL removal of set-comprehension

ACTIONS - conversion of set-comprehension sc_i to filter_i - elimination of true-filter - distribution of choice operator over conditional - removal of choice operator

>4

~transf in <funct sub_match> with rule <u_i: scv_f>4

f u n c t i o n SUB_MATCH (FSI: s e t o f fo ; FS2: s e t _ o f _ f o ) : s e t _ o f _ i ; i f IS_Y_FO(FSI) t h e n

(SC_I ( ( IN: i n s t a n c e ) : boo l ; IS_ME~_I(IN, bIK_SING_I(VOID)) A t r u e ) ~ e l s e

Page 312: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

304 IV.3 INFERENCE, CLAUSE, and FORMULA

(SC_I((IN: ins tance) : bool; IS_MEM_I(IN, JOIN_SET_SET(UNION_FO_I((F2: formula): bool; t rue , (F2: formula): se t_of_ i ; MATCH_FO(ARB_FO(FS1), F2))(FS2),

SUB_MATCH(DEL_FO(ARB_FO(FSI), FSI), FS2))) a true)~ endif

CONDITION FULFILLED? DETE}~MINATE[MK_SING_I(VOID)~ ~y4

CONDITION FULFILLED? DETERMINATE[JOIN_SET_SET(UNION_FO_I((F2: formula): bool; true, (F2: formula):

se t_of_ i ; MATCH_FO(ARB_FO(FSI), F2))(FS2), SUB_MATCH(DEL_FO(ARB_FO(FSI), FSI), FS2))]

my4

~t rans f in <funct sub_match> with rule <u_i: in_f> inverted4

funct ion SUB_MATCH (FSI: se t of fo; FS2: set_offo): se t of_i ; if IS_Y_FO(FSI) then

~FILTER_I((IN: instance): bool; true)(MK_SING_I(VOID))~ else

(FILTER_I((IN: instance): bool; true)(JOIN_SET_SET(UNION_FO__I((F2: formula): bool; t rue , (F2: formula): se t_of_ i ; MATCH_FO(ARB_FO(FSI), F2))(FS2), SUB_MATCH(DEL_FO(ARB_FO(FSI), FSI), FS2))))

endif

GIVE NAME FOR PARAMETER: E ~is4

CONDITION FULFILLED? DETENMINATE~MK_SING_I(VOID)] by~

GIVE NAME FOR PARAMETER: E ~is4

CONDITION FULFILLED? DETEHMINATE[JOIN_SET_SET(UNION_FO_I((F2: formula): bool; true, (F2: formula):

set_of_i; MATCH_FO(AHB_FO(FSI), F2))(FS2), SUB_MATCH(DEL_FO(ARB_FO(FSI), FSI), FS2))~

.transf in <funct sub_match> with rule <c: sdy_c> inverted~

funct ion SUB_MATCH (FSI: se t o f fo; FS2: se t of_fo) : se t_of i ; ( i f IS_Y_FO(FS1) then

some IS: s e t of i II EQ_SET_.I(IS, MK_SING_I(VOID)) e l s e

some IS: s e t o f i I1EQ_SET_I(IS, JOIN_SET_SET(UNION_FO_I((F2: formula): bool; t rue , (F2: formula): se t_of_ i ; MATCH_FO(ARB_FO(FS1), F2))(FS2), SUB.JqATCH(DEL30(ARB_FO(FS1), FS1), FS2)))

e n d i f )

CONDITION FULFILLED? DE~HMINATE[IS_Y30(FSI)] ~y4

. t r a n s f in <funct sub_match> with ru le <c: cdy_f22> inverted~

funct ion SUB_MATCH (FSI: se t of fo; FS2: s e t o f f o ) : s e t_of i ; some IS: se t of i I!

~ i f IS_¥_~O(FS1) then

Page 313: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of funct ions 305

EO_SET__I(IS, MK_SING_I(VOID)) else

EQ_SET_I(IS, JOIN_SET_SET(UNION_FO_I((F2: formula): bool; true, (F2: formula): set_of_i; MATCH__FO(ARB_FO(FS1), F2))(FS2), SUB_MATCH(DEL_FO(ARB_FO(FS1), FSt), FS2)))

endif)

~transf in <funct sub_match> with rule <p: srm_q>4

funct ion SUB_MATCH (FSI: se t of fo; FS2: se t_of fo): se t_of_i ; (some IS: set_of i II EO_.SET_I(IS,

if IS_Y_FO (FSI) then

MK_Z ING_.I (VOID) else

JOIN__SET__SET(UNION_.FO_/((F2: formula) : bool; true, (F2: formula) : set_of_i; MATC}{_FO(AP~_FO(FSI), F2))(FS2), SUE_MATCH(DEL_FO(ARB_.FO(FSI), FS1), FS2))

endif))

CONDITION FULFILLED? IS_EQUAL_PRE[EQ_SET_/, set_of_i] my~

CONDITION FULFILLED? i f IS_Y30(FS1) then

MK_SING_I(VOID) else

JOIN_SET_SET(UNION_FO_I((F2: formula): bool; true, (F2: formula): set of i; MATCH_FO(ARB_FO(FSI), F2))(FS2), SUB_MATCH(DEL_FO(ARB_FO(FSI), FSI), FS2))

endif isof_submode set of i my4

~co~nent<

I LEVEL

i' aOAL

>~

recurs ive

t a i l - r e c u r s i o n

due to associativity of join_set_set, sub_match can be made tail- recursive by the rebracketing rule (cf. [Bauer, W6ssner 82])

~copy <funct sub_match>4

func t ion SUB_MATCH (FSI: se t of fo; FS2: s e t _ o f f o ) : se t_of i ; i f IS_Y_FO(FS1) then

MK_SING_/(VOID) e l se

JOIN_SET_SET(UNION_FO_I((F2: formula): bool; t rue , (F2: formula): se t_of_i ; MATCH_FO(ARB_FO(FS1), F2))(FS2), SUB_MATCH(DEL_FO(ARB_FO(FS1), FS1), FS2))

end i f

. t r a n s f <funct sub_match> with ru le <r: rb_2>4 CONDITION FULFILLED7 ASSERT[JOIN_SET_SET(X, JOIN_SET_SET(Y, Z)) = JOIN_SET_SET(JOIN_SET_SET(X, Y), Z)] ~y4

Page 314: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

306 IV.3 INFERENCE, CLAUSE, and FORMULA

CONDITION FULFILLED? ASSERT~JOIN_SET_SET(X, MK_SING_/(VOID)) = JOIN_SET_SET(MK_SING_I(VOID), X)] ~y4

GIVE NAME FOR PARAMETER: NEWFUNCT ~h4

GIVE NAME FOR PARAMETER: NEWPAR ~is.

CONDITION FULFILLED? NEW[H, IS]

~co~ment<

I GOAL tail-recursion can immediately be transformed to iteration; sequentialization of collective assignments; local optimizations

ACTIONS - conversion of recursion to while-loop - sequentialization of collective assignments - elimination of redundant assignments

>4

~transf in <funct sub_match> with rule <r: cv_r_w_3>4

funct ion SUB_MATCH (FSl: set_of_go; FS2: set_of_fo): se t_of_i ; (begin

funct ion H (FSI: se t_of fo; FS2: se t of fo; IS: se t_of_i ) : se t of i ; if IS_Y_FO(FSI) then

IS else

H(DEL_FO(ARB_.FO(FSI), FSI), FS2, JOIN_SET_SET(IS, UNION_FO_I((F2: formula): bool; t rue , (F2: formula): se t_of_i ; MATC}{_20(ARB_FO(FSl), F2) ) (FS2)) )

endif ; H(FSI, FS2, MK._SING_I(VOID))

end)

GIVE NAME FOR PARAMETER: VX.l ~vfs4

GIVE NAME FOR PARAMETER: VX2 ~vgs~

GIVE NAME FOR PARAMETER: VX3 ~vis4

CONDITION FULFILLED? NEW[VFS, VGS, VIS] ~y4

~transf in <funct sub_match> with rule <v: sq_a3_3>4

funct ion SUB_MATCH (FSI: se t of fo; FS2: set_of_fo): set_of i ; begin

(var VFS: se t of fo, var VGS: se t of fo, var VIS: se t_of i ) := (FSI, FS2, MK_SING_I(VOID)); while -IS_Y_.FO (VFS) loop ~(VFS, VGS, VIS) := (DEL_FO(ARB_.FO(VFS), VFS), VGS, JOIN_SET_SET(VIS,

UNION_FO_I((F2: formula): bool; t rue , (F2: formula): set_of i; MATCH_FO(ARB_FO(VFS), F2)) (VGS))))

endloop;

Page 315: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I V . 3 . 2 Developments o f f u n c t i o n s 307

VlS end

~transf in <funct sub_match> with rule <v: sa>4

f u n c t i o n SUB_MATCH (FSI: s e t o f fo ; FS2: s e t _ o f f o ) : s e t _ o f i ; b e g i n

( v a t VFS: s e t o f fo , v a r VGS: s e t o f fo , v a r VIS: s e t o f i ) := (FS1, FS2, MK_SING_t(VOID)); w h i l e ~IS_Y_FO(VFS) loop

VIS := JOIN_SET_SET(VlS, UNION_FO_I((F2: formula): bool; true, (F2: f o r m u l a ) : set of i; MATCIL~O(ARB_FO(VFS), FZ))(VGS));

CVGS := VGS> ; VFS :: DEL_FO(ARB_FO(VFS), VFS)

endloop; VIS

end

CONDITION FULFILLED? DEFINED[VGS] ~y~

~ t r a n s f i n <f tmct sub_match> w i t h r u l e <v: rm_sa>4

f u n c t i o n SUB_MATCH (FSI: s e t o f f o ; FS2: s e t _ o f _ f o ) : s e t o f i ; b e g i n

( v a r VFS: s e t o f fo , v a t VGS: s e t o f fo , v a t VIS: s e t o f i ) := (FSI, FS2, MK_SING_I(VOID)); w h i l e ~IS_Y_FO (VFS) loop

~VIS := JOIN_SET_SET(VIS, UNION_FO_I((F2: fo rmula ) : b o o l ; t r u e , (F2: fo rmula ) : s e t _ o f _ i ; MATCH_FO(AHB_FO(VFS), F2)) (VGS)) ;

sk ip> ; VFS : : DEL_FO(ARB_FO(VFS), VFS)

endloop; VlS

end

~copy <funct sub_match>4

f u n c t i o n SUB_MATCH (FSI: s e t o f f o ; FS2: s e t of f o ) : s e t _ o f i ; b e g i n

( v a r VFS: s e t o f fo , v a r VGS: s e t o f fo , v a t VIS: s e t o f i ) := (FSI, FS2, ~K_SING_I(VOID)) ; while ~IS_Y_FO (VFS) loop

VIS := JOIN_SET_SET(VIS, UNION_FO_I((F2: formula): bool; true, (F2: fo rmula ) : s e t o f _ i ; MATCH_FO(ARB_FO(VFS), F2)) (VGS)) ;

VFS := D E L 3 0 ( A ~ 3 0 ( V F S ) , VFS) endloop; VIS

end

~stop*

END SKERN START SKERN

Page 316: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

308 IV.3 INFERENCE, CLAUSE, and FOI~ULA

.comment<

Development of function

MATCH_SET_.FO

>4

.install unit <units aux al: match_set__fo>4

.copy <funct match__set_.fo>4

function MATCH_SET_.FO (FSI: set of fo; FS2: set of fo): set_of_i; SC__I((I: instance): hool;

NON_BED_I(I, U_OPS_SET_.FO(FSI)) A EO_SET_FO(INST_SET_.FO(FSI, I), FS2))

.comment<

I UNIT

I LEVEL

I GOAL

match_set_fo

descriptive, pre-algorithmic, set-comprehension over infinite domain

removal of the set-comprehension over infinite domain, reduction of match_set_fo to sub_.match

ACTIONS - eq_set_fo(inst_set_fo(fsl, i), fs2) is split into is_suh__fo(inst_set_fo(fsl, i), fs2)A is_sub_fo(fs2, inst_set__fo(fsl, i))

- introduction of set-comprehension over those instances satisfying only is_sub_fo(inst_set_fo(fsl, i), fs2)

- fold by specification of the auxiliary function sub_match - original infinite set-comprehension is expressed by filtering those

instances out of sub_match(fsl, fs2), which also satisfy is_sub_fo(fs2, inst_set_fo(fsl, i))

>4

-transf in <funet match_set_fo> with rule <~fo: qsi_s>4

function MATCH_SET_FO (FSI: set of fo; FS2: set_of_fo): set of_i; SC_I((I: instance) : hool;

NON_RED_I(I, U_OPS_SET_FO(FSI)) ^ ~EO_SET_FO(INST_SET_FO(FSI, I), FS2)~ )

CONDITION FULFILLED? DETERMINATE[INST_SET_FO(FSI, I), FS2~

.transf in <funet match__set_fo> with rule <b: ay__aal> inverted4

.transf in <funct match_set__fo> with rule <theorems: thl>~

function MATCH_SET_/rO (FSI: set of re; FS2: set of fo): set_of_i; SC__I((I: instance): bool;

(NON_RED_I(I, U_OPS_SET_FO(FSI)> A IS_SUB_.FO(INST_SET__FO(FSI, I), FS2)) A IS_SUB_.FO(FS2, INST_SET_.FO(FSI, I) ))

Page 317: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of functions 309

~transf in <funct match_set_fo> with rule <u_i: uis_m>4

function MATCH_SET_riO (FSI: set of fo; FS2: set of fo): set of i; SC_I((I: instance): bool;

((IS_MEM_I(I, BASE_SET..FO(FSI, FS2)) A NON__RED_I(I, U_OPS_.SET_FO(FSI)) A IS_ZUB_FO(INST_SET_FO(FSI, I), FS2))) A IS_SUB_FO(FS2, INST_SET_FO(FSI, I)))

GIVE NAME FOE PARAMETER: X ,in4

CONDITION FULFILLED? DETEEMINATE[NON_RED_I(IN, U_OPS_SET_FO(FSI)) A IS_SUB_FO(INST_SET_FO(FSI, IN), FS2)] .y4

CONDITION FULFILLED? false ~D IS_MEM_I(I, BASE_SET_FO(FSI, FS2)) =~

DEFINED[NON_RED_I(IN, U_OPS_SET_FO(ESI)) A IS_SUB_FO(INST_SET_FO(FSI, IN), FS2)]

.transf in <funct match_set_fo> with rule <u_i: ucv_s_m>4

function MATCH_SET_riO (FSI: set_of_fo; FS2: se t of fo): set_of_i; SC_I((I: instance): bool;

IS_MEM_/(I, (UNION_I_I((IN: instance): bool; NON_RED_I(IN, U_OPS_SET_FO(FS1)) A IS_SUB_FO(INST_SET_FO(FS1, IN), FS2), (IN: instance): set_of_i; MK_SING_I(IN))(BASE_SET_FO(FS1, FS2))) ) A IS_SUB_/D(FS2, INST_SET_FO(FS1, I ) ) )

CONDITION FULFILLED? DETERMINATE[BASE_.SET_FO(FSI, FS2)] ~y4

.transf in <funct match_set_fo> with rule <theorems: thl> inverted~

function MATCH_SET_FO (FSI: se t of fo; FS2: se t of t"o): set_of i; SC_/((I: instance): bool;

IS_MEM_I(I, SC_I((IN: instance) : bool; (IS_MEM_I(IN, BASE_SET_FO(FS1, FS2)) a NON_BED_I(IN, U_OPS_SET_FO(FS1)) A IS_SUB_FO(INST_SET_.FO(FS1, IN), FS2)) )) A IS_SUB_FO(FS2, INST_SET_FO(FS1, I ) ) )

-install unit <units aux al: sub_match>4

~transf in <funct match_set_/o> with rule <f: ff2>4

function MATCH_SET_FO (FSI: set_of_fo; FS2: se t of fo): set_of_i; SC_I((I: instance): bool;

IS_MEM_/(I, ~SC_I((IN: instance): bool; NON_RED_I(IN, U_OPS_SET_FO(FS1)) A IS_SUB_.FO(INST_SET_FO(FSI, IN), FS2))~ ) A IS_ZUB_FO(FS2, INST_SET_FO(FSI, I)))

GIVE NAMED/MARKED UNIT FOR PARAMETEH: statD__F ~funct sub_match4 CONDITION FULFILLED? DEFINED[SC_/((IN: instance): bool; NON_RED_I(IN, U_OPS_SET_FO(FSI))A

IS_ZUB_FO(INST_SET_FO(FS1, IN), FS2))] =~ DEFINED[SUB_MATCH(FS1, FS2)] ~y4

.transf in <funct match_set_fo> with rule <b: ch_a_sa>~

,transf in <funct match_set_/o> with rule <u__i: scv_f>4

function MATCH_SET_FO (FSI: set_of_fo; FS2: se t of fo): set_of_i; (SC_I((I: instance): bool;

IS_MEM_I(I, SUB_MATCH(FS1, FS2))A IS_SUB_FO(FS2, INST_SET_F0(FS1, I ) ) )~

Page 318: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

310 IV.3 INFERENCE, CLAUSE, and FORMULA

CONDITION FULFILLED? DETEI~MINATE[SUB_MATCH(FSI, FS2)] my~

~copy <funct match_set_fo>4

function MATC}{_SET_~O (FSI: set of fo; FS2: set_of_fo): set_of i; FILTER_I((I: instance): bool;

IS_SUB_FO(FS2, INST_SET~O(FSI, I)))(SUB_MATCH(FSI, FS2))

~stop~

END SKERN START SKEPJN

.comment<

Development of function

IS__INSTANCE

>4

.install <structure clause> unit <clause structural: clause>4

mcopy <funct is_instance>4

function IS_INSTANCE (CLI: clause; CL2: clause): bool; 3 IS: instance II EQ_CL(INST_CL(CL1, IS)~ CL2)

~cozment<

UNIT is_instance

LEVEL descriptive, pre-algorithmic, existential quantification over infinite domain instance

GOAL removal of the existential quantification by reducing is_instance(c, d) to -is_emptyset_i(match_cl(c, d))

ACTIONS - the infinite existential quantification over instances is confined to those instances which are relevant to the arguments of is_instance via the predicate non_redundant__i specified by type INSTANCE.

- fold by the auxiliary function match_cl

>4

.transf in <funct is__instance> with rule <theorems: th15>4

function IS_INSTANCE (CLl: clause; CL2: clause): bool; (3 IS: instance I| EQ_CL(INST_CL(CLI, IS), CL2))

~transf in <funct is_instance> with rule <theorems: thO>~

function IS_.INSTANCE (CLI: clause; CL2: clause): bool; IS: instance II (NON~ED_I(IS, U_OPS_CL(CLI)) A EQ_CL(INST_CL(CLI, IS), CL2))

Page 319: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of functions 311

~transf in <funct is_instance> with rule <u_i: uis_m>4

function IS_INSTANCE (CLI: clause; CL2: clause): bool; 3 IS: instance I! (IS_MEM_/(IS, BASE_CL(CLI, CL2)) A

(NON_2ED_/(IS, U_OPS_CL(CLI)) A EQ_CL(INST_CL(CLI, IS), CL2)))

GIVE NAME FOR PARAMETER: _X ~i~

CONDITION FULFILLED? DETERMINATE[NON_RED_I(I, U_OPS_CL(CLI)) A EO_CL(INST_CL(CLI, I), CL2) ] ~y4

CONDITION FULFILLED? false c IS_MEM_I(IS, BASE_CL(CLI, CL2)) =$

DEFINED[NON_RED_I(I, U_OPS_CL(CLI)) A EO_CL(INST_CL(CLI, I), CL2) ] my4

~transf in <funct is_instance> with rule <u_i: ucv__s_m>4

function IS_INSTANCE (CLI: clause; CL2: clause): bool; 3 IS: instance II IS_MEM_I(IS, ~UNION_I_I((I: instance): bool;

NON_RED_I(I, U_OPS_CL(CLI)) A EO_CL(INST_CL(CLI, I), CL2), (I: instance) : set_of_i; MK_ZING_I(I))(BASE_CL(CLI, CL2))))

CONDITION FULFILLED? DETE~MINATE[BASE_CL(CLI, CL2)] ~y~

~transf in <funct is_/nstance> with rule <theorems: thO> inverted*

function IS_INSTANCE (CLI: clause; CL2: clause) : bool; 3 IS: instance tl IS_MEM__I(IS, SC__I((I: instance): bool; ((IS_MEM_I(I, BASE_CL(CLI, CL2)) A NON_RED_/(I, U_OPS_CL(CLI)) A EQ_CL(INST_CL(CLI, I), CL2))) ))

~install unit <units aux al: match_cl>4

~transf in <funct is_instance> with rule <f: ff2>4

function IS_INSTANCE (CLI: clause; CL2: clause): bool; 3 IS: instance II IS_MEM_/(IS, (SC_I((I: instance): booll

NON_RED_I(I, U_OPS_CL(CLI)) A EQ_CL(INST_CL(CLI, I), CL2))) )

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct match_cl4 CONDITION FULFILLED? DEFINED[SC_I((I: instance): 5ool; NON_RED__I(I, U_OPS_CL(CLI)) A

EQ_CL(INST_CL(CLI, I), CL2))] ~ DEFINED[MATCH_CL(CLI~ CL2)] by4

~transf in <funct is__instance> with rule <p: ecv_a>~

function IS_INSTANCE (CLI: clause; CL2: clause): heel; (3 IS: instance II IS_MEM_I(IS, MATCH__CL(CLI, CL2)))

~transf in <funct is_instance> with rule <m_i: ycv_.a> inverted*

function IS_INSTANCE (CLI: clause; CL2: clause): hool; ((¥ IS: instance II -IS_MEM__I(IS, MATCH_CL(CLI, CL2))))

~copy <funet is_instance>~,

Page 320: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

312 IV.3 INFERENCE, CLAUSE, and FORMULA

f u n c t i o n IS_INSTANCE (CLI: c lause ; CL2: c l ause ) : bool; ~IS_¥_I(MATCH_CL(CLI, CL2))

~copy into file <units aux al> <funct is_instance> <is__inst>4

~stop~

END SKERN START SKERN

~comment<

Development of function

F_A_I

>4

~install <structure inference> unit <inferenc structural: inference>4

~copy <funct f_a_i>~

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_.INF((NEW: inference): bool;

3 AX: inference; IN: instance; PREM: clause il IS_MEM_INF(AX, AXIOMS) A EQ__INF(INST_INF(AX, IN), NEW) A IS_MEM_CL(PREM,P~EMISES(AX)) A NON_RED_I(IN, UNION_O(U_OPS_FO(CONSEQUENT(CONCLUSION(AX))), U_OPS_FO(CONSEQUENT(PEEM))) A EQ_FO(INST30(CONSEQUENT(CONCLUSION(AX)), IN), CONSEQUENT(GOAL)) A EQ_/~O(INST_FO(CONSEQUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF))))

~comment<

I UNIT

LEVEL

f i l t e r _ a n d _ i n s t a n t i a t e ( f_a_ i )

descriptive, pre-algorithmic, set-comprehension over infinite domain ~nference, existential quantification over infinite domains

GOAL removal of the set-comprehension over infinite domain, removal of the existential quantification over infinite domains reduction of f_~_/ to applications of the set-functionals union_m_n and fap_m_n

>4

~install unit <units aux al: non_red__i>~

~comment<

GOAL the existential quantification of ax and prem can be removed by exhaustion of axioms and premises (ax), respectively; the quantification of in is removed by representing in as the join of two instances under which consequent(conclusion(ax)) matches consequent(goal) respectively consequent(prem) matches consequent(conclusion(inf)) (compare development of match_cl)

Page 321: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments o f functions 313

ACTIONS - unfold of non_red_i - application of theorem 6 - predicate logic transformation - application of theorems 5, 18 and 19 - 2 folds by non_red_i

>4

.transf in <funct f_m_i> with rule <f: uff2>~

GIVE NAbIED/~D UNIT FOR pARAMETER: statDF ~funct non_red_i4

~transf in <funct f_a_/> with rule <m_o: mdy_u>4

func t i on F_A_/ (INF: i n f e r e n c e ; GOAL: c lause ; AXIOMS: s e t of i n f ) : s e t of i n f ; SC_INF((NEW: i n f e r e n c e ) : hool ;

3 AX: inference; IN: instance; PREM: clause i! IS~_INF(AX, AXIOMS) A EQ_INF(INST_INF(AX, IN), NEW) A IS_~IEM_CL(PREM, PREMISES(AX)) A (V O: operator H ISDEF(IN, O) <=> ~IS_jMEM_O(O, UNION_O(U_OPS_FO(CONSEQUENT(CONCLUSION(AX))), U_OPS_FFO(CONSEQUENT(PREM))))> ) A EQ_FO(INST30(CONSEQUENT(CONCLUSION(AX)), IN), CONSEQUENT(GOAL)) A EQ_FO(INST_FO(CONSEQUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF))))

CONDITION FULFILLED? DETERMINATE[O] -y~

~ t r a n s f in <funct f_a_i> wi th r u l e <theorems: th6>~

func t i on F_A_I(INF: i n f e r ence ; GOAL: c lause ; AXIOMS: s e t of i n f ) : s e t of in f ; SC_INF((NEW: i n f e r e n c e ) : bool ;

3 AX: inference; IN: instance; PREM: clause {! IS_MEM_INF(AX, AXIOMS) A EQ_INF(INST_INF(AX, IN), NEW) ^ IS_MEM_CL(PREM, PREMISES(AX)) A ~(V O: operator II ISDEF(IN, O) ¢~ IS_MEMO(O, U_OPS_.FO(CONSEQUENT(CONCLUSION(AX)))) V IS_MEM_O(O, U_OPS_FO(CONSEOUENT(PREM))))) A EO_FO(INST_FO(CONSEOUENT(CONCLUSION(AX)), IN), CONSEOUENT(GOAL)) ^ EQ_FO(INST_FO(CONSEQUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF))))

GIVE NAME FOR PARAMETER: ! ~i4

GIVE NAME FOR PARAMETER: J ~j4

.transf in <funct f_a_i> with rule <b: ay_nal>4 ~transf in <funct f_a_i> with rule <b: ay_aal>4 * t r a n s f in <funct f_n_R> wi th ru l e <b: ay_aal>~

,transf in <funct f_a_i> with rule <p: eno_ar> inverted~

f u n c t i o n F_A_/ (INF: in fe rence ; GOAL: c lause ; AXIOMS: s e t of i n f ) : s e t of i n f ; SC_/NF((NEW: i n f e r e n c e ) : bool ;

3 AX: i n f e r ence ; IN: i n s t a n c e ; PREM: c l a u s e {} IS_MEM_INF(AX, AXIOMS) A EO_/NF(INST_/NF(AX, IN), NEW) A IS_~M_CL(PREM, PREMISES(AX)) ^ ~((3 I: instance U q J: instance II V O: operator l{ (ISDEF(I, O) ¢:> IS_MEM_O(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX) ) )) ) A (ISDEF(J, O) ¢:~ IS_J~-~_O(O, U_OPS_FO(CONSEQUENT(PREM))))A (JOINABLE(I, J)A EQ_~I(IN, JOIN_I_I(I, J)))) A (EO_FO(INST_FO(CONSEOUENT(CONCLUSION(AX)), IN), CONSEOUENT(GOAL) ) A EO_FO(INST_FO(CONSEOUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF) ) ) ) )~ )

Page 322: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

314 IV.3 INFERENCE, CLAUSE, and FORMULA

CONDITION FULFILLED? IS_EMPTYSORT[instance]

.transf in <funct f_a_i> with rule <p: eno_ar> inverted-

function F_jk_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_.INF((NEW: inference): bool;

3 AX: inference; IN: instance; PREM: clause II IS_MEM_INF(AX, AXIOMS) A EQ_INF(INST_.INF(AX, IN), NEW) A IS_MEM_CL(PREM, PREMISES(AX)) A (3 I: instance U ((3 J: instance I[ V O: operator II (ISDEF(I, O) ¢=> IS_MEMO(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX))))) A (ISDEF(J, O) ¢~ IS_MEM_O(O, U_OPS_FO(CONSEOUENT(PREM)))) A (JOINABLE(I, J) A EQ_/(IN~ JOIN_I_I(I, J)))) A (EQ_FO(INST_.FO(CONSEQUENT(CONCLUSION(AX)), IN), CONSEQUENT(GOAL)) A EQ_FO(INST_FO(CONSEQUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF))))) ))

CONDITION FULFILLED? IS_EMPTYSORT[instance] mn~

*transf in <funct f_a_i> with rule <p: ano_ar> inverted4

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC__INF((NEW: inference): bool;

3 AX: inference; IN: instance; PREM: clause 111S_MEM_INF(AX, AXIOMS) A EQ_INF(INST_.INF(AX, IN), NEW) A IS_MEM_CL(PREM, PREMISES(AX)) A (3 I: instance II 3 J: instance II ((V O: operator II (ISDEF(I, O) ¢=> IS_MEM_O(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX))))) A (ISDEF(J, O) <=> IS_MEMO(O, U_OPS_FO(CONSEQUENT(PREM)))) A (JOINABLE(I, J) EQ_I(IN, JOIN_I_I(I, J)))) A (EQ_FO(INST__FO(CONSEOUENT(CONCLUSION(AX)), IN), CONSEQUENT(GOAL)) A EQ_.FO(INST_FO(CONSEOUENT(PREM), IN), CONSEOUENT(CONCLUSION(INF))))) ))

CONDITION FULFILLED? IS_EMPTYSORT[operator~ ran4

~transf in <funct f_a_i> with rule <b: cv_eq_iai>4

.name in <funct f_a_i> with~

function F_A_Z (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): bool;

3 AX: inference; IN: instance; PREM: clause II IS_MEM_INF(AX, AXIOMS) A EQ_INF(INST__INF(AX, IN), NEW) A IS_MEM_CL(PREM, PREMISES(AX)) A (3 I: instance II 3 J: instance il ~ O: operator II (ISDEF(I, O) :=> IS_MEMO(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX))))) A (IS_~M_O(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) ==> ISDEF(I, 0)) A ((ISDEF(J, O) ==> ISmMEM_O(O, U_OPS30(CONSEQUENT(PEEM)))) A (IS_MEMO(O, U_OPS_FO(CONSEQUENT(PREM))) =~ ISDEF(J, 0))) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J))) A (EQFO(INST_FO(CONSEQUENT(CONCLUSION(AX)), IN), CONSEQUENT(GOAL)) A EQ_.FO(INST_FO(CONSEQUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF))))) ))

GIVE NAME FOR NEXT UNIT: *el04

*transf in <expr elO> with rule <b: cy._a>* .transf in <expr elO> with rule <b: ay_aal>4 ~transf in <expr elO> with rule <p: ady_a>~ ~transf in <expr elO> with rule <p: ady_.a>.

Page 323: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3 .2 Developments o f f u n c t i o n s 315

~transf in <expr elO> with rule <p: arm_.ne>4

(V O: operator II (IS_MEMO(O, U_OPS_/PO(CONSEQUENT(CONCLUSION(AX)))) =# ISDEF(I, 0)) A ((ISDEF(I, O) ~ IS_MEMO(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX))))) A ((ISDEF(J, O) ~ IS_MEMO(O, U_OPS_.FO(CONSEQUENT(P~EM)))) A (IS_MEM_O(O, U_OPS_FO(CONSEQUENT(PREM))) =~ ISDEF(J, 0))))) A ((V O: operator [I JOINABLE(I, J) EQ_/(IN, JOIN_I_I(I, J)))) A ((V O: operator II EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), IN), CONSEQUENT(GOAL)) A EQ..FO(INST_FO(CONSEQUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF)))))

CONDITION FULFILLED? IS_EMPTYSORT[operator] mn4

CONDITION FULFILLED? IS_EMPTYSORT[operator] mn~

btransf in <expr elO> with rule <p: ady_a>4 ~transf in <expr elO> with rule <b: ay_aal> inverted4 ~transf in <expr elO> with rule <p: ady__a>~ ~transf in <expr elO> with rule <h: ay__aal>4 .transf in <expr elO> with rule <b: cy_a>. ~transf in <expr elO> with rule <b: ay._aal>~ ~transf in <expr elO> with rule <b: ay_aal> inverted4 ~transf in <expr elO> with rule <b: ay_aal> inverted4 ~transf in <expr elO> with rule <b: cy_a>~ ~transf in <expr elO> with rule <b: ay_aal> inverted4

~ t r a n s f in <expr elO> with rule <theorems: th5> inverted4

(Y O: operator II (ISDEF(I, O) ~ IS_MEMO(O, U_OPS_FO(CONSEqUENT(CONCLUSION(AX))))) A (ISDEF(J, O) ~ IS_MEM_O(O, U_OPS_FO(CONSEqUENT(PREM))))) A (Y O: operator II IS_MEM_O(O, U_OPS_FO(CONSEQUENT(PREM))) ~ ISDEF(J, 0)) A (~EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), IN), CONSEQUENT(GOAL)) A (Y O: operator II IS_MEM_O(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) ISDEF(I, 0)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))~ A EQ_FO(INST_FO(CONSEQUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF))))

*transf in <expr elO> with .transf in <expr elO> with ~transf in <expr elO> with btransf in <expr elO> with ~transf in <expr elO> with ~transf in <expr elO> with ~transf in <expr elO> with

rule <b: ay__aal>4 rule <b: ay_aal>4 rule <b: cy_a>4 rule <h: ay_aal> inverted. rule <b: ay_aal> inverted~ rule <b: cy_a>~ rule <b: ay_aal> inverted.

~transf in <expr elO> with rule <theorems: thl8>-

(V O: operator II (ISDEF(I, O) ~ IS_MEM_O(O, U_OPS_FO(CONSEOUENT(CONCLUSION(AX))))) A (ISDEF(J, O) ==) IS_MEM_O(O, U_OPS_FO(CONSEOUENT(PREM))))) A (EQ_FO(INST_FO(CONSEQUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF))) A (V O: operator II IS_MEMO(O, U_OPS_FO(CONSEQUENT(PREM))) =~ ISDEF(J, 0)) A (JOINABLE(I, J) A EQ..I(IN, (JOIN_/_I(I, J)) )) A (EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL)) A (V O: operator II IS_MEMO(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) =~ ISDEF(I, 0))))

~transf in <expr elO> with rule <theorems: th19>4

(V O: operator II (ISDEF(I, O) ~ IS_MEM_O(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX))))) A (ISDEF(J, O) =~ IS_MEM_O(O, U_OPS_FO(CONSEQUENT(PREM))))) A (EQ_FO(INST_FO(CONSEQUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF))) A

Page 324: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

316 IV.3 INFEI~ENCE, CLAUSE, and FONMULA

(V O: operator II IS_MEM_O(O, U_OPS_FO(CONSEQUENT(PREM))) ~ ISDEF(J, 0)) A ((JOINABLE(I, J)> A EQ_I(IN, JOIN_/_I(J, I))) A (EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL)) A (V O: operator II IS_MEMO(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) ~ ISDEF(I, 0))))

.transf in <expr elO> with rule <theorems: th5> inverted-

(V O: operator II (ISDEF(I, O) ~ IS_MEM_O(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX))))) A (ISDEF(J, O) ~ IS_MEM_O(O, U_OPS_.FO(CONSEQUENT(PI~EM))))) A (~EQ__FO(INST_FO(CONSEQUENT(PREM), IN), CONSEQUENT(CONCLUSION(INF))) A (V O: operator II IS_MEM_O(O, U_OPS_FO(CONSEQUENT(PREM))) ==> ISDEF(J, 0)) A (JOINABLE(J, 1) A EQ_I(IN, JOIN_I_I(J, I)))) A (EQ_.FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL)) A (V O: operator II IS_MEM_O(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) ~ ISDEF(I, 0))))

~transf in <expr elO> with rule <theorems: thl8>-

(V O: operator II (ISDEF(I, O) ~ IS_MEM_O(O, U_OPS_FO(CONSEqUENT(CONCLUSION(AX))))) A (ISDEF(J, O) =~ IS_MEM_O(O, U_OPS_FO(CONSEqUENT(PREM))))) A (EQ_FO(INST_FO(CONSEqUENT(PREM), J), CONSEqUENT(CONCLUSION(INF))) A (V O: operator II IS_MEM_O(O, U_OPS_FO(CONSEquENT(PREM))) =~ ISDEF(J, 0)) A (JOINABLE(J, I) A EQ_I(IN, ~JOIN_I_I(J, I)) )) A (EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL)) A (V O: operator II IS_MEM_O(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) =~ ISDEF(I, O))))

~transf in <expr elO> with rule <theorems: thlg>4

(V O: operator II (ISDEF(I, O) ~ IS_MEM_O(O, U_OPS_FO(CONSEqUENT(CONCLUSION(AX))))) ^ (ISDEF(J, O) =~ IS_MEM_O(O, U_OPS__FO(CONSEGUENT(PREM))))) A (EQ__FO(INST_FO(CONSEQUENT(PEEM), J), CONSEQ[~NT(CONCLUSION(INF))) A (V O: operator II IS_MEMO(O, U_OPS_.FO(CONSEqUENT(PREM))) ~ ISDEF(J, 0)) A (~JOINABLE(J, I)) A EQ_I(IN, JOIN_I_I(I, J))) A (EQ_.FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL)) A (V O: operator II IS_jMEM_O(O, U_OPS_/PO(CONSEQUENT(CONCLUSION(AX)))) =~ ISDEF(I, 0))))

*transf in <expr ~transf in <expr ~transf in <expr *transf in <expr .transf in <expr ~transf in <expr ~transf in <expr ~transf in <expr

elO> with rule <b: cy_a>* elO> with rule <b: ay_aal> inverted4 elO> with rule <b: cy..a>~ elO> with rule <p: ady_a>~ elO> with rule <b: ay_Jaal>4 elO> with rule <b: ay_aal> inverted~ elO> with rule <p: ady_a> inverted. elO> with rule <b: ev_eq_iai> inverted4

~transf in <expr elO> with rule <f: ff2>4

(V O: operator I[ ISDEF(J, O) ~ IS_MEMO(O, U_OPS_FO(CONSEOUENT(PREM)))) A (((V O: operator 11 ISDEF(I, O) ¢~ IS_MEMO(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))))) A ((V O: operator II IS_jMEM_O(O, U_OPS_FO(CONSEQUENT(PREM))) ~> ISDEF(J, 0)) A EQ_FO(INST_FO(CONSEQUENT(PREM), J), CONSEqUENT(CONCLUSION(INF))) A (JOINABLE(I, J) A EQ__I(IN, JOIN_I_I(I, J))) A EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL))))

GIVE NAMED/bIAHKED UNIT FOR PARAMETER: statDF -funct non_red_i~ CONDITION FULFILLED? DEFINED~ O: operator II ISDEF(I, O) ¢~

IS_MEMO(O, U_OPS_FO(CONSEQUENT(CONCLUSION(AX))))] DEFINED[NON_RED_I(I, U_OPS30(CONSEQUENT(CONCLUSION(AX))))]

.y4

Page 325: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I V . 3 . 2 Developments of functions 317

.transf in <expr elO> with rule <b: ay_aal> inverted. -transf in <expr elO> with rule <b: ay_aal> inverted. ~transf in <expr elO> with rule <b: ay_aal> inverted4 -transf in <expr elO> with rule <b: cy__a>4 ~transf in <expr elO> with rule <b: ay_aal>. .transf in <expr elO> with rule <b: ay_aal>. ~transf in <expr elO> with rule <b: ay_aal>. .transf in <expr elO> with rule <b: ay_aal> inverted. .transf in <expr elO> with rule <p: ady_a> inverted. ~transf in <expr elO> with rule <b: cv_eq_iai> inverted-

*transf in <expr elO> with rule <f: ff2>-

((V O: operator II ISDEF(J, O) ¢~ IS_MEM_O(O, U_OPS_FO(CONSEQUENT(PREM))))) A (NON_RED_.I(I, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) A (EQ_FO(INST_FO(CONSEQUENT(PREM), J), CONSEQUENT(CONCLUSION(INF))) A ((JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J))) A EQ_FO(INST_.FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL)))))

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF .funct non_.red_/, CONDITION FULFILLED? DEFINED[V O: operator II ISDEF(J, O) ¢~ IS_MEM_O(O, U_OPS_FO(CONSEQUENT(PREM)))] ==~

DEFINED[NON_RED_I(J, U_OPS_FO(CONSEQUENT(PREM)))] - y -

.transf in <expr elO> ~transf in <expr elO> ~transf in <expr elO> ~transf in <expr elO> .transf in <expr elO> ~transf in <expr elO> .transf in <expr elO>

with rule <b: ay_aal> inverted. with rule <b: cy_a>. with rule <b: ay_aal>. with rule <b: ay__aal> inverted. with rule <b: ay_aal> inverted4 with rule <b: cy_a>. with rule <b: ay_aal> inverted.

.comment<

GOAL in is now represented as join of i and j; the quantification of i and j is removed next, they are obtained by matching consequent(conclusion(ax)) against consequent(goal) and consequent(prem) against consequent(conclusion(inf)); both developments are done in parallel

ACTIONS - introduction of set-comprehension making use of theorem 2 - fold of match_fo

>.

.transf in <expr elO> with rule <theorems: th2>-

~NON_RED_I(I, U_OPS_.FO(CONSEQUENT(CONCLUSION(AX)))) A EQ_FO(INST_FO(CONSEOUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL))) A (~NON_RED_I(J, U_OPS_.FO(CONSEQUENT(PREM))) A EO_.FO(INST_.FO(CONSEQUENT(FREM), J), CONSEOUENT(CONCLUSION(INF)))) A (JOINABLE(I, J) A EO_I(IN, JOIN_/_I(I, J))))

btransf in <expr elO> with rule <u_i: uis_m>4

((IS_MEM_I(I, BASE30(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL))) A NON__RED_I(I, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) A EQ_.FO(INST_.FO(CONSEOUENT(CONCLUSION(AX)), I), CONSEOUENT(GOAL)))) A (((IS_MEM_I(J, BASE_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))

Page 326: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

318 IV.3 INFERENCE, CLAUSE, and FOf~MULA

NON_RED_I(J, U_OPS_FO(CONSEQUENT(PREM))) A EQ_FO(INST_.FO(CONSEQUENT(PREM), J), CONSEQUENT(CONCLUSION(INF))))) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I__I(I, J))))

GIVE NAME FOR PARAMETER: X ~i-

CONDITION FULFILLED? DETERMINATE[NON_RED_/(I, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) A

EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL))] my.

CONDITION FULFILLED? false E D IS__MEM_/(I, BASE_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)))

DEFINED[NON~ED_I(I, U_OPS_FO(CONSEQUENT<CONCLUSION(AX)))) A EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL))]

my.

GIVE NAME FOR PARAMETER: _X ~i-

CONDITION FULFILLED? DETE~dINATE[NON_.RED_/(I, U__OPS_FO(CONSEQUENT(PREM))) A

EQ_FO(INST_FO(CONSEQUENT(PREM), I), CONSEQUENT(CONCLUSION(INF)))] my.

CONDITION FULFILLED? false ~D IS_MEM_I(J, BASE_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))

DEFINED[NON_RED_I(I, U_OPS_FO(CONSEQUENT(PREM))) A EQ_FO(INST_FO(CONSEQUENT(PREM), I), CONSEQUENT(CONCLUSION(INF)))]

~transf in <expr elO> with rule <u_i: ucv_s_.m>.

IS_MEM_I(I, ~UNION_I_I((I: instance): bool; NON_RED_I(I, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) ̂

EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL)), (I: instance): set of i; MK_SING_I(I))(BASE_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)))~ ) A (IS_MEM_I(J, ~qJNION_I_I((I: instance): bool; NON_RED_I(I, U_OPS_FO(CONSEQUENT(PREM))) ^ EQ_FO(INST_FO(CONSEQUENT(PREM), I), CONSEQUENT(CONCLUSION(INF))), (I: instance): set of_i; MK_SING_I(I)) (BASE_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))~ ) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J))))

CONDITION FULFILLED? DETEI~4INATE[BASE_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL))~ ~y4

CONDITION FULFILLED? DETEI~4INATE[BASE_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF)))~ ~y~

~trRnsf in <expr elO> with rule <theorems: th2> inverted4

I S ~ ( I , SC_/((I: instance): bool; ~IS_MEM._I(I, BASE_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL))) A NON_BED_I(I,U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) A EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL))~ )) A (IS_MEM_/(J, SC_I((I: instance): bool; {IS_MEM_/(I, BASE_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF)))) A NON_RED_I(I, U_OPS_FO(CONSEQUENT(PREM))) ^ EQ_FO(INST_FO(CONSEQUENT(PREM), I), CONSEQUENT(CONCLUSION(INF)))~ )) ^ (JOINABLE(I, J) A EQ_I(IN, JOIN_/_I(I, J))))

Page 327: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of functions 319

~install unit <units aux al: match_fo>.

~transf in <expr elO> with rule <f: ff2>-

IS_MEM_I(I, (SC_I((I: i n s t a n c e ) : bool ; NON_BED_I(I, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) A EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL)))) ) A IS_MEM__I(J, (SC__I((I: instance): bool; NON_RED_I(I, U_OPS_FO(CONSEQUENT(PREM))) A EQ_FO(INST_FO(CONSEQUENT(PREM), I), CONSEQUENT(CONCLUSION(INF))))) ) A (JOINABLE(I, J) ~ EQ_I(IN, JOIN_/_/(I, J))))

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct match_fo. CONDITION FULFILLED? DEFINED[SC_I((I: instance): bool;

NON__RED_I(I, U_OPS_FO(CONSEQUENT(CONCLUSION(AX)))) A EQ_FO(INST_FO(CONSEQUENT(CONCLUSION(AX)), I), CONSEQUENT(GOAL)))]

DEFINED[MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL))]

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~ftmct match_fo. CONDITION FULFILLED? DEFINED~SC_I((I: instance): boo1;

NON_RED__I(I, U_OPS_FO(CONSEQUENT(PREM))) ^ EQ_FO(INST_FO(CONSEQUENT(PREM), I), CONSEQUENT(CONCLUSION(INF))))] =:) DEFINED[MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF)))]

my.

~transf in <expr elO> with rule <h: ay_aal> inverted4

~com~ent<

J GOAL elimination of quantification of i and j

I ACTIONS - application of theorem 9

>4

~transf in <funct f_a_i> with rule <theorems: th9>-

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_/NF((NEW: inference): bool;

3 AX: inference; IN: instance; PREM: clause II IS_MEM_INF(AX, AXIOMS) A EQ_INF(INST_INF(AX, IN), NEW) A IS_MEM_CL(PREM, PREMISES(AX)) A ((3 I: instance [J 3 J: instance n IS_MEM_I(I,MATCB_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL))) A IS_MEM_I(J, MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF)))) A (JOINABLE(I, J) EQ_I(IN, JOIN_I_I(I, J))))) )

~com~ent<

J 'GoAL can therefore be resolved by exhaustion (functional ex_cl)

j ..... ACTIONS - sequentialisation of quantification

predicate logic transformations fold by ex_cl

>4

existential qunatification of clause prem is bound by premises (ax) and

Page 328: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

320 IV.3 INFERENCE, CLAUSE, and FOI~MULA

~transf in <funct f_a_i> with rule <p: est_3_lll>.

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set o f inf): set of inf; SC_INF((NEW: inference): bool;

(3 AX: inference; IN: instance; PREM: clause [[ IS_MEM_.INF(AX, AXIOMS) A EQ_INF(INST_/NF(AX, IN), NEW) A IS_MEM_~L(PREM, PREMISES(AX)) A IS_MEM_/(IN, JOIN_SET_SET(MATCH_~O(CONSEQUENT(CONCLUSION(AX)), CONSEOUENT(GOAL)), MATCH_FO(CONSEOUENT(PREM), CONSEOUENT(CONCLUSION(INF)))))) )

~ t r a n s f in <func t f_a_i> wi th r u l e <b: ay_aa l> .

~transf in <funct f_a_l> with rule <p: eno_al>.

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): hool;

3 AX: inference lJ 3 IN: instance II (3 PREM: clause If IS_MEM_INF(AX, AXIOMS) A EO_INF(INST_INF(AX, IN), NEW) A (IS_MEM_CL(PREM, PREMISES(AX)) A IS_MEM_I(IN, JOIN_SET_SET(MATCH_FO(CONSEOUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEOUENT(PREM), CONSEOUENT(CONCLUSION(INF))))))) )

CONDITION FULFILLED? IS_EMPTYSORT[clause] mn4

.transf in <funct f_a_i> with rule <b: ch_n_sa>* ~transf in <funct f_n_i> with rule <b: si_satr> inverted.

~transf in <funct f_a_i> with rule <p: ercv_u> inverted.

function F_A_.I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): hool;

3 AX: inference Jl 3 IN: instance tl IS_MEM_INF(AX, AXIOMS) A EO_INF(INST_INF(AX, IN), NEW) A ((3 PREM: clause II IS_MEM_CL(PREM, PREMISES(AX))

true A IS_MEM_I(IN, JOIN_SET_SET(MATCH_FO(CONSEOUENT(CONCLUSION(AX)), CONSEOUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEOUENT(CONCLUSION(INF))))))) )

~transf in <funct f__a_i> with rule <f: becon> inverted.

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: ifiference): hool;

B AX: inference II 3 IN: instance I{ IS_MEM__INF(AX, AXIOMS) A EO_INF(INST_/NF(AX, IN), NEW) A (B (PREM: clause II IS_MEM_CL(PREM, PREMISES(AX))

(true)) II (IS_MEM_I(IN, JOIN_SET_SET(MATCH_F0(CONSEOUENT(CONCLUSION(AX)), CONSEOUENT(GOAL)), MATCH_FO(CONSEOUENT(FREM), CONSEOUENT(CONCLUSION(INF)))))) ))

GIVE NAME FOR PARAMETER: X ~prem.

CONDITION FULFILLED? DEF_.DET[PREM~ ~y4

CONDITION FULFILLED? {PREM} ~ KNOWN~true] ~y~

GIVE NAME FOR PARAMETER: m ~clause*

CONDITION FULFILLED? PREM isof_~ubmode c l a u s e

GIVE NAME FOR PARAMETER: n ~bool*

Page 329: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3 .2 Developments o f f u n c t i o n s 321

CONDITION FULFILLED? t r u e isof_submode boo l

GIVE NAME FOE PARAMETER: X *prem4

CONDITION FULFILLED? DEF_DET[PREM]

CONDITION FULFILLED? (PREM} ~ KNOWN[IS__MEM_I(IN, JOIN_SET_SET(MATCII_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF)))))]

GIVE NAME FOR PARAMETER: m ~clause~

CONDITION FULFILLED? PREM isof_submode clause ~y~

GIVE NAME FOR PARAMETER: n ~boo14

CONDITION FULFILLED? IS_MEM_I(IN, JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))) isof__submode bool

my~

~transf in <funct f_a_i> with rule <f: ab_l>-

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): bool;

3 AX: inference II 3 IN: instance II IS_MEM_INF(AX, AXIOMS) A EQ_INF(INST_INF(AX, IN), NEW) A ((3 (PREM: clause II IS_MEM_CL(PREM, PREMISES(AX))

((PREM: clause): boel; true)(PREM)) II ((PREM: clause): bool; IS_MEM_I(IN, JOIN_$ET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))))(PREM))) )

GIVE NAME FOR PARAMETER: X ~s4

GIVE NAME FOR PARAMETER: m ~set of clq

GIVE NAME FOR PARAMETER: n ~boo14

CONDITION FULFILLED? 3 (PREM: clause II IS_MEM_CL(PREM, PREMISES(AX)) A ((PREM: clause): bool; true)(PREM))

II ((PREM: clause): bool; IS_MEM_I(IN, JOIN_SET_SET(MATCH_FO(CONSEQUENT( CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM),CONSEQUENT(CONCLUSION(INF))))))(PREM) isof_submode bool

~y4

GIVE NAMED/MARKED UNIT FOR PARAMETER: G ~in <funct f_.a_i>.

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): bool;

3 AX: inference II 3 IN: instance II IS_MEM_INF(AX, AXIOMS) A EQ_INF(INST_INF(AX, IN), NEW) A (3 (PREM: clause II IS_MEM_CL(PREM, ~PREMISES(AX)) ) A ((PREM: clause): bool; true)(PREM)) II ((PREM: clause): bool; IS_MEM_I(IN, JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))))(PREM)))

CONDITION FULFILLED? DEFINED[PREMISES(AX)] ~y4

Page 330: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

322 IV.3 INFERENCE, CLAUSE, and FORMULA

CONDITION FULFILLED? PREMISES(AX) isof__submode set of cl ~y~

~install unit <units aux al: ex__cl>~

~transf in <funct f_a_i> with rule <f: al_er>4

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): bool;

3 AX: inference II 3 IN: instance II IS_MEM_INF(AX, AXIOMS) A EQ__INF(INST_INF(AX, IN), NEW) A ((S: set of cl): bool; (3 (PREM: clause II IS_MEM_CL(PREM, S) A ((PREM: clause): bool; true)(PREM)) II ((PREM: clause): bool; IS_MEM_I(IN, JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEOUENT(PREM), CONSEOUENT(CONCLUSION(INF))))))(PREM)) )(PREMISES(AX)))

GIVE NAME FOR PARAMETER: X .x4

CONDITION FULFILLED? NEW[X] ~y4

btransf in <funct f_a_i> with rule <f: ff_f2_fl>4

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): bool;

3 AX: inference [I 3 IN: instance il IS_MEM_INF(AX, AXIOMS) A EQ_INF(INST_INF(AX, IN), NEW) A (((S: set of cl): bool; 3 (X: clause I[ IS_MEM_CL(X, S) A ((X: clause): bool; true)(X)) II ((X: clause): bool; IS__MEM_/(IN, JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_.FO(CONSEQUENT(X), CONSEQUENT(CONCLUSION(INF))))))(X)))(PREMISES(AX)))

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct ex_cl~ CONDITION FULFILLED? DEFINED[(S: set of el): bool;

3 (X: clause II IS_MEM_CL(X, S) ~ ((X: clause): bool; true)(X)) II ((X: clause): bool; IS_MEM_I(IN, JOIN_SET_SET(MATCH_FO(CONSEOUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH30(CONSEOUENT(X), CONSEOUENT(CONCLUSION(INF))))))(X)]

DEFINED[EX_CL((X: clause): bool; true, (X: clause): bool; IS_MEMI(IN, JOIN_SET_SET(MATCH_FO(CONSEOUENT(CONCLUSION(AX)), CONSEOUENT(GOAL)), MATCH_FO(CONSEQUENT(X), CONSEOUENT(CONCLUSION(INF))))))~

~y~

.coTmment<

l >4

GOAL !

existential quantification of instance in is now also bound and can also I be resolved by exhaustion (functional ex_i) J

ACTIONS - conversion of functional ex_cl to union_cl__i - predicate logic transformations - fold of ex_/

-transf in <funct f_a_i> with rule <u_cl_i: mcy_u> inverted4

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_~NF((NEW: inference) : bool;

3 AX: inference i| 3 IN: instance II IS_j~__INF(AX, AXIOMS) A EQ_INF(INSTjNF(AX, IN), NEW) A ~EX_CL((X: clause): bool; true, (X: clause): bool; IS_MEM_I(IN, JOIN_SET_SET(MATCH_FO(CONSEOUENT(CONCLUSION(AX)),

Page 331: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I V . 3 . 2 Developments o f f u n c t i o n s 323

CONSEOUENT(GOAL) ) , MATCH_FO(CONSEOUENT(X), CONSEOUENT(CONCLUSION(INF) ) ) ) ) ) (PREMISES(AX))) )

CONDITION FULFILLED? DETEI~4INATE[IN~ m-y~

~ t r a n s f in < func t f_a_ i> w i t h r u l e <b: cy_a>4 * t r a n s f in < f u n c t f_a_ i> w i t h r u l e <b: ch_a_sa>4 . t r a n s f in < f u n c t f_a_ i> w i t h r u l e <b: s i _ s a t r > i n v e r t e d .

. t r a n s f in < f u n c t f _ s u / > w i t h r u l e <f: becon> i n v e r t e d 4

f u n c t i o n F_A_/ (INF: i n f e r e n c e ; GOAL: c l a u s e ; AXIOMS: s e t o f i n f ) : s e t o f i n f ; SC_INF((NEW: i n f e r e n c e ) : boo l ;

3 AX: i n f e r e n c e II 3 IN: i n s t a n c e II IS_MEM_/(IN, UNION CL_/((X: c l a u s e ) : b o o l ; t r u e , (X: c l a u s e ) : s e t _ o f _ i ; JOIN_SET_SET(MATCH_FO(CONSEOUENT(CONCLUSION(AX)), CONSEOUENT(GOAL) ), MATCH_FO(CONSEOUENT(X), CONSEQUENT(CONCLUSION(INF) ) ) ) ) (PREMISES(AX))) A ( t r u e ) A (IS_MEM__INF(AX, AXIOMS) A EO_INF(INST_INF(A×, IN), NEW)) )

GIVE NAME FOR PARAMETER: _X ~in~

CONDITION FULFILLED? DEF_DET[IN] ~y4

CONDITION FULFILLED? (IN} c KNOWN[true] ~y~

GIVE NAME FOR PARAMETER: m_ ~instance.

CONDITION FULFILLED? IN isof_submode instance by.

GIVE NAME FOR PARAMETER: n_ ~bool~

CONDITION FULFILLED? true isof__submode bool my4

GIVE NAME FOR PARAMETER: _X ~in4

CONDITION FULFILLED? DEF_DET[IN] m-y4

CONDITION FULFILLED? fIN} c_ KNOWN[IS_MEM_INF(AX, AXIOMS)A EO_INF(INST_INF(AX, IN), NEW)] my~

GIVE NAME FOR PARAMETER: m ~instance4

CONDITION FULFILLED? IN isof_submode instance my4

GIVE NAME FOR PARAMETER: n ~bool~

CONDITION FULFILLED? IS_MEM_INF(AX, AXIOMS) A EO_INF(INST_INF(AX, IN), NEW) isof__submode bool by4

~transf in <funct f_a_i> with rule <f: ab_/>~

Page 332: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

324 IV.3 INFERENCE, CLAUSE, and FORMULA

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set ofinf): set of inf; SC_INF((NEW: inference): bool;

3 AX: inference II (3 IN: instance II IS_MEM_I(IN, UNION_CL_I((X: clause): bool; true, (X: clause): set of_i; JOIN_SET_SET(MATCH_!PO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH__FO(CONSEQUENT(X), CONSEQUENT(CONCLUSION(INF))))) (PREMISES(AX))) A ((IN: instance): hool; true)(IN) A ((IN: instance): hool; IS_MEM_INF(AX, AXIOMS) A EQ_INF(INST_INF(AX, IN), NEW))(IN)) )

GIVE NAME FOR PARAMETER: X ~s~

GIVE NAME FOR PARAMETER: m ~set of i4

GIVE NAME FOR PARAMETER: n ~boo14

CONDITION FULFILLED? 3 IN: ins tance li IS_.MEM_I(IN, UNION_CL_I((X: clause) : bool; t rue , (X: clause):

set_of_i; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEOUENT(GOAL)), MATCH_FO(CONSEQUENT(X), CONSEQUENT(CONCLUSION(INF)))))(PREMISES(AX))) A ((IN: instance): bool; true)(IN) A ((IN: instance): bool; IS_MEM_INF(AX, AXIOMS) A EQ_INF(INST_INF(AX, IN), NEW))(IN) isof_submode bool

~y~

GIVE NAMED/MARKED UNIT FOR PARAMETER: G ~in <funct f_a_i>4

funct ion F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf ; SCjNF((NEW: inference) : bool;

3 AX: inference II 3 IN: ins tance II IS_MEM_I(IN, (UNION_CL_/((X: clause): bool; t rue , (X: clause): se t of i ; 50IN_SET_SET(MATCH_20(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_.FO(CONSEQUENT(X), CONSEQUENT(CONCLUSION(INF))))) (PREMISES(AX)))) A ((IN: instance): bool; true)(IN) A ((IN: instance): bool; IS_MEM_/NF(AX, AXIOMS) A EQ_INF(INST_INF(AX, IN), NEW))(IN))

CONDITION FULFILLED? DEFINED[UNION_CL_I((X: clause): bool; true, (X: clause): set of_i;

JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(X), CONSEQUENT(CONCLUSION(INF)))))(PREMISES(AX))]

~y4

CONDITION FULFILLED? UNION_CL_I((X: clause): bool; true, (X: clause): set_of_i;

JOIN_SET_SET(MATCH_.FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_riO(CONSEQUENT(X), CONSEQUENT(CONCLUSION(INF)))))(FREMISES(AX)) isof_submode set of i

~y4

~install unit <units aux al: ex_i>4

~transf in <funct f_a_i> with rule <f: al_e>4

func t ion F_A_I (INF: inference; GOAL: c lause; AXIOMS: se t of i n f ) : se t of in f ; SC_INF((NEW: inference) : bool;

3 AX: inference I1 ((S: se t of i ) : bool; (3 IN: ins tance 11 IS_MEM_I(IN, S) a ((IN: ins tance) : bool; t r u e ) ( I N ) A ((IN: ins tance) : bool; IS_MEM_INF(AX, AXIOMS)A EO_/NF(INST_INF(AX, IN), NEW)) ( IN)~) (UNION_CL_I((X: clause) : bool; t rue , (X: c lause) : se t_of_i ; JOIN_SET_SET(MATCH_FO(CONSEOUENT(CONCLUSION(AX)), CONSEQUENT(GOAL) ), MATCN_FO(CONSEQUENT(X), CONSEOUENT(CONCLUSION(INF) ) ) ) ) (PREMISES (AX)) ) )

GIVE NAME FOR PARAMETER: _Y ~×4

Page 333: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of functions 325

CONDITION FULFILLED? NEW[X] my.

~transf in <funct f_a_i> with rule <p: ercv_u> inverted*

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC__INF((NEW: inference): hool;

3 AN: inference II ((S: set_of i): bool; (3 X: instance II IS_MEM_I(X, S) A ((X: instance): bool; true)(X) A ((X: instance): hool; IS_3MEM_INF(AX, AXIOMS) A EQ_.INF(INST__INF(AX, X), NEW))(X)) )(UNION_CL_I((X: clause): bool; true, (X: clause): set_of_i; JOIN_SET__SET(MATCH_.FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(X), CONSEQUENT(CONCLUSION(INF))))) (PREMISES(AX))))

.transf in <ftmct f_a_i> with rule <f: ff_I2_fl>*

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): hool;

3 AX: inference |I (((S: set_of_i): bool; 3 (X: instance II IS_MEM_I(X, S) ~ ((X: instance): bool; true)(X)) II ((X: instance): bool; IS_MEM_/NF(AX, AXIOMS) A EQ_.INF(INST_INF(AX, X), NEW))(X)))(UNION_CL_I((X: clause): bool; true, (X: clause): set_of_i; JOIN_SET__SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(X), CONSEQUENT(CONCLUSION(INF))))) (PREMISES(AX))))

GIVE NAMED/MARKED UNIT FOR PARb24ETER: statD_~F ~funct ex_i. CONDITION FULFILLED? DEFINED[(S: set of i): bool; 3 (X: instance J! IS_MEM_I(X, S) A ((X: instance): bool;

true)(X)) II ((X: instance): bool; IS_MEM_/NF(AX, AXIOMS) A EQ_INF(INST_INF(AX, X), NEW))(X)] =~

DEFINED[EX_I((X: instance): bool; true, (X: instance): bool; IS_MEM_INF(AX, AXIOMS) A EQ_INF(INST_INF(AX, X), NEW))~

~transf in <funct f_a_i> with rule <u_/: eno_al>4

function F_A./ (INF: inference; GOAL: clause; AXIOMS: set_of_inf): set of inf; SC_INF((NEW: inference): hool;

3 AX: inference [! (EX__I((X: instance): bool; true, (X: instance): bool; IS_MEM_/NF(AX, AXIOMS) A EQ_/NF(INST_INF(AX, X), NEW))(UNION_CL_I((X: clause): bool; true, (X: clause): set of_i; JOIN_SET_SET(MATCH_.FO(CONSEQUENT( CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(X), CONSEQUENT( CONCLUSION(INF)))))(PREMISES(AX)))) )

CONDITION FULFILLED? DEF_DET[IS_MEM_INF(AX, AXIOMS)] my.

*transf in <funct f_a_i> with rule <b: ch_a_sa>*

~comment<

I GOAL removal of existential quantification of inference ax

I ACTIONS - analogously to steps above

>4

~transf in <funct f_a_i> with rule <p: ercv_u> inverted4

Page 334: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

326 IV.3 INFERENCE, CLAUSE, and FORMULA

function F_.A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): bool;

(3 AX: inference II IS_MEM_INF(AX, AXIOMS) A EX_/((X: instance): bool; true, (X: instance): bool; EQ_INF(INST_/NF(AX, X), NEW)) (UNION_CL_I((X: clause): bool; true, (X: clause): set of_i; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(X), CONSEQUENT(CONCLUSION(INF)))))(PREMISES(AX)))) )

.transf in <funct f_a_/> with rule <b: si_satr> inverted.

*transf in <funct f_a_i> with rule <f: al_ab>~

funct ion F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf ; SC_INF((NEW: inference) : bool;

3 (AX: inference II IS_MEM_INF(AX, AXIOMS) A true) II EX_I((X: ins tance) : bool; t rue , (X: ins tance) : bool; EQ_INF(INST_INF(AX, X), NEW)) (UNION_CL_I(((X: c lause) : bool; t r ue ) , ~(X: c lause) : se t of_i; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(X), CONSEQUENT(CONCLUSION(INF))))~ )(PREMISES(AX))))

GIVE NAME FOR PARAMETER: Y ~prem4

CONDITION FULFILLED? NEW[PREM] ~y4

GIVE NAME FOR PARAMETER: Y .prem4

CONDITION FULFILLED? P~W[PREM] ~y~

. t r a n s f in <funct f_a_i> with ru le <f: al_ab>4

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC__INF((NEW: inference): bool;

3 (AX: inference II IS_MEM_INF(AX, AXIOMS) ~ true) [I EX_/(((X: instance): bool; true) , ((X: instance): bool; EQ_INF(INST_INF(AX, X), NEW)) ) (UNION_CL_I((PREM: clause): hool; true, (PREM: clause): set_of i; JOIN_SET_SET(MATCH_.FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEOUENT(PREM), CONSEOUENT(CONCLUSION(INF)))))(PREMISES(AX))))

GIVE NAME FOR PARAMETER: Y .in~

CONDITION FULFILLED? NEW[IN] ~y4

GIVE NAME FOE PARAMETER: Y ~in.

CONDITION FULFILLED? NEW[IN] ~y4

.transf in <funct f_a_i> with rule <f: becon> inverted4

funct ion F_A_/ (INF: inference; GOAL: clause; AXIOMS: se t of i n f ) : se t of inf ; SC_/NF((NEW: inference) : bool;

3 (AX: inference II IS_MEM_/NF(AX, AXIOMS) A ~ t rue) ) II (EX_I((IN: ins tance) : bool; t rue , (IN: ins tance) : bool; EQ_/NF(INST_INF(AX, IN), NEW)) (UNION_CL_/((PREM: clause) : bool; true, (PREM: clause) : set_of_i; JOIN_.SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_.FO(CONSEOUENT(PREM), CONSEQUENT(CONCLUSION(INF) ) ) ) ) (PREMISES (AX)) )> )

Page 335: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of functions 327

GIVE NAME FOR PARAMETER: X ~ax.

CONDITION FULFILLED? DEF_DET[AX] my4

CONDITION FULFILLED? (AX} ~ KNOWN[true~ ~y4

GIVE NAME FOR PARAMETER: m ~inference4

CONDITION FULFILLED? AX isof_submode inference .y4

GIVE NAME FOR PARAMETER: n ~bool-

CONDITION FULFILLED? true isof__submode bool ~y4

GIVE NAME FOR PARAMETER: X ~ax*

CONDITION FULFILLED? DEF_DET[AX] ~y4

CONDITION FULFILLED? {AX} ~ KNOWN[EX_I((IN: instance): bool; true, (IN: instance): hool; EQ_INF(INST_INF(AX, IN), NEW))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of_i; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT( GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF)))))(PREMISES(AX)))~

~y4

GIVE NAME

CONDITION

GIVE NAME

CONDITION

FOR PARAMETER: m ,inference4

FULFILLED? AX isof_submode inference

FOR PARAMETER: n ~bool*

FULFILLED? EX_I((IN: instance): bool; true, (IN: instance): bool;

EQ_INF(INST_INF(AX, IN), NEW))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of i; JOIN_SET_SET(MATCHDO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT( GOAL) ), MATCNj~O(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF) ) ) ) ) (PREMISES(AX)) ) isof_submode bool

,y4

.transf in <funct f_a_i> with rule <f: al_er>~

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of i n f ) : set of inf; SC_INF((NEW: inference): bool;

~3 (AX: inference II IS_MEM_INF(AX, AXIOMS) A ((AX: inference): bool; true)(AX)) II ((AX: inference): bool; EX_I((IN: instance): bool; true, (IN: instance) : boo1; EQ_INF(INST_INF(AX, IN), NEW)) (UNION_CL_I((PREM: clause) : bool; true, (PREM: clause) : set_of_i; JOIN_SET_SET(MATCIL_FO(CONSEQUENT(CONCLUSION(AX) ), CONSEQUENT(GOAL) ), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF) ) ) ) ) (PREMISES(AX)) ) ) (AX)~)

GIVE NAME FOR PARAMETER: _Y ~x~

CONDITION FULFILLED? NEW[X] ~y4

Page 336: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

328 IV.3 INFERENCE, CLAUSE, and FOI~4ULA

~transf in <funct f_a_i> with rule <f: ab_l>4

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): bool;

(3 (X: inference [[ IS_MEM_INF(X, AXIOMS) A ((X: inference): bool; true)(X)) II ((X: inference): bool; EX_I((IN: instance): bool; true, (IN: instance): bool; EQ__INF(INST_INF(X, IN), NEW))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set of i; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM),CONSEQUENT(CONCLUSION(INF))))) (PREMISES(X))))(X)))

GIVE NAME FOR PARAMETER: X ~s4

GIVE NAME FOR PARAMETER: m ~set of inf4

GIVE NAME FOR PARAMETER: D ~bool4

CONDITION FULFILLED? 3 (X: inference I[ IS_MEM_INF(X, AXIOMS) A ((X: inference): bool; true)(X)) II ((X:

inference): bool; EX_I((IN: instance): bool; true, (IN: instance): bool; EQ_INF(INST_INF(X, IN), NEW))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of_i; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF)))))(PREMISES(X))))(X) isof_submode bool

my~

GIVE NAMED/MARKED UNIT FOR PARAMETER: G ~in <funct f_a_i>4

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC__INF((NEW: inference): bool;

3 (X: inference I[ IS_MEM_INF(X, (AXIOMS)) A ((X: inference): bool; true)(X)) IN ((X: inference): bool; EX_I((IN: instance): hool; true, (IN: instance): bool; EO_INF(INST_INF(X, IN), NEW))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of_i; JOIN__SET__SET(MATCH_FO(CONSEQUENT(CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH_/D(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))) (PREMISES(X))))(X))

CONDITION FULFILLED? DEFINED[AXIOMS] ~y4

CONDITION FULFILLED? AXIOMS isof__submode set of inf my4

~install unit <units aux al: e×_inf>4

*transf in <funct f_a_A> with rule <f: ff_f2_fl>4

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): bool; (((S: set of inf): bool; 3 (X: inference I[

IS_MEM_INF(X, S) A ((X: inference): bool; true)(X)) [I ((X: inference): bool; EX_I((IN: instance): bool; true, (IN: instance): bool; EQ_INF(INST_INF(X, IN), NEW))(UNION_~L_I((PREM: clause): bool; true, (PREM: clause): set_of i; JOIN_SET_SET(MATCIL_FO(CONSEQb~NT(CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))) (PREMISES(X))))(X)))(AXIOMS))

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF bfunct ex_inf~ CONDITION FULFILLED? DEFINED[(S: set of inf): bool; 3 (X: inference II IS_MEM_~NF(X, S) A ((X: inference):

bool; true)(X)) II ((X: inference): bool; EX_I((IN: instance): bool; INSTB_INF(X,

Page 337: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of funct ions 329

IN), (IN: instance): bool; EQ_INF(INST_INF(X, IN), NEW))(UNION_CL_I((PREM: clause) bool; true, (PREM: clause): set_of_i; JOIN_SET_SET(MATCH_FO(CONSEOUENT( CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH_FO(CONSEOUENT(PREM), CONSEGUENT(CONCLUSION(INF)))))(PREMISES(X))))(X)] DEFINED[EX_INF((X: inference): bool; true, (X: inference): bool;

EX_I((IN: instance): bool; true, (IN: instance): bool; EO_INF(INST_INF(X, IN), NEW))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set of_i; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))) (PREMISES(X))))~

~y4

~conm~ent<

GOAL removal of functional sc_inf (set-comprehension), replacement of sc_inf by union_iLl_iLl (finite set-comprehension)

ACTIONS - algebraic transformations of functionals sc_inf, union_iLl_iLl, ex_inf, filter_inf

>4

~transf in <ftmct f_a_i> with rule <q: eqt_sy>4

function F_A_/ (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): bool; EX__INF((X: inference): bool; true, (X: inference):

bool; EX_I((IN: instance): bool; true, (IN: instance): bool; (EQ_INF(INST_/NF(X, IN), NEW)) )(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of_i; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH_/D(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))) (PREMISES(X))))(AXIOMS))

GIVE NAME FOR PARAMETER: ~ ~inference-

CONDITION FULFILLED? KIND[INST_/NF(X, IN)~ = inference ~y4

CONDITION FULFILLED? IS_EQUAL_PRE[EQ__INF, inference] ~y4

~transf in <funct f_a_i> with rule <m_inf: msi~k> inverted-

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): bool; EX_INF((X: inference): bool; true, (X: inference):

bool; EX_I((IN: instance): 5ooi; true, (IN: instance): bool; (EO_INF(NEW, INST_INF(X, IN))) )(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of_i; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQ[~NT(CONCLUSION(INF))))) (PREMISES(X))))(AXIOMS))

~transf in <funct f_a_i> with rule <u_i_inf: mcy_u> inverted4

funct ion F_A_I (INF: inference; GOAL: clause; AXIOMS: se t of i n f ) : se t of in f ; SC_/NF((NEW: inference) : bool; EX_INF((X: inference) : bool; t rue , (X: inference) :

bool; ~EX_I((IN: ins tance) : bool; t rue , (IN: ins tance) : bool; IS_MEM_INF(NEW, MK_SING_INF(INST_INF(X, IN) ) ) ) (UNION_CL_I ((PREM: clause) : bool; t rue, (PREM: clause) : se t_of i ; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(X)), CONSEQUENT(GOAL) ), MATCH_~O(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF) ) ) ) ) (P~EMISES(X)) )) ) (AXIOMS))

Page 338: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

330 IV.3 INFERENCE, CLAUSE, and FORMULA

CONDITION FULFILLED? DETENMINATE[NEW~ my.

mtransf in <funct f_a_i> with rule <u_inf_in: mcy_u> inverted4

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; SC_INF((NEW: inference): bool; (EX_INF((X: inference): bool; true, (X: inference):

bool; IS_MEM_INF(NEW, UNION_I_INF((IN: instance): bool; true, (IN: instance): set of inf; MK__SING_INF(INST_INF(X, IN)))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of_i; JOIN_SET_SET(MATCH_FO(CONSEQUENT( CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH__FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF)))))(PREMISES(X)))))(AXIOMS)) )

CONDITION FULFILLED? DETERMINATE[NEW] my.

mtransf in <funct f_a_j> with rule <b: si_satr> inverted.

mtransf in <funct f_a_i> with rule <u_inf: scv_f>4

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set ofinf): set of inf; (SC_INF((NEW: inference): bool; IS_MEM_INF(NEW, UNION_INF_IN((X: inference): 5ooi;

true, (X: inference): set of inf; UNION_I_INF((IN: instance): bool; INSTB_INF(X, IN), (IN: instance): set of inf; MK_SING_INF(INST_INF(X, IN)))(UNION_CL_I((PREM: clause): bool; true~ (PREM: clause): set_of_i; JOIN_.SET_SET(MATCH..FO(CONSEQUENT( CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF)))))(PREMISES(X))))(AXIOMS)) A true))

CONDITION FULFILLED? DETEI~MINATE[UNION_INF_IN((X: inference): bool; true, (X: inference): set of inf;

UNION_I_INF((IN: instance): bool; true, (IN: instance): set of inf; MK_SING_INF(INST_INF(X, IN)))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of i; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(X)), CONSEQUENT( GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))) (PREMISES(X))))(AXIOMS)]

~y4

~transf in <funct f_a_i> with rule <u_inf: in_f> inverted*

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; (FILTER_INF((NEW: inference): bool; true)(UNION_INF__IN((X: inference): bool;

true, (X: inference): set of inf; UNION_I_INF((IN: instance): bool; INSTB_INF(X, IN), (IN: instance): set of inf; MK_SING_INF(INST_INF(X, IN)))(UNION_CL_I((PREM: clause): bool; true, (PI~EM: clause): set of_i; JOIN_SET_SET(MATCH_FO(CONSEQUENT( CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT( CONCLUSION(INF)))))(P]~EMISES(X))))(AXIOMS))>

GIVE NAME FOR PARAMETER: ~ minfs*

CONDITION FULFILLED? DETERMINATE[Lg~ION_/NF_IN((X: inference): bool; true, (X: inference): set of inf;

UNION_I_INF((IN: instance): bool; true, (IN: instance): set of inf; MK_SING_INF(INST_/NF(X, IN)))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of_i; JOIN_SET_SET(MATCH_.FO(CONSEQUENT(CONCLUSION(X)), CONSEQUENT( GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))) (PREMISES(X))))(AXIOMS)]

my.

mtransf in <funct f_m_i> with rule <f: al_ab>4

Page 339: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.2 Developments of functions 33]

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; some INFS: set of inf II EQ_SET_INF(INFS, UNION_INF_IN(~(X: inference): bool; true) ,

((X: inference): set of inf; IfNION__I_INF((IN: instance): bool; true, (IN: instance): set of inf; MK_SING_INF(INST_INF(X, IN)))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of i; JOIN_SET__SET(MATCH_~FO(CONSEQUENT( CONCLUSION(X)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF)))))(PREMISES(X)))) )(AXIOMS))

GIVE NAME FOR PARAMETER: Y ~ax4

CONDITION FULFILLED? NEW[AX] ~y4

GIVE NAME FOR PARAMETER: X ~ax~

CONDITION FULFILLED? NEW[AX~ ~y4

~transf in <funct f__8_i> with rule <u_i_inf: gcv_u> inverted*

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; some INFS: set of inf II EQ_SET_INF(INFS, UNION_INF_IN((AX: inference): bool; true,

(AX: inference): set of inf; (UNION_I..INF((IN: instance): bool; true, (IN: instance): set ofinf; MK_SING_INF(INST_.INF(AX, IN)))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of i; JOIN_SET_SET(MATCH_FO(CONSEQUENT( CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PEEM), CONSEQUENT(CONCLUSION(INF)))))(PEEMISES(AX)))) )(AXIOMS))

~transf in <funct f_a_.i> with rule <p: srm_q>4

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; (some INFS: set of inf II EQ_SET__INF(INFS, UNION__INF_IN((AX: inference): bool; true,

(AX: inference): set of inf; FAP_I_INF((IN: instance): bool; true, (IN: instance): inference; INST_/NF(AX, IN))(UNION_gL__I((PREM: clause): bool; true, (PREM: clause): set of i; JOIN_SET_SET(MATCH_FO(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF))))) (PREMISES(AX))))(AXIOMS)))

CONDITION FULFILLED? IS_EQUAL__PEE[EQ_SET._INF, set of inf~ ~y~

CONDITION FULFILLED? UNION_INF_IN((AX: inference): bool; true, (AX: inference): set_ofinf;

FAP_I_INF((IN: instance): bool; true, (IN: instance): inference; INST._INF(AX, IN))(UNION_CL_I((PREM: clause): hool; true, (PREM: clause): set of_i; JOIN_SET_SET(MATCH20(CONSEQUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH_FO(CONSEQUENT(PREM), CONSEQUENT(CONCLUSION(INF)))))(PREMISES(AX))))(AXIOMS) isof_submode set of inf

~y~

Page 340: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

332 IV.3 INFERENCE, CLAUSE, and FORMULA

~ c o p y <funct f_a_i>~

function F_A_I (INF: inference; GOAL: clause; AXIOMS: set of inf): set of inf; UNION_INF_IN((AX: inference): bool; true, (AX: inference): set of inf;

FAP_I_INF((IN: instance): bool; true, (IN: instance): inference; INST_INF(AX, IN))(UNION_CL_I((PREM: clause): bool; true, (PREM: clause): set_of_i; JOIN_SET_SET(MATCH_FO(CONSEOUENT(CONCLUSION(AX)), CONSEQUENT(GOAL)), MATCH..FO(CONSEQUENT(PREM), CONSEQUENT (CONCLUSION(INF)))))(PREMISES(AX)))) (AXIOMS)

~stop4

END SKERN

Page 341: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.3 Developments of selected theorems 333

3.3. Developments o f s e l ec t ed theorems

START SKERN ~comment<

Development of theorem

TIt9

>4

.install <expr thgt> unit <theorems: th9t>4

~copy <expr th9t>4

IS_MEM_I(IN, JOIN_SET_SET(IS, JS))

~comment<

I GOAL proof of theorem 9

ACTIONS - unfold of join_set_set and join_i_set - conversion of functionals fap_i_i and union_i_/ into two finite

existential quantifications (functional ex_i) - conversion of ex_i into existential quantification - logical and algebraic simplifications

>4

~install unit <units au× al: ~oin_set_set>4

~install unit <units aux al: 3oin_i_set>4

~install unit <units aux al: ex_i>4

~transf in <expr th9t> with rule <f: uff2>-

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD_FF ~funct 3oin_set.~set4

~transf in <expr th9t> with rule <f: uff2>4

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD__FF ~funct 3oin_/_set4

~transf in <expr th9t> with rule <u_i_i: mcy_u>4

(IS_MEM_I(IN, UNION_I_I((I: instance): bool; true, (I: instance): set_of_i; FAP_I__I((J: instance): bool; JOINABLE(I, J), (J: instance): instance;

JOIN_I_I(I, J))(JS))(IS)))

CONDITION FULFILLED? DETERMINATE[IN] my4

~transf in <expr th9t> with rule <u_i_i: gcv_u>~

EX_I((I: instance): bool; true, (I: instance): bool; IS_MEM_I(IN, (FAP_I_I((J: instance): bool; JOINABLE(I, J), (J: instance): instance;

JOlN_I_I(I , J ) ) ( J S ) ) ) ) ( IS)

Page 342: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

334 IV.3 INFERENCE, CLAUSE, and FOI~WULA

~t rans f in (expr th9 t ) with ru l e <u_i_i: mcy_u)~

EX_/((I: i n s t ance ) : bool ; t rue , ( I : i n s t ance ) : bool ; ~IS_MEM_I(IN, UNION_I_I((J: i n s t ance ) : bool ; JOINABLE(I, J ) , (J: ins tance) :

se t_of_ i ; MK_SING_I(JOIN_I_/(I, J ) ) ) ( J S ) ) ~ ) ( IS)

CONDITION FULFILLED? DETEBMINATEIIN] my4

~transf in <expr thgt> with rule <m_i: msi_k>4

EX_/((I: instance): bool; true, (1: instance): bool; EX_/((J: instance): bool; JOINABLE(I, J), (J: instance): hool;

(IS_MEM_~(IN, ~_SINO_/(JOIN_LI(I, J)))))(JS))(IS)

* t r a n s f in <e×pr thgt> with ru le <f: uf f_f2_f l>*

EX_I((I: i n s t ance ) : bool ; t rue , ( I : i n s t ance ) : bool; (EX_/((J: i n s t ance ) : bool ; JOINABLE(I, J ) , (J: i n s t ance ) : bool ;

EO_/(IN, JOIN_I_I(I, J) ) ))(JS) ) (IS)

CONDITION FULFILLED? DEF_.DET[(J: instance): bool; JOINABLE(I, J), (J: instance): hool; EQ_I(IN, JOIN_I_I(I,

J ) ) ] ~y4

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF . func t ex_i4

* t r a ns f in <e×pr thgt> with ru l e <f: uf f_f2_f l>4

~EX_I((I: ins tance) : bool ; t rue , ( I : i n s t ance ) : bool; ((S: s e t of i ) : bool; 3 (X: ins tance U IS_MEM_I(X, S) A ((J : i n s t ance ) : hool; JOINABLE(I, J ) ) (X)) H

((J : instance): bool; EO_I(IN, JOIN_I_I(I , J ) ) ) ( X ) ) ( J S ) ) ~ ( I S )

CONDITION FULFILLED? DEF_DET[(I: instance): bool; true, (I: instance): bool; ((S: set_of i); bool;

3 (X: instance fl IS_MEM_I(X, S) A ((J: instance): bool; JOINABLE(I, J))(X)) II (J: instance): bool; EQ_I(IN, JOIN_I_I(I, J)))(X))(JS)]

.y4

GIVE NAMED/MARKED UNIT FOR PARAMETER; statDF .funct ex_i.

~transf in <expr thgt> with rule <f: appl_l>4

((S; set_of_i): hool; B (X: instance H IS_MEM_I(X~ S) A (((I: instance): bool; true)(X)) ) lJ ((I: instance): bool; ((S: set of i): hool; 3 (X: instance n IS_MEM_/(X, S) A (((J: instance): bool; JOINABLE(I, J))(X)) ) H ((J: instance): bool; EQ_I(IN, JOIN_I_I(I, J)))(X))(JS))(X))(IS)

CONDITION FULFILLED? DEF_DET[X] ~y4

CONDITION FULFILLED? X isof_submode instance ,y4

CONDITION FULFILLED? DEF_DET[X]

Page 343: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I V . 3 . 3 Developments o f s e l e c t e d theorems 335

CONDITION FULFILLED? X isof_submode instance .y4

~transf <expr th9t> with rule <f: appl_l>4 CONDITION FULFILLED? DEF_DET[IS~ ~y~

CONDITION FULFILLED? IS isof_suhmode set of i ~y~

~transf in <expr thgt> with rule <p: ercv_u>4

(3 (X: instance {l IS_MEM_I(X, IS) A true) II ((I: instance): bool; ((IS: set of i): bool; 3 (X: instance 111S_MEM_I(X, IS) ~ JOINABLE(I, X)) II ((J: instance): booli EQ_..I(IN, JOIN_I_ I ( I , J ) ) ) ( X ) ) ( J S ) ) ( X ) )

. t r a n s f in <expr th9 t> w i t h r u l e <b: s i _ _ s a t r > . ~ t r a n s f in <expr th9 t> w i t h r u l e <b: ch__sa__a>*

.transf in <expr th9t> with rule <f: appl_l>~

3 X: instance II IS./MEM_I(X, IS) A ((I: instance): bool; (((IS: set_of_i): bool; 3 (X: instance II IS_MEM_I(X, IS) A JOINABLE(I, X)) II ((J: instance): bool; EQ_I(IN, JOIN_I_I(I, J)))(X))(JS)) )(X)

CONDITION FULFILLED? DEF_DET[JS]

CONDITION FULFILLED? JS isof_suhmode set of i

~transf in <expr thgt> with rule <f: al_er>~

3 X: instance il IS_MEM_I(X, IS) A ((I: instance): bool; 43 (X: instance il IS_MEM_I(X, JS) A JOINABLE(I, X)) {{ ((J: instance): boo l ; EQ_I(IN, JOIN_I_I(I, J)))(X)~ )(X)

GIVE NAME FOR PARAMETER: [ ~y#

CONDITION FULFILLED? NEW[Y] ~y4

~transf in <expr thgt> with rule <f: appl_l>-

3 X: instance II IS_MEM_I(E, IS) A ((I: instance): bool; 3 (Y: instance il IS_MEM_I(Y, JS) A JOINABLE(I, Y)) II (((J: instance): bool; EQ_I(IN, JOIN_I_I(I, J)))(Y)> (X)

CONDITION FULFILLED? DEF__DET[Y~ my4

CONDITION FULFILLED? Y isof_submode instance my4

btransf in <expr thgt> with rule <f: app]__l>4

3 X: instance 1} IS_MEM..I(X, IS) A (((I: instance): bool; 3 (Y: instance II IS_MEM_I(Y, JS) A JOINABLE(I, Y)) {{ EO_I(IN, JOIN_I_I(I, Y)))(X))

CONDITION FULFILLED? DEF_DET[X] my4

Page 344: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

336 IV.3 INFERENCE, CLAUSE, and FOEMULA

CONDITION FULFILLED? X isof_~ubmode i n s t a n c e *sr~

* t r m a s f in <expr th9t> wi th r u l e <p: ercv_u>4

3 X: i n s t a n c e tl IS_MEM_I(X, IS) A 4(3 (Y: i n s t a n c e II IS_MEM_I(Y, JS) A JOINABLE(X, Y)) II EQ_I (IN, JOIN_I_I(X, Y ) ) ) )

b t r a n s f in <expr th9t> w i t h r u l e <p: eno_sal> i n v e r t e d 4

9 X: i n s t a n c e II 4IS_MEM_I(X, IS) A (3 Y: i n s t a n c e II IS_MEM_I(Y, JS) h JOINABLE(X, Y) A EO_I(IN, JOIN_I_I(X, Y))))

CONDITION FULFILLED? IS_EMPTYSORT[instance] *n4

* t r a n s f in <expr th9t> wi th r u l e <b: ch~sa_a>~

* t r a n s f in <expr th9t> wi th r u l e <f: a l_e>*

X: i n s t a n c e II 49 Y: i n s t a n c e I[ IS_MEM_I(X, IS) h (IS_MEM_I(Y, JS) A JOINABLE(X, Y) A EQ_I(IN, JOIN_I_I(X, Y ) ) ) )

GIVE NAME FOR PARAMETER: Y ~j~

CONDITION FULFILLED? NEW~'J]] ~y4

.transf in <expr th9t> with rule <f: al_e>~

43 X: i n s t a n c e II 9 J: instance H IS_MEM_I(X, IS) A (IS_MEM_I(J, JS) A JOINABLE(X, J) A E0_I(IN, JOIN_I_I(X, J))))

GIVE NAME FOR PARAMETER: _Y ~i~

CONDITION FULFILLED? NEW[I~ ~y~

*transf in <expr th9t> with rule <b: ay_asar> inverted~

9 I: instance il 3 J: instance il IS_MEM_I(I, IS) A 4(IS_MEM_I(J, JS) A JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J))))

CONDITION FULFILLED? (false c D IS_MEM_I(J, JS) A true c_D JOINABLE(I, J)) ~ DEFINED[EO_I(IN, JOIN_I__I(I,

J) ) ] *y4

* t r a n s f in <expr th9t> wi th r u l e <b: ay_aa]> i n v e r t e d ~

. i n s t a l l <expr th9s> u n i t <theorems: th9s>4

*copy <expr th9s>~

9 I: i n s t a n c e 11 3 J: i n s t a n c e II IS_MEM_I(I, IS) h IS_MEM_I(J, JS) ^ (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))

~copy <expr th9t>.

Page 345: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I V . 3 . 3 Developments o f s e l e c t e d theorems 337

B I: instance II 3 J: instance II IS_MEM_I(I, IS) A IS_MEM_I(J, JS) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))

.stop4

END SKERN START SKERN

bcon~ment<

Development of theorem

THI7

>4

~install <expr thl7s> unit <theorems: thl7s>4

~copy <expr thl7s>4

V O: operator II IS_MEM_O(O, U_OPS_SET_FO(FS)) =~ ISDEF(I, O)

~comment<

GOAL proof of theorem 17 by use of rule aso_a

ACTIONS - unfold of u_ops_set_fo - logical transformations - fold by functional all_o - application of rule aso_a - unfold of all_o - the steps allowing application of aso_a are redone in reverse order

>4

-install <structure formula> unit <formula structural: formula>4

~transf in <expr thl7s> with rule <f: uffl>4

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF .funct u_ops_set_fo4

btransf in <expr thl7s> with rule <b: ch_i_si>4

V O: o p e r a t o r II (IS_MEMO(O, UNION_FO_O((F: formula): b o o l ; true, (F: formula): set_of o; U_OPS_FO(F))(FS)) ~ ISDEF(I, 0)~

CONDITION FULFILLED? false _m D IS_MEM 0(0, UNION_FO_O((F: formula): bool; true. (F: formula): set_of_o;

U_OPS_FO(F) ) (FS)) ~ DEFINED[ISDEF(I, O) ] my~

~transf in <expr thl7s> with rule <p: arcv_u> inverted4

~4 O: operator H IS_MEM 0(0, UNION_FO_O((F: formula): bool; true, (F: formula): set_of o; U_OPS_FO(F))(FS)) =~ ISDEF(I, 0)~

~transf in <expr thl7s> with rule <b: si__satr> inverted4

Page 346: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

338 IV.3 INFERENCE, CLAUSE, and FONMULA

~transf in <expr thl7s> with rule <f: becon> inverted4

V (0: operator II IS_MEMO(O, UNION_FO_O((F: formula): bool; true, (F: formula): s e t of o; U_OPS_FO(F))(FS)) A ( t r u e > ) II (ISDEF(I, 0)>

GIVE NAME FOR PARAMETER: X ~04

CONDITION FULFILLED? DEF_DET[O] my4

CONDITION FULFILLED? (0} ~ KNOWN[true] my4

GIVE NAME FOR PARAMETER: m ~operator4

CONDITION FULFILLED? 0 isof_submode operator my4

GIVE NAME FOR PARAMETER: D ~bool,

CONDITION FULFILLED? true isof_.submode hool wy4

GIVE NAME FOR PARAMETER: X ~o4

CONDITION FULFILLED? DEF~ET[O~

CONDITION FULFILLED? {0} ~ KNOWN[ISDEF(I, 0)] ~y-

GIVE NAME FOR PARAMETER: m ~operator,

CONDITION FULFILLED? 0 isof_submode operator ~y4

GIVE NAME FOR PARAMETER: n ~bool-

CONDITION FULFILLED? ISDEF(I, O) isof_submode bool my4

~transf in <expr thl7s> with rule <f: ab_l>,

(%/ (0: operator II IS_MEM_O(O, UNION_FO_O((F: formula): bool; true, (F: formula): set_of o; U_OPS_FO(F))(FS)) ~ ((0: operator): bool; true)(O)) II

((0: operator): bool; ISDEF(I, 0))(0)>

GIVE NAME FOR PARAMETER: X ~s,

GIVE NAME FOE PARAMETER: m ~set of o*

GIVE NAME FOR PARAMETER: n~bool,

CONDITION FULFILLED? V (0: operator II IS_MEMO(O, UNION_FO_O((F: formula): bool; true,

(F: formula): set of o; U_OPS_FO(F))(FS)) A ((0: operator): bool; true)(O)) II ((0: operator): bool; ISDEF(I, 0))(0) isof_submode bool

my,

GIVE NAMED/MARKED UNIT FOR PARAMETER: G ~in <expr thl7s>,

Page 347: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.3 Developments of selected theorems 339

V (O: operator ;I IS_MEMO(O, (UNION_FO_O((F: formula): bool; t rue, (F: formula): se t of_o; U_OPS_FO(F))(FS)~ ) a ((O: operator): bool; true)(O)) 11

((O: operator) : bool; ISDEF(I, O))(O)

CONDITION FULFILLED? DEFINED~UNION_FO_O((F: formula): bool; true, (F: formula): set of_o; U_OPS_FO(F))(FS)] ~y~

CONDITION FULFILLED? UNION_FO_O((F: formula): bool; true, (F: formula): set_of_o; U_OPS_FO(F))(FS)

isof_submode set_ofo *y*

GIVE NAME FOR PARAMETER: NE___WW *new~

*install unit <units aux al: all_o>.

.transf in <funct all_o> with rule <f: al_ar>.

funct ion ALL_O (P: funct ion (operator) bool; O: funct ion (operator) bool) : funct ion (set_of o) bool; (S: se t of o): bool;

~ / (X: operator II IS_MEM O(X, S) a P(X)) 11 q(X))

GIVE NAME FOR PARAMETER: [ ~o~

CONDITION FULFILLED? NEW~O] my4

.transf in <expr thl7s> with rule <f: ff_f2_fl>~

( ( (S : set_of_o): bool; Y (O: operator II IS_MEMO(O, S) A ((O: opera tor) : bool; true)(O)) J[

((O: operator) : bool; ISDEF(I, O))(O)))(UNION_FO_O((F: formula): bool; t rue, (F: formula): set_of_o; U_OPS_FO(F))(FS))

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct all_G4 CONDITION FULFILLED? DEFINED[(S: set_of_o): bool; V (0: operator [I IS_MEM_O(O, S) A ((0: operator): bool;

true)(O)) II ((0: operator): bool; ISDEF(I, 0))(0)] ::> DEFINED[ALL_O((O: operator): bool; true, (0: operator): bool; ISDEF(I, 0))]

~y~

~transf in <expr thl7s> with rule <u_~fo_o: aso_a> inverted4

~ALL_O((O: operator): bool; true, (O: operator): bool; ISDEF(I, O))(UNION_FO_O((F: formula): bool; true, (F: formula): set_of o; U_OPS_FO(F))(FS)))

*transf in <expr thl7s> with rule <f: uff_f2_fl>4

ALL_FO((F: formula): bool; true, (F: formula): bool; ~ALL_O((O: operator) : bool; true, (0: opera tor) : bool;

ISDEF(I, O))>(U_OPS_FO(F)))(FS)

CONDITION FULFILLED? DEF_DET[(O: operator): bool; true, (0: operator): bool; ISDEF(I, 0)] ~y~

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD__FF ~funct all_o*

Page 348: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

340 IV.3 INFERENCE, CLAUSE, and FORMULA

. t r a n s f in <expr thl7s> with ru l e <f: becon>4

ALL_FO((F: formula): bool; t rue , (F: formula): bool; ((S: s e t of_o): bool ; Y (0: opera to r II IS_MEM_O(O, S) ~ ( ( ( 0 : ope ra to r ) : bool; t rue) (O)~ ) II

(((0: opera to r ) : bool ; ISDEF(I, 0 ) ) ( 0 ) ) )(U_OPS_FO(F)))(FS)

CONDITION FULFILLED? DEF_DET[O] .y4

CONDITION FULFILLED? {0} ~ KNOWN~true]

CONDITION FULFILLED? 0 isof_submode operator

CONDITION FULFILLED? true isof__submode bool ~y4

CONDITION FULFILLED? DEF_DET~O]

CONDITION FULFILLED? {0} ~ KNOWN[ISDEF(I, 0)]

CONDITION FULFILLED? 0 isof_submode operator

CONDITION FULFILLED? ISDEF(I, O) isof_submode bool ~y4

~transf in <expr thl7s> with rule <p: arcv_u>~

ALL_FO((F: formula): bool; true, (F: formula): bool; ((S: set of_o): bool; ~V (0: operator II IS_MEM_O(O, S) A true) II ISDEF(I, 0)) )(U_OFS_FO(F)))(FS)

~transf in <expr thl7s> with rule <b: ch_i_si> inverted4 -transf in <expr thl7s> with rule <b: si__satr>4

-transf in <expr thl7s> with rule <f: appl_l>~

ALL_FO((F: formula): bool; true, (F: formula): hool; (((S: set_of_o): bool; V O: operator I{ IS_MEM_O(O, S) =~ ISDEF(I, O))(U_OPS_FO(F))) )(FS)

CONDITION FULFILLED? DEF_DET[U_OPS_FO(F) ] ~y4

CONDITION FULFILLED? U_OPS_FO(F) isof_submode set of o wy~

-copy <expr thl7s>~

ALL_FO((F: formula): bool; true, (F: formula): bool; V O: operator II IS_MEMO(O, U_OPS_FO(F)) ~ ISDEF(I, O))(FS)

~install <expr thl7t> unit <theorems: thl7t>4

~copy <expr thl7t>4

ALL_FO((F: formula): bool ; t rue , (F: formula): bool; V O: ope ra to r I11S_MEM_O(O, U_OPS_FO(F)) ~ ISDEF(I, O))(FS)

Page 349: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.3 Developments of selected theorems 341

,,-stop.,

END SKERN

THIS CATALOG CONTAINS THEOREMS IN FORM OF A RULE AND FOR EACH RULE TWO ADDITIONAL UNITS, ONE FOR THE SOURCE SCHEME AND ONE FOR THE TARGET SCHEME. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

THEOREMS TH = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

THO NON_RED_.I(IN, U_OPS_CL(Q.))A E0_CL(INST_CL(C, IN), D) <-> IS_MEM_I(IN, BASE_CL(C, D)) A (NON_RED_I (INN, U_OPS._CL(C_) ) A EQ_CL(INST_CL(C_, IN), D) )

THI NON_RED_I ( IN, U_0PS_SET_FO(FS) ) A IS_SUB_FO(INST._SET_FO(FSS, IN), GS) <-> IS_MEM_/(IN, BASE_SET_FO(FS, GS)) A (NON_RED_I(I_NN, U_OPS_SET_FO(FS) ) ^ IS_SUB_FO(INST_SET_FO(F_SS, IN), GS) )

TIt2 NON_BED_I(IN, U_OPS_FO(F)) A EO_FO(INST_FO(F, IN), G) <-> ISA~IEM_I(IN, BASE_FO(_F, _G)) A (NONJED_I(IN, U_OPSJO(_F)) ^ EO_.FO(INST_FO(_F, IN), G_))

TH3 ISDEF(JOIN_I_I(! , ~) , O) <-> ISDEF(!, O) v ISDEF(~, O) >-< JOINABLE[!, ~]

TH4 ISDEF(_I, O) ~ EO_TS(TS, GET(JOIN_I__I(I, _J), O)) <-> ISDEF(I, O_) ~ EO_TS(T, GET(I, _O)) >-< JOINABLEU, J_]

TIt5 EO_FO(INST_FO(L I), fi) ^ (V O: operator [I IS_MEM_O(O, U_OPS_FO(F_)) =# ISDEF(I, 0)) A (JOINABLE(I, J_) A EQ_I(IN, JOIN_I_I(I, J_))) <-> EO_FO(INST_FO(F, IN), G_) A (V O: o p e r a t o r H IS_MEM_O(O, U_OPS_FO(F)) ~ ISDEF(I, O)) ^ <JOINASLE<I, J_) A EO_I(IN, JOIN_I_I<I, J_)))

Page 350: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

342 IV. 3 INFERENCE, CLAUSE, mad FORMULA

TH6 V O: operator l{ ISDEF(IN, O) ¢:> IS_MEM O(0, OS) V IS_MEMO(O, OT) <-> 3 I: instance li 3 J: instance lJ %/ O: operator {l

(ISDEF(I, O) ¢~ IS_MEM_O(O, OS)) A (ISDEF(J, O) O IS_MEM_O(O, OT)) A (JOINABLE(_I, J) A EQ_I(IN, JOIN_/_I(_I, J_)))

>-< [!] = USERDEFINED[_I] A [J_] : USERDEFINED[J~ A -_I in O S A -J_ in O_~S A -! in O T ^ -J_ in O_TT ̂ -_I in I__NN A -J in I_NN

TH7 IS-SUB_FO(INST-SET_FO(FS, I), GS) ^ (V O: operator I} IS_MEMO(O, U_OPS_SET_FO(FS)) =>

ISDEF(I, O)) A (JOINABLE(I, J_) a EQ_I(IN, JOIN_I_I(I, J_))) <-> IS_SUB_FO(INST-SET_/PO(FS, IN), GS)A (V O: operator l} IS_MEM_O(O, U_OPS_SET_FO(FS)) =)

ISDEF(!, 0)) ^ (JOINABLE(I, J_) a EQ_I(IN, JOIN_I_/(I, J)))

TH8 EQ-SET_FO(INST-SET_FO(FS, _I), GS) A (V O: operator II IS_MEM_O(O, U_OPS-SET_FO(F_SS)) ::>

ISDEF(I, 0_)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(_I, J_))) <-> EQ-SET_FO(INST_SET_FO(FS, IN), GS) A (V O: operator l| IS_MEM_O(O, U_OPS_SET_FO(FS)) ::>

ISDEF(I, 0)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))

TH9 3 I: i n s t a n c e II 3 J : i n s t a n c e l{ IS_MEM_I(I, IS) A

IS_MEM_I(J_, JS) A (JOINABLE(I, J ) A EQ_I(IN, JOIN_I_I(I_, J_))) <-> IS_I~M_I(IN, JOIN_SET_SET(IS, JS) ) >-< [I] = USERDEFINED[I] A [J]l = USERDEFINED[[J_]

THIO Is-S~_Y0(~, !) <-> ALL_FO((X: ~ula): bool; true,

(X: ~rmula): bool; EX_FO((%: ~rmula): bool; true, (%: ~rmula): bool; EQ_FO(X, %)) (!)) (~)

>-< [X~ : USERDEFINED[X~ A [!] : USE~EFINED[Y~

TIt15 3 I : i n s t a n c e [I EQSL(INST_CL(C_, I ) , I))

3 I_: i n s t a n c e II NON_RED_I(_I, U_OPS_CL(C}) A EQ_CL(INST_CL(C__, _I), D}

Page 351: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.3 Developments of s e l e c t e d theorems 343

Till 6 IS_SUB_FO(INST_SET_FO(FS, IN), G S) <-> ALL_FO((_F: formula) : bool ; t r u e ,

(F: formula) : bool ; EX_FO((G: formula) : bool ; t r u e , (G: formula) : bool ; EO_FO(INST_FO(F, IN), 9_))

(as)) (FS) >-< [F~ = USERDEFINED[F] A [G_] = USERDEFINED[G~

TH16B IS_SUB_FO(GS, INST_SET_FO(FS, IN) ) <-> ALL_FO((_G: formula) : bool; true,

(G_: formula): bool; EX_FO((_F: formula): bool; true, (F: formula): bool; EO_FO(INST_FO(F, IN), G_))

(FS)) (GS) >-< IF] = VSE~DEFIN~D[_F] A [a_J = USF.RDEFINZD[fi]

Till 7 V O: operator II IS_ME~_O(O, U_OPS_SET_FO(FS)) ~ ISDEF(_I, O) <-> ALL_FO((F: formula) : bool; true,

(F: formula) : bool ; (V O_: ope ra to r l{ IS_MEM_O(O, U_OPS_FO(_F)) =~ ISDEF(_I, _O))) (FS)

>-< [_F] = USERDEFINED[F~

Till 8 JOIN_I_I(_I, J_) <-> JOINZ_I(J_, _I)

Till 9 JOINABLE(_I, _J) <-> JOINABLE(_J, _I)

TH22 FILTER..~((_Y: m): boo1; _P) (S_)

beg in (var V_RR: s e t _ o f m, v a t V S: s e t of m) := (EMPTYSET_M, S_); var V_ZZ: m; while ~IS_Y_M(VS) loop

v_Zz : = ARB_M(VS) ; i f ((_Y: m): bool ; P)(V_ZZ) then VR := ADD_M(V_ZZ, VR) e l s e V_RR := V_RR e n d i f ; v s := DEL_M(VZ, V S ) )

Page 352: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

344 IV.3 INFERENCE, CLAUSE, and FORMULA

endloop; v__~R

end >-< [V__RR~ = USERDEFINED[[VR~ A [VS~ = USEI~DEFINED[VS~ A [VZ]] = USERDEFINED~VZ~ A NEWIV__RR, VS, VZ]

THOS NON_RED_I(IN, U_OPS_CL(C)) A EO_CL(INST_CL(C, IN), D)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

THOT IS_MEM_I(IN, BASE_CL(C, D)) A (NON_I~ED_I(IN, U_OPS_CL(C)) A EO_CL(INST_CL(C, IN), D))

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

T i l l s NON_RED_I(IN, U_OPS._SET_FO(FS)) ^ IS_SUB_FO(INST_SET_FO(FS, IN), GS)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

THI T IS_MEM_I(IN, BASE...SET_FO(FS, GS)) A (NON_RED_I(IN, U_OPS_SET_FO(FS)) ^ IS_SUB._FO(INST...SET_FO(FS, IN), GS))

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TH2S NON_RED_I(IN, U_OPS_.FO(F)) A EO_FO(INST_FO(F, IN), G)

TH2T IS_MEM_I(IN, BASE_FO(F, G)) A (NON_I~EDj(IN, U_OPS__FO(F)) ^ EO_FO(INST..FO<F, IN), Q))

TH3S ISDEF(JOIN~(I , J) , O)

TH3T ISDEF(I, O) V ISDEF(J, O)

TH4S ISDEF(I, O) :~ EO_TS(TS, GET(JOIN_I_I(I, J), 0))

Page 353: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.3 Developments of selected theorems 345

TH4T ISDEF(I, O) ~ EQ_TS(T, GET(l, 0))

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

THSS EQ_FO(INST_FO(F, I), G) A (V O: operator II IS_MEMO(O, U_OPS_FO(F)) =* ISDEF(I, 0)) A (JOINABLE(I, J) A EQ__I(IN, JOIN_I_I(I, J)))

THST EQ_FO(INST_FO(F, IN), G) A (V O: operator II IS_MEM_O(O, U_OPS_FO(F)) ~ ISDEF(I, 0)) ^ (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TH6S V O: operator [l ISDEF(IN, O) ¢~ IS_MEM_O(O, OS) V IS_MEM_O(O, OT)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TH6T 3 I: instance tl 3 J: instance II V O: operator II (ISDEF(I, O) ¢=> IS_MEM_O(O, OS)) ^ (ISDEF(J, O) ¢~ IS_MEM_O(O, OT)) ^ (JOINABLE(I, J) A EQ_I(IN, JOIN_I__I(I, J)))

TH7S IS_SUB_FO(INST_SET_/D(FS, I), GS) A (V O: operator II IS_MEM_O(O, U_OPS_SET_FO(FS)) ~ ISDEF(I, 0)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))

TH7T IS_ZUB_FO(INST_SET_/X)(FS, IN), GS) A (%/ O: operator II IS_MEM_O(O, U_OPS_~ET_FO(FS)) =* ISDEF(I, 0)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))

TH8S EO_SET_FO(INST_SET_FO(FS, I), GS) A (%/ O: operator II IS_MEMO(O, U_OPS_SET_FO(FS)) =~ ISDEF(I, 0)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))

Page 354: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

346 IV.3 INFERENCE, CLAUSE, and FORMULA

TH8T EQ._SET_FO(INST_SET_.FO(FS, IN), GS) A (V O: operstor II IS_MEM_O(O, U_OPS..SET_FO(FS)) ==) ISDEF(I, O)) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_.I(I, J)))

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TH9S B I: instance II B J: instance II

IS_MEM_I(I, IS) A IS_MEM_I(J, JS) A (JOINABLE(I, J) A EQ_I(IN, JOIN_I_I(I, J)))

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

THgT IS_MEM_/(IN, JOIN_SET_SET(IS, JS))

THIOS IS_SUB_FO(S, T)

TH107" ALL_FO((X: formula) : bool; true,

(X: formula): bool; EX_.FO((Y: formula): bool; true, (Y: formula): bool; EQ_FO(X, Y)) (T)) (S)

THI 5S 3 I: instance II EQ_CL(INST_CL(C, I), D)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

THI 5T 3 I: instance II NON_RED__I(I, U_OPS_CL(C)) A EQ_CL(INST_CL(C, I), D)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

THI 6S IS_SUB_.FO(INST_SET_FO(FS, IN), GS)

Page 355: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.3.3 Developments of s e l e c t e d theorems 347

Till 6T ALL_FO((F: formula): bool ; t r ue ,

(F: formula): bool ; EX_FO((G: formula): bool ; t r ue , (G: formula): bool; EQ_FO(INST30(F, IN), G))

( a s ) ) (FS)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Till 6BS IS_SUB_FO(GS, INST_SET_FO(FS, IN))

Till 6BT ALL_FO((G: formula) : bool ; t rue ,

(G: formula): bool; EX_FO((F: formula): bool; t rue , (F: formula): bool; EO_FO(INST_YO(F, IN), G))

(FS)) (Gs)

Till 7S Y O: opera to r {{ IS_MEM_O(O, U_OPS_SET_FO(FS)) ~ ISDEF(I, O)

TH17 T ALL_FO( (F: formula) : bool ; t r ue ,

(F: formula): bool; (Y O: ope ra to r H IS_MEM O(O, U_OPS_FO(F)) ~ ISDEF(I, O)))(FS)

TH18S JOIN_I_~ (I, J)

THIST JOIN_I_I (J, I)

THI 9S JOINABLE (I, J)

Till 9T JOINABLE(J, I)

TH22S FILTER_M((Y: m): bool ; P)(S)

Page 356: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

348 IV.3 INFERENCE, CLAUSE, and F O ~ L A

TH22T beg in

(var VR: s e t o f m, var VS: se t_of_m) := (EMPTYSET_M, S); v a t VZ: m; w h i l e ~IS_Y_M(VS) loop

VZ := ARB_M(VS); i f ((Y: m): bool ; P)(VZ) then VR := ADD_~(VZ, VR) e l s e VR := VR e n d i f ; VS := DEL_M(VZ, VS))

endloop; VR

end

END CATALOG THEOF,,EMS

Page 357: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.1 Informal description of the match functions 349

4. TEI~M

4.1. Informal description of the match-functions

MATCH_AS matching instances of a given sequence of sequences of terms with another such sequence (matching arts with arts)

MTC_TS matching instances of a given sequence of terms with another such sequence (problem of sequence variables: the first sequence may be shorter than the other one; no unique solution but combinatorial variety)

MTC_T matching instances of a given term with another one

MTC_S combinatorial subcase of MTC_TS in which the first term of the given sequence is a sequence variable

MTC_SF matching instances of a single sequence variable with arbitrary suhsequences at the front of a given sequence of terms

MTC_SR matching instances of a given sequence of terms with arbitrary subsequences at the rear of another such sequence

(auxiliary functions)

FUSE_SET_SET result of MTC_S evaluated from the results of MTC__SF and MTC_SR for the respective subproblems:

tsl /~-- ~--~-- ~--\

t s 2

mtc_sf mtc_sr k )

y

combinatorial variety

COMBINE_/ result of MTC_SF evaluated from the first matching instance

add(void, s, <first_ts(ts2)>) = f and the result of MTC_SF applied to the rest of ts2, that is, it yields the set of instances of the form

add(void, s, ts) where ts is either <first_ts(ts2)> or of the form

<first_ts(ts2)> & r with r the righthand side of an instance from the set evaluated by MTC_SF when being applied to rest_ts(ts2)

Page 358: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

350 IV.4 TEI~M

4.2. S p e c i f i c a t i o n o f a u x i l i a r y func t ions

function (Ii, I2: set of_i; TS: terms; L: nat II ~IS_Y_TS(TS)): set_of i FUSE_SET_SET,

FUSE_SET_SET(A, B, TS, L) = {JOIN_I_I(II, I2) H JOINABLE_I_I(II, I2) A IS_MEM_I(II~ A) A IS_MEM_I(I2, B) ^

IINST_T(FIRST_TS(TS), I1 ) ] + [INST_TS(REST_TS(TS), I2) 1 = L}

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

funct ion ( I : ins tance ; SI: s e t o f i Jl SINGLE_SQVAB(UNION_I({I}, Sl)): set_of_i COMBINE_I,

function (SI: set of i): bool SINGLE_SQVAR,

SINGLE_SQVAR(SI) = 3 (O: operator II IS_SOVAB_O(O)) II EQ_SET_O(DOMAIN_SI(SI), (O})

COMBINE_I(I, EMPTYSET_I) = EMPTYSET_/,

COMBINE_I(ADD(VOID, S, TSI), ABD_I(ADD(VOID, S, TS2), SI)) = ADD_I(ADD(VOID, S, TSI & TS2), COMBINE_/(ADD(VOID, S, TSI), SI)),

funct ion (Sl: se t_o f i ) : s e t _ o f o DOMAIN_SI,

DOMAIN__SI(EMPTYSET_/) = EMPTYSET_O,

DOMAIN_SI(UNION_I((I), SI)) = UNION_O(DOMAIN_I(I), DOMAIN_SI(SI))

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

THIS CATALOG CONTAINS THE SPECIFICATIONS OF FUNCTION MATCH_AS (CONFER STRUCTURE INSTANCE). FURTHERMORE THE AUXILIARY FUNCTIONS MTC_TS, MTC_T, MTC_S, MTC_SF AND MTC_SR ARE CONTAINED. THEY EVOLVE FROM THE METHODOLOGICAL POINT OF VIEW, BY ABSTRACTION DURING THE DEVELOPMENT OF THE MATCH-FUNCTIONS. TECHNICALLY, THE ABSTRACTION STEPS WITHIN THIS DEVELOPMENT ARE PERFOI~MED BY FOLDING STEPS.

SPECIFIED FUNCTION STRUCTURE INSTANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MATCH-AS function MATCH_AS (AS1: args; AS2: args): set_of_i;

FILTER_I((I: instance): bool; EOUAL_AS(INST_AS(ASI, I), AS2))(REL_INSTS_AS(ASI, AS2))

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

ABSTRACTED FUNCTIONS DEVELOPMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MTC-TS funct ion MTC_TS (TSI: terms; TS2: terms): s e t of i ;

FILTER_I((I: i n s t ance ) : bool ; EOUAL_TS(INST_TS(TS1, I ) , TS2)) (REL_INSTS_TS(TS1, TS2))

Page 359: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.2 Specification of auxiliary functions 351

/Trc-.T funct ion MTC_T (TI: term; T2: term): se t_of_i ;

FILTER_I((I: ins tance) : bool; -IS_VAR_O(OPTOR(TI)) A EOUAL_TS(INST_T(TI, I ) , MAKE_TS(T2)))

(REL_INSTS_T<TI, T2) )

MTC-S funct ion MTC_S (TSI: terms; TS2: terms): se t_of_i ;

FILTER_I((I: instv_nee): bool; -IS_Y_TS(TS1) A (IS_SQVAR_O(OPTOR(FIRST_TS(TS1))) A ISDEF(I, OPTOR(FIRST_TS(TS1))) A (EQUAL_TS(GET(I, OPTOR(FIRST_TS(TSI))),

GET_FRONT_TS(TS2, LENGTH_TS(GET(I, OPTOR(FIRST_TS(TSI)))))) ^ EOUAL_TS(INST_TS(REST_TS(TSl), I),

DEL_FRONT_TS(TS2, LENGTH_TS(GET(I, OPTOR(FIRST_TS(TSI))))))))) (REL_INSTS_TS(TSI, TS2))

MTC-SF function MTC_SF (T: term; TS: terms): set_of i;

FILTER_I((I: instance): bool; IS_SOVAR_O(OPTOR(T))^ ISDEF(I, OPTOR(T))A EOUAL_TS(INST_T(T, I)~ GET_FRONT_TS(TS, LENGTH_TS(INST_T(T, I))))) (REL_INSTS_TS(MAKE_TS(T), TS) )

t~TC-SR function MTC_SR (TSI: terms; TS2: terms): set_of_i;

FILTER~_I((I: instance) : bool; EOUAL_TS(INST_TS(TSI, I), GET_BEAR_TS (TS2, LENGTH_TS ( INST_TS ( TS i, I ) ) ) ) ) (REL__INSTS_TS ( TS i, TS2 ) )

END OF FILE MATCH FUNC

Page 360: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

352 IV.4 TERM

4 . 3 . Developments

START SKERN

~comment<

Development of function

MATCH_AS

to recursive form

>4

*install unit <match func al: match_as>4

~comment<

GOAL Development of the case IS_Y_AS(ASI) IS_Y_AS(AS2)

after expansion of EO_AS

ACTIONS - Expansion of EO_AS, simplification - Distribution of filter to else-guard - Specialization of first then-branch (both sequences empty) - Evaluation of REL_INSTS__AS within this branch - Reduction of the corresponding filer to a singleton

instance

>4

.transf in <funct match_as> with rule <ss_as: qcv_h2>4

function MATCK_AS (AS1: args; AS2: args): set of_i; FILTER_I((I: instance): bool;

(EQUAL_AS(INST_AS(ASI, I), AS2)) )(P~EL_INSTS_AS(ASI, AS2))

CONDITION FULFILLED? DETERMINATE[INST_AS(ASI, I), AS2] ~y4

~t rans f in <funct match_as> with rule <instance: iysi_i_as>4

func t ion MATCH_AS (ASI: args; AS2: args) : se t_of_i ; FILTER_I((I: ins tance) : bool;

i f ~IS_Y_AS(INST_AS(AS1, I ) )~ A IS_Y_AS(AS2) then

t rue 0 - (IS_Y_AS(INST_AS(ASI, I))~ A -IS_Y_AS(AS2) t h e n

EOUAL_TS(FIRST_AS(INST_.AS(AS1, I)), FIRST_.AS(AS2)) A EOUAL_AS(REST_AS(INST_.AS(AS], I)), REST_AS(AS2))

e l s e f a l se

endif)(REL_INSTS_AS(AS1, AS2))

Page 361: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4 .3 Developments 353

~ t r a n s f in <funct match_as> wi th r u l e <uu_i: fdp_h2_ana>.

f u n c t i o n ~L~TCH_AS (ASI: args ; AS2: a r g s ) : s e t o f_ i ; (FILTER_I ( ( I : i n s t ance ) : bool ;

i f IS_Y_AS(AS1) A IS_Y_AS(AS2) then

t r u e 0 ~IS_Y_AS(AS1) A ~IS_Y_AS(AS2) then

EOUAL_TS(FIRST_AS(INST__AS(ASI, I)), FIRST_AS(AS2) ) A EOUAL_AS(EEST_.AS(INST._AS(ASI, I)), REST_AS(AS2))

e l s e f a l s e

end i f ) (RE L_INS TS_AS (AS 1, AS2 ) )

CONDITION FULFILLED? DETERMINATE[IS_Y_AS(ASI), IS_Y_AS(AS2) ~y.

CONDITION FULFILLED? EMPTYSET_I-=D REL_INSTS_AS(ASI, AS2) ::> DEFINED[IS_Y_AS(ASI), IS_Y_AS(AS2)]

~y4

~transf in <funct match_as> with rule <ss_as: h2su_l__yy>4

function MATCH_AS (ASI: args; AS2: args): set of i; (if IS_Y._AS(ASI) A IS_¥_AS(AS2) then

FILTER_I ( ( I : i n s t ance ) : bool ; t r u e ) (REL_~NSTS_AS(AS1, AS2)) 0 ~IS_Y_AS(AS1) A-IS_Y_AS(AS2) then

FILTER_I( ( I : i n s t a n c e ) : bool ; EOUAL_TS(FIRST_AS(INST_AS(AS1, I ) ) , FIRST_AS(AS2)) A

EQUAL_AS(REST_AS(INST_~S(ASI, I) ), REST_AS(AS2) )) (REL_INSTS_AS(AS1, AS2) ) else

FILTER_I((I: instance) : bool; false) (REL_INSTS_AS(ASI, AS2)) endif>

~transf in <funct match_as> with rule <instance: rlsi_yy_as>4

function MATCH_AS (ASI: args; AS2: args): set of_i; if IS_Y_AS(ASI) A IS_Y_AS(AS2) then

FILTER_I ( ( I : instance) : bool; true) ((REL_INSTS_AS (EMPTY_AS, E~PTY_AS)) ) 11 ~IS_Y_AS(AS1) A -IS_Y_AS(AS2) then

FILTER_I((I: i n s t a n c e ) : bool ; EQUAL_TS(FIRST_AS(INST_AS(AS1, I ) ) , FIRST_AS(AS2)) A

EOUAL_AS(REST_AS(INST_AS(ASI, I)). REST_&S(AS2))) (REL_INSTS_AS(ASI, AS2)) else

FILTER_I((I: instance): bool; false)(REL_INSTS_AS(ASI, AS2)) endif

*transf in <funct match_as> with rule <uu_i: fsp_tr>*

function MATCH_AS (AS1: args; AS2: args): set_of_i; if IS_Y_AS(ASI) A IS_Y_AS(AS2) then

(FILTER_/((I: instance) : bool; true) (MK_SING_I(VOID))) 0 -IS_Y_AS(ASI) A-IS_Y_AS(AS2) then

Page 362: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

354 IV,4 TERM

FILTER_I((I: instance): bool; EQUAL_TS(FIRST_AS(INST_AS(ASI, I)), FIRST_AS(AS2)) A

EQUAL_AS(REST_AS(INST_AS(AS1, I)), REST_AS(AS2)))(REL_INSTS_AS(ASI, AS2)) else

FILTER_I((I: instance): bool; false)(REL_INSTS_AS(ASI, AS2)) endif

bcomment<

GOAL Development of the case in which one sequence is empty, the other is not l I ACTIONS R e d u c t i o n of the f i l t e r in the else-branch of the guard to EMPTYSET_I ]

>4

~transf in <funct match_as> with rule <uu_i: fsp_fl>4

function MATCH_AS (AS1: args; AS2: args): set_of i; if IS_Y_AS(ASI) ^ IS_Y_AS(AS2) then

MK__SING_I(VOID) 0 ~IS_Y_AS(ASI) A ~IS_Y_AS(AS2) then

FILTERj((I: instance): bool; EQUAL_TS(FIRST_AS(INST_AS(ASI, I)), FIRST_AS(AS2)) ^

EQUAL_AS(REST_AS(INST_AS(ASI, I)), REST_AS(ASZ)))(REL_INSTS_AS(ASI, AS2)) else

(FILTER_I((I: instance): bool; false)(REL_INSTS_AS(ASI, AS2))) endif

CONDITION FULFILLED? DEFINED[REL_INSTS_AS(ASI, AS2)] ~y~

~transf in <funct match_as> with rule <instance: icy_It_as>*

funct ion MATCH_AS (AS1: args; AS2: args): se t_of i; i f IS_Y_AS(ASI) A IS_Y_AS(AS2) then MK_SING_I(VOID)

D ~IS_Y_AS(ASI) A -IS_Y_AS(AS2) then

FILTER_I((I: instance): hool; EQUAL_TS((FIRST_AS(INST_AS(ASI, I))) , FIRST_AS(AS2)) A

EQUAL_AS(REST_AS(INST_AS(ASI, I)), REST_AS(AS2)))(REL_~NSTS_AS(ASI, AS2)) else

EMPTYSET_I endif

~comment<

GOAL Development of the case 'NOT' IS_Y_TS (ASI) 'NOT' IS_Y_TS (AS?.)

Page 363: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4 .3 Developments 355

ACTIONS - Commutation of INST_AS and REST_AS - "Distribution" of the filter to the 'AND' employing function

JOIN_SET_SET (Theorem) - Abstraction of the lefthand filter (evaluates the matching instances

of FIRST_AS(AS1) and FIRST_AS(AS[)) as function MTC_TS - Folding of the righthand filter (evaluates the matching instances

of REST_AS(AS1) and REST_AS(AS2)) by MATCH_AS (recursion)

>4

~transf in <funct match_as> with rule <instance: icy_rs_as>4

f u n c t i o n MATCH_AS (ASI: a rgs ; AS2: a r g s ) : s e t _ o f i ; if IS_Y_AS(ASI) A IS_Y_AS(AS2) then

MK_S ING_I ( VOID ) D -IS_Y_AS(ASI) A ~IS_Y_AS(AS2) then

FILTER_I ( (I : instance) : bool; EQUAL_TS(INST_TS(FIRST_AS(ASI), I), FIRST_AS(AS2)) A

EQUAL_AS(~REST_AS(INST_AS(ASI, I))~ , REST_AS(AS2))) (REL_INSTS_AS(ASI, AS2)) else

EMPTYSET_I endif

*transf in <funct match_as> with rule <instance: fdp_a_tsas>4

f u n c t i o n MATCH_AS (ASI: args ; AS2: a rgs ) : s e t _ o f i ; if IS_Y_AS(ASI) A IS_Y_AS(AS2) then

MK_SING_I (VOID) n ~IS_Y_AS(ASI) A ~IS_Y_AS(AS2) then

~FILTER_I((I: instance) : bool; EQUAL_TS ( INST_TS (FIRST_AS (AS i), I ), FIRST_AS (AS2)) A

EOUAL__AS(INST_AS(REST_AS(ASI), I), REST_AS(AS2))) (REL_INSTS_AS(ASI, AS2))) else

EMPTYSET_I endif

.install <funct spmtc_ts> unit <match func al: mtc_ts>~

*install <funct spmatch_as> unit <match func al: match_as>~

. t r a n s f in <funct match_as> with rule <f: ff2>*

function MATCH_AS (AS1: args; AS2: args): set_of i; if IS_Y_AS(ASI) A IS_Y_AS(AS2) then

MK_SING_I (VOID) 0 ~IS_Y_AS(ASI) A ~IS_Y_AS(AS2) then

JOIN_SET_SET(~FILTER_I((I: instance): bool; EQUAL_TS(INST_TS(FIRST_AS(ASI), I), FIRST_AS(AS2))) (REL__INSTS_TS(FIRST_AS(AS1), FIRST_AS(AS2)))~ , ~FILTER_J[((I: instance) : bool; EOUAL_AS(INST_AS(REST_AS(AS1), I), REST_AS(AS2))) (REL_INSTS_AS(REST_AS(ASI), REST_AS(AS2)))~ )

else EMPTYSET_I

e n d i f

Page 364: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

356 IV.4 TERM

GIVE NAMED/MARKED UNIT FOR PARAMETER: staiD IF ~funct spmtc_ts- CONDITION FULFILLED? DEFINED[FILTER_~((I: instance): bool;

EQUAL_TS(INST_TS(FIRST_AS(ASI), I), FIRST_AS(AS2))) (REL_/NSTS_TS(FIRST_AS(ASI), FIRST_AS(AS2)))~ =$ DEFINED[MTC_TS(FIRST_AS(ASI), FIRST_AS(AS2))]

my4

GIVE NAMED/MARKED UNIT FOR PARAMETER: statD F ~funet spmatch_as~ CONDITION FULFILLED? DEFINED[FILTER__I((I: instance): bool;

EQUAL_AS(INST_AS(REST_AS(ASI), I), REST_.AS(AS2))) (REL_/NSTS_AS(REST_AS(ASI), REST_AS(AS2)))] =~ DEFINED[MATCH_.AS(REST_AS(ASI), REST_AS(AS2))]

~y4

~copy <funct match_as>-

function MATCH_AS (AS1: args; AS2: args): set of_i; if IS_Y_AS(AS1) A IS_Y_AS(AS2) then

MK__SING_I(VOID) D -IS_Y_AS(ASI) A -IS_Y_AS(AS2) then

JOIN_SET_SET(MTC_TS(FIRST_AS(ASI), FIRST_AS<AS2)), MATCH_AS(REST_AS(AS1), REST_AS(AS2)))

else EMPTYSET_I

endif

~stop.

END SKERN START SKERN

*comment<

Development of function

MTC_TS

to recursive form

>4

binstall unit <match func al: mtc_ts>4

~transf in <funct mtc_ts> with rule <instance: i_ts>~

function MTC_TS (TSI: terms; TS2: terms): set of i; FILTER__I((I: instance) : bool;

EQUAL_TS((INST_TS(TSI, I)) , TS2) ) (REL_INSTS_TS(TSI, TS2))

Page 365: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 357

~Dopy <funct mtc_ts>4

function MTC_TS (TSI: terms; TS2: terms): set_of i; if IS_Y_TS(TSI) t h e n

if IS_Y_TS(TS2) then

MK_SING_I(VOID) else

EMPTYSET_I endif

else if IS_Y_TS(TS2) then

if IS_SQVAR_O(OPTOR(FIRST_TS(TS]))) then

MTC_S(TSI, EMPTY_TS) else

EMPTYSET_I endif

else if IS_PLVAR_O(OPTOR(FIRST_TS(TSI))) then

JOIN_SET__SET(MK_SING_I(ADD(VOID, OPTOR(FIRST_TS(TSI)), FIRST_TS(TS2))), MTC_TS(REST_TS(TSI), REST_TS(TS2)))

0 IS_SQVAR_O(OPTOR(FIRST_TS(TSI))) then MTC_S(TSI, TS2)

else JOIN_SET_.SET(MTC_T(FIRST_TS(TS]), FIRST_TS(TS2)),

MTC_TS(REST_TS(TSI), REST_TS(TS2))) endif

endif endlf

~stop4

END SKERN START SKERN

~comment<

Development of function

MTC_T

To recursive form

>4

~install unit <match func al: mtc_t>4

~comment<

GOAL

>4

Diminishing of REL_INSTS_T(tl, t2) to the relevant instances of the arguments of tl and t2, i.e. to REL_INSTS._AS(ARGS(tl), ARGS(t2)). This is possible since the operator of tl is no variable.

Page 366: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

358 IV.4 TERM

~transf in <funct mtc_t> with rule <instance: rldm_t_as>.

function MTC_T (TI: term; T2: term): set_of_i; (FILTER_I((I: instance): bool;

-IS_VAR_O(OPTOR(TI)) A EQUAL_TS(INST_T(TI, I), MAKE_TS(T2)))(REL_INSTS_T(TI, T2)))

~comment<

I GOAL Conditional form after expansion of INST_T I !

- Distribution of EOUAL_TS and the filter to the conditional - Reduction of the filter with predicate 'FALSE' to EMPTYSET_I

>4

~transf in <funct mtc_t> with rule <instance: i_t>*

func t ion MTC_T (TI: term; T2: term): se t of i ; FILTER_I((I: ins tance) : bool;

-IS_VAR_O(OPTOR(TI)) A EOUAL_TS((INST_T(TI, I)) ,MAKE_TS(T2))) (REL_/NSTS_AS(ARGS(TI), ARGS(T2)))

~transf in <funct mtc_t> with rule <c: cdy_f21>-

~transf in <funct mtc_t> with rule <b: su_nsa_fl>*

func t ion MTC_T (TI: term; T2: term): se t_of_i ; FILTER_I((I: ins tance) : bool;

~IS_VAR_O(OPTOR(TI)) A if IS_VAR_O(OPTOR(TI)) then

EOUAL_TS(if ISDEF(I, OPTOR(TI)) then

GET(I, OPTOR(TI)) else

MAKE_TS(TI) endif , MAKE TS(T2))

e l se EQUAL_TS(MAKE_TS(MAKE_T(OFTOR(TI), INST_AS(ARGS(TI), I))), MAKE_TS(T2))

endif) )(REL_/NSTS_AS(ARGS(TI), ARGS(T2)))

CONDITION FULFILLED? DETERMINATE[IS_VA~_O(OPTOR(TI))]

~transf in <funct mtc_t> with rule <c: csi_fl>*

~trsmsf in <funct mtc_t> with rule <b: cv_sa_e>.

function MTC_T (TI: term; T2: term): set of i; FILTER~/((I: instance): bool;

(-IS_VAR_O(OPTOR(TI)) A EOUAL_TS(MAKE_TS(MAKE_T(OFTOR(TI), INST_AS(AI~S(TI), I))), MAKE_TS(T2))) )(REL_INSTS_AS(ARGS(TI), ARGS(T2)))

~transf in <ftmct rote_t> with rule <uu_j.: fdp_c>4

func t ion MTC_T (TI: term; T2: term): se t_of i ; ~FILTER_/( ( I: ins tance) : boo1;

Page 367: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 359

if - IS_VAR_O (OPTOR (TI) ) then

EQUAL_TS(MAKE_TS(MAKE_T(OPTOR(TI), INST_AS(ARGS(TI), I))), MAEE_TS(T2) ) else

false endif)(REL_INSTS_AS(ARGS(TI), ARGS(T2))))

CONDITION FULFILLED? DETERMINATE[-IS__VAR_O(OPTOR(TI))] ~y4

CONDITION FULFILLED? EMPTYSET_I E D REL_INSTS_AS(ARGS(TI), ARGS(T2)) ::~ DEFINED[~IS_VAR_O(OPTOR(TI)) ]

~y~

~transf in <funct mtc_t> with rule <uu_i: fsp_.fl>4

~comment<

i ........... GOAL Conditional form after expansion of EQUAL_TS

~TIONS

??

- Expansion of EOUAL_TS to a conditional - Elimination of "blind" branches - Distribution of the filter to the conditional - Reduction of the then-filter to EMPTYSET_I

>4

*transf in <funct mtc_t> with rule <s_ts: qcv_c>-

funct ion MTC_T (TI: term; T2: term): se t_of_i ; i f -IS_VAR_O(OPTOR(T1)) then

FILTER_I((I: ins tance) : bool; ~EOUAL_TS(MAKE_TS(MAKE_T(OPTOR(TI), INST_AS(ARGS(TI), I))), MAKE_TS(T2))) ) (REL_INSTS_AS(ARGS(TI), ARGS(T2)))

else EMPTYSET...I

endif

CONDITION FULFILLED? DETERMINATE[MAKE_TS(MAEE_T(OPTOR(TI), INST_AS(ARGS(TI), I))), MAKE_TS(T2)~ ~y4

*transf in <funct mtc_t> with rule <s_ts: iyk>4

funct ion MTC_T (TI: term; T2: term): se t_of_i ; i f ~IS_VAR_O(OPTOR(T1) ) then

FILTER_I((I: instance): bool; i f ~IS_Y_TS(MAKE_TS(MAKE_T(OPTOR(T1), INST_AS(ARGS(T1), I))))9 then

IS_Y_TS (MAKE_TS (T2)) e lse

if ~IS_Y_TS(MkKE_TS(T2))9 then

f a l s e e l se

EOUAL_T(FIRST_TS(MAKE_TS(MAKE_T(OPTOR(T1), INST_AS(ARGS(TI), I)))), FIRST_TS(MAKE_TS(T2))) ^ EOUAL_TS(REST_TS(MAKE_TS(MAKE_T(OPTOR(T1),

Page 368: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

360 IV.4 TERM

INST_AS(ARGS(TI), I)))), REST_TS(MAKE_TS(T2))) endif

endif)(HEI._INSTS_AS(ARGS(TI), ARGS(T2))) else

EMPTYSET_I endif

CONDITION FULFILLED? DEFINEDEMAKE_T(OPTOR(TI), INST_AS(ARGS(TI), I))] my.

CONDITION FULFILLED? KIND~MAKE_T(OPTON(TI), INST_AS(AHGS(TI), I))] = term ~y4

CONDITION FULFILLED? DEFINED~T2] my.

CONDITION FULFILLED? KIND[T2] = term byq

btransf <funct mtc_t> with set <c: csi_fl> documented*

~comment<

I GOAL Development of the filter predicate

>4

ACTIONS - Simplifications - Expansion of EQUAL_T - Simplifications

mtransf <funct mtc_t> with set <s_ts: fk>, <s_ts: rk> documented. CONDITION FULFILLED? EIND[MAKE_T(OPTOR(TI), INST_AS(ARGS(TI), I))~ = term

FK IS APPLIED TO FIRST_TS(MAKE_TS(MAKE_T(OPTOR(T1), INST_AS(ARGS(T1), I))))

CONDITION FULFILLED? KIND[T2] = term my.

FK IS APPLIED TO FIRST_TS(MAKE_TS(T2))

CONDITION FULFILLED? KIND~MAKE_T(OPTOR(TI), INST_AS(ARGS(T1), I))~ = term

CONDITION FULFILLED? DEFINED[MAKE_T(OPTOR(TI), INST_AS(ARGS(TI), I))~ ~y4

RK IS APPLIED TO REST_TS(MAKE_TS(MAKE_T(OPTOR(T1), INST_AS(ARGS(T1), I))))

Page 369: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 361

CONDITION FULFILLED? KIND[T2~ = term ~y4

CONDITION FULFILLED? DEFINED[T2~ ~y~

RK IS APPLIED TO REST_TS(MAKE_TS(T2))

~transf in <funct mtc_t> with rule <s_ts: qyy>~

function MTC_T (TI: term; T2: term): set of i; if ~IS_VAR_O(OPTOR(TI)) then

FILTER_I((I: instance): bool; EQUAL_T(MAKE_T(OPTOR(TI), INST_AS(ARGS(TI), I)), T2) A (EQUAL~TS(EMPTY_TS, EMPTY_TS)) )(REL_INSTS_AS(ARGS(TI), ARGS(T2)))

else EMPTYSET_I

endif

~transf in <funct mtc_t> with rule <b: si_atr>4

~transf in <funct mtc_t> with rule <term: ql_t>1

function MTC_T (TI: term; T2: term): set of i; if -IS_VAR_O(OPTOR(TI)) then

FILTER_I((I: instance): bool; (EQUAL_T(MAKE_T(OPTOR(TI), INST_AS(ARGS(TI), I)), T2)) )(REL_INSTS_AS(ARGS(TI),

ARGS(T2))) else

EMPTYSET_I endif

CONDITION FULFILLED? DETERMINATE[MAKE_T(OPTOR(TI), INST_AS(ARGS(TI), I)), T2~ ~y4

~transf in <funct mtc_t> with rule <term: op_mk>4

function MTC_T (TI: term; T2: term): set of_i; if -IS_VAR_O(OPTOR(TI)) then

FILTER_I((I: instance): beol; EQ_O((OPTOR(MAK~_T(OPTOR(TI), INST_AS(ARGS(TI), I)))> , OPTOR(T2)) A

NON_DIST_O((OPTOR(MAKE_T(OPTOR(TI), INST__AS(ARGS(TI), I)))) , OPTOR(T2)) A EOUAL_AS(ARGS(MAKE_T(OPTOR(TI), INST_AS(ARGS(TI), I))), ARGS(T2))) (REL_INSTS_AS(ARGS(TI), ARGS(T2)))

else EMPTYSET_I

endif

CONDITION FULFILLED? ASSERT[MAKABLE_T(OPTOR(TI), INST_AS(ARGS(TI), I))~ my4

CONDITION FULFILLED? ASSERT[MAKABLE_T(OPTOR(TI), INST_AS(ARGS(TI), I))~ ~y4

Page 370: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

362 IV.4 TERM

~transf in <funct mtc__t> with rule <term: asjnk>4

function MTC_T (TI: term; T2: term): set of_i; if ~IS_VAR_O(OPTOR(TI) ) then

FILTER_I((I: instance): bool; EQ_O(OPTOR(TI), OPTOR(T2)) A NON_DIST_O(OPTOR(TI), OPTOR(T2)) A EOUAL_AS((ARGS(MAKE_T(OPTOR(TI), INST_AS(ARGS(TI), I)))> , ARGS(T2))) (REL_INSTS_AS(ARGS(TI), ARGS(T2) ) )

else EMPTYSET_I

endif

CONDITION FULFILLED? ASSERT[MAKABLE_T(OPTOR(TI), INST_AS(ARGS(TI), I) )]

~comment<

GOAL Final development of the filter resulting in the conditional if EQ_O(OPTOR(TI), OPTOR(T2)) 'AND'

NON__DIST_O(OPTOR(TI), OPTOR(T2)) then MATCH_AS(ARGS(TI), ARGS(T2)) else EMPTYSET_I endif

ACTIONS - Conversion of the 'ANDSEQ' into a conditional - Distribution of the filter to the conditional - Reduction of the else-filter to EMPTYSET_I - Folding of MATCH_AS

>4

.transf in <funct mtc_t> with rule <b: cv_sa_c>-

function MTC_T (TI: term; T2: term): set of i; if ~IS_VAR_O(OPTOR(TI)) then

FILTER_I((I: instance): bool; ~EQ_O(OPTOR(TI), OPTOR(T2)) A NON_DIST_O(0PTOR(TI), OPTOR(T2)) A EQUAL__AS(INST_AS(ANGS(TI), I), ARGS(T2))) )(REL_INSTS_AS(ARGS(TI), ARGS(T2)))

else EMPTYSET_I

endif

.transf in <funct mtc_t> with rule <uu_i: fdp_c>~

function MTC_T (TI: term; T2: term): set of i; i f -IS_VAR_O(OPTOR(T1) ) then

(FILTER_I((I: instance) : bool; if EQ_O(OPTOR(TI), OPTOR(T2)) A NON_DIST_O(OPTOR(TI), OPTOR(T2)) then

EOUAL_AS(INST_AS(ARGS(TI), I), ARGS(T2)) else

false endif) (REL_INSTS_.AS(ARGS(TI), ARGS(T2) )))

else EMPTYSET_I

endif

Page 371: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4 .3 Developments 363

CONDITION FULFILLED? DETERMINATE~EQ_O(OPTOR(T1), OPTOR(T2)) A NON_DIST_O(OPTOR(TI), OPTOR(T2)) ~y~

CONDITION FULFILLED? EMPTYSET_I m_D REL_INSTS_AS(ARGS(TI), ARGS(T2)) ==>

DEFINED[EQ_O(OPTOR(TI), OPTOR(T2)) A NON_DIST_O(OPTOR(TI), OPTOR(T2)) ~y4

~transf in <funct mtc_t> with rule <uu_i: fsp_fl>4

~install <funct spmatch_as> unit <match func al: match_as>~

~transf in <funct mtc_t> with rule <f: ff2>~

function MTC_T (TI: term; T2: term): set of i; i f ~ IS_VAE_O (OPTOR (T 1 ) ) then

i f EQ_O(OPTOR(T1), OPTOR(T2)) A NON_DIST_O(OPTOR(T1), OPTOR(T2)) then

(FILTER_I((I: instance): bool; EQUAL_AS(INST_AS(ARGS(TI), I), ARGS(T2))) (REL_INSTS_AS(ARGS(TI), AHGS(T2)))>

else EMPTYSET_I

endif e l s e

EMPTYSET_I e n d i f

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct spmatch_as. CONDITION FULFILLED? DEFINED[FILTER_/( (I : instance) : bool ;

EOUAL_AS(INST_AS(ARGS(TI), I), ARGS(T2))) (REL_INSTS_AS(ARGS(TI), ARGS(T2))) ~ ~> DEFINED [MATCH_AS (ANGS (TI), ARGS ( T2 ) ) ]

my4

~copy <funct mtc_t>~

function MTC_T (TI: term; T2: term): set_of i; if -IS_VAR_O(OPTOR(T1) ) then

if EQ_O(OPTOR(TI), OPTOR(T2)) A NON_DIST_O(OPTOR(T1), OPTOR(T2)) then

MATCH_AS(ARGS(T1), ARGS(T2) ) else

EMPTYSET_I endif

else EMPTYSET_I

endif

~stop4

END SKERN START SKERN

Page 372: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

364 IV.4 TERM

~cormment<

Development of function

MTC_S

to recursive form

>4

~install unit <match func al: mtc_s>4

~comment<

GOAL Conversion of GET into INST_T

>4

~transf in <funct mtc__s> with rule <instance: gcv_/_t>4

function MTC_S (TSI: terms; TS2: terms): set_of_i; FILTER_/((I: instance): bool; -IS__Y_TS(TSI) A (IS_SQVAR_O(OPTOR(FIRST_TS(TSI))) A

ISDEF(I, OPTOR(FIRST_TS(TSI))) A EQUAL_TS( (GET(I, OPTOR(FIRST_TS(TSI)))) , GET_FRONT_TS(TS2, LENGTH_TS((GET(I, OPTOR(FIRST__TS(TSI)))) )1) A EOUAL_TS(INST_TS(REST_TS(TSI), I), DEL_FRONT_TS(TS2, LENGTH_TS((GET(I, OPTOR(FIRST_TS(TSI)))) )))))(REL_INSTS_TS(TSI, TS2))

~comment<

GOAL Simplification of the filter predicate after the analysis of EQ_TS(tsl, DEL__FRONT_TS(ts2, I)) w.r.t, the predicate EO_N(LENGTH_TS(tsl)+I, LENGTH_TS(ts2))

ACTIONS - Analysis of EQ_TS - Localization of 'NOT' IS_Y_TS(TSI) to condition and else-branch of

the conditional (required for the local decidablility of the enabling condition of the simplification a 'and' false to false, cf. next step)

- Reduction of the else-braslch to 'FALSE' - Removal of localized conditions

>4

~transf in <funct mtc_s> with rule <ss_ts: qcv_df__gr>4

function MTC_S (TSI: terms; TS2: terms): set of i; FILTER_I((I: instance): bool;

-IS_Y_TS(TSI) A (IS_SOVAR_O(OPTOR(FIRST_TS(TSI))) A ISDEF(I, OPTOR(FIRST_TS(TSI))) A EQUAL_TS(INST_T(FIRST_TS(TSI), I), GET_FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TSI), I)))) A (EOUAL_TS(INST_TS(REST_TS(TSI), I), DEI,_FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TSI), I))))) ))(REL_INSTS_TS(TSI, TS2))

.transf in <funct mtc_s> with rule <b: id__ac_te>4

funct ion MTC_~ (TSI: terms; TS2: terms): sea_of_i; FILTER_I((I: ins tance) : bool;

~IS_Y_TS(TSI) A (IS_SQVAR_O(OPTOR(FIRST_TS(TSI))) A

Page 373: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 365

ISDEF(I, OPTOR(FIItST_TS(TS1))) a 4,,EC)UAL_TS(INST_T(FIRST_TS(TS1), I ) , GET_FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TSI), I)))) A if EQ_N(LENGTH_TS(INST_TS(REST_TS(TSI), I)) + LENGTH_TS(INST_T(FIRST_TS(TSI), I)),

LENGTH_TS(TS2)) A LENGTH_TS(TS2) ge LENGTH_TS(INST_T(FIRST_TS(TSI), I)) V LENGTH_TS(TS2) It LENGTH_TS(INST_T(FIRST_TS(TSI), I)) A IS_Y_TS(TS2)

then EQUAL_TS (INST_TS (REST_TS (TS 1 ), I),

GET_REAR_TS(TS2, LENGTH_TS(INST_TS(REST_TS(TSI), I)))) else

LENGTH_TS(TS2) it LENGTH_TS(INST_T(FIRST_TS(TSI), I)) A ~IS_Y_TS(TS2) A IS_Y_TS(INST_TS(REST_TS(TSI), I) )

e n d i f ) )) (REL_INSTS_TS(TS1, TS2))

~comment<

['"GOAL . . . . . . . . . . Decomposition of the filter into the fusion of two filters by means of ] t h e o r e m INSTANCE: fdp_as_tsts

ACTIONS - Conversion of 'ANDSEQ' to conditional - Distribution of the filter to the conditional - Reduction of the else-filter t EMPTYSET_I - Application of the theorem

>4

~transf in <funct mtc_s> with rule <b: cv_sa_c>4

function MTC_S (TSI: terms; TS2: terms): set_of_i; FILTER_/((I: instance): bool;

(~IS_Y_TS(TSI) A (IS_SQVAR_O(OPTOR(FIRST_TS(TSI))) A ISDEF(I, OPTOR(FIRST_TS(TSI))) A if EQ_.N(LENGTH_TS(INST_TS(REST_TS(TSI), I)) + LENGTH_TS(INST_T(FIRST_TS(TSI), I)),

LENGTH_TS(TS2)) ^ LENGTH_TS(TS2) ge LENGTH_TS(INST_T(FIRST_TS(TSI), I)) V LENGTH_TS(TS2) it LENGTH_TS(INST_T(FIRST_TS(TSI), I)) A IS_Y_TS(TS2)

then EQUAL_TS(INST_T(FIRST_TS(TSI), I),

GET._FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TSI), I)))) A EQUAL_TS(INST_TS(REST_TS(TSI), I), GET_REAR_TS(TS2, LENGTH_TS(INST_TS(P~ST_TS(TSI), I))))

else EQUAL_TS(INST_T(FIRST_TS(TSI), I),

GET_FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TSI), I)))) A (LENGTH_TS(TS2) it LENGTH_TS(INST_T(FIRST_TS(TSI), I)) A ~IS_Y_TS(TS2) A IS_Y_TS(INST_TS(REST_TS(TSI), I)))

endif)) )(REL_.INSTS_TS(TSI, TS2))

*transf in <funct mtc_s> with rule <b: ay_aal>* ~transf in <funct mtc_s> with rule <b: ay_aal> inverted.

~transf in <funct mtc_s> with rule <ss_ts: gfsi_l>.

funct ion MTC_~ (TSI: terms; TS2: terms): s e t_o f_ i ; FILTER_I((I: i n s t ance ) : bool;

i f -IS_Y_TS(TS1) then

IS_SQVAR_O(OPTOR(FIRST_TS(TSI))) A ISDEF(I, OPTOR(FIRST_TS(TSI))) A if EQ_N(LENGTH_TS(INST_TS(REST_TS(TSI), I)) +

LENGTH_TS(INST_T(FIRST_TS(TSI), I)), LENGTH_TS(TS2)) A LENGTH_TS(TS2) ge LENGTH_TS(INST_T(FIRST_TS(TS1), I)) V LENGTH_TS(TS2) It

Page 374: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

366 IV.4 TERM

LENGTH_TS(INST_T(FIRST_TS(TS1), I ) ) ^ IS_Y_TS(TS2) then

EQUAL_TS(INST_T(FIRST_TS(TS1), I), GET_FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TSI), I)))) A

EQUAL_TS(INST_TS(REST_TS(TSI), I), GET_REAR_TS(TS2, LENGTH_TS(INST_TS(REST_TS(TSI), I))))

e l s e EQUAL_TS(INST_T(FIRST_TS(TSI), I),

~GET_FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TS1), I)))~ ) A LENGTH_TS(TS2) It LENGTH_TS(INST_T(FIRST_TS(TSI), I)) A (~IS_Y_TS(TS2) A IS_Y_TS(INST_TS(REST_TS(TS1), I)))

endif e l s e

f a l s e endif)(REL_INSTS_TS(TS1, TS2))

CONDITION FULFILLED? ASSERT[LENGTH_TS(TS2) it LENGTH_TS(INST_T(FIRST_TS(TSI), I))]

.transf in <ftmct mtc_s> with rule <ss_ts: qsi_ll>~

function MTC_S (TSl: terms; TS2: terms): set_of_i; FILTER_I((I: instance): bool;

if -IS_Y_TS(TSI) then

IS_SQVAR_O(OPTOR(FIRST_TS(TSI))) A ISDEF(I, OPTOR(FIRST_TS(TS1))) A if EQ_N(LENGTH_TS(INST_TS(REST_TS(TS1), I)) +

LENGTH_TS(INST_T(FIRST_TS(TSI), I)), LENGTH_TS(TS2)) A LENGTH_TS(TS2) ge LENGTH_TS(INST_T(FIRST_TS(TS1), I)) v LENGTH_TS(TS2) i t LENGTH_TS(INST_T(FIHST_TS(TS1), I ) ) A IS_Y_TS(TS2)

then EQUAL_TS(INST_T(FIRST_TS(TSI), I),

GET_FRONT_TS(TS2, LENGTH_TS(INST_T(FIHST_TS(TSI), I)))) A EQUAL_TS(INST_TS(REST_TS(TSI), I),

GET_REAR_TS(TS2, LENGTH_TS(INST_TS(REST_TS(TSI), I)))) e l s e

~EQUAL_TS(INST_T(FIRST_TS(TSI), I), TS2)~ A LENGTH_TS(TS2) i t LENGTH_TS(INST_T(FIRST_TS(TSI), I)) A (-IS_Y_TS(TS2) A IS_Y_TS(INST_TS(REST_TS(TSI), I)))

e n d i f e l s e

f a l s e endif)(REL_INSTS_TS(TS1, TS2))

CONDITION FULFILLED? ASSERT[LENGTH_TS(TS2) I t LENGTH_TS(INST_T(FIRST_TS(TSI), I))] ~y4

*transf <funct mtc_s> with set <b: si_fla> documented~

.transf in <funct mtc_s> with rule <uu_i: fdp_c>~

function MTC_~ (TSI: terms; TS2: terms): set_of_i; ~FILTER_I((I: instance): bool;

i f ~IS_Y_TS(TS1) then

IS~SQVAR_O(OPTOR(FIHST_TS(TSI))) A ISDEF(I, OPTOR(FIRST_TS(TSI))) A if EQ_N(LENGTH_TS(INST_TS(REST_TS(TS]), I)) +

LENGTH_TS(INST_T(FIRST_TS(TSI), I)), LENGTH_TS(TS2)) A LENGTII_TS(TS2) ge LENGTH_TS(INST_T(FIRST_TS(TS1), I)) V LENGTH_TS(TS2) It LENGTH_TS(INST_T(FIRST_TS(TSI)~ I)) A IS_Y_TS(TS2)

Page 375: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

I V . 4 . 3 Developments 367

then EQUAL_TS ( INST_T (FIRST_TS (TS I), i),

GET_FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TSI), I)))) A EOUAL_TS ( INST_TS (REST_TS (TSl), I),

GET_BEAR_TS (TS2, LENGTH_TS ( INST_TS (REST_TS ( TS 1 ), I ) ) ) ) else

false e n d i f

e l s e false

endif) (REL_INSTS_TS(TSI, TS2)))

CONDITION FULFILLED? DETERMINATE[-IS_Y_TS(TSI)~ ~y~

CONDITION FULFILLED? EMPTYSET_/ E D REL_INSTS_TS(TSI, TS2) =~ DEFINED[-IS_Y_TS(TSI)]

by~

~transf in <funct mtc_s> with rule <uu_i: fsp_fl>4

function MTC_S (TSI: terms; TS2: terms): set of_i; if -IS_Y_TS (TSI) then

FILTER_/( (I: instance) : bool ; IS_SQVAR_O(OPTOR(FIRST_TS(TSI))) A ISDEF(I, OPTOR(FIRST_TS(TS] )) ) A if EQ_N(LENGTH_TS(INST_TS(REST_TS(TS1), I)) +

LENGTH_TS(INST_T(FIEST_TS(TS1), I)), LENGTH_TS(TS2)) ^ LENGTH_TS(TS2) ge LENGTH_TS(INST_T(FIRST_TS(TSI), I)) V LENGTH_TS(TS2) It LENGTH_TS(INST_T(FIRST__TS(TS1), I)) A IS_Y_TS(TS2)

then EQUAL_TS ( INST_T (FIRST_TS (TS 1 ), I),

GET_FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TSI), I)))) A EQUAL_TS ( INST_TS (REST_TS (TS 1 ), I),

GET_REAR_TS(TS2, LENGTH_TS(INST_TS(REST_TS(TSI), I))) ) else

false endif) (REL_INSTS_TS(TSI, TS2))

else (FILTER-/((I: instance): bool; false)(REL_INSTS_TS(TSI, TS2)))

endif

CONDITION FULFILLED? DEFINED[REL_INSTS_TS(TSI, TS2)~ ~y4

*transf in <funct mtc_s> with rule <instance: fdp_as_tsts>-

function MTC_S (TSI: terms; TS2: terms): set_of i; if ~IS_Y_TS(TSI) then

(FILTER_I((I: instance): bool; IS_SQVAR_O(OPTOR(FIRST_TS(TSI))) A ISDEF(I, OPTOR(FIRST_TS(TSI))) A if EQ_N(LENGTH_TS(INST_TS(REST_TS(TSI), I)) +

LENGTH_TS(INST_T(FIRST_TS(TSI), I)), LENGTH_TS(TS2)) A LENGTH_TS(TS2) Ee LENGTH_TS(INST_T(FIRST_TS(TSI), I)) V LENGTH_TS(TS2) It LENGTH_TS(INST_T(FIRST_TS(TSI), I)) A IS_Y_TS(TS2)

then EQUAL_TS(INST_T(FIRST_TS(TSI), I),

GET_FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TSI), I)))) A EOUAL_TS(INST_TS(REST_TS(TSI), I),

GET_REAR_TS(TS2, LENGTH_TS(INST_TS(REST_TS(TS]), I))))

Page 376: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

368 IV.4 TERM

else f a l s e

endif)(REL_INSTS_TS(TSI, TS2))~ else

EMPTYSET_I endif

~con~nent<

GOAL A b s t r a c t i o n of t he l e f t h a n d f i l t e r ( e v a l u a t e s a l l match ing i n s t a n c e s o f t he sequence v a r i a b l e FIRST_TS(TS1) w i t h a r b i t r a r y subsequences a t t he f r o n t o f TS2) as f u n c t i o n MTC_SF. A b s t r a c t i o n o f t he r i g h t h a n d f i l t e r ( e v a l u a t e s a l l match ing i n s t a n c e s of REST_TS(TS1) wi th a r b i t r a r y sub - sequences a t the r e a r o f TS2) as f u n c t i o n MTC_SR.

>4

~install <funct spmtc_sf> unit <match func al: mtc_sf>-

~transf in <funct mtc_~> with rule <f: ff2>4

function MTC_S (TSI: terms; TS2: terms): set_of i; if -IS_Y_TS (TS i) then

FUSE_SET_SET((FILTER_I((I: instance): bool; IS_SQVAR_O(OPTOR(FIRST_TS(TSI))) A ISDEF(I, OPTOR(FIRST_TS(TSI))) A EOUAL_TS(INST_T(FIRST_TS(TSI), I),

GET_FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TSI), I))))) (REL_INSTS_TS(MAKE_TS(FIRST_TS(TSI)), TS2))) , FILTER_I((I: instance): bool; EQUAL_TS(INST_TS(REST_TS(TSI), I),

GET_REAR_TS(TS2, LENGTH_TS(INST_TS(REST_TS(TSI), I))))) (REL_INSTS_TS(REST_TS(TSI), TS2)), TSI, LENGTH_TS(TS2))

else EMPTYSET_I

endif

GIVE NAMED/MARKED UNIT FOR PARAMETER: statl)F .funct spmtc_sf~ CONDITION FULFILLED? DEFINED[FILTER_I((I: instance): bool;

IS_SQVAR_O(OPTOR(FIRST_TS(TSI))) A ISDEF(I, OPTOR(FIRST_TS(TSI))) A EQUAL_TS(INST_T(FIRST_TS(TSI), I), GET_FRONT_TS(TS2, LENGTH_TS(INST_T(FIRST_TS(TSI), I)))))(REL_INSTS_TS(MAKE_TS(FIRST_TS(TSI)), TS2))] DEFINED[MTC_SF(FIRST_TS(TSI), TS2)~

~y~

binstall <funct spmtc_sr> unit <match func al: mtc_sr>4

~transf in <funct mtc_s> with rule <f: ff2>~

function MTC__S (TSI: terms; TS2: terms): set_of i; if -IS_Y_TS(TSI) then

FUSE_SET_SET(MTC_SF(FIRST_TS(TSI), TS2), (FILTER_I((I: instance): hool; EQUAL_TS(INST_TS(REST_TS(TSI), I),

GET_REAR_TS(TS2, LENGTH_TS(INST_TS(REST_TS(TSI), I))))) (REL_INSTS_TS(REST_TS(TSI), TS2))) , TSI, LENGTH_TS(TS2))

else EMPTYSET_I

endif

Page 377: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 369

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct spmtc_sr. CONDITION FULFILLED? DEFINED[FILTER._I((I: instance): bool;

EOUAL_TS(INST_TS(REST_TS(TSI), I), GET_REAR_TS(TS2, LENGTH_TS(INST_TS(REST_TS(TSI), I)))))(REL_INSTS_TS(REST_TS(TSI), TS2))~ ~ DEFINED[MTC_SR(REST_TS(TSI), TS2)~

my4

~copy <funct mtc_s>4

function MTC_S (TSI: terms; TS2: terms): set_of i; if ~IS_Y_TS(TSI) then

FUSE_SET_SET(MTC_SF(FIRST_TS(TSI), TS2), MTC_SR(REST_TS(TSI), TS2), TSI, LENGTH_TS(TS2))

else EMPTYSET_I

endif

~stop4

END S KEP24 START SKERN

~comment<

Development of function

MTC_SF

to recursive form

>4

~install un i t <match func al: mtc_sf>*

~comment<

GOAL Simplification of filter predicate after expansion of INST_T at the left argument-position of EQ_TS resulting in a conditional of the form

if IS_SQVAR_O(OPTOR(T)) 'AND' ISDEF(I, OPTOR(T)) then el else e2 endif

>4

ACTIONS - Expansion of INST_T into a conditional - Distributions and simplifications

~transf in <funct mtc_sf> with rule <instance: i_t>4

func t ion MTC_SF (T: term; TS: terms): se t_of_i ; FILTER_/( (I : ins tance) : bool;

IS._~QVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A EOUAL_TS((INST_T(T, I)~ , GET_FHONT_TS(TS, LENGTH_TS(INST_T(T, I ) ) ) ) ) (REL_/NSTS_TS(MAKE_TS(T), TS) )

Page 378: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

370 IV.4 TERM

bt rans f in <funct mtc_sf> with ru le (c: cdy_f21>4

. t r a n s f in ( funct mtc_sf) with ru le (bb: si_asac_t>4

funct ion MTC_SF (T: term; TS: terms): se t_of_ i ; FILTER_I((I: ins tance) : bool;

~IS_SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A i f IS_VAR_O(OPTOR(T) ) then

EQUAL_TS(if ISDEF(I, OPTOR(T)) then

GET(I, OPTOR(T) ) e l s e

MAKE_TS (T) endif, GET_FRONT_TS(TS, LENGTH_TS(INST_T(T, I))))

else EQUAL_TS(MAKE_TS(MAKE_T(OPTOR(T), INST_AS(ARGS(T), I))), GET_FRONT_TS(TS, LENGTH_TS(INST_T(T, I))))

endif~ ) (REL_INSTS_TS(MAKE_TS(T), TS))

CONDITION FULFILLED? (true--=D IS_SQVAR_O(OPTOR(T)) A true m D ISDEF(I, OPTOR(T))) :=>

ASSERT[EQ_B(IS_VAR O(OPTOR(T)), true) ] ~y~

.transf in <funct mtc_sf> with rule <c: cdy_f21>~

.transf in <funct mtc_sf> with rule <b: ld__sac>4 ~transf in <funct mtc_sf> with rule <b: ay__asal>4 btransf in <funct mtc__sf> with rule <b: ip_sa>~

.comment<

I GOAL Reduction of the else-branch to 'FALSE'

>4

*transf in <funct mtc__sf> with rule <b: cv__sa_c>~

function MTC_SF (T: term; TS: terms): set_of i; FILTER_I((I: instance) : bool;

if IS_SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) then

EQUAL_TS(GET(i, OPTOR(T)), GET_FRONT_TS(TS, LENGTH_TS(INST_T(T, I)))) else

~IS_SOVAR_O(OpTOR(T)) A ISDEF(I, OPTOR(T)) A EQUAL_TS(MAKE TS(T), GET_FRONT_TS(TS, LENGTH_TS(INST_T(T, I))))>

endif) (REL_INSTS_TS(MAKE_TS(T), TS))

*transf in <funct mtc_sf> with rule <c: csi_ec_e>4

funct ion MTC_SF (T: term; TS: terms): se t_of_ i ; FILTER_I((I: instance) : bool;

~ i f IS_SQVAR_O(OPTOR(T)) h ISDEF(I, OPTOR(T)) then

EQUAL_TS(GET(1, OPTOR(T)), GET_FRONT_TS(TS, LENGTH_TS(INST_T(T, I)))) e l s e

i f IS__SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) then

EQUAL_TS(MAKE_TS(T), GET_FRONT_TS(TS, LENGTH_TS(INST_T(T, I ) ) ) ) e l s e

Page 379: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 371

false endif

endif) )(REL_INSTS_TS(MAKE_TS(T), TS))

CONDITION FULFILLED? false E D IS_SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) =~

ASSERT[EQ_B(IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)), false)] my4

~cor~ment<

I GOAL Conditional form after the expansion of the other INST_T

ACTIONS - Expansion of INST_T into a conditional - Distributions of functions to conditionals - Simplifications

>4

~transf in <funct mtc_sf> with rule <instance: i_t>4

f u n c t i o n MTC_SF (T: term; TS: terms): s e t _ o f i ; FILTER_/((I: i n s t a n c e ) : bool;

if IS_SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) then

EOUAL_TS(GET(I, OPTOR(T)), GET_FRONT_TS(TS, LENGTH_TS( (INST_T(T, I)) ))) else

false endif) (REL_INSTS_TS(MAKE_TS(T), TS))

~transf <funct mtc_sf> with set <c: cdy_f>, <c: cdy_f22> documented4 CDY_F IS APPLIED TO LENGTH_TS ( i f IS_VAR_O(OPTOR(T) ) then

if ISDEF(I, OPTOR(T)) then

GET(I, OPTOR(T) ) else MAKE_TS (T)

endif else

MAKE_TS(MAKE_T(OPTOR(T), INST_AS(ARGS(T), I))) endif)

CDY._F IS APPLIED TO LENGTH__TS ( if ISDEF(I, OPTOR(T)) then

GET(I, OPTOR(T) ) e l s e

MAKE_TS ( r ) end i f )

Page 380: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

372 IV.4 TEll4

CDY_F22 IS APPLIED TO GET_FHONT_TS (TS, if IS_V~_O(OPTOR(T) ) then

if ISDEF(I, OPTOR(T)) then

LENGTH_TS(GET(I, OPTOR(T) ) ) else

LENGTH_TS (MAKE_TS (T)) endif

else LENGT~L.TS(MAKE_TS(MA_KE_T(OPTOR(T), INST_AS(AHGS(T), I) ) ) )

endif)

CDY_F22 IS APPLIED TO GET_FRONT_TS(TS, if ISDEF(I, OPTOR(T)) then

LENGTH_TS(GET(I, OPTOR(T))) else

LENGTH~TS(MAKE_TS(T)) endif)

CDY322 IS APPLIED TO EQUAL_TS(GET(I, OPTOR(T)), if IS_VAR_O(OPTOR(T)) then

if ISDEF(I, OPTOR(T)) then

GET_FRONT_TS(TS~ LENGTH__TS(GET(I~ OPTOR(T)))) else

GET3RONT_TS(TS, LENGTH_TS(MAKE_TS(T))) endif

else GET_FHONT_TS(TS, LENGTH_TS(MAKE_TS(MAKE_T(OPTOR(T), INST_AS(AHGS(T), I)))))

endif)

CD¥_.F22 IS APPLIED TO EOUAL_TS(GET(I, OPTOR(T)), if ISDEF(I, OPTOR(T)) then GET_FHONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T))))

else GET_/~RONT_TS(TS, LENGTH_TS(MAKE_TS(T)))

endif)

~transf in <funct mtc_sf> with rule <c: csi_tc_t>4

func t ion MTC_SF (T: term; TS: terms): se t_of i~ FILTER_I((I: ins tance) : bool;

~ i f IS_30VAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) then

Page 381: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 373

if IS_VAR_O(OPTOR(T) ) then

if ISDEF(I, OPTOR(T)) then

EOUAL_TS(GET(I, OPTOR(T)), GET_.FRONT_TS(TS, LENGT}{_TS(GET(I, OPTOR(T))))) else

EQUAL_TS(GET(I, OPTOR(T)), GET__FRONT_TS(TS, LENGTH_TS(MAKE_TS(T))) ) endif

else EQUAL_TS (GET ( I, OPTOR (T) ), GET_FRONT_TS ( TS ~ LENGTH_TS (MAKE_TS (MAKE_T (OPTOR (T),

INST_AS(ARGS(T), I) ) ) ) ) ) endif

else false

endif~ ) (REL_INSTS_TS(MAKE_TS(T), TS))

CONDITION FULFILLED? true _c D IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) =~

ASSERT[EQ_B(IS_VAR_O(OPTOR(T)), true)

.transf in <funct mtc_sf> with rule <c: csi_tc_t>.

function MTC_SF (T: term; TS: terms): set_of_i; FILTER_I((I: instance): bool;

(if IS_SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) then

if ISDEF(I~ OPTOR(T)) t h e n

EOUAL_TS(GET(I~ OPTOR(T)), GET_FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T))) )) else

EOUAL_TS(GET(I, OPTOR(T)), GET_FRONT_TS(TS, LENGTH_TS(MAKE_TS(T)))) endif

else false

endif) ) (REL_INSTS_TS(MAKE_TS(T), TS))

CONDITION FULFILLED? true _c D IS_SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T))

ASSERT[EQ_B(ISDEF(I, OPTOR(T)), true) ]

.comment<

GOAL Analysis o f EO_TS within the then-branch I I

I ACTIONS - Conversion of EO_TS into an adjuction ('OR ~) of the cases "both arguments empty" and "both arguments non-empty"

- Simplification of the adjunction

>4

.trsnsf in <func% mtc_sf> with rule <s_ts: qcv_o>~

function MTC_SF (T: term; TS: terms): set_of_i; FILTER_I((I: instance) : bool;

if IS_SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) then

Page 382: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

374 IV.4 TEI~M

~EQUAL_TS(GET(I, OPTOR(T)), GET_.FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T)))))) else

false endif)(REL_INSTS_TS(MAEE_TS(T), TS))

CONDITION FULFILLED? DETEI~MINATE[GET(I, OPTOR(T)), GET_FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T))))] my4

.transf in <funct mtc__sf> with rule <s_ts: asu__iyl_iz>.

function MTC_SF (T: term; TS: terms): set_of_i; FILTER_/((I: instance): bool;

if IS__SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) then

(IS_Y_TS(GET(I, OPTOR(T))) A IS_Y_TS(GET_.FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T)))))) V (-IS_Y_TS(GET(I, OPTOR(T))) A -IS_Y_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T))))) A EQUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(GET3RONT_TS(TS, LENGTH__TS(GET(I, OPTOR(T)))))) A EQUAL_TS(EEST_TS(GET(I, OPTOR(T))), REST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T)))))))

else false

endif)(REL_INSTS_TS(MAKE_TS(T), TS))

CONDITION FULFILLED? DETEEMINATE~GET(I, OPTOR(T))] ~y4

~transf in <funct mtc_sf> with rule <s_ts: iy_gfz>4

function MTC_SF (T: term; TS: terms): set_of_i; FILTER_I((I: instance): bool;

if IS_SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) then

IS_Y_TS(GET(I, OPTOR(T))) A (IS_Y_TS(GET_FRONT_TS(TS, 0))) V (~IS_Y_TS(GET(I, OPTOR(T))) A - IS_Y_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T))))) A EOUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T)))))) A EQUAL_TS(REST_TS(GET(I, OPTOR(T))), REST_TS( GET_.FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T)))))))

else false

endif)(REL_INSTS_TS(MAKE_TS(T), TS))

CONDITION FULFILLED? DEFINED[TS] ~y~

CONDITION FULFILLED? KIND~TS] = terms my4

.transf in <funct mtc_sf> with rule <b: si_atr>4

~transf in <funct mtc_sf> with rule <ss_ts: iysi_niy_gfl>4

funct ion MTC_SF (T: term; TS: terms): s e t of i ; FILTER_I((I: ins tance) : bool;

i f IS_SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) then

IS_Y_TS(GET(I, OPTOR(T))) V (~-IS_Y_TS(GET(I, OPTOR(T))) A -IS_Y_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T)))))~ A EQUAL_T(FIRST_TS(GET(I, OFTOR(T))), FIRST_TS(GET_FRONT_TS(TS,

Page 383: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 375

LENGTH_TS(GET(I, OPTOR(T)))))) A EQUAL_TS(REST_TS(GET(I, OPTOR(T))), P~ST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T)))))))

else false

endif)(REL_INSTS_TS(MAKE_TS(T), TS))

CONDITION FULFILLED? DETERMINATE[GET(I, OPTOR(T))] ~y~

~transf in <tuner mtc_sf> with rule <ss_ts: sasu_fgf..f>4

function MTC_SF (T: term; TS: terms): set_of i; FILTER_/((I: instance): bool;

if IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) then

IS_Y_TS(GET(I, OPTOR(T))) V ((-IS_Y_TS(GET(I, OPTOR(T))) A -IS_Y_TS(TS) a EOUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I,

OPTOR(T)))))) A EQUAL_TS(REST_TS(GET(I, OPTOR(T))), REST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T))))))))

e l s e false

endif)(P~L_INSTS_TS(MAKE_TS(T), TS))

CONDITION FULFILLED? DETEI~MINATE[GET(I, OPTOR(T))~ ~y4

~transf in <funct mtc_sf> with rule <b: cv_sa__c> inverted4

function MTC_SF (T: term; TS: terms): set_of_i; FILTER_I((I: instance): bool;

(if IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) them

IS_Y_TS(GET(I, OPTOR(T))) V (-IS_Y_TS(GET(I, OPTOR(T))) A ~IS_Y_TS(TS) EQUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(TS)) A EQUAL_TS(P~ST_TS(GET(I,

OPTOR(T))), REST_TS(GET_FIK)NT_TS(TS, LENGTH_TS(GET(I, OPTOR(T))))))) else

false endif~ )(REL_INSTS_TS(MAKE_TS(T), TS))

~transf in <funct mtc_sf> with rule <b: id_sao>4

~comment<

GOAL "Distribution" of the filter to the 'OR' resulting in a UNION_I of two filters, afterwards conversion of the first of them into the conditional

if IS_SOVAR__O(OPTOR(T)) then ADD(VOID, OPTOR(T), EMPTY_TS) else EMPTYSET_I endif

>4

~t rans f in <funct mtc_sf> with ru le <uu_i: fdp_o>4

funct ion MTC__SF (T: term; TS: terms): se t_of_ i ; (FILTER_I((I: ins tance) : bool;

(IS_SQVAR_O(OPTOR(T)) ^ ISDEF(I, OPTOR(T)) a IS_Y_TS(GET(I, OPTOR(T)))) v (IS_S~VAR_O(OFTOR(T)) ^ ISDEF(I, OPTOR(T)) A (-IS_Y_TS(GET(I, OFTOR(T))) A

Page 384: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

376 IV.4 TERM

-IS_Y_TS(TS) ~ EQUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(TS)) A EOUAL_TS(REST_TS(GET(I, OPTOR(T))), REST_TS(GET_FRONT_TS(TS, LENGTR_TS(GET(I,

OPTOR(T)))))))))(REL-/NSTS_TS(MAKE_TS(T), TS)))

CONDITION FULFILLED? DETEEMINATE[REL_INSTS_TS(MAKE_TS(T), TS)]

.transf in <funct mtc_sf> with rule <instance: fsi_s_iyg_ts>.

funct ion MTC_SF (T: term; TS: terms): se t_of_i ; UNION_I((FILTER_I((I: ins tance) : bool;

IS_SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A IS_Y_TS(GET(I, OPTOR(T)))) (REL_/NSTS_TS(MAKE_TS(T), TS))) , FILTER_I((I: ins tance) : bool; IS_SQVAD_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A (-IS_Y_TS(GET(I, OPTOR(T))) A -IS_Y_TS(TS) A EQUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(TS)) A EQUAL_TS(REST_TS(GET(I, OPTOR(T))), REST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I,

OPTOR(T))))))))(REL_INSTS_TS(MAKE_TS(T), TS)))

.comment<

I GOAL Case Analysis of the remaining filter w.r.t, the predicate IS_Y_TS(TS)

ACTIONS - Branching with the mentioned predicate - Reduction of the then-filter to EMPTYSET_/ - "Distribution" of the else-filter to the 'AND' by means of theorem

INSTANCE: FDP_A_S_TTS employing function COMBINE_I - Folding of the righthand argument of COMBINE_/ by MATCH_SF

(recursion)

>4

.transf in <funct mtc_sf> with rule <c: csi_qb> inverted4

function MTC_SF (T: term; TS: terms): set_of_i; UNION_I(if IS_SQVAR_O(OPTOR(T)) then

ADD(VOID, OPTOR(T), EMPTY_TS) else

EMPTYSET_I endif, (FILTER_I((I: instance): bool;

IS__SOVAR_O(OPTOR(T)) A ISDEF(I, OFTOR(T)) ~ (-IS_Y_TS(GET(I, OPTOR(T))) A -IS_Y_TS(TS) A EOUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(TS)) A EQUAL_TS(REST_TS(GET(I, OPTOR(T))), REST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I, OPTOR(T))))))))(REL_INSTS_TS(MAKE_TS(T), TS))) )

GIVE NAMED/MARKED UNIT FOR PARAMETER: C -in <funct mtc__sf>*

function MTC__SF (T: term; TS: terms): set_of_i; UNION_/(if IS_SOVAR_O(OPTOR(T) ) then

ADD(VOID, OPTOR(T), EMPTY_TS) e l s e

EMPTYSET_I endif, FILTER_/((I: instance): bool;

IS_SQVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A (-IS_Y_TS(GET(I, OPTOR(T))) A - (IS_Y_TS(TS)) A EQUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(TS)) A EOUAL_TS(REST_TS(GET(I, OPTOR(T))), REST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I,

OPTOR(T))))))))(REL_INSTS_TS(MAKE_TS(T), TS)))

Page 385: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 377

CONDITION FULFILLED? KIND[IS_Y_TS(TS)] = bool ~y~

CONDITION FULFILLED? DEFINED[IS_Y_TS(TS)] my~

.transf in <funct mtc_sf> with rule <c: csu_tfl>.

function MTC_SF (T: term; TS: terms): set_of_i; UNION_I(if IS_SOVAR_O(OPTOR(T)) then

ADD(VOID, OPTOR(T), EMPTY_TS) else

EMPTYSET_I endif, (if IS_Y_TS(TS) then

FILTER_I((I: instance): bool; IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A (-IS_Y_TS(GET(I, OPTOR(T))) A -IS_Y_TS(TS) A EOUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(TS)) A EOUAL_TS(REST_TS(GET(I, OPTOR(T))), REST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I,

OPTOR(T))))))))(REL_INSTS_TS(MAKE_TS(T), TS)) else

FILTER_/((I: instance): hool; IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A (-IS_Y_TS(GET(I, OPTOR(T))) A -IS_Y_TS(TS) A EOUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(TS)) A EOUAL_TS(REST_TS(GET(I, OPTOR(T))), REST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I,

OPTOR(T))))))))(REL_INSTS_TS(MAKE_TS(T), TS)) endif~ )

~name in <funct mtc_sf> with.

funct ion MTC_SF (T: term; TS: terms): se t_of_ i ; UNION_/( if IS_SOVAR_O(OPTOR(T)) then

ADD(VOID, OPTOR(T), EMPTY_TS) else

EMPTYSET_I endif, if IS_Y_TS(TS) then

(FILTER_I((I: instance): bool; IS_~OVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A (-IS_Y_TS(GET(I, OPTOR(T))) A false A EQUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(TS)) A EOUAL_TS(REST_TS(GET(I, OPTOR(T))), REST_TS(GET_.FRONT_TS(TS, LENGTIt_TS(GET(I, OPTOR(T))))))))(REL_INSTS_TS(MAKE_TS(T), TS)))

else (FILTER_I((I: instance): bool;

IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A (~IS_Y_TS(GET(I, OPTOR(T))) A -IS_Y_TS(TS) A EQUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(TS)) A EQUAL_TS(REST_TS(GET(I, OPTOR(T))), REST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I,

OFTOR(T))))))))(REL_INSTS_TS(MAKE_TS(T), TS))) endif)

GIVE NAME FOR NEXT UNIT: pt4

GIVE NAME FOR NEXTUNIT: ~e4

~t rans f in <expr t> with ru le <b: ay_sasal> inver ted~

Page 386: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

378 IV.4 TERM

~transf in <expr t> with rule <bb: shmmsaa_sar>~

FILTER_I((I: i n s t a n c e ) : bool ; ~IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A ~ IS_Y_TS(GET(I, OPTOR(T))) A false~ A EOUAL_T(FIRST_TS(GET(I, OPTOR(T))), FIRST_TS(TS)) A EQUAL_TS(REST_TS(GET(I,

OPTOR(T))), REST_TS(GET_FRONT_TS(TS, LENGTH_TS(GET(I,OPTOR(T))))))) (REL_INSTS_TS(MAKE_TS(T), TS))

CONDITION FULFILLED? DETERMINATE[ISDEF(I, OPTOR(T))] ~y~

-transf <expr t> with set <b: si_afl>, <b: si_safl>, <b: si_flsa>, <uu_i: fsp_f> documented4 .copy <expr t>~

EMPTYSET_I

.transf <expr e> with rule <instance: fdp_a_s_tts>.

.transf in <expr e> with rule <instance: gcv_i_t>4

i f IS_SQVAR_O(OPTOR(T)) A ~IS_Y_TS(TS) A FITS(OPTOR(T), MAKE_TS(FIRST_TS(TS))) then

COMBINE_/(ADD(VOID, OFTOR(T), MAKE_TS(FIRST_TS(TS))), FILTER_I((I: instance): bool; IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A

EQUAL_TS((GET(I, OPTOR(T))) , GET_FRONT_TS(REST_TS(TS), LENGTH_TS ((GET (I, OPTOR(T) )) ) ) ) ) (REL_INSTS_TS (MAKE_TS (T), REST_TS (TS)) ) )

else EMPTYSET_I

e n d i f

.install <funct spmtc_sf> unit <match func al: mtc_sf>~

~transf in <expr e> with rule <f: ff2>*

i f IS_SOVAR_O(OPTOR(T)) A ~IS_Y_TS(TS) A FITS(OPTOR(T), MAKE_TS(FIRST_TS(TS))) then

COMBINE_I(ADD(VOID, OPTOR(T), MAKE_TS(FIRST_TS(TS))), (FILTER_I((I: instance) : bool; IS_ZOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A

EOUAL_TS(INST_T(T, I), GET_FRONT_TS(REST_TS(TS), LENGTH_TS(INST_T(T, I) ) ) ) ) (REL_INSTS_TS(MAKE_TS(T), REST_TS(TS) ) )) )

else EMPTYSET_I

endif

GIVE NAMED~KED UNIT FOR PARAMETER: statDF ~funct spmtc_sf4 CONDITION FULFILLED? DEFI~D[FILTER_I ( (I: instance ) : bool;

IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(T)) A EQUAL_TS(INST_T(T, I ) , GET_FRONT_TSfREST_TS(TS), LENGTH_TS( INST_T(T, I) ) ) ) ) (REL_INSTS_TS(~KE._TS(T), REST_TS(TS) ) ) ~

DEFINED~MTC_SF(T, REST_TS (TS)) ]

,comment<

I GOAL Final simplification of the whole function body

Page 387: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 379

ACTIONS - Distribution of UNION_/ to conditionals - Elimination of UNION_I with EMPTYSET_I-argument - Elimination of "blind" branches

>4

~copy <funct mtc_sf>4

function MTC_SF (T: term; TS: terms): set_of_i; UNION_I(if IS_SOVAR_O(OPTOR(T) ) then

ADD(VOID, OPTOR(T), EMPTY_TS) else

EMPTYSET_I endif, if IS_Y_TS (TS) then

EMPTYSET_/ else

if IS_SOVAR_O(OPTOR(T)) A -IS_Y_TS(TS) A FITS(OPTOR(T), MAKE_TS(FIRST_TS(TS) )) then

COMBINE_/(ADD(VOID, OPTOR(T), MAKE_TS(FIRST_TS(TS))), MTC_SF(T, REST_TS(TS))) else

EMPTYSET_I endif

endif)

.transf <funct mtc_sf> with set <c: cdy_f21>, <c: cdy_f22>, <re_i: usi_er>, <re_i: usi_el> documented. .transf in <funct mtc__sf> with rule <c: csu_ttr>4

function MTC_SF (T: term; TS: terms): set_of_i; ( i f IS_SOVAR_O(OPTOR(T) ) then

if IS_Y_TS (TS) then

ADD(VOID, OPTOR(T), EMPTY_TS) else

if IS_SOVAR_O(OPTOR(T)) A -IS_Y_TS(TS) A FITS(OPTOR(T), MAEE_TS(FII~ST_TS(TS))) then

UNION_/(ADD(VOID, OPTOR(T), EMPTY_TS), COMBINE_I(ADD(VOID, OPTOR(T), MAKE_TS(FIRST_TS(TS) ) ), MTC_SF(T, REST_TS(TS) ) ) )

else ADD(VOID, OPTOR(T), EMPTY_TS)

endif end i f

e l s e if IS_Y_TS (TS) then

EMPTYSET_I else

if IS_SQVAR_O(OPTOR(T)) A-IS_¥_TS(TS) A FITS(OPTOR(T), MAKE_TS(FIRST_TS(TS))) then

CO~I~E_I(ADD(VOID, OPTOR(T), ~L~XE_TS(FIRST_TS(TS))), MTC_SF(T, REST_TS(TS)) ) e l s e

EMPTYSET_/ endif

endif endif~

Page 388: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

380 IV.4 TERM

~transf in <funct mte_sf> with rule <c: csu_efl>4

function MTC_SF (T: term; TS: terms): set_of_i; (if IS_SOVAR_O(OPTOR(T) ) then

if IS_Y_TS (TS) then

ADD(VOID, OPTOR(T), EMPTY_TS) else

if true A -IS_Y_TS(TS) ~ FITS(OPTOR(T), MAKE_TS(FIRST_TS(TS))) then

UNION_I(ADD(VOID, OPTOR(T), EMPTY_TS), COMBINE_I(ADD(VOID, OPTOR(T), MAKE_TS(FIRST_TS(TS) ) ), MTC_SF(T, REST_TS(TS) ) ) )

else ADD(VOID, OPTOR(T), EMPTY_TS)

endif endif

else if IS_Y_TS (TS) then

EMPTYSET_I else

if IS_SQVAR_O(OPTOR(T)) A -IS_Y_TS(TS) ~ FITS(OPTOR(T), MAKE_TS(FIRST_TS(TS))) then

COMBINE_I(ADD(VOID, OPTOR(T), MAKE_TS(FIRST_TS(TS))), MTC_SF(T, REST_TS(TS))) else

EMPTYSET_I endif

endif endif~

~name in <ftmct mtc_sf> with4

function MTC_SF (T: term; TS: terms): set_of_i; if IS_SOVAR_O(OPTOR(T) ) then

(if IS_Y_TS (TS) then

ADD(VOID, OPTOR(T), EMPTY_TS) else

if true A ~IS_Y_TS(TS) ~ FITS(OPTOR(T), MAKE_TS(FIRST_TS(TS))) then

UNION_I(ADD(VOID, OPTOR(T), EMPTY_TS), COMBINE_I(ADD(VOID, OPTOR(T), MAKE_TS (FIRST_TS (TS)) ), MTC_SF (T, REST_TS (TS)) ) )

else ADD(VOID, OPTOI~(T), EMPTY_TS)

endif endif~

else (if IS_Y_TS (TS) then

EMPTYSET_I else

if false A ~IS_Y_TS(TS) ~ FITS(OPTOR(T), MAKE_TS(FIRST_TS(TS))) then

C(IMBINE_I(ADD(VOID, OPTOR(T), MAKE_TS(FIRST_TS(TS))), MTC_~F(T, REST_TS(TS))) e l se

EV~TYSET_I endi f

endif~ end i f

Page 389: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 381

GIVE NAME FOR NEXT UNIT: ~t24

GIVE NAME FOR NEXT UNIT: ~e24

~transf <expr t2> with rule <c: csu_etr>~

~transf <expr t2> with set <b: si_atr>, <b: si_trsa>, <b: si_fla>, <b: si_flsa>, <c: csi_qb> documented~

~copy <expr t2>4

i f IS_Y_TS (TS) then

ADD(VOID, OPTOR(T), EMPTY_TS) else

if FITS(OPTOR(T), MAKE_TS(FIRST_TS(TS))) then

UNION_I(ADD(VOID, OPTOR(T), EMPTY_TS), COMBINE_I(ADD(VOID, OPTOR(T), MAKE_TS(FIRST_TS(TS) ) ), MTC_SF(T, REST_TS(TS) ) ) )

else ADD(VOID, OPTOR(T), EMPTY_TS)

e n d i f endif

~transf <expr e2> with set <b: si_atr>, <b: si_trsa>, <b: si_fla>, <b: si_flsa>, <c: csi_qb> documented~

~copy <expr e2>~

EMPTYSET_I

~copy <funct mtc_sf>4

f u n c t i o n MTC_SF (T: term; TS: te rms) : s e t _ o f i ; if IS_SOVAR_O(OPTOR(T)) then

if IS_Y_TS(TS) then

ADD(VOID, OPTOR(T), EMPTY_TS) else

if FITS(OPTOR(T), MAKE_TS(FIRST_TS(TS))) then

UNION_I(ADD(VOID, OPTOR(T), EMPTY_TS), COMBINE_I(ADD(VOID, OPTOR(T), MAEE_TS(FIRST_TS(TS))), MTC_SF(T, REST_TS(TS))))

else ADD(VOID, OPTOR(T), EMPTY_TS)

endif endif

else EMPTYSET_I

endif

~stop~

END SKERN START SKERN

Page 390: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

382 IV.4 TERM

~com~ent<

Development of function

MTC_SR

to recurslve form

>4

binstsll unit <match func al: mtc_sr>4

~corment<

GOAL Conversion of EQ_TS into an 'OR' and "distribution" of th6 filter resulting in a UNION__I of two filters

>4

~transf in <funct mtc_sr> with rule <ss_ts: qcv_o_grl_r>4

function MTC_SR (TSI: terms; TS2: terms): set_of_i; FILTER_I((I: instance): bool;

(EQUAL_TS(INST_TS(TSI, I), GET_REAR_TS(TS2, LENGTH_TS(INST_TS(TSI, I))))) ) (REL_INSTS_TS(TSI, TS2))

CONDITION FULFILLED? DETEI~MINATE[INST_TS(TSI, I), TS2] ~y4

~transf in <funct mtc_sr> with rule <uu_i: fdp_o>4

function MTC_SR (TSI: terms; TS2: terms): set of i; (FILTER_I((I: instance): bool;

EOUAL_TS(INST_TS(TSI, I), TS2) V (-IS_Y_TS(TS2) A EOUAL_TS(INST_TS(TSI, I), GET_J~EAR_TS(REST_TS(TS2), LENGTH_TS(INST_TS(TSI, I))))))(REL_INSTS_TS(TSI, TS2)))

CONDITION FULFILLED? DETEI~4INATE[REL_INSTS_TS(TSI, TS2)] my4

~comment<

I GOAL

>4

Folding of the lefthand filter by MTC_TS

~install <funct spmtc_ts> unit <match func al: mtc_ts>4

~transf in <funct mtc_sr> with rule <f: ff2>4

function MTC_SR (TSI: terms; TS2: terms): set of i; UNION_I((FILTER_I((I: instance): bool;

EOUAL_TS(INST_TS(TSI, I), TS2))(REL_INSTS_TS(TSI, TS2))) , FILTER_I((I: instance): bool; -IS_Y_TS(TS2) A EQUAL_TS(INST_TS(TSI, I), GET_REAR_TS(REST_TS(TS2),

LENGTH_TS(INST_TS(TSI, I)))))(REL_INSTS_TS(TSI, TS2)))

GIVE NAMED/MAP~KED UNIT FOR PARAMETER: statDF ~funct spmtc_ts4

Page 391: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.4.3 Developments 383

CONDITION FULFILLED? DEFINED[FILTER_I((I: instance): bool;

EOUAL_TS(INST_TS(TSI, I), TS2))(REL_INSTS_TS(TSI, TS2))] =~ DEFINED~MTC_TS(TSI, TS2)]

~y4

~comment<

GOAL Development of the remaining filter to the conditional if 'NOT' IS_Y_TS(TS2) then MTC_SH(TSI, REST_TS(TS2)) else EMPTYSET_/ endif

ACTIONS - Conversion of sequential and to conditional - Distribution of the filter to the conditional - Reduction of the else-filter to EMPTYSET_I - Diminishing of REL_/NSTS_TS(TSI, TS2) - Folding of MTC_SR

>4

.transf in <funct mtc_sr> with rule <b: cv_~sa_c>4

function MTC_SR (TSI: terms; TS2: terms): set of_i; UNION_I(MTC_TS(TSI, TS2), FILTER_I((I: instance) : bool;

(~IS_Y_TS(TS2) A EOUAL_TS(INST_TS(TSI, I), GET_.REAR_TS(REST_TS(TS2), LENGTH_TS(INST_TS(TSI, I) ) ) )) ) (REL__INSTS_TS(TSI, TS2) ) )

~transf in <ftmct mtc_sr> with rule <uu_i: fdp_c>4

function MTC_SR (TSI: terms; TS2: terms): set_of i; UNION_I(MTC_TS(TSI, TS2), (FILTER_I((I: instance) : bool;

if -IS_Y_TS (TS2) then

EQUAL_TS(INST_TS(TSI, I), GET_REAR_TS(REST_TS(TS2), LENGTH_TS(INST_TS(TSI, I)))) else

false endif) (REL_/NSTS_TS(TSI, TS2))) )

CONDITION FULFILLED? DETERMINATE[~IS_Y_TS (TS2) ] ~y~

CONDITION FULFILLED? EMPTYSET_I _c D REL_INSTS_TS(TSI, TS2) ~ DEFINED[-IS_Y_TS(TS2)]

m-y~

~transf in <funct mtc_sr> with rule <uu_i: fsp__fl>~

*transf in <funct mtc_sr> with ru le <instance: rldm~sr_ts>~

function MTC_SR (TSI: terms; TS2: terms): set_of_i; UNION_I(MTC_TS(TSI, TS2>, if - IS_Y_TS (TS2) then

(FILTER_/((I: instance): bool; EOUAL_TS(INST_TS(TSI, I), GET_REAR_TS(REST_TS(TS2), LENGTH_TS(INST_TS(TSI,

I) ) ) ) ) (REL_INSTS_TS (TSI, TS2) )) else

EMPTYSET_I endif)

Page 392: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

384 IV.4 TERM

~install <funct spmtc_sr> unit <match func al: mtc_sr>.

~transf in <ftmct mte_sr> with rule <f: ff2>4

function MTC_SR (TSI: terms; TS2: terms): set_of_i; UNION_/(MTC_TS(TSI, TS2), if ~IS_Y_TS(TS2) then

(FILTER~((I: instance): bool; EOUAL_TS(INST_TS(TSI, I), GET_REAR_TS(REST_TS(TS2), LENGTH_TS(INST_TS(TSI, I)))))(REL_INSTS_TS(TSI, REST_TS(TS2))))

else EMPTYSET_I

endif)

GIVE NAMED/MARKED UNIT FOR PARAMETER: statDF ~funct spmtc_sr4 CONDITION FULFILLED? DEFINED[FILTER_I((I: instance): bool;

EQUAL_TS(INST_TS(TSI, I), GET_REAR_TS(REST_TS(TS2), LENGTH_TS(INST_TS(TSI, I))))) (REL_INSTS_TS(TSI, REST_TS(TS2)))] ~ DEFINED[MTC_SR(TSI, REST_TS(TS2))]

my~

~comment<

I GOAL Final simplification of the whole function-body

- Distribution of UNION_/ to the conditional - Elimination of the else-union

>4

.transf in <funct mtc_sr> with rule <c: cdy_f22>.

~transf in <funct mtc_sr> with rule <m_i: usi_er>4

~copy <ftmct mtc_sr>4

funct ion MTC_~R (TSI: terms; TS2: terms): se t_of i ; i f ~IS_Y_TS(TS2) then

UNION_I(MTC_TS(TS1, TS2), MTC_SR(TS1, REST_TS(TS2))) e l se

MTC_TS(TS1, rs2) end i f

~stop4

END SKERN

Page 393: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.5 Experiences

385

5. Experiences

The formal development of the core of CIP-S from the specification has been performed down to imperative, procedural level of CIP-L, i .e. the operations of the newly defined types are represented by equivalent functions and procedures from suitable modules (cf. [Bauer et al. 85]). To our surprise, the formal developments tun~d out far less formidable than we had feared. Therefore we also t ry to communicate our experiences that were made during the formal system development. These experiences are either of a more general, methodological nature or tied to the use of the CIP prototype.

5.1. I~l(gical experiences with Iz~ti(ml devel(lwen~s

Some of the experiences in connection with the formal system development by transformations are on the pure methodological side, i.e. independent of the use of the prototype transformation system.

Clean modular structure

The fact that the system development turned out to be less formidable than we had feared was, to a large extent, due to the very clean overall modular structure of the specification. This in particular allowed independent development of the essential parts of the system without the usual "interface problems", since the structure of the in~plementation actually follows the structure of the specification. Also ~ clean fine structuring in the individual operations paid, since i t provided a rough guide-line for the respective developments: Each operation could be developed individually, and only at the very end of the development certain pieces were put together, mainly by means of unfolding. Thus we have learnt that i t PaYs to invest time into a carefully structured specification, since this not only contributes to clarity and understandability, but also significantly decreases the actual development time.

Use of available knowledge

When the development process started, everybody's experience was based on relatively small case studies. In particular, nobody had an idea on how many new strategies and transformation rules would have to be developed in order to perform the actual derivations. Fortunately, however, i t turned out that the currently acc~ulated knowledge in the field of transformational programming provides a good and even fairly sufficient basis for practical work.

Creation of rule catalogs

One of the main efforts during the developments were the accumulation and organization of the necessary catalogs of transformation rules. Although quite a number of individual rules already were available from previous case studies, a lot of new ones had to be derived and formally proved correct. This is because most of the previous developments concentrated on specific aspects or certain methodological technic~es like recursion removal, backtracking, or tabulation. In developing the system core, however, we had to deal with many of these aspects at a time. Moreover, aiming at an imperative, procedural realization of the specification, the development touched all the levels of CIP-L, i.e, the abstract i~ypes as well as functional, applicative, and imperative levels. We think that the result of our efforts, i.e. the now available catalogs of rules (cf. Part V), provide a good and rather ~rehensive basis for future practical developments - either still with the prototype system or later with CIP-S.

Page 394: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

386

IV.5 Experiences

Organization of the rule catalogs

In order to keep the mass of rules structured to allow easy retrieval and quick access, the rules have been partitioned into several smaller catalogs. There is one group of catalogs for rules dealing with specific language constructs or with specific language levels, a further group for rules over data type, and a third for rules expressing techniques (e.g. fold, unfold, change of recursion). Within each catalog of rules there are two extreme possibilities of organization. First, one can use very large catalogs containing mmLv specific but also v ~ powerful rules, that allow big steps in the developments. Second, one can have rather small catalogs with only few but general rules realizing only small steps. Of course, i t is up to the program~ with vlnich degree of specialization or generali~ of his rules he prefers to work. Our experience has taught us that i t is indeed possible and practical to use quite large catalogs. To allow nevertheless easy retrieval and quick access, we have devised a certain nommclature for rules. Since the name of a rule reflects the idea of application, we were, in most cases, able to determine the name of a desired rule and hence to find i t in the respective catalog by simply following these naming conventions backwards.

Generalization of transformation rules by abstraction

After having done some of the concrete developments, certain sim17arities between some of them could be observed. By identif~dng these "development patterns" and clearly bringing out the respective similarities by suitable abstractions, widely applicable, fairly general transformation rules could be developed as a by-product of the actual system development. The rules given in [M~ller, Paukner 86] for "conditional join operations" are a i~ypical example of such rules. I t is to be hoped that further large-scale applications of the transformational approach will lead to similar "side effects", thus helping to establish a practically extremely useful, manageable set of basic principles for program development.

Libraries of imple~tations for basic data types

I t alrea~ has been advocated elsevahere that "libraries" of different implementations for basic data t)~Des such as sets, sequences, maps, etc. should be established. From our current experience with the system development we can whole-heartedly support this view. However, we also found out that for practical use, i t would be extremely helpful, ~f any such implementation also would be augmented with sufficient information (e.g. about efficiency relative to some context) in order to guide the choice of implementation.

Need for more tedmical knowledge about the development of data l~i~s

Ali~ugh, for our particular problem, we were able to manage the (theoretically non-trivial) formal transition from algebraically defined data t)IDes to f irst, not yet operative implementations by computation structures, we are convinced that more efforts have to be invested in order to solve this problem on a more general level. In some sense a si~nTar remark holds for the data ~ developments at the 'qower" end, i.e. the transition to efficient pointer implementations using the concept of updatable storage. Thus our experiences confirm the gradually realized need for more methodological work on data ~ developments, but also on the question of how to suitably interlm~ne control structure and data structure developments ("joint development").

5.2. F_xperiem~ in using the C~ ~

Apart from the more general methodological experiences, we also made experiences on the use of an implemented system - in our case the existing, purely experimental CIP prototype system - for the transformational development of large-scale software.

Page 395: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

IV.5.2 Experiences in using the CIP prototype system

387

Functionality of the prototype

Most of the developments actually done with the prototype f i rst had been sketched out on paper. For bringing these developments to full formality on the prototype, a number of problems had to be overcome, nearly all of which resulted from a certain lack of functionality in the prototype system. This unpleasant experience, however, turned out to contribute considerably to the validation of CIP-S. In particular, we are now convinced that the definitive system offers all those facilities that are lacking in the pretotype.

Machine support for documentation

One reason for f i rst sketching out developments on paper certainly was the slow response time of the available computer due to the fact that i t had to be shared with the students at our institute. Thus blind alleys in developments had to be avoided as far as possible. Another, even more important reason for avoiding blind alleys was the fact that the prototype offers no help in recording developments - except for the session log provided by the underlying operating system - such that backtracking within the prototype is rather cumbersome. Again, CIP-S overcomes this problem by providing convenient documentation facilities (cf. 111.2.7).

Flex11)ility of the user environment

Due to the rather limited technical possibilities v~en the prototype system was developed, its user environment was designed sinnTarly to then prevailing job control languages. In the light of currently available technology this is certainly not only out-of-date, but really hampers practical work. Although this is not part of the system core (and as such not yet specified), we envisage for CIP-S a much more flexible user environment. This is not only to comprise menu facilities for conveniently selecting system functions as well as window techniques for being able to survey the current program version, the history of development so far, and the actual rule catalogs simultaneously, but also rather comfortable and flexible means for formulating transformational programs. Moreover i t is desirable to use a "mouse" or a "joystick" rather than a cumbersome cursor for marking the application point of a transformation rule.

Formality and rigour imposed by the system

One experience made while working even still with the prototype system, however, compensated us for part of the drawbacks mentioned above. I t was the fact that a few of the sketches of developments done on paper turned out to be wrong when done in the strict formality required by a mechanical tool. This affirmed the attitude that a transformation system should not only free the programmer from the clerical work but also prevent him from making errors due to lack of care.

5.3. Overall remarks in retrospect

Our experiences so far within the ClP transformation system project not only prove i ~ t i t is indeed ~s ib l e to formally specify large-scale software with reasonable effort, but also confirm our opinion that i t is even ~on~nic to do so, since the hard problems in connection with the system had to be solved already with the specification - however, with certainly less effort than e.g. on the level of procedural programs. Comparing the efforts that went into the two main tasks of the CIP transformation system project, namely giving a formal specification and then implementing i t at the imperative level using the transformational approach, one can say in retrospect that both were about equal in terms of man-power.

Page 396: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

388

IV.5 Experiences

Our experiences also have shown that the algebraic approach to system specification is a very useful one, although notational additions would be necessary in order to ease the formulation. In particular the possiblqity (offered by the algebraic approach) to write descriptive specifications rather than operative ones turned out to be exIYemely useful and also helped in keeping the formal specification at an appropriate length.

As to using the transformational approach and a r~rming system for implementing the specified system, i t clearly turned out to be far simpler and less time-cons~ing than expected. We are rat~r convinced that i f we had had avmqable the transformation catalogs we have now and also the ~ I o g i c a l experience gained within this f i rst large-scale development, even using the prototype with all i ts limitations, a similar developmmt now could be done in a fraction of the time we actually needed. Thus we are rather optimistic with respect to further large-scale applications of both the algebraic specification technique and the transformational approach to program development.

In especially the combination of both turned out to be rather fruitful. In 111.3. we have given an example for the validation of the specification. However, the developmants have contributed to the validation quite as much. The applicablqity conditions of the transformations pointed out inconsistencies, missing p~licates or restrictions, and other errors in the specifications. Almost identical or rather analogous developments revealed possiblTities for further abstractions, simplifications, or parameterization and hence improvements of the specification. On the other hand, the resulting modifications of the specification caused hardly any modifications of the developments in almost all cases. Therefore, the developments could be re-used.

Although being aware that our mainly positive experiences were gained in connection with an "insider application", we hope that these experiences in using formal methods will encourage other people, especially those in industrial environments, to try these techniques themselves.

Page 397: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

PART V

TRANSFORMATION RBFS

This part gives the complete catalogs of transformation rules used in the formal development of the system. During acc~ulation of these catalogs i t soon became necessary to systematize both the catalogs and the rule names. Therefore each of the catalogs contains rules for a particular area of application. Preceding the actual rules, there is always an explanation of the systematic mnemonic associated with the rule names. Within each catalog, the rules are given in lexicographical order of these names. Since these rules were used in working with the prototype system, they are stil l given in the notation used in [Bauer et al. 85] rather than in the notation of Part I I . A few typical rules are given in the notation of Part I I in VI .8 . .

Page 398: The Munich Project CIP: Volume II: The Program Transformation System CIP-S
Page 399: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.I Remarks about r u l e s 391

i. Remarks about r u l e s

The applicability conditions of transformation rules typically contain syntactic and semantic meta-operators like USED, KNOWN, KIND, DEFINED, DETERMINATE etc. The basic ones for CIP-L are defined in [Bauer et al. 85]. In addition, the transformation rules of the previous sections may also contain the following meta-operators:

USERDEFINED[. ] :

Evaluation of USERDEFINED[S_] is done by the transformation system; it asks the user to instantiate the scheme variable _S by an identifier (cf. [Riethmayer et a l . 85] ) .

USERSROWN[. ] : Evaluation of USERSHOWN[S] is done by the transformation system; it asks the user to instantiate the scheme variable _S by a program fragment of appropriate syntactic type (cf. [Riethmayer et al. 85] ).

. [. f o r . ] EI[E 2 f o r E 3] d e n o t e s t h e e x p r e s s i o n o b t a i n e d from E 1 a f t e r s i m u l t a n e o u s

rep lacement o f a l l o c c u r r e n c e s o f E 3 by E 2 (and p o s s i b l y renaming o f bound

i d e n t i f i e r s ) . DEF_DET[. ] :

DEF~ET[E] = DEFINED[El ^ DETEt~MINATE[E] ASSERT[. ] :

ASSERT[El = (E - true) • in . :

X in E : (X e USED[El) (This corresponds to the predicate OCCURS[. in .] in [Bauer et al. 85].)

• isof_submode . : E isof_submode m = ~ KIND[El = m if m is no submode

P(E) A E isof_submode n if type m = X: n II P(X) IS_EMPTYSORT[. ] :

emptyness predicate on sorts IS_ZOUAL_PRE[. ,. ] :

IS_EOUAL_.PRE[EQ, m] is true iff EQ is an equality predicate on sort m (cf. IV.I.2.1.).

. is_bound . : X is__bound E is true iff X is a bound identifier in E.

NEWI. ] :

NEW[X] is an abbreviation for -((X in S) V (X in T)), where S and T are the source and target scheme, respectively, of the rule.

For convenience, several unary meta-operators are also used in multi-ary notation: P[X I, ... , Xn] abbreviates P[XI] A ... A P[Xn].

In many of the types specified in Part III explicit equality prdicates on the primitive sorts are given. They define congruence relations on the objects of the corresponding sorts. Since CIP-L does not restrict the semantics of a polymorphic type to a disting~lished model, it may be the case, that this congruence is not simply the identity on the respective objects. But then it is useful to base the transformation relation --> on the congruence rather than on the identity. Then, the relation <-> used in the rules of the previous sections means semantically equivalent wrt. the respective congruence. As a consequence, the predicate DETEMINATE[.] must then be weakened to express that an expression is determinate wrt. the congruence.

The r u l e c a t a l o g s f o r s e t s ( S e c t i o n 2 . 2 . ) and c o n d i t i o n a l j o i n o p e r a t i o n s ( S e c t i o n 2 . 4 . ) can be viewed as c a t a l o g schemes, s i n c e s e t s and j o i n s a r e p a r a m e t e r i z e d by p r i m i t i v e s o r t s . In t he names o f t he o p e r a t i o n s o f t h e a c c o r d i n g t y p e s , t h e s e pa ramete r s o r t s a re o f t e n used as s u f f i x e s . S ince t h e p r o t o t y p e t r a n s f o r m a t i o n sys tem does no t a l l ow schema-paramete r s as p a r t s o f i d e n t i f i e r s , t h e r u l e s a c t u a l l y used in t h e developments were o b t a i n e d from t h e s e s c h e m a t i c r u l e s by i n s t a n t i a t i n g them w i t h a c t u a l s o r t s .

Page 400: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

392 Y.l Remarks about rules

Since the p r o t o t y p e does not a l low scheme v a r i a b l e s f o r sequences o f t e rms , r u l e s l i k e SO_A2_2 and SQ_A3_3 o f s e c t i o n 2 .5 . must be f o r m u l a t e d f o r each i n d i v i d u a l l e n g t h o f t h e s equences . This i s no t n e c e s s a r y in t h e new sys tem (compare s p e c i f i c a t i o n o f te rms in I I I . 2 . 9 . 1 . ) .

For t he use w i th t h e p r o t o t y p e sys tem, t he r u l e s have to be w r i t t e n in l i n e a r n o t a t i o n . Thus, r u l e s l i k e

S S

T T

are written as S <-> T >-< C and S --> T >-< C , respectively.

Finally, it should be noted, that the equality symbol in applicability conditions denotes the term equality.

For further explanations about rules, in especially about their notation and their applicability conditions, we refer to [Riethmayer et al. 85].

Page 401: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.2.1 Boolean expressions 393

2. Rules f o r constructs o f the scheme-language

2 . 1 . Boolean expressions

THIS CATALOG CONTAINS TRANSFORMATION RULES FOR THE MANIPULATION OF BOOLEAN EXPRESSIONS B ======================================================================================

AB = ABSORPTION AC = ASSOCIATIVITY AND CHANGE OF OPERATOR AY = ASSOCIATIVITY CA = COMMUTATIVITY AND ASSOCIATIVITY CC = COMMUTATIVITY AND CHANGE OF OPERATOR CH : CHANGE OF OPERATOR CV = CONVERSION CY = C~TATIVITY IP = IDEMPOTENCE LD = LEFT-DISTRIBUTIVITY MT = MELTING OF CONDITIONALS RD = RIGHT-DISTRIBUTIVITY SI = SIMPLIFICATION SU = SUBSTITUTION

A : A C = if-then-else(CONDITIONAL) / CONDITION E = else EQ = ¢~ FL = false I = L/R = THE LEFT/RIGHT TWO TERMS ARE BRACKETED N = - 0 =V SA = & SI = :e>

SO = v T = t h e n

TR = t r u e

ABSORPTION AB ~ = ~ = ~ = ~ ~ = ~ = ~ ~ = ~ ~ ~ = ~

AB-SASAL (~ A Q) A P <-> P A 0 >-< DETERMINATE[P]

ASSOClATIVITY AND CHANGE OF OPERATOR AC

AC-ASAL (~ ^ Q) A R <-> P A (~ A R) >-< false E D P =~ DEFINED[~]

ASSOCIATIVITY AY ======================================================================================

AY-AAL ( P A ~ ) AR <-> EA ( ~ A R )

Page 402: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

394 V.2 Rules f o r c o n s t r u c t s o f t h e scheme- language

AY-.ASAL

<->

P A (_Q ~ ~_) >.-< ( f a l s e c~ p A t r u e c Q) ~ DEFINED[R]

AY-..ASAR E A (Q ~ R) <-> (P A Q) ~ R >-< (false ~ P A true ~ ~) =~ DEFINED[R]

AY-.SAAL (E ~ ~) A R <-> P ~ (Q A R) >-< false ~D ~ =~ DEFINED[R~

AY...SASAL

COMMUTATIVITY AND ASSOCIATIVITY CA

CA-AA (P_ A _Q) A (R A S_) <-> (P A _R) A (Q.Q_ A S)

COMMUTATIVITY AND CHANGE OF OPERATOR CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CC-SA P A Q <-> Q A P >-< false E D P ~ DEFINED[Q]

CC-SAAR ~ (Q A R) <-> Q A (P ~ ~) >-< false ~D ~ =~ DEFINED[~]

CHANGE OF OPERATOR CH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C H-A-S A P A Q 4-> P__ ~ Q >--< false ---D -P ~ DEFINED[Q_]

CH-I..S I P_ ~ Q <-> P ~ O >-< false c D P_ ~ DEFINED[O_~

Page 403: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.2.1 Boolean e x p r e s s i o n s 395

CH-O-SO V ~ <-> P V Q >~< true E D P ~ DEFINED~Q~

CH-.SA-A P ~ Q__ <-> P A Q >-< false c D P ~ DEFINED~Q_]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

CONVERSION CV

CV-C-SAONSA if C then P else Q endif <->

(C_ ~ P_) V (-C_ ~ e_) >-<

KIND[P] = bool A KIND[q~ = bool A DETERMINATE[C]

CV-.EQ--IAI ¢~ Q <-> (P ~ Q) A (Q ~ P)

CV-SA-C ~ ~ <-> if P then ~ else false endif

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

COMMUTATIVITY CY

CF-A P_.AQ_ <-> ~^P_

CY-EO p~_ <-> Q c~_P

CY~ £V~ <-> QVP

CY-.SA _P ~ Q_ <-> Q_ ~ P >-< false _c D P ~ DEFINED[O_] A false m_ D Q ~ DEFINED~P]

CY...SASAR P z~ (o zs R) <->

>-<

false _=m P =~ DEFINED[O].A false -rod Q ~ DEFINED[P]

Page 404: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

396 V.2 Rules f o r c o n s t r u c t s o f t he scheme- language

IDEMPOTENCE IP

IP-A P A P <-> P >-< KIND[P] = bool

IP-O P v P <-> E >-< KIND[P] = bool

I P-SO P V P <-> E >-< KIND[P] = bool

LEFT DISTRIBUTIVITY LD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LD-.4C-~E P A if C then Q_ else R endif <-> if C_ then P A 0 else P A I~ endif

LD-CEQ P ¢~ if B then T else E endif <-> if B then P_ ¢=) T else P ¢~ E endif

LD-SAA P /~ (Q A R) <-) (_P /~ Q) A (P /~ R)

LD-SAC P A if C then O else R endif <-> if P A C then Q else P A R endif

LD-.,gACI P_ A i f C_ then Q.Q e l se _R endif <->

if C_ then P A Q else _P A R_ endif >-<

false __~ P ==~ DEFINED[C Q]

LD-SAO _P A (Q_ V H) <-> (_P A ~) v (_P A _R) >-< DETERMINATE[P~

LD-SOSA P_ V (Q_ A R) <-> (P V 0_) A (P V R_) >-< DETERMINATE[P]

Page 405: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.2 .1 Boo lean e x p r e s s i o n s 397

MELTING OF CONDITIONALS MT

~/T-ETEACTC if A then if B then E1 else E_22 endif else E_33 endif ^ if A then if B_ then E44 else E5 endif else E_66 endif <->

if A then if B then E1 A E4 else E2 A E5 endif else E3 A E6 endif >-<

DETEI~MINATE~A] A true =-D _A :=~ DETEI~MINATE[B]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

RIGHT-DISTRIBUTIVITY RD

RD-AA (P_ A 0_) A I:/ <-> (P_ A _R) A (Q A R_)

RD-CA i f C_ then P_ else Q_ endif A R <-> i f C then P A R else 0 A R endif

RD-OC-TE i f C t h e n ~ e l s e R e n d i f v P <-> i f C t h e n 0 v P e l s e R v P e n d i f

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SIMPLIFICATION OF EXPRESSIONS SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

S I-.AF L P_ A false <-> false >-< [P] = USERSHOWN[P] A DEFINED[P] A KIND[P_] = bool

SI-.ATR P A true <-> P_ >-< KIND[P] = bool

SI-..ATRL t r u e a P_ <-> P >-< KIND[P] = b o o l

SI-~O P ~ P <-> true >-< EP] = USEmSNOWNIE] ~ KIND[P] = bool A DEF_DETEPJ

S I-I~QF L P ¢~ f a l s e <-> -_P

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SI-~LA false A P <-> false >-< [P] = USERSHOWNEP] ~ KINDEP] = bool ^ DEFINED[P]

Page 406: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

398 V.2 Ru les f o r c o n s t r u c t s o f t h e s c h e m e - l a n g u a g e

SI--FLO false V P <-> E >-< KIND[.P] : bool

SI--FLSA false A E <-> false >-< [P] = USERSHOWN~.P] A KIND[P] = bool

SI- -FLSI false ==)E <-> true >-< [E] : USERSHOWN[E] ~ KIND[El = bool

SI...NFL ~ f a l s e <-> t r u e

S I - O F L V false <-> E >-< KIND[P ] : bool

SI.-SAFL E A false <-> false >-< [E] = USERSHOWN[E] A KIND[P] = bool A DEFINED[P]

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SI--SATR E ~ true <-> E >-< KIND[El = bool

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SI-TRA true A E <-> E >-< KIND[El = bool

SI--TRSA true /~ P_ <-> P >-< KIND[P ] = bool

SUBSTITUTE WITHIN SECOND OPERAND OF ANDSEQ/ORSEQ FIRST OPERAND BY TRUE/FALSE SU = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SU-FA~AR (P_ ¢=) Q_) ~ R <-> (E ¢~ _Q) A S_ >-< DETEBMINATE[Q_, E] A [S_] = RIP for Q_]

SU-.NSA.-FL ~P A Q <-> ~P A R >-< DETERMINATE[El A [_R] = _Q[false for P]

SU-SA...TR P_ ~ Q < - > P ~ R >-< DETEI~MINATE[~] ^ [R_] = ~ [ t r u e f o r P_]

Page 407: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.2.1 Boolean expressions 398

SU-SOSA (C V D) ~ P <->

if C then 0 else E ,~ R endif >-<

DETEEMINATE[P_] ^ [Q] = P[true for C~ A [E~ = D[false for C~ ^ [_R] = P_[false for C_]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

END CATALOG.. B

THIS CATALOG CONTAINS ADDITIONAL RULES TO CATALOG B USED IN THE DEVELOPMENT OF STRUCTURES TERM A~ INSTANCE BB

SH = SHIFT SI = SIMPLIFICATION

A = AND C = CONDITIONAL R = BRACKETING RIGHT SA = SEQUENTIAL AND T = THEN-BRANCH

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SHIFT SH

SH-ASAA-SAR (_A A B_) A (C ^ D__) <-> (A ^ B_) A ((}3 A C_) ^ D_) >-< DETEHMINATE[B]

SIMPLIFICATION SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

S I - .AS AC--T (A A B) /~ i f C then P e l s e Q e n d i f <-> (_A ^ ~_) ~ P >-<

(true _m A ^ t r u e _m B_) ~ ASSERT[EQ_B(C, t r u e ) ]

END CATALOG BB

Page 408: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

400 V.2 R u l e s f o r c o n s t r u c t s o f t h e s c h e m e - l a n g u a g e

2.2. Conditionals and guards

THIS CATALOG CONTAINS TRANSFOI@dATION RULES FOR CONDITIONALS AND GUARDS C

C = CONDITIONAL D = IF-THEN-ENDIF S = SOME

CY = COMMUTATIVITY DY = DISTRIBUTIVITY SI = SIMPLIFICATION SU = SUBSTITUTION

C = (CV__) TO CONDITIONAL

A = ARGUMENT/ASSIGNMENT C = CONDITIONAL E = ELSE F = FUNCTION APPLICATION FL = FALSE NS = NESTED QB = EQUAL BRANCHES T = THEN TR = TRUE

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

C~TATIVITY OF CONDITIONAL CCY

CCY-~S i f _A t h e n i f B_ t h e n E1 e l s e E22 e n d i f e l s e i f B t h e n E_33 e l s e E4 e n d i f e n d i f <->

i f B t h e n i f A t h e n E_! e l s e E33 e n d i f e l s e i f A t h e n E_22 e l s e E4 e n d i f e n d i f

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

DISTRIBUTIVITY OF CONDITIONAL CDY =======================================================================================

CDY_~I X := if _B then E1 else E_22 endif <-> if B then X := E_II else _X := E__22 endif

CDY-.A1 if B then F I(X) else F_22(_X) endif <--> if B then F_!I else F_22 endif (X)

C D Y - F _F(if C then B_! else B__22 endif) <-> if C then F(B_~I) else _F(B_22) endif

CDY--F21 F(if A then B_ else C endif, D) <-> if A then F(B_, D) else F(C, D) endif

Page 409: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V . 2 . 2 C o n d i t i o n a l s and g u a r d s 401

CDY.-F22 F(D, if h then B else C endif) <-> if A then F(D, B) else F(D, C) endif

CDY-,F32 F(D, i f A t h e n B e l s e C_ e n d i f , E) <-> if A then F(D, B, _E) else _F(D_, C, E_) endif

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SIMPLIFICATION OF CONDITIONAL CSI

CSI-2_.C-.E if A_ then E1 else if B_ then E~2 else E_33 endif endif <->

if A then E1 else E_33 endif ~-<

false c_~ A ~ ASSERT[EQ_B(B, false)]

CSI..-FL if false then E else [ endif <-> F >-< [E] : USERSHOWN[E] A KIND[El : KIND[F]

CSI-QB i f C t h e n E e l s e E_ e n d i f <->

E >-<

[C] = USERSHOWNIC_] A KIND[C] = bool A DEFINED[q]

CS I -TC-.T i f _A t h e n i f B_ t h e n E1 e l s e E_22 e n d i f e l s e E_33 e n d i f <->

i f _A t h e n E1 e l s e E_33 e n d i f >-< t r u e -=D A ==~ ASSERT[EO_B(B, t r u e ) ]

CSI--TR i f t r u e t h e n E e l s e [ e n d i f <-> E >-< [ [ ] = USERSHOWN[[] A KIND[I] = KIND[El

SUBSTITUTION IN CONDITIONAL CSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CSU-EFL i f A t h e n P_ e l s e _R e n d i f

i f _A t h e n _P e l s e Q e n d i f >-< [ ~ ] = R_[fa lse f o r A]

Page 410: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

402 V.2 Rules f o r c o n s t r u c t s o f t he scheme- language

CSU-,gTR if h then P else R endif --> if A then P else ~ endif >-< ~] = R[true for "hi

CSU--TFL i f A then P e l s e R e n d i f - -> i f A then Q e l s e R e n d i f >-< [Q] = P [ f a l s e f o r -A]

CSU-.TTR if A then £ else R endif --> i f A then ~ else R endif >-< [Q] = P[true for A]

CSU--TTR--EFL i f B then P e l s e Q_ e n d i f ---->

i f B_ then PP e l s e ~_ e n d i f >-< [P_PP] = P [ t r u e f o r B_] ^ ~Q_Q] = Q [ f a l s e f o r B]

======================================================================================

COMMUTATIVITY OF IF-THEN-ENDIF DCY

DCY-C if C_ then if D then E1 else E_22 endif endif <->

if D then if C then E_!l endif else if C then E2 endif endif

DISTRIBUTIVITY OF IF-THEN-ENDIF DDY

DDY-F F(if C then E endif) <--> if C then F(E) endif

DDY-I~31 F(if C then E endif, P_22, P_~3) <-> if C then F(E, P__22, F3) endif

SIMPLIFICATION OF IF-THEN-ENDIF DSI

DSI.-.TR if true then E endif <->

DISTRIBUTIVITY OF SOME SDY

SDY..~ some X: m II i f B then P e l s e Q e n d i f <-> if B_ then some X: m II P e l s e some X: m II ~ e n d i f

Page 411: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.2.2 Conditionals and guards 403

>-<

-_X in B A DETERMINATE[B]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

END CATALOG C

THIS CATALOG CONTAINS PARTICULAR TRANSFORMATION RULES FOR CONDITIONALS USED IN THE DEVELOPMENT OF THE STRUCTURES TERM AND INSTANCE, WHICH ARE NOT CONTAINED WITHIN THE STANDARD CATALOG C CC

C = CONDITIONAL R = ELSE-GUARD

CV = CONVERSION SH = SHIFT

A =AND C = CONDITIONAL E = ELSE-BRANCH Q = EQUAL BRANCHES

SHIFTING CONDITIONS CSH

CSH-~EEH2-A if A

then E1 e l s e i f B then E2 e l s e i f C then E3 D D then E44 e l s e E5 e n d i f e n d i f

e n d i f <->

i f A then E1 e l s e i f

then E2 else if ~A A ~B A C then E33

D -A A -B ^ D then E_44 else E_55 endif endif

endif >-<

DETERMINATE[A, ~]

CONVERSION OF ELSE-GUARD HiCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I I2CV-C.~ E i f A t h e n X ~ B t h e n _Y e l s e X e n d i f <->

if B then _Y else ~ endif >-<

[A] = USERSHOWN[AJ A KIND[A] = boo l ^ DEFINED[_A~ A t r u e E v B =~ ASSERT[EQ_B(A, f a l s e ) ~

END CATALOG CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 412: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

404 V.2 Rules f o r constructs o f the scheme-language

2 . 3 . A p p l i c a t i v e l e v e l

THIS CATALOG CONTAINS RULES ON THE APPLICATIVE LEVEL L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PP = POSTPONE SO = SHIFT OBJECT DECLARATION

C = CONDITONAL CD = CONSTANT DECA~ATION E = ELSE-BRANCH

POSTPONE CONSTANT DECLARATION PP_CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PP-CDI begin const X: m = D; E end <-> begin E where cnnst X: m = D end

PP-CD4 begin const (XI: ml, X2: m2, X3: m3, X4: m4) = (Dl, D21 D3, D4); E_ end <->

begin E where const (X_!: ml, X2: m_22, X3~: m3 i X4: m4) = (D_!l, I)2, D3, D4)

end

SHIFT OBJECT DECLARATION SO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SO-C-E b e g i n i f B t h e n E_l e l s e E_~2 e n d i f where c o n s t C: m = D end ---->

b e g i n i f B t h e n E1 e l s e E2 whe re c o n s t C: m = D e n d i f end >-<

~C in B A -C in E_!l A true c D B ~ (DEFINED[D] A D isof_submode m)

END CATALOG L

Page 413: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.2.4 Pre-algorithmic constructs 405

2.4 Pre-algorithmic constructs

THIS CATALOG CONTAINS TRANSFOI~MATION RULES FOR THE MANIPULATION OF PREALGORITI~MIC CONSTRUCTS P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

KEYWORDS: UNIVERSAL/EXISTENTIAL QUANTIFICATION, COMPREHENSIVE CHOICE, DESCRIPTION, COMPREHENSION

A = UNIVERSAL QUANTIFICATION (ALL) E = EXISTENTIAL QUANTIFICATION (EXIST) S = COMPREHENSIVE CHOICE (SOME) / SEGMENT

R = RESTRICTED DOMAIN

AY = ASSOCIATIVITY CY = C~4MUTATIVITY CV = CONVERSION DY = DISTRIBUTIVITY IN = INTRODUCTION NO = NOT OCCURS F~4 = REMOVAL ST = SEQUENTIALIZE TUPLE DOMAIN

A = A

C = CONDITIONAL F = FUNCTION FL = false L/R = THE LEFT/RIGHT TWO TERMS ARE BRACKETED NE = NOT EMPTY SORT 0 = V / ARBITRARY OPERATOR P = PREDICATE Q = EQUALITY SA = SEQUENTIAL AND TR = true U = (CV_) UNRESTRICTED

DISTRIBUTIVITY OF UNIVERSAL QUANTIFICATION ADY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ADY-.4 VX: m, P ^ ~ <-> (vx: m" E) ^ (Vx: m, Q)

ADY-C V X: m U i f B t h e n Q e l s e P e n d i f <->

i f B_ t h e n V X: m II Q e l s e V X: m II P e n d i f >-<

~X in B A DETEHMINATE~]

NOT-OCCURS-RULES FOR THE UNIVERSAL QUANTIFICATION ANO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANO-AR V X: m II P A Q <-> (V X: ! II P_) A R >-< -X_ in R A ~IS_~TYSORT[E]

Page 414: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

406 V.2 R u l e s f o r c o n s t r u c t s o f t h e s c h e m e - l a n g u a g e

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

CONVERSION OF RESTRICTED UNIVERSAL QUANTIFICATION ARCV

ARCV-U 9' (_X: m II P ) II Q < -> V X: at II P =# Q_

REMOVAL OF UNIVERSAL QUANTIFICATION ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

APM-NE VX: tuliP <->

_P >-<

IX] -- USERDEFI~D~] A[m] = USERDEFINED[m_] A -X_ in P A -IS~TYSORT[m]

ARM--TR V X: m II true <-> true >-< [_X] = USERDEFINED[~] A[m] = USERDEFINED[_m]

CONVERSION OF EXISTENTIAL QUANTIFICATION ECV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ECV-A 3 x: m 11 P <-> -(V x_: m_ il -P)

F_,~-U B (_X: m_ li P) II 9 <-> 3 X: m II P ~

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

CONNUTATIVITY OF EXIS'I~NTIAL QUANTIFICATION ECY

ECY 3 _X: m_, (3 _Y: n it P_) <-> 3 X: n, (~ x_: m_. P) >-< ([~1 -- LZ]) ~ (~a) -- [n))

DISTRIBUTIVITY OF EXISTENTIAL QUANTIFICATION EDY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

EDY-,A 3 X: m II P A Q <-> (q X: m II P) A (3 X: m II Q) >-< -_X in P V -X in 9

EDY-~C 3 X: m II i f C t h e n P e l s e _Q e n d i f <->

i f C t h e n 3 X: m II P e l s e 9 X: m II O e n d t f >-<

~X in C A DETEI~INATE[C]

Page 415: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.2.4 Pre-algorithmic constructs 407

EDY-SAC 3 X: m IIE ~ if C_. then _P else Q_. endif <->

if C_ then 3 X: m I# E A P_ else 3 X: m I~ E A _O endif >-<

-_X in C_ ̂ DEF_DET[C~

INTRODUCTION OF EXISTENTIAL OUANTIFICATION EIN

EIN

3 x: ~ e , EQP(_X, E_) ^ E >-<

[E_] = USERSHOWN[E_] /1 (DEFINED[Q] ~=) DEFINED[E_]) A [X~ = USERDEFINED[X] ~X i n Q. ^ [ m o d e l = USERDEFINED~mode] a E_ i s o f _ s u b m o d e mode ^ [EQP] = USERDEFINED[EOP] A IS_CONGRUENCE[EOP] A [_P] = O[_X for E_]

EIN-ESA B X: m IIP Z~ O ---->

3 X: m II P a (3 Y: m , PS a QS) >-<

[Y] = USERDEFINED[_Y] ~ ((-([Y] : [_X])) ~ (~Y in P_ A -Y in _O)) A [ P S I -- ELY f o r X_] ^ [OS] : O_[Y_ f o r X_]

IDENTIFIER OF THE EXISTENTIAL QUANTIFICATION DOES NOT OCCUR IN THE LEFT/RIGHT (L/R) TERM OF THE CONJUNCTION BUILT WITH A/~ ENO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ENO-AL B X: mli t ^ ~ <-> P ^ (3 X: m II Q) >-< -X in P ^ -IS_EMPTYSORT[m]

ENO-AR 3 X: m J| P A Q <-> (3 X: m II P) A Q >-< ~X in Q ^ -IS_EMPTYSORT[m]

ENO-SAL 3 X: m i! P ~ Q <-> P ~ (~ X: m I! ~ ) >-< ~X i n P ^ ~IS_EMPTYSORT[m]

ENO-SAR 3 X: m {J P a O_ <-> (3 X: m J{ P) A 0 >-< ~_X in O_ ̂ -IS_EMPTYSORT[m]

ASSOCIATIVITY OF RESTRICTED EXISTENTIAL QUANTIFICATION ERAY = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

ERAY-RP 3 (_X: m If P ~_Q) II _R <-> 3 (X: m II _P) II 0 ~, R

Page 416: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

408 V.2 Rules f o r c o n s t r u c t s o f t h e s c h e m e - l a n g u a g e

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

CONVERSION OF RESTRICTED EXISTENTIAL OUANTIFICATION ERCV

E~V..17 3 (X : m II P ) If 9 < - > :l X: m 11 P A 0

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

DISTRIBUTION OF RESTRICTED EXISTENTIAL QUANTIFICATION ERDY

ERDY-RO 3 (X: m II P v O) It R <-> (] (_X: m_ Ii P_) il R) v (] (X_: m_ II ~) II R)

REMOVE EXISTENTIAL OUANTIFIER EI~ ======================================================================================

5 X : m l l P <->

>-<

IX] = USERDEFINED[X_] A I m ] = USERDEFINED[m_] A -_X in P A -IS_,EbIPTYSORT[_m]

gRM-~3 X: m II EQP(X, E)

- - - ->

t r u e >-< IS_J~OUAL_PRE[EOP, m] A E i s o f _ s u b m o d e m A -X in E ^ DEFINED[El

gRI~-OSA X: m II EOP(X, E) A P_P_

- - - ->

>-< IS_EQUAL_PREKEQP, ml ^ -X i n E ^ DEF_~ET[E_I ^ JR] : _PIE_ f o r _X] ^ ASSERT[begin f u n c t i o n PP (X_: _m): b o o l ; P_; %' (A: m; B: m II EOP(A, B)) II PP(A) (=>

PP(B) e n d ]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

REMOVAL OF RESTRICTED EXISTENTIAL QUANTIFICATION ERRM ======================================================================================

ERRM-RFL 3 (X: m II f a l s e ) II P - - > f a l s e

SEQUENTIALIZE TUPLE DOMAIN OF EXISTENTIAL QUANTIFICATION EST

EST-3-, /11 3 Xl : ml; X2: m2; X 3 : m 3 I1 p <-> 3 Xl: m_!l II ] X 2 : m 2 tl ] X 3 : m 3 11 P

Page 417: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.2.4 Pre-algorithmic constructs 409

DISTRIBUTIVITY OF SEGMENT SDY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SDY--A V _X: m , b e g i n _E w h e r e c o n s t C: c m = v e n d <->

b e g i n ¥ X: m l! E w h e r e c o n s t C: cm = F e n d >-<

-([_X] = [C~) A -_X i n _F A DETE~INATE[_F]

SDY--ER 3 (Y: _m , b e g i n E w h e r e c o n s t C: mc = F e n d ) [I P_ <->

b e g i n 3 (Y: m , E_) II P_ w h e r e c o n s t C: mc = F e n d >-<

DETE~INATE[F] A -([_Y] = [ C ] ) A ~C i n P_ A -Y i n _F

SDY-F22 b e g i n F(X, Y) w h e r e c o n s t Z: _m = E e n d <->

_F(X, b e g i n Y w h e r e c o n s t Z: m = E e n d ) >-<

*Z_ i n F ^ ~Z_ i n X_

SDY-OR _Lop b e g i n R w h e r e c o n s t C: mc = F e n d <->

b e g i n L_ o p R_ w h e r e c o n s t C: mc = F e n d >-<

-,C_ in L A ~C_ i n

REMOVAL OF COMPREHENSIVE CHOICE S ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - - . . . . . . . . . . . . . . . . . . . . . . . . . . .

SPJ/--Q some _X: m , EaP(_X, E_)

E

>-<

IS_~QUAL_.PRE[EQP, m_] A ~_X i n E A E i s o f _ s u b m o d e m_

END CATALOG P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 418: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

410 V.2 Rules f o r c o n s t r u c t s o f t h e scheme- language

2 . 5 . P r o c e d u r a l l e v e l

THIS CATALOG CONTAINS RULES FOR THE PROCEDURAL LEVEL V = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

CV : CONVERT FS : FLATTEN SEGMENT IA : INTRODUCE FROM ASSIGNMENT IN : INTRODUCE FROM EXPRESSION MA : MOVE ASSIGNMENT RM : REMOVE SA : SKIP ASSIGNMENT SQ : SEQUENTIALIZE

A : ASSIGNMENT C : CONDITIONAL CD : CONST-DECLARATION D : DUPLICATED V : VARIABLE DECLARATION WITH INITIALISATION W : VARIABLE DECLARATION WITHOUT INITIALISATION S : SEGMENT

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

CONVERT CV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CV--WA--V var _V: m_; _V := E_ <-> var V: m := E_

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

FLATTEN SEGMENT FS = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

FS4.-23 b e g i n s t a t S 1 ; b e g i n s t a t S 2 ; s t a t S 3 end; E end ( -> b e g i n s t a t S 1 ; statS_22; s t a t S 3 ; E_ end >-( $ = (DECLARED[statS2; s t a t S 3 ] n (USED[El u DECLARED[statS1]))

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

INTRODUCE FROM ASSIGNMENT IA = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

IA..a X :=E -->

b e g i n X :-- F; _X := I end >-< IF] = USERSHOWN[F] A F isof_submode KIND[X] ^ DEFINED[F] A [NEWT = USERDEFINED[NEW] A -([NEW] = IX]) A [G_] = E_[NEW for F] A -_X in G_ A [ I ] = G[X f o r NEW]

IA--A-B32 begin statSl; X := ~; statS3 end ---->

begin statSl; X := ~; X := !; statS3end

Page 419: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V . 2 . 5 P r o c e d u r a l l e v e l 411

>-<

I F ] -- USERSHOWN[F] A _F i s o f _ s u b m o d e KIND[X] A DEFINED[F] A [~W] = USERDEFINED[NE_WW] A ~([~W] : S_X]) h [G] = E_[NE_WW for F] A -_X in G h [ I ] = G_[~ f o r NEW]

IA.~A V:=E_ ---->

begin vat _X: m_; X_ := _F; _V := G_ end >-<

[_X] = USERDEFINED[_X] A -(IV] = [_X]) A[m] = USERDEFINED[m] A IF] = USERSHOWN[_F] A DEFINED[[] ^ F isof__submode m A -_X in E A [G] = E_[_X for F]

INTRODUCE FROM EXPRESSION IN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IN--WA E_

b e g i n v a r X: m; X : : _F; _G end >-<

L x ] -- USERDEFI~DtX_] A [ m ] = U S E R D E F I ~ D ~ ] A [_m] = USERSHO~[F] A DEFI~D~_r] ^ F isof_submode m A ~_X in E_ A [G] = E_[_X for F]

MOVE ASSIGNMENT MA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MA-C : : i f ~ t h e n ~ e l s e E e n d i f - - > i f C t h e n V := D e l s e ~ := ~ e n d i f

MA-S2 _V := begin statDECL; E end ---->

begin statDECL; V := E_ end >-<

-({V} _c DECLARED[statDECL])

~A--S3 V := begin statDECLl; statDECL2; E_ end

begin statDECLl; statDECL2; V := E end >-<

-({V} _c (DECLARED[statDECL1] U DECLARED[statDECL2]) )

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

REMOVE I~M

RM-CD3 b e g i n s t a t S ; c o n s t C: m : _E; X : : F e n d

b e g i n s t a t S ; _X := E; _X : : G_ end

Page 420: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

412 V.2 Rules for constructs of the scheme-language

>-<

KINDS_X] : m A ~X in F A [G_] = FIX f o r C]

RM-SA statS; skip <-> stats

SKIP ASSIGNMENT SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

sA :: X --> skip >-( DEFINED[X]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SEOUENTIALIZE S0 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SQ-CD4-4 beg in cons t (X!: ml, X_22: m2, X33: m3, X_44: m4) = (El , E2, E_33, E4); E_ end <-> beg in

cons t (Xh re_l, X~2: m_22, g3: m3) = (Ell , E2, E3); const X4:m4 = E~4; E_

end >-<

-X_!l in E_~4 A -X__22 in E~4 A ~X__33 in E__44 A -X4 in E ! A ~X_44 in E22 A ~X4 in E~3

SQ-A2-2 (X_!l, X2) :: (E_!l, E2) <-> X! := El; X_22 :-- E__22 >-< -X ! in E_/2 A ~([Xl] = IX21)

(x_!, x z, ~) := (El, ~, ~) <->

x_~3 :: E S; X2 := E2; X_l := El >-<

-X_33 in E1 A -X_22 in E1 A ~X_33 in E__22 A -([X__33] : IX2]) A ~([X3~ = X~]) A -(Ix2] : ix!I)

END CATALOG V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 421: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V . 3 . 1 Maps 413

3. R u l e s for data types and computation structures

3.1. Maps

THIS CATALOG CONTAINS TRANSFORMATION RULES FOR MAP G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ABBREVIATIONS:

G = GET P = PUT R = REM

AB = ABSORPTION

ABSORPTION OF PUT PAB

PAB-G PUT(N, GET(N, T ) , .T.T) <->

_.T >-< IN] = USERSHOWN[N] A DEFINEDIN] ^ N isof_submode i A ASSERT[ISA(N, T)] A DETEI~4INATE[N, T]

PAB-,R PUT(!, ~, REM(!, T)) <-> PUT(I, ~, ~) >-< DETENMINATE[!]

END CATALOG G

Page 422: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

414 Y.3 Rules f o r d a t a t y p e s and computa t ion s t r u c t u r e s

3 .2 S e t s

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

THIS CATALOG CONTAINS TRANSFORMATION RULES FOR SETS SPECIFIED BY THE ABSTRACT DATA

TYPE SET M

EX = EXHAUSTION PRINCIPLE

A : ADD_M

K : MK_SING_M

M : IS_MEM_M

O : EO_SET_M

S = IS_SUB_M

U = UNION_M

Y = IS_Y_M

AY = ASSOClATIVITY

C = CONDITIONAL

CV = CONVERSION

DY = DISTRIBUTIVITY

IN = INTRODUCTION

SI = SIMPLIFICATION

SU = SUBSTITUTION

A = (CV_) UNIVERSAL QUANTIFICATION

(SI_) ADD_M

E = EMPTYSET

G = ARBITRARY SET

T = THEN

R = RIGHT ARGUMENT

L = LEFT ARGUMENT

SIMPLIFICATION OF CONDITIONAL CSI

CS1. -Y

i f IS_Y_M(_S) then E_ e l s e F e n d i f <-> if IS_Y_M(S_) t hen G else F endif >-<

[9.] -- E_[EMPTYSET_M f o r S]

EXHAUSTION PRINCIPLE EX

EX-M IS_~M._M(_X, S) <-> ~IS_Y_~(S_) a begin EQ_M(X, Y) V IS_MEM_M(_X, DEL_M(Y, S)) where c o n s t _Y: m = ARB_M(S) end >-< [_Y] -- USERDEFINED[_Y] /~ -Y in _X A -Y in _S

Page 423: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3.2 S e t s 415

INTRODUCTION IN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IN-C P_ <->

i f IS_Y_M(S) then Q e l s e P e n d i f >-< IS] = USERSHOWN[_S] Z~ DEFINED[IS] ^ KIND[S_] = set_of m ^ i'Q] = P~EMPTYSET_M f o r S]

DISTRIBUTIVITY OF IS_MEM_M APPLICATIONS MDY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MDY-U IS_MEM_M(,X , UNION_M(S_, T)) <->

IS_MEM_M(_X, S_) V IS_MEM_M(_X, T) >-< DETENMINATE[-X]

SIMPLIFICATION OF IS_MEM_M APPLICATIONS MSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MSI-E IS_MKM_M (-X, EMPTYSET_M) <->

false >-<

IX] = USERSHOWN[X] A DEFINED[X] A KIND[X] = m

MSI-/~ IS_MEM_M(,X, MK_SING_M(~)) <-> EO_M(X, [)

CONVERSION OF EQ_SET_M APPLICATIONS QCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

~..A..A EQ_SET_M(S, ADD_M(-X, T)) <->

V _Y: s , IS_ME~LM(L S_) ¢~ EO_M(_Y, X) v IS_MEM_M(_Y, T) >-< [~] = USERDEFINED[Y] A -_Y in S A -Y in T A -Y_ in -X A DETERMINATE[S, _T, X]

~CV-A-~L EQ_SET_M(EMPTYSET_M, _S) <->

V X: m , ~IS_.~SM~(_X, S_) >-<

~] = USERDEFI~D~ A -_X in _S

Page 424: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

416 V.3 Rules f o r d a t a t y p e s and c o m p u t a t i o n s t r u c t u r e s

GCV-AM-G EQ_SET_M(S, T) <->

Y _X: m n IS_MEM_M(X_, S_) ¢~ IS_MEM_M(X, T) >-<

[_X~ = USERDEFINED[X] ~ ~X in S_ ̂ ~_X i n T ^ DETErMINATE[S, T]

SIMPLIFICATION EQ_SET_M APPLICATIONS QSI

QSI-S EQ_SET_M(_L, _R) <-> IS_SUB_M(_L, R) A IS_ZUB_.M(R, _L) >-< DETEI~MINATE[_L, R]

CONVERSION OF IS_SUB_M APPLICATIONS SCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SCV-.AM-G Is_sUB_M(S, T) <->

V X_: m , IS_MEM_M(X, _S) ~ IS_MEM_M(_X, T) >-<

[_X] = USERDEFINED[X~ A -_X in S_ A -X in T

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SIMPLIFICATION OF IS_SIIB_..N APPLICATIONS SSI

SS1. . .EL IS_SUB_M (EMPTYSET_M, R) <->

t r u e >-<

[L~] = USERDEFINED[R] A KIND[R_] = set of m A DEFINED~_R]

ASSOCIATIVITY OF UNION_M APPLICATIONS UAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UAY-U UNION~(UNION_M(R, S), T) <-> L~ION_M(R, UNION_M(S, T))

SIMPLIFICATION OF UNION_M APPLICATIONS USI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

USI-EL UNION_M(EMPTYSET_M, R) <-> R >-< KIND[R] = set of m

USI-ER UNION_M(M, EMPTYSET_M) <-> M >-< KIND[M] = set o f m

CONVERSION OF IS_Y_.M APPLICATIONS YCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 425: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3.2 Sets 417

YCV-A IS_Y_M(S) <-> V X: m Jl ~IS_MEM_M(X, S) >-< [X~ = USEI~DEFINED[X~ ~ -X in

SUBSTITUTION OF IS_Y_M YSU ======================================================================================

Y~U..2 if IS_Y_M{FS) then T_BB else E_BB endif <->

if IS_Y_M(FS) then T__BB else EBM endif >-<

DETE~MINATE[FS] A EB_MM~F_SS for UNION_M(MK__SING_M(ARB_M(FS)), DEL_M(AEB_M(FS), F S))~ = EB~UNION_M(MK_ZING_M(ARB_M(FS)), DEL_M(ARB_M(FS), F_SS)) for FS]

END CATALOG M ======================================================================================

Page 426: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

418 V.3 R u l e s f o r d a t a t y p e s and c o m p u t a t i o n s t r u c t u r e s

3 . 3 . N a t u r a l numbers

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

THIS CATALOG CONTAINS TRANSFORMATION RULES FOR NATURAL NUMBERS N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

AR = ARITHMETIC RULES E = EXISTENTIAL QUANTIFICATION (EXIST) Q = EQUALITY

SI = SIMPLIFICATION

C = CONDITIONAL = MINUS ( - )

O : ONE (1) P : PLUS (+) PN = POSITIVE NUMBERS Z = ZERO

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

ARIT}~IETIC RULES AR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

AR-M N_-N --> 0 >-< DEF_DET[N~

AR-PO~O N_+I-I <-> _N

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SIMPLIFICATION OF EXISTENTIAL QUANTIFICATION ESI

ESI. .E~ K: n a t II i f EQ_N(K, O) t h e n E_ e l s e F e n d i f

_G V (~ _K: nat II -EQ_N(K, O) a _F) >-<

[S_] = E l 0 f o r K]

ESI-PN OL___DD: nat II ~E0_N(OLD, 0) A E --> B OLD: nat II [ >-< [F~ = E~OLD + 1 for OLD]

SIMPLIFICATION OF EQUALITY QSI

OSI-OZ EQ__N(1, O) <-> f a l s e

Page 427: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V . 3 . 3 N a t u r a l n u m b e r s 419

~SI....ZZ EQ_~I(O, O) <-> true

END CATALOG N

Page 428: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

420 V.3 Rules for data types and computation structures

3.4. Conditional join operations

THIS CATALOG CONTAINS TRANSFORMATION RULES FOR SET FUNCTIONALS

COMPARE MOELLER, B, PAUKNER, O: TRANSFORMATION RULES FOR CONDITIONAL

JOIN OPERATIONS;

AND FILE SETFI~CT CIP U ======================================================================================

A = UNIVERSAL QUANTIFIER

D = THAT_M

E = EXISTENTIAL QUANTIFIER

F = FILTER

G = FAP_M_N

H = FT_M

M = MEMBERSHIP

S = SC_M

U = UNION (FUNCTIONAL)

Y = IS_Y_M

CV = CONVERSION

CY = COMMUTATIVITY

DM = DISTRIBUTE OVER MAPPING

DP = DISTRIBUTE OVER PREDICATE

DS = DISTRIBUTE OVER SET

DY = DISTRIBUTIVITY

IM = INTRODUCTION BY MAPPING

IN = INTRODUCTION

IS -- INTRODUCTION BY SET

NO = NOT OCCURS

RM = REMOVAL

SR = SHIFT CONDITION

SI = SHIFT INNER

SM = SIMPLIFY ON ACOUNT MAPPING

SO = SHIFT OUTER

SP = SIMPLIFY ON ACOUNT PREDICATE

SS = SIMPLIFY ON ACOUNT SET

V = UNION (FUNCTION)

A =AND

C = CONDITIONAL

E = EMPTYSET

EK = EXIST

FL = FALSE

K = ME_ZING

L = LEFT ARGUMENT

M = I S ~

0 = OR

O = EQUALITY

P = PREDICATE

R = SECOND ARGUMENT

SA = ANDSEO

DISTRIBUTION OVER MAPPING OF UNIVERSAL QUANTIFICATION ADM

ADM-A

ALL_M((X_!: m): bool; _P_, (X2: m): bool ; ~ ^ R)(S_) <->

Page 429: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3.4 Condi t ional j o in ope ra t ions 421

ALL..~((X_!: m): bool; P, (X.~2: m): bool ; Q)(S.) A ALL..~((XI: m): bool; P, (X_22: m): bOol; _~)(S) >-< DETEI~INATE[P] A DETEI~INATE[S_]

DISTRIBUTION OVER SET OF UNIVERSAL QUANTIFICATION ADS = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

ADS-A ALL_M((XI: m): bool; P., (X_22: m): bool; Q_)(S) ^ ALL..M((X._II: m): bool; P, (X2: m): bool; Q)(T) <-> ALL..M((Xh m): bool ; P, (X.~2: m): bool ; ~)(UNION_.M(S__, T))

NOT OCCURS RULES FOR UNIVERSAL QUANTIFICATION ANO

ANO-AR ALL_M((XI: m): bool; P, (X_2.: m): bool; Q ^ _R)(S_) <-> ALL_M((Xl: m): bool; P, (X_22: m): boo1; Q_)(S) ^ _R >-< ~X.~2 in R_ A DETERMINATE[_RJ

SHIFT ASH = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

ASH--~ EX_M((XI: m): bool; P, (X2: m): bool; Q_)(S) ^ ALL_M((XI: m): bool; P, (X2: m): bool ; R_)(S) <-> EX_M((Xh m): bool; P, (X2: m): bool; Q a R)(S_) a ALL..M((XI: m): bool; P, (X__22: m): bool; R_)(S_) >-<

DETEI~MINATE[P, R] A DETERMINATE[S]

SHIFT OUTER OF UNIVERSAL QUANTIFICATION ASO = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

ASO-A ALL_M((XI: m): boo1; P,

(X.22: m): bool ; ALL__N((Y._!: n): bool ; _Q, (Y2: n): bool ; R)(T))(S) <-> ALL_N((Yh n): bool; Q, (Y_22: n): bool ; _R)

(UNION_M_N((XI: m): bool; _P, (X2: m): s e t _ o f n; T_)(S_)) >-< ~([X2] = [Y1] V [X2] = [Y2]) ^ -X_22 in _Q A -X_22 in R

CONVERSION OF THAT_.M DCV = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

DCV.-~/ THAT__M((_X: m): bool; IS_MEM..M(_X, S_) A P) <->

FT_M((X_: m): bool; P__)(S__)

Page 430: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

422 V.3 Rules for data types and computation structures

>-< DETERMINATE[S] A -_X in S

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

DISTRIBUTIVITY OF THAT_M DDY

DDY-C THAT_M((X: m): bool; if C then P else ~ endif) <->

if C then THAT_M((X: m): bool; P) else THAT_M((X: m): bool; _Q) endif >-< ~X in C_. A DETERMINATE[C]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

NOT OCCURS RULES FOR THAT_M DNO ======================================================================================

DNO...SAL THAT_M((X: m): boo1; P_ A ~) <-> i f _P then THAT_M((X: m): boo1; O) endi f >-< ~X_ in P_ A DETERMINATE[P]

REMOVAL OF THAT_M DRM

THAT_M((_X: m): bool; EQ_M(_X, E)) ---->

S

>-< -_X in E A DETERMINATE[El

CONVERSION OF EXISTENTIAL QUANTIFICATION ECV

ECV-2K EX_M((X: m): bool; _P, (X: m): bool; Q_)(_S) <->

_X: m , (IS_MEM_M(X, S) Z, (P_ A _~)) >-<

-X in S ^ DETERMINATE[S]

ECV-MP EX_M((XI: m): bool; P, (X22: m): bool; EQ_N(E, F))(S) <-> IS_MEM_N(E, FAP_M_N((XI: m): bool; P, (X__2: m): n; _F)(S_)) >-< -X_22 in E_ ̂ DETERMINATE[E_]

COMMUTATIVITY OF EXISTENTIAL QUANTIFICATION ECY ...................................................................................... ......................................................................................

Page 431: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3.4 Conditional join operations 423

ECY.-EK EX_M((X_~I: m): bool; P_, (X_22: m): bool; B _Y: n II O_)(S_) <->

_Y: n II EX_M((XI: m): bool; P_, (X2: m): bool; O_)(S) >-< -(IX1] : [Y] V IX2] = [Y]) A -_Y in P A -Y in S

m m ~ m ~ m ~ m m m m m m ~ m ~ m m m m m m m m m ~ m m m ~ m m m ~ m m m ~ m z m m m m ~ m m ~ m m m m m m m m m m m m m m m ~ m ~ m m m ~ m m

INTRODUCTION OF EXISTENTIAL QUANTIFICATION BY MAPPING EIM

EIH..~ IS_~EM__M(C_, _S) A Q

EX..M((_X: m): bool; _P, (%: m): bool; EQ_M(X, C))(~_) >-< [X] = USERDEFINED[_~] h ~X in C_ A ~X in O_ A [P] = O_[X for C] A DEFINED~P, C] A DETERMINATEEC]

INTRODUCTION OF EXISTENTIAL QUANTIFICATION EIN

EIN-T2A OLD: m II P. A Q_

PC(PI, P2) /~ begin Q where const OLD: m = F(P1, P2) end >-< [funct ion P__CC (PFI: ml; PF2: ~ ) : bool; q _X: m [I IS_MEMAM(X_, _T) A S_]

= USERSHOWN[PC] [P] = IS_MEM_M(X, _T) A S~OL_DD, P_!l, P2 for _X, PFI, PF~.] A [function F (PFl: m!l; PF__22:m2 II PC(PFI, PF__/2)): m; FT_M((_X: m): bool; S_)(_T)] = USERSHOWNEF] h DEFINED[O__, F(P1, P 2 ) ]

EIN-.T2SA

---->

PC(P1, P2) A begin O where const OL_DD: m = F(PI, P2) end >-< [function P_~C (PF_~I: ml; PF2: m22): bool; ~ X: m II ISAMEM_M(X, T) A S]

= USERSHOWN[P_QC] A [P] = IS_MEM_M(_X, T) A S_~0L__DD, P_!l, P_~2 for _X, PFI, PF2] A [function _F (PF__!I: m_!l; PF2:m2 II P_CC(PF_!I, PF__22)): m; FT_M((_X: m): bool; S_)(_T)] = USERSHOWN[F] h DEFINED[Q__, F(P1, P2)]

m m m ~ m m ~ m m ~ m m m ~ m ~ m m m m m m m m m ~ m m m m m m ~ m m ~ m m ~ m m m m m m m m m m ~ m m m z ~ m m ~ m ~ m ~ m ~ m m m m m ~ m m ~ m m m m

NOT OCCURS RULES FOR EXISTENTIAL QUANTIFICATION ENO

ENO-AL EX_M((XI: m): bool; P, (X2: m): bool; O A _R)(S) <-> _0 A EX_M((XI: m): bool; P, (X2: m): bool; _R)(S) >-< ~X_22 in 0 A DEF_DET[Q_]

Page 432: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

424 V.3 Rules for data types and computation structures

E~IO-AR EX_M((XI: m): bool; P_, (X2: m): bool; O ^ _R)(S_) <-> EX_M((XI: m): bool; P, (X2: m): bool; Q_)(S_) A R >-< -X_~2 in ~ ^ DEF_DET[_~]

SHIFT OUTER OF EXISTENTIAL OUANTIFICATION ESO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ESO-E EX_N((XI: n): bool; P,

(X2: n): bool; EX_M((Y_!: m): bool; 0, (Y2: m): bool; R)(T))(S) <->

EX_M((Yh m): bool; Q_, (Y2: m): bool; _R)(UNION_N_M((XI: n): bool; _P, (X2: n): set_of m; T)(S_))

>-< - ( I X 2 ] = [Y1] V [)(21 = [Y2]) A -X2 in QQ A -X2 in R

ELIMINATION OF EXISTENTIAL OUANTIFICATION BY MAPPING ESM

ESM-Q EX_M((X: m): bool; P, (X: m): bool; EO_M(_X, _C))(_S) ---->

IS_MEM_M(C_, S_) ~ O_ >-<

-X in C_ ̂ DEFINED[P_, C] A [g] : P~C for _X] h ASSERT[begin function PP (X_: m): bool; P_;

V (A: m; B: m 11 EO_M(A, B)) }{ PP(A) ¢~ PP(B) e n d ]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

CONVERSION OF EILTER_.N FCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FCV.-G FILTER_M((Y: m): boo1; _P)(S_) <-> FAP_M_M((_Y: m): boo1; _P, (Y: m): m; _Y)(_S)

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

sIMPLIFICATION ON ACCOUNT OF PREDICATE OF FILTER FSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FSP....M FILTER_M((_X: m): b o o l ; IS_MEM_M(_X, S_) a P)(S_) <->

FILTER_M((_X: m): bool; _P)(S) >-<

-_X in S_ A DETEI~4INATE[S]

CONVERSION OF FAP_M_N GCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C~V-U FAP_M_N((XI: m): bool; P, (X2: m): n; _F)(_S) <->

Page 433: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3.4 Conditional join operations 425

UNION_M_N(()[!: m): bool; P, (X2: m): set of_n; MK_SING_N([))(S)

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

sIMPLIFICATION OF FAP ON ACCOUNT OF SET GSS

GSS-E FAP_M_N((XI: m): bool; P, (X__22: m): n; E)(EMPTYSET_M) --> EMPTYSET_N

INTRODUCTION OF MAPPINGS IN ======================================================================================

IN..4

E <->

ALL_M(()[: m): bool; true, (_X: m): bool; G-)(ME_~ING_M(C)) >-<

~ = USERSHOWN[C_~ A C_ isof_submode m A DEFINED[C~ A DETERMINATE[C~ A [)[1 = USERDEFINED[X~ A G_[C_ for X] = F[~ for C~ A -)[ in F A KIND[F~ = bool

IN.2 F <->

EX_M(()[: m): bool; true, (X: m): bool; G)(MK_SING_M(C_)) >-<

[C~ = USERSHOWN[C~ A C- isof_submode m A DEFINED[C~ ^ DETERMINATE[C] A [)[] = USERDEFINED[X~ A G_[C for X] = _F[)[ for C~ A ~)[ in _F A KIND[F] = bool

IN--F some _R: set of m II EO__SET_M(_R, S) <->

FILTER_M(()[: m): bool; true)(_S) >-<

[_HI = USERDEFINEDLR] A ~_R in S_ A [X_~ = USERDEFINED[X~ A DETERMINATE[S]

I N S P_ <->

IS_MEM._M(E, SC_M((X: m): boo l ; 0_)) >-< [E] = USERSHOWN[E] A E isof_submode m i DEFINED[E~ A DETERMINATE[El A [X~ : USERDEFINED[X] A ~ ] : _P[)[ f o r E_] A -X i n P A KIND[_P] : b o o l

<->

~ION~'i_N((X: m): b o o l ; t r u e , (X: m): s e t o f - n ; G-)(~_SING-M(C)) >-< [C-] : USERSHO~[C-1 ~ C- i s o f ~ m o ~ m A DEFI~D[C-l A

Page 434: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

426 V.3 Rules f o r d a t a t ypes and compu ta t i on s t r u c t u r e s

DETERMINATE[C] h [ ~ ] = USERDEFINED[X] A fi[C f o r X] = E[~ f o r C] A -X in E ^ KINDE£] = s e t o f n

CONVERSION OF MEMBERSHIP MCV

MCV-G IS_MEM_N(X, FAP..M_N((YI: m): bool; _P, (Y2: m): n; F)(S_)) <-> EX_.M((Y!I: m): bool; P, (Y2: m): bool; EQ_N(%, _F))(_S) >-< ~Y2 in X A DETERMINATE[X]

======================================================================================

C~TATIVIT¥ OF MEMBERSHIP MCY ======================================================================================

MCY-U IS_MEM_~(_Y, UNION_M_N((X_!: m): boo l ; P, (X_22: m): s e t _ o f n; _F)(S)) <-> EX_M((X_!: m): b o o l ; _P, (XZ: m): boo l ; IS_MEMO(Y_, _F))(_S) >-< -x_22 i n V A DETENMINATE[Y~

CONVERSION OF SC_M SCV

SCV-.F SC_M((_X: m): bool; IS_MEM_M(X_, S_) A _P) <->

FILTER_M((X_: m): bool; P)(S_) >-< -_X in S A DETERMINATE[S]

======================================================================================

CO~t~JTATIVITY OF SC..N SCY

SCY--E SC_M((_X: m): boo l ; EX_N((YI: n ) : boo l ; P, (Y2: n ) : boo l ; _O)(T)) ---->

UNION_N_M((Y_I: n ) : boo l ; P_, (Y2: n ) : s e t _ o f m; SC_M((_E: m): boo1; ~ ) ) ( T ) >-< - ( I X ] : [Y1] V [X_] : [Y2]) A -X in T A -_X in _P A (IS_EMPTYSORT[_m] ~ DEFINEDIT])

DISTRIBUTION OVER PREDICATE OF SC_M SDP ======================================================================================

SDP-C SC_M((_X: m): bool; if B_ then _P else _Q endif) <->

if B_ then SC__M((_X: m): bool; P) else SC_M((_X: m): bool; 0_) endif >-<

-_X in B A DETERMINATE[B]

Page 435: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3.4 Conditional join operations 427

SDP.I) SC_M((X: m): bool; E v Q)

UNION_M(SC_M((X: m): boo1; P), SC_M((X: m): bool; Q))

SIMPLIFICATION ON ACCOUNT OF PREDICATE OF SC_M SSP

SSP-FL SC_M((X: m): bool; false) <-> EMPTYSET_M >-< [X~ = USERDEFINED[X]

SSP-Q SC_M((X: m): bool; EO_M(C, ~)) --> MK_SING_M(C) >-< -X in

CONVERSION OF UNION UCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UCV-S UNION_M_N((_X: m): bool; _P, (X: m): set of n; MK_SING_N(F))(S_)

SC_N((Y: n): bool; 3 _X: m II IS_MEM_M(_X, S) A (P A EQ_N(Y, _F))) >-<

[Y] = USERDEFINED[Y_] A -([X~ = [Y~) A -_Y in P_ A -_Y in _F A -Y in S A DETERMINATE[S_]

UCV-S-M UNION_M_M((_X: m): bool; P, (X: m): set_of_m; MK_SING_M(X))(_S) ---->

SC_M((X_: m): bool; IS_MEM_M(X, S) A P) >-<

~X in S_ A DETEI~MINATE[S_]

CO~94UTATIVITY OF UNION UCY = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

ucY-U UNION_M_N((X_!I: m): bool; P, (X2: m): set_of_n;

UNION_O_N((Y_!I: o): bool; O A _R, (Y2: o): set_of_n; F)(T))(_S) ---->

UNION_O_N((YI: o): bool; _Q, (Y2: o): set_of_n; UNION_M_N((X_!I: m): bool; P A R_, (XZ: m): set_of n; F_) (S_) ) (T)

>-< ~( I IX2~ = [ ~ ] V [X21 = [ Y 2 ~ v [Y2] = Q 'X l ] ) ^ ~X_22 in _T A -X_22 in Q_ A -Y__22 in P A ~Y22 in S A false _c D _P :> DEFINED[O] A false -=D Q ~ DEFINED[P]

DISTRIBUTION OVER MAPPING OF UNION UDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UDM--V UNION_M_N((X_!: m): bool; _P, (X2: m): set_of_n; UNION_N(F, _G))(S)

Page 436: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

428 V.3 Rules for data types and computation structures

UNION_N(UNION_M_N((X!: m): bool; P, (X2: m): set_of_n; F)(8), UNION_M_N((X_!: m): bool; P, (X22: m): set_of n; G)(S))

>-< DETERMINATE[P] ^ DETERMINATE[S]

DISTRIBUTION OVER SET OF UNION lIDS = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

UDS--V UNION_M_N((XI: m): bool; P, (X22: m): set_of_n; F)(UNION_M(S, T)) <-> UNION_N(UNION~((XI: m): bool; P, (X2: m): set of n; F)(S),

UNION_M_N((~I: m): bool; P, (X_22: m): set_of_n; F)(T))

INTRODUCTION OF UNION_M_M BY SET UIS

UIS--M IS_MEM_M(Y, S) A P SS

IS_MEM_M(Y, UNION_M_M((_X: m): bool; P, (X: m): set of m; MK_SING_M(X))(_S)) >-< [X_~ = USERDEFINED[X~ A ([X~ = [Y~ V ~X in P SS) A [P_] = P_SS[_X for Y~ A DETERMINATE[P~ A (false c~ IS_MEM_M(Y, _S) =~ DEFINED[P~)

SHIFT INNER OF UNION USI

USI-U UNION_M_N((_X: m): bool; P, (X: m): set_of_n;

UNION_O_N(([: o): bool; O, (Y: o): set_of n; _F)(_T))(S_) ---->

UNION_M_N((_X: m): bool; P A EX_O((_Y: o): bool; true, (Y: o): bool; O)(T), (_X: m): set of_n; F)(S)

>-< -([X~ = [_Y]) ̂ -Y in _F

SIMPLIFICATION ON ACCOUNT OF MAPPING OF UNION USM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ................................................................................................

USM-.K .UNION_M_N((XI: m): 5ooi; true, ---->

S

>-< DETERMINATE[S_]

(X2: m) : set_of_n; MK_SING_M(X2)) (S_)

SHIFT OUTER OF UNION USO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...........................................................................................

uso-u UNION_M__N((XI: m): bool; P_, (X_22: m): set_of n;

UNION_O_N((YI: o) : bool; O, (2: o) : set_of_n; _F) (_T)) (S_)

Page 437: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3.4 Conditional join operations 428

UNION_O_N((YI: o): bool; Q, (Y2: o): set_of_n; F) (UNION_M_N((XI: m): bool; P, (X2: m): set_of n; T)(_S))

>-< ~([X2] = [YI] v [X_22] = [Y2~) A ~X_~2 in F A ~X__22 in Q_ A -Y_22 in T

SIMPLIFICATION OF UNION ON ACCOUNT OF SET USS

USS-E UNION_M__N((XI: m): bool; _P, (X2: m): set of_n; _E)(EMFTYSET_M) <-> EMPTYSET_N

COMMUTATIVITY OF IS_Y YCV

YCV-FE ~S_Y_~(~I~TEK_~((X: m)" bool; _P ~ _O)(s_))

~EX_M((X: m): boo l ; P_, (X: m): boo l ; O)(_S)

END CATALOG U

Page 438: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

430 V.3 Ru les f o r d a t a t y p e s and c o m p u t a t i o n s t r u c t u r e s

3 . 5 . DEVTREE

THIS CATALOG CONTAINS TRANSFORMATION RULES WHICH ARE VALID FOR THE STRUCTURE DEVTREE DUE TO LAWS OF THE OCCURRING MODES AND RULES WHICH ARE DERIVED DURING THE DEVELOPMENT

LRI

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

LAWS OF THE RECORD-TYPE devunit

I I 1 INIT(N) is INIT --> true >-< DEFINED~N]

IIP INIT(N) is PROPER --> false >-< DEFINED[N]

PI POST(INIT(N)) <->

PP POST(PROPER(N1, N2, P_.R_R, IN, RE)) --> N22 >-< DEFINED[N1, P__RR, IN, ~E~

======================================================================================

LAWS OF THE RECORD-~/PE e d g e _ l a b e l

INFCEL INFO(CEL(PREMS, INF,0, REL)) --> INFO >-< DEFINED~PREMS, REL~

PRECEL PREMS(CEL(PREMS, INF_~O, REL) ) --> PREMS >-< DEFINED~INFO, REL]

RELCEL REL(CEL(pREMS, INFO, RE__LL)) --> RE___LL >-< DEFINED~PREMS, INFO~

DERIVED VERSIONS (D) OF THE RULES USED IN THE DEVELOPMENT OF DEVTREE

D/TTD DESCENDANTS(N, _T) ---->

DES (MF~SING_MT (_N), _~) >-<

DEF_DET[N, T~ A N isof_submode mterm A KIND~T~ -- devtree

Page 439: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3,5 DEVTREE 431

D 1 TTHP HAS_.PRED(N, 0, _T) <->

IS._IN(N, T) >-<

DEF_DET[_N, T] A KIND[N] : mterm A KIND[T] = devtree

DITTIC INFO(COLLECT(P_!, P2, P_33, P4)) <->

COLLECT_INFO(FI, P_~2, P~3, P..44) >-< DEF._DET[P1, P22, P...33, P_44] A ASSEI~T[COMPACTABLE(P1, P._22, P___33, P_44)~

MEM..NODES

ISjN(_N, I) <->

IS..MEM__MT(.NN, NODES(T) ) >-<

DEF_DET[_N, T] A KIND[N] -- mterm A KIND[T] = devtree

I)i TTPC PREMS (COLLECT(P1, P2, P.3_3, P4) ) <->

COLLECT..PREM(P1, P2, P__33, P4) >-<

DEF_DET[P1, P2, P.33, P._44~ A ASSERT[COMPACTABLE(P1, P...22, P.33, P..~4)]

D1 TTPP~D PRED(_N.N, l, T) <->

PRE(GET_DEVUNIT(_N, T) ) >-<

DEF_DET[_N, T] ^ KIND[N] = mterm ^ KIND[T] = devtree ^ ASSERT[HAS_PRED(_N, l, T)~

D/TTRC REL(COLLECT(PI, P2, P3, P_..44)) <->

REL_CO~mOSE(~, ~, P__3, P4) >-<

DEF_DET[PI, P2, P_..33, P4] A ASSERT[COMPACTABLE(P1, P2, P3, P4)]

D I TTEDE3 D~s(s__, _T) <->

EDES(EMPTYSET_MT, _S, T) >-<

KIND[S] = set of mt A KIND[T] = dev_tree A DEF_DET[S_, T]

Page 440: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

432 V.3 Rules for data types and computation structures

END CATALOG LRI =======================================================================================

= = •••••--•••--•••••••••••••••••--•••••••--••••••------•••••••--••••••••••••----•••••••••••••--•••

LAWS OF THE TYPE MAP LR2 ======================================================================================

PAB..~ PUT(I, V, REM(I, T)) <-> PUT(I, V, T) >-< DETEI~MINATE[I]

......................................................................................

PAB--G PUT(N, GET(N, T), T) <-> T >-< ISA[T, N_] A DETERMINATEEN, T]

======================================================================================

DERIVED VERSIONS OF THE RULES USED IN THE DEVELOPMENT OF DEVTREE

UF-ADD ADD_DVU(X, S) --> PUT(POST(X), X, S) >-< DEF_DET[X, S]

.......................................................................................

UF-I)EL DEL._DVU(_X, _S) --> REM(POST(X), S) >-< DEF_DET[.X, S]

......................................................................................

UF-E~IPTY EMPTYSET_.DVU() --> VOID()

UF--GET--DEV GET_DEVUNIT(N_, T) --> GET(N, T) >-< DEF_DET[N, T] ^ ASSERT[IS_IN(N, T)]

......................................................................................

UF-JS--IN IS_IN(NN_, T) --> ISA(N, T) >-< DEF__DET[N, T]

......................................................................................

UF--IS..21EM IS..MEM._DVU(X, S) --> ISA(POST(X), S) >-< DEF..DET[X, S_]

======================================================================================

END CATALOG LR2 ======================================================================================

Page 441: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3 .6 CLAUSE 433

3 . 6 . CLAUSE

THIS CATALOG CONTAINS TRANSFORMATION RULES CORRESPONDING TO THE LAWS OF THE ABSTRACT DATA TYPE CLAUSE CLAUSE

A = ANTECEDENTS C = CONSEQUENT M = MAKE_CL

SI = SIMPLIFICATION

SIMPLIFICATION OF ANTECEDENTS ASI

ASI-H ANTECEDENTS (MAKE_CL ( ~T~, CONS,))

ANTE >-<

true

SIMPLIFICATION OF CONSEOUENT CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CSI-J~ CONSEOUENT (MAKE_CL (ANTE, CONS))

CONS >-<

~rue

END CATALOG CLAUSE

Page 442: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

434 V.3 Rules f o r d a t a t y p e s and computa t ion s t r u c t u r e s

3 . 7 . FORMULA

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

THIS CATALOG CONTAINS TRANSFONMATION RULES CORRESPONDING TO THE LAWS OF THE ABSTRACT DATA TYPE FORMULA. FORMULA

A = ARGS P = PRED_.SYMB

Sl = SIMPLIFICATION

SIMPLIFICATION OF ARGS ASI = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

AS1-M ARGS (MAKE_FO(PRED_SYMB, ARGS) ) ---->

ARGS >-<

DEFINED~PEED__SYMB]

SIMPLIFICATION OF PRED_SYMB PSI

PSI-// PRED_SYMB(MAKE_FO(PRED_SYMB, ARGS) )

PRED_SYMB >-< DEFINED[ARGS]

END CATALOG FORMULA

Page 443: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V . 3 . 8 TERM 4 3 5

3.8. TERM

======================================================================================

THIS CATALOG CONTAINS TRANSFORMATION RULES CONCERNING THE CONSTITUENTS OF STRUCTURE TERM TERM

AS = ARGS MK = MAKE_T OP = OPTOR OL = EQUAL_ ("STRONG" TERM-EQUALITY)

======================================================================================

RULES FOR THE SELECTOR "ARGS" AS

AS-MK ARGS(MAKE_T(O, AS)) --> A.~S >-< ASSERTa'MAKABLE_T(O_, AS)]

======================================================================================

RULES FOR THE SELECTOR "OPTOR" OP ======================================================================================

OP-MK OPTOR(MAKE_T(O, A_SS)) --> O >-< ASSERT[MAEABLE_T(O, AS)]

======================================================================================

EQUAL QL = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

QL-.~ EOUAL_T (T1, T2) <->

EO_O(OPTOR(TI), OPTOR(T2)) ^ NON_DIST_O(OPTOR(TI), OPTOR(TZ)) EQUAL_AS(ARGS(TI), ARGS(T2) ) >-<

DETEFaMINATE IT!, 7'2]

======================================================================================

END CATALOG TERM

======================================================================================

THIS CATALOG CONTAINS TRANSFORMATION RULES FOR SEQUENCES ON term (terms) S_TS

C = CONDITIONAL CN -- CONC_TS DF = DEL._FRONT_TS F = FIRST_TS GF = GET_FRONT_TS IY = IS_Y_TS K = MAKE_TS L = LENGTH_TS Q = EQUAL_TS R = REST_TS Y = EMPTY_TS

Page 444: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

436 V.3 Rules f o r da t a types and computation structures

CV = CONVERSION DC = DECOMPOSITION DY = DISTRIBUTIVITY SU = SUBSTITUTION

A = AND L = LEFT 0 = OR T = THEN-BRANCH Z = ZERO

SUBSTITUTION IN AND ASU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A SU...I Y L-J .Z IS_Y_TS(S) ^ _P <-> ~S_¥_TS($_) ^ O_ >-< DETE~INATEIS_] ^ I~] = E[ 0 f o r LENCTH_TS(S_)]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SUBSTITUTION IN CONDITIONAL CSU

CSU--Y-T if IS_Y_TS(S_) then E1 else E_22 endif <->

if IS_Y_TS(_S) then _G else E__22 endif >--<

DETERMINATE[S~ A [G_] = EI[EMPTY_TS for S~

DECOMPOSITION DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

BC S <->

if -IS_Y_TS(S_) then CONC_TS(MAKE_TS(FIRST_TS(S) ), REST_TS(S) ) else EMPTY_TS endif >-<

DETEI~MINATE IS]

DELETE_FRONT_TS DF = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

DF I 2 DEL_FRONT_TS(EMPTY_TS~ I) --> EMPTY_TS >-< DEFINED~_I~

CONVERSION OF DELETE_FRONT_TS DFCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

DFCV-CR DEL3RONT_TS (S_, I) <->

if IS_Y_TS(S) then EMPTY_TS else REST_TS(S_) endif >-<

DETERMINATEly]

Page 445: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V. 3 .8 TERM 437

FIRST_TS F

FK FIRST_TS(MAKE_TS(X)) <-> X >-< KIND[X~ = term

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

GET_FRONT_TS GF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

GF12 GET_FRONT_TS(EMPTY_TS, I ) - -> EMPTY_TS >-< DEFI~D[_I]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

CONVERSION OF GET_FRONT_TS GFCV

GFCF-CKF GET_FRONT_TS (S_, I) (-)

if IS_Y_TS(_S) then EMPTY_TS else MAKE_TS(FIRST_TS(_S)) endlf >-<

DETERMINATE[S~

IS_Y_TS IY = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

IY-GFZ IS_Y_TS(GET_FRONT_TS(S, 0)) --> true >-< DEFINED[S] ^ KIND[S] = terms

IYK IS_Y_TS (MAKE_TS (_X)) <->

false >-<

[X_] = USERSHOWN[X] A DEFINED[X] A KIND[X] = term

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

LENGTH_TS MAKE_TS LK = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

LK LENGTH_TS(MAKE_TS(_X)) --> 1 >-< DEFINED[X] A KIND[X] = TERM

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

EQUAL_TS Q . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -- . . . . . . . . . . . . . . . . . . . . . .

09}'-CN-A EQUAL_TS(CONC_TS(R, _S), T) <->

EO~AL_TS(R_, GET_~ONT_TS(L ~ENGTH_TS(R) ) ) A EQUAL_TS(_S, DEL~NT_TS(T, LENGTI~_TS(_R) ) ) >-<

DETERMINATE JR, T]

Page 446: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

438 V.3 Rules f o r d a t a t ypes and computa t ion s t r u c t u r e s

OKK EOUAL_TS(MAKE_TS(X), MAKE_TS(Y)) <-> EQUAL_T(_X, Y)

OKY EOUAL_TS(MAKE_TS(S), EMPTY_TS) --> false >-< DEFINED[S] A KIND[S] = terms

QY-L EQUAL_TS(EMPTY_TS, S) <-> IS_Y_TS(S)

QYY EQUAL_TS(EMPTY_TS, EMPTY_TS) <-> true

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

CONVERSION OF EQUAL_TS QCV

OCV-C EQUAL_TS (_S, T) <-> if IS_Y_TS (S) then IS_Y_TS (T) else if IS_Y_TS(T)

then false else EQUAL_T (FIRST_TS (S), FIRST_TS (T)) A EQUAL_TS (REST_TS (S_), REST_TS (T)) endif

endif >-<

DETERMINATE[S, T]

~::V-o EaUAL_TS (_S, I) <->

IS_Y_TS(S) A IS_Y_TS(T) V (-IS_Y_TS(S) A -IS_Y_TS(T) EOUAL_.T (FIRST_TS (S), FIRST_TS (T)) A EQUAL_TS (REST_TS (S_), REST_IS (T)) ) >-<

DETERMINATE[S, _T]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

REST...TS R ======================================================================================

RK REST_TS (MAKE_TS (_X)) <-> EMPTY_TS >-( IX] = USERSHOWNLX] A KIND[X] = t e rm A DEFINED[X]

Page 447: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V. 3 . 8 TEl@4 439

END CATALOG S_TS = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

THIS CATALOG CONTAINS LOCAL EXTENSIONS OF THE CATALOG S SS_AS = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

H : ELSE-GUARD (SUBSCRIPT-CONVENTION CF. UU_I) Q = EQUAL_AS

CV = CONVERSION SU = SUBSTITUTION

H : ELSE-GUARD Y : EMPTY_AS

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SUBSTITUTION IN ELSE-GUArD OCV = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

H2SU-J --YY i f IS_Y_AS(S) A IS_Y_AS(T) then A ~ B then C_ else D_ endif ---->

if IS_Y_AS(S) A IS_Y_AS(T) then AA ~ B then C_ else D_ endif >-<

[A_AA] = A[EMPTY_AS, EMPTY_AS for S, T]

CONVERSION OF EQUAL_AS OCV

QCV.-II2 EQUAL_AS (S~, $2)

i f IS_Y_AS(S1) A IS_Y_AS(S2) t h e n t r u e

~IS_Y..AS(S1) ^ ~IS_¥_AS(AS2) t h e n EQUAL_IS(FIRST_AS(S1), FIRST_AS(S2)) A EQUAL_AS(REST_AS(S1), REST_AS(S2)) e l s e f a l s e

e n d i f >-<

DETEI~INATE[S1, $2]

END CATALOG SS.....AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

THIS CATALOG CONTAINS LOCAL EXTENSIONS OF THE CATALOG S_TS SS_TS

H = ELSE-GUARD O = EQUAL_TS SA = SEQUENTIAL AND

CV = CONVERSION SI = SIMPLIFICATION SU = SUBSTITUTION

Page 448: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

440 V.3 Rules for data types and computation structures

DF = DEL_FRONT_TS F : FIRST_TS GF : GET_FRONT_TS GR : GET_/~EAR_TS IY = IS_Y_TS L = LENGTH_TS N : NOT 0 = OR R : REST_TS

I : LENGTH-ARGUmENT

I: LENGTH-ARGUMENT

SIMPLIFICATION OF GET_FRONT_TS GFSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

GFSI...L GET_FRONT_TS(T, LENGTH_TS(S)) - -> T >-< ASSERT[LENGTH_TS(T) I t LENGTH_TS(S)]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SUBSTITUTION IN ELSE-GUARD HSU = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

HSU-GF1 -DF1 i f -IS_Y_TS(S) A -IS_Y_TS(_T) A _A t h e n E1 B -~S_Y_TS(S_) ^ -~S_Y_TS(T) ^ B_ t h e n E2 e l s e E3 e n d i f

i f ~IS_¥_TS(S) A - IS_¥ TS(T) A A then D_! 0 ~IS_Y_TS(S_) A ~IS_Y_TS(T) A B t h e n D_22 e l s e E_33 e n d i f >-< [D_~] = EI[MAKE_TS(FIRST_TS(_S)), ~ST_TS(_S), MAKE_TS(FIRST_TS(T)), REST_TS(T) f o r

GET_FRONT_TS(S, 1) , DEL_FRONT_TS(S_, 1) , GET_FRONT_TS(T, 1) , DEL_.F~ONT_TS(T, 1]) ,a

[D_/2] = E_22~AKE_TS(FIRST_TS(S)), REST_IS(S), MAKE_TS(H~ST_TS(T)), REST_TS(T) f o r GET_FRONT_TS(S, 1) , DEL_FRONT_TS(S_, 1) , GET_FRONT_TS(T, 1) , DEL_FRONT_TS(T, 1 ) ]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SIMPLIFICATION OF IS_Y_TS IYSI

IYS1--NIY-.GFL -ZS_Y_TS(S) ^ -ZS_Y_TS(G~T_Y~ONT_TS(T, LENGTH_TS(S))) <-> -IS_Y_TS(S) ^ ~IS_Y_TS(T) >-< DETEI~INATE[S ]

CONVERSION OF EQUAL_TS QCV

t~CV--DF-GR EOUAL_TS(S, DEL3RONT_TS(T, N)) <-> i f (EQ_N(LENGTH_TS(S) + N, LENGTH_TS(!)) A LENGTH_TS(T) g e N ) v

(LENGTK_TS(T) I t N ^ IS_Y_TS(!)) t h e n EQUAL_TS(S, GET_REAR_TS(T, LENGTK_TS(S))) e l s e LENGTH_TS(T) I t N A ~IS_Y_TS(T) A IS_Y_TS(S) e n d i f

Page 449: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V. 3.8 TEI~M 441

~CV-O-~;RL-2 EQUAL_TS(_S, GET_REAR_TS(T, LENGTH_TS(_S) ) ) <->

EQUAL_TS (_S, T) v ( -IS_Y_TS (T) A EQUAL_TS (_S, GET_REAR_TS (REST_TS (T), LENGTH_TS (_S)) ) ) >-< DETEI~INATE~, T~

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SIMPLIFICATION OF EQUAL_TS QSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

~SI-LL EQUAL_TS(T, S_) --> f a l s e >-< ASSERT~LENGTH_TS(S) i t LENGTH_TS(T)]

SUBSTITUTION SASU

SASU-I~GF_.F -IS_Y_TS(S) A -IS_Y_TS(T) A _P <-> -IS_Y_TS(S_) ^-IS_Y_TS(T) ~ ~_ >-<

~Q] = _P~FIRST_TS(T) for FIRST_TS(GET_FRONT_TS(_T, LENGTH_TS(S_)))] A DETERMINATE~S]

END CATALOG SS_TS

Page 450: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

442 V.3 Rules for data types and computation structures

3.9. INSTANCE

THIS CATALOG CONTAINS TRANSFORMATION RULES CONCERNING THE CONSTITUENTS OF THE STRUCTURE INSTANCE INSTANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

F = FILTER_/ G = GET I = INST_ IY = IS_Y_ KT = MAKE_T RL = REL_INSTS_

CV = CONVERSION CY = CO/~dUTATIVITY DM = DIMINISHING DP = DISTRIBUTION ON PREDICATE SI = SIMPLIFICATION SU = SUBSTITUTION

A -- AND AS = ARGS

D -- IS_DEF FR = FIRST_ G = GET I = INST_ L = LENGTH_ N = NOT P = IS_PLVAR_O R = RIGHT ARGUMENT RS = REST_ S = I S_SQVAR._O T = TERM TS = TERMS V = IS_VAR_O / VOID Y = EMPTY SEQUENCE

SIMPLIFICATION OF ISDEF DSI

DSI--V ISDEF( VOID, O) <->

false >-<

[O] = USERSHOWN[O] Z~ DEFINED[O] ~ KIND[O] = operator

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

DISTRIBUTION ON PREDICATE OF FILTER_/ FDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FDP-A--I)-TTS FILTER_I((I: instance) : bool;

ISDEF(_I, OPTOR(FIRST_TS(TSI) )) /h EOUAL_T(FIRST_TS(GET(_I, OPTOR(FIRST_TS (TS_._!I)) ) ), FIRST_TS(TS_~2) ) A EOUAL_TS(INST_TS(REST_TS(TSI), I), REST_TS(TS2))) (REL_INSTS_TS(TS__.!, TSZ))

<->

Page 451: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3.9 INSTANCE 443

JOIN_SET_SET( MK_ZING_I(ADD(VOID, OPTOR(FIRST_TS(TSI)), FIRST_TS(TS2))), FILTER_I((I: instance): bool; EOUAL__TS(INST_TS(REST_TS(TSI), I), REST_TS(TS2))) (P~L_INSTS_TS(REST_TS(TSI), REST_TS(TS2))))

FDP--A-NV--TTS FILTER_/((I: instance) : bool;

~IS_VAR_O(OPTOR(T_ll) ) A EOUAL_TS(INST_T(T_!I, _I), MAKE_TS(T__22) ) A EOUAL_TS(INST_TS(TSI, _I), TS2))

(REL_INSTS_TS(CONC_TS(MAKE_TS(TI), TSI), CONC__TS(MAKE_TS(T2), TS___22))) ---->

JOIN_SET_SET( FILTER_I((_I: instance) : bool; .IS_VAR_O(OPTOR(T_!I)) A

EOUAL_TS(INST_T(TI, I), MAKE_TS(T2))) (REL_INSTS_T(T_!I, T__22)), FILTER-/((_I: instance) : bool; EOUAL_TS(INST_TS(TS___!I, _I), TS2)) (REL_INSTS_TS(TS___!I, TS___22) ) )

FDP-AS-.TSTS FILTER_I((I: instance): bool;

IS_SOVAR_O ( OPTOR( FIRST_TS (S_)) ) A ISDEF ( I, OPTOR (FIRST_TS (S)) ) A if (EO_.N(LENGTH._TS(INST_TS(REST_TS(S_), _I)) + LENGTH_TS(INST_T(FIRST_TS(S_), !)),

LENGTH_TS(_T)) A LENGTH_TS(T) ge LENGTH__TS(INST_T(FIRST_TS(S), I))) V (LENGTH_TS(T) It LENGTH_TS(INST_T(FIRST_TS(S), _I)) A IS_Y_TS(T))

then EOUAL_TS ( INST_T (FIRST_TS (S), I),

GET_FRONT_TS(T, LENGTH_TS(INST_T(FIRST_TS(S), _I)))) A EOUAL_TS ( INST_TS (EEST_TS (S_), I),

GET_REAR_TS(T, LENGTH_TS (INST_TS(REST_TS(S), I) ) ) ) else

false endif) (P~EL_INSTS_TS(S, T))

---->

FUSE_SET_SET ( FILTEP~_I( (_I: instance) : bool; IS_SOVAI~O(OPTOR(FIRST_TS(S) ) ) A

ISDEF(_I, OPTOR(FIRST_TS(_S))) /~ EOUAL_TS(INST_T(FIRST_TS(S_), I), GET_/~ONT_TS(T, LENGTH_TS(INST_T(FIRST_TS(S), _I)))) )

(REL_INSTS_TS(MAKE_TS(FIRST_TS(S_)), T)), FILTER_/((_I: instance): bool; EQUAL_TS(INST_TS(P~EST_TS(S), I),

GET_REAR_TS(T, LENGTK_TS(INST_TS(REST_TS(S_), I) ) ) ) ) (REL_INSTS_TS(P~EST_TS(S), T) ), s_, LENGTH_TS (T))

FDP-A-S-TTS FILTER_I((I: instance): bool;

IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(_T)) A (~IS_Y_TS(GET(I, OPTOR(~))) A ~IS_Y_TS(TS) ~ EQUAL_T(FIRST_TS(GET(!, OPTOR(T_))), FIRST_TS(TS)) ^ EQUAL_TS(REST_TS(GET(I, OPTOR(T))), REST_TS (flET_F~ONT_TS (TS, LENGTK_TS (GET(I, OPTOR(T) ) ) ) ) ) ) )

(EEL_INSTS_TS(MAKE_TS(T), TS) ) <-> if IS_SQVAR_O(OPTOR(T) ) A -IS_Y_TS(TS) A FITS(OPTOR(T), MAKE_TS(FIRST_TS(TS) ) ) then

COMBINE_I(ADD(VOID, OPTOR(T), MAKE_TS(FIRST_TS(TS))),

Page 452: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

444 V.3 Rules for data types and computation structures

FILTER_I((!: instance): bool; IS_SOVAR_O(OPTOR(!)) A ISDEF( L OPTOR(!)) EQUAL_TS(GET(L OPTOR(~)), GET_FRONT_TS(REST_TS(TS), LENGTH_TS(GET( L

OP~OR(~)))))) (REL__INSTS_TS(MAKE_TS(T), REST_TS(TS))))

else EMPTYSET_I endif

F D P-~- -T 3 ~ FILTER_/((_~: ins tance) : bool;

EO~A~_TS(~NST_TS(FIRST_~S(S_), ! ) , FIRST~S(!)) ^ EOUAL~ ( INST_~S (~ST_~S (S_), ! ) , REST_~S ( ! ) ) )

(RELjNSTS_~S(S, ! ) ) <-> JOIN_SET_SET(FILTER_I((I: instance): bool;

EOUAL_TS(INST_TS(FIRST_AS(S_), _I), FIRST_AS(T))) (REL_/NSTS_TS(FIRST_AS(S_), FIRST_AS(T))), FILTER_/((I: instance) : bool; EQUAL_AS(INST_AS(REST_AS(S), I), REST_AS(T) ) ) (REL_INSTS__AS(REST_AS(S), REST_AS(T)) ) )

======================================================================================

sIMPLIFICATION OF FILTER_/ FSI

FS I - S - ~ YG--TS FILTER_~((I: ins tance) : bool; IS_SOVAR_O(OPTOR(T)) A ISDEF(I, OPTOR(_T))

ISJ_TS(GET(!, OPTOR(T) ) ) ) (REL_~NSTS_TS(M~_TS(T), T~) ) <-> i f IS_SOVAR_O(OPTOR(T)) then ADD(VOID, OPTOR(T), EMPTY_TS) e l se EMPTYSET_I endi f

CONVERSION OF GET GCV ======================================================================================

GCV--/-T GET(I, OPTOR(_T)) --> INST_T(_T, I)

INST_ I

INST_T (T_, !) <-> if IS_VAN_O(OPTOR(_T) ) then i f ISDEF(I, OPTOR(T)) then GET(I, OPTOR(T)) e l se MAKE_TS(_T) end i f e l s e MAEE_TS(MAKE_T(OPTOR(T_), INST_AS(ARGS(T), I) ) ) end i f

I-TS INST_TS (_S, _I) <-> i f IS_Y_TS (S_) then EMPTY_TS e l s e CONC_TS(INST_T(FIRST_TS(S_), I ) , INST_TS(REST_TS(S_), I ) ) end i f

Page 453: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3.9 INSTANCE 445

COb94UTATIVITY OF INST ICY

I CY--FR-.AS FIRST_AS(INST_AS(S, ~)) <-> INST_TS(FIRST_AS(S), I)

ICY-.,P.S-.AS REST_AS(INST_AS(S, !)) <-> INST_AS(REST__AS(S), !)

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SIMPLIFICATION OF IS_Y IYSI

IYSI- . I - .AS IS_Y_AS(INST_AS(S, !)) <-> IS_Y_AS(S)

MAKE_T KT

//T-J-AS MAKE_TS(bIAKE_T(OPTOR(_T), INST...AS(ARGS(T), ! ) )) <-> i f IS_VAR_O(OPTOR(T) ) then MAKE_TS(MAKE_T(OPTOR(T), EMPTY_AS) ) else INST_T(T, I) endif

DIMINISHING OF REL_/NSTS RLDM

RLDM.-~--TS FILTER_/((I: ins tance) : bool; IS_VAR_O(OPTOR(FIRST_TS(S))) A

(~ISDEF(_I, OPTOR(FIRST_TS(S))) A EQUAL_TS(INST_TS(REST_TS(S), I ) , REST_TS(T)))) (REL_INSTS_TS(S, T) ) --> EMPTYSET_I

RLDM-.RSR--TS FILTER_/((I: instance): bool; P) (REL_INSTS_TS(S_, _T)) <-> FILTER~((I: ins tance) : bool; P) (REL~NSTS_TS(S, REST3S(T))) >-< -DI~Y in P_ A IA] = P[DV~IY for REST_TS(_T)] A -_T in _A

RLDM-T-AS FILTER_I((I: instance) : bool; -IS_VAR_O(OPTOR(TI)) a _P) (REL_INSTS_T(T_!I, T2)) <-> FILTER_I((_I: ins tance) : bool; -IS_VAR_O(OPTOR(T1)) A _P) (REL_~NSTS_AS(~S(~), A~S(T2)))

Page 454: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

446 V.3 Rules f o r d a t a t ypes and computa t ion s t r u c t u r e s

======================================================================================

SIMPLIFICATION OF HEL_INSTS RLSI ======================================================================================

R ~ I ~ Y - A S RELjNSTS~S(EMPTY~S, EMPTY.S) <-> MK_SING~(VOID)

RLSI--YY--TS REL_INSTS_TS(EMPTY_TS, _S) --> MK_SING_I(VOID)

======================================================================================

SUBSTITUTION SU

SU-.P-£~-G--TS

IS_PLVAR_O(O) A (ISDEF(I, O) A _A) ---->

IS_PLVAR_O(O) A (ISDEF(I, O) A B__) >-<

EC_] = AE1 for LENGTH_TS(GET(I, O))! [B_] = C_[MAKE_TS(FIRST_TS(GET(I, 0 ) ) ) for GET(I, O) ]

======================================================================================

END CATALOG INSTANCE ======================================================================================

~ ~ ~ m ~ m = ~ ~ ~ z ~ ~ ~ ~ ~ = ~

THIS CATALOG CONTAINS PARTICULAR RULES FOR THE SET FUNCTIONALS, WHICH ARE NOT CONTAINED WITHIN THE STANDARD CATALOG U. THE RULES CONCERN SETS OF INSTANCES. UU_I ======================================================================================

C = CONDITIONAL F = FILTERS H = ELSE-GUARD i: NUMBER OF THEN-BRANCHES

(SH_) il...ik: INDICES OF BRANCHES TO WHICH THE RULE APPLIES THE SHIFT, WHERE E: INDEX OF ELSE-BRANCH

T: SHIFTING TO ALL THEN-BRANCHES

DP = DISTRIBUTION ON PREDICATE NO = NOT OCCURS

SH = SHIFTING SP = SIMPLIFY BY PREDICATE

E = ELSE H = ELSE-GUARD P = PREDICATE T = THEN

A =AND F = FUNCTION APPLICATION FL -- FALSE FT = FILTER

N = NOT 0 = OR SA = SEQUENTIAL AND TR = TRUE

Page 455: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3 .9 INSTANCE 447

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SHIFTING IN CONDITIONAL CSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CSH-EE-FT if A then E1 else if B_

then E_22 else FILTER_I((I: instance): bool; P) (E) e n d i f

e n d i f <->

i f A t h e n E1 else if n

then E_22 else FILTER_I((I: instance) ; bool; -_A A _P) (E) endif

endif >-<

DETEI~MINATE [A~

CSH-~E-H2FT

if A then E1 else if B__

then E_22 else if C_

then E__33 DD_ then FILTER_I((!: instance) : bool; R) (_E) else E44 endif

endif e n d i f <->

if A then E1 e l s e i f n

t h e n E_/2 else if C

then E__33 0n then FILTER_I((_I: instance) : hool; -A A _H) ~E) else E_44 e n d i f

e n d i f e n d i f >-<

DETEI~MINATE[A~

CSH-ET-H2FT

if A then E1 else if n

then if

Page 456: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

448 V.3 Rules f o r d a t a t y p e s and compu ta t i on s t r u c t u r e s

then FILTER_I((I: instance): bool; R_!)(TI) ~S then FILTER_I((I: instance) : bool; R2) (T_22) else E_~3 e n d i f

e l s e E4 e n d i f

e n d i f

i f _A t h e n E1 e l s e i f B_

t hen i f C t h e n FILTER_I((I : i n s t a n c e ) : b o o l ; -A A R1) (T1)

then FILTER_I((I_: instance) : bool; ~_A A R2) (T_22) else E3 endif

else E4 endif

e n d i f y-~ DETEI~IINATE [A]

CSH-.ETF--TFT

t h e n E1 else if

t h e n F(X, if t h e n FILTER_I((! : i n s t a n c e ) : boo l ; P A R)(~) e l s e E2 e n d i f )

else E33 endif

e n d i f

i f _A t h e n E1 e l s e i f B_

t h e n F(_X, i f C_

e l s e E_3~ e n d i f

e n d i f >-< DETE~IINATE [A~

t h e n FILTER_I((I : i n s t a n c e ) : boo l ; ~A A P A Q)(E) e l s e E2 e n d i f )

DISTRIBUTION ON FILTER-PREDICATE FDP

FDP-C FILTER_I((I : i n s t a n c e ) : boo l ; i f B_ t h e n C_ e l s e D e n d i f ) ( E ) <-> i f B_ t h e n FILTER_I((I : i n s t a n c e ) : b o o l ; _C)(_E)

e l s e FILTER_I((I : i n s t a n c e ) : b o o l ; _D) (E) e n d i f

Page 457: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V. 3.9 INSTANCE 449

>-<

~! in B_ ^ DETEI~4INATE[B] ^ (EMPTYSETj E D E ==~ DEFINED~B])

FDP-H2-.ANA FILTER--I((I: instance): bool;

if A A B then D ~A ^ "~ then e l s e e n d i f ) ( E )

<-> ifAAB then FILTER_I((~: instance): bool; R)(E) U -hA-~ then FILTER_I((!: i n s t a n c e ) : bool ; S) (E) e l s e FILTER_I((!: i n s t a n c e ) : bool ; ! ) ( ~ ) e n d i f >-< -~ in A A -~ in B A DETERMINATE[A, B] A (EMPTYSET...I E D E ~ DEFINEDEA, B])

FDP-.O FILTER_I((I: instance): bool; _A v B_)(E_) <->

UNIONS(FILTER_I((!: instance) : hool; A) (E_), FILTER_I((I: instance) : bool; B) (E)) >-<

DETEI~MINATE[E]

NOT-OCCUltS-RULES FOR FILTER FNO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FNO-P FILTER_I((I: i n s t a n c e ) : boo l ; P) (E) ---->

i f P then _E e l s e EMPTYSET_I e n d i f >-< "! in P A DETERMINATE[P]

FNO-PSAA FILTER_I((!: instance): bool; _A A (B A C))(E) <->

if B then FILTER_If(I: instance): bool; A A C)(E) else EMPTYSET_I endif >-<

~! in B_ A (((~EMPTYSET_I E D E) ^ true =-D function (I: instance): bool; A) ::~ DEFINED[B])

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SIMPLIFY BY FILTER--PREDICATE FSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FSP-.$'L FILTER_/((! : i n s t a n c e ) : boo l ; f a l s e ) (E) - -> E~PTYSET_I >-< DEFINED[El

Page 458: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

450 V.3 Rules f o r d a t a t ypes and computa t ion s t r u c t u r e s

FSP--TR FILTER_I((~: instance): bool; true)(E) -~>

======================================================================================

SHIFTING IN ELSE-GUAR~ HiSH

H2SH--2-SA

then E1

then FILTER_/((I: instance): bool; R)(E) else E_22 endif <-> if t h e n E1

t h e n FILTER_I((I : i n s t a n c e ) : boo l ; B A R)(E) e l s e E2 e n d i f >-< DETERMINATE~B~

H2SH--T-2SA

if A then F(FILTER_I((I: instance) : bool; P_) (El), X_!l) ~B then G_(FILTER_I((_I: instance): bool; Q_)(E_22), ){2) else E__33 endif <-> if _A then F(FILTER_I((I: instance): bool; A ~ P)(E_!I), X_!l)

B_ then G_(FILTER_I((_I: instance): bool; B ~ Q__)(E_~2), X_22) else E33 endif >-< DETERMINATE[A, B~

H2SH--T-gA if _A then FILTER_I((I: instance): bool; P)(EI)

B_ then FILTER_I((I: instance): bool; ~)(E22) else E_33 e n d i f <-> if _A then FILTER_I((_I: instance): bool; _A ~ _P)(E_!I)

B_ then FILTER_I((I: instance): bool; B A Q)(E2) else E__33 e n d i f >-< DETERMINATE[A, B~

END CATALOG UU_I

Page 459: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.3.10 OPERATOR 451

3.10. OPERATOR

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

THIS CATALOG CONTAINS TRANSFORMATION RULES FOR THE CONSTITUENTS OF THE RESPECTIVE STRUCTURE OPERATOR OPERATOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CV = CONVERSION SH = SHIFTING

C = CONDITIONAL R = ELSE-GUARD (SUBSCRIPT-CONVENTION CF. UU_I) P = IS_PLVAR_O S = IS._SOVAR_O T = THEN-BRANCH V = IS_VAR_O

CONVERSION OF CONDITIONAL CCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CCV-II2--V-PS if IS_VAR_O(O) then E_! else E_22 endlf <->

if IS_PLVAR_O(O) then E1 D IS_SOVAR_O(O) then E1 else E2 endif >-<

DETERMINATE[O]

~ = = = = = = = = = = = = = ~ = ~ r ~ n = = m z = m ~ = = = ~ n ~ ` ~ r z : n ~ z . ~ = = ~ z ~ = ~ = ~ - ~ = = = = = = ~ = = ~ m = =

SHIFTING IN ELSE-GUARD HiSH

H2SH-.T-PS--V if IS_PLVAR_O (0) then F_l(A_l, if B_l then FILTER_/((I: instance): heel; P__!l)(E__!l) else C__!l endif) U IS_SOvAR_o(o) t hen F.~2(A2, i f B2 then FILTER__I((I: i n s t a n c e ) : b o e l ; P.22)(E_22) e l s e C2 e n d i f ) else D_ endif <->

if IS_PLVAR_O (_0) then F_!l(A_!l, if B_!l

then FILTER_I((I: instance) : bool; IS_VAR_O(O_) A P_!l) (El) else C_!l endif)

u Is_sovAR_o(o) then F_22(A2, if B__22

then FILTER_I((I: instance) : bool; IS_VAR_O(O) A P__22) (E2) else C~2 endif)

else D_ endif >-<

DETERMINATE[O~ A -I in O_

END CATALOG OPERATOR

Page 460: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

452 V.4 Technicaltransformation rules

4. Technical transformation rules

4.1. Abstraction rules

= ~ m m = ~ = ~ = ~ m ~ : : ~ : ~ m ~ = ~ z ~ z m ~ m ~ = ~ = ~ = ~ ~ = = = ~ m = ~ = ~ = = m m

THIS CATALOG CONTAINS ABSTRACTION RULES A

IN = INTRODUCTION NB = NESTED BLOCKS RM = REMOVAL

CONST = CONSTANT DECLARATION STAT = STATEMENT

m ~ m ~ m m m m ~ m m m m m m ~ m ~ : : ~ m m : ~ m ~ m m m m ~ m ~ m m m m ~ m m m m m m m m m m ~ m ~ m ~ m m m m m m m m m m m m m m ~ m ~ m m ~ m m m

INTRODUCTION IN

IN-~ONST

---->

begin const C: m = D; F end y-<

[D_] = USERSHOWN[D~ A DEFINED[D~ ^ [C~ = USERDEFINED[C~ A ~C in E A -C is_bound E_ ̂ -C in D A[m] -- USERDEFINED[m~ A D_ isof_submode m A IF] = E[C for D] ^ USED[D_I _c KNOWN[EJ

I N-S TAT

---->

begin statDECL; E end >-<

IstatDECL~ = USERSHOWN[statDECL~ A • = (DEFINED~statDECL] 0 USEDEE]) ^ USED[statDECLI c KNOWN[E~

REMOVAL RM

P~-NB begin const CI: cml = El;

begin const C2:cm2 -- E_22; E_33 end end <->

begin const CI: cml = El; const C2:cm2 = E_22; z3

end >-<

-([Cl] -- [CZl)

Page 461: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.4.1 A b s t r a c t i o n r u l e s 453

PM-NB5 begin const Cl: cml = El;

begin const C2:cm2 = E2; const C3:cm3 = E_33; const C4:cm4 = E4; const C5:cm5 = E5; const C6:cm6 = E~;

end end <->

begin const Cl: cml = El; const C2:cm2 -- E2; const C3:cm3 -- E33; const C4:cm4 -- E4; const C5:c~5 -- E55; const C6:cm6 = E_66;

end >-<

END CATALOG A

Page 462: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

454 V.4 Technica l t r a n s f o r m a t i o n r u l e s

4.2. Equalities

THIS CATALOG CONTAINS TRANSFORMATION RULES WHICH DESCRIBE GENERAL FOUNDATIONS OF LOGIC SUCH AS SUBSTITUTION, PROPERTIES OF EQUALITY, AND SO FORTH Q . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

EQ = EQUALITY SU = SUBSTITUTION

T = FUNCTION NOTATION OF (TYPE-DEFINED) EQUALITY

SY = SYNIMETRY

SUFFIXES FOR SUBSTITUTION: WITH RESPECT TO THE ARGUMENTS OF THE EQUALITY P~EDICATE MEANS 21 SUBSTITUTION OF SECOND ARGUMENT BY FIRST ONE

A = ^

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

EQUALITY IN FUNCTIONAL NOTATION EQT

EQT-S Y

EOP(X1, X2)

EQP(X2, Xl) >-< I_m] = USERDEFINED[_m] ~ KIND[Xl] = m ^ IS_EQUAL..PRE~EQP, m]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SUBSTITUTION WITH FUNCTIONAL NOTATION OF E~UALITY SUT = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SUT-.21A EQP(~ , X2) ^ E_ - -> E Q P ( ~ , X2) ^ E >-< [m] = USERDEFINED[m] A KIND[Xl] = m A IS_EQUAL_PRE~EQP, m__] A ~NEWPARI] = USERDEFINED~NEWPARI] /~ ~NEWPAR2~ = USERDEFINED~NEWPAR2} /X NEWINEWPAR1, NEWPAR2] h [fi_] -- E~NEWPAR1, NEWPAR2 f o r Xl, X2] a ASSERT[begin f u n c t i o n PP (NEWPARI: m; NEWPAR2: m_): bool ; G;

Y (h: m; B: m II EQP(A, B)) II PP(A, B) ¢=> PP(A, A) end] ^ [_F] = EIX1 f o r X2]

END CATALOG Q

Page 463: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.4.3 Change of recursion 455

4 . 3 . Change o f r e c u r s i o n

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

THIS CATALOG CONTAINS COMPLEX TRANSFOI~MATION RULES FOR CHANGE OF RECURSION R = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

CV : CONVERSION FR = FUNCTION REVERTING FU = FUSE OC : OPERAND CO~4UTATION RB : RE-BRACKETING

C : CONDITIONAL CE : CONSTANT EXPRESSION R : RECURSION W : WHILE-LOOP TP : TUPELING

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

CONVERSION CV

CV-.R--W--.! b e g i n

f u n c t i o n G_ (X: rex): f u n c t i o n (ms) n s ; (S: ms) : n s ; if B_ then E else G_(F_!)(F2) where const C: mc : F endif;

G_( A._XX ) < A.._SS) end - - - - >

b e g i n (var V_/X: ~_~_, var VS: ms) :: (A_/X, AS); v a t VC: mc; while -B_BB l o o p

v~ := LF; (VX, V.._SS) :: (FF1, FF__22)

endloop; E E

e n d >-< ([V X] : USERDEFINED[VXX] A [V_SS] = USERDEFINED~V_SS] A ~VC] : USERDEFINED~V__q]) A ~W[VE, V__SS, VC] A ~BB] : B__[VX, V_SS f o r X_, S__] A E~_E] : E V ~ , V_SS f o r _X, S ] A [[FF] : FiVX, V S f o r _X, S ] A [FF__!] : F_!liVX, V_SS, VC f o r X, S, C_] A [FF2] = F2 V[~, V_SS, V CC fo r X, S, C_]

CV-~-M-3 b e g i n

f u n c t i o n G (Xl : ml; X_~2: m2; X3: m3): r ; i f B t h e n E e l s e G(A1, A2, A__33) e n d i f ;

G_(F1, F2, F3) e n d

b e g i n ( v a r VXh m l , v a r VX_22: ~_ , v a r VX3: m3) := (F1, F2, F 3 ) ; w h i l e -BB l o o p

(VXl, VX._~2, VX3) := (AA..__ll, AA2, AA3) e n d l o o p ; E__~E

end

Page 464: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

456 V.4 Technica l t r a n s f o r m a t i o n r u l e s

>-< ([VXI] = USERDEFINED[VXI~ A [VX2] = USERDEFINED[VX2] A [VX3~ -- USERDEFINED[VX3}) NEWIVXl, VX2, VX3] A EBB] = B_[VXl, VX2, VX3 fo r Xl, X2, X3] ^ [AAII : AliVX1, VX~, ~ fo r Xl, X2, X3] A [AA2| -- A2[VXI, VX2, VX3 for XI, X2, X3] A [AA3] = A3[PX1, VX2,, V X3 for X1, X2, X3] A z[E~] : ~_[VXl, vx2, vx3 fo r X1, X2, X3]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

FUSE FU

EU--TP3-.C f u n c t i o n _F (PI: ml; ~ : m2; P3: m3; P 4 : m 4 I{ PC): r ;

CONS(F~(P~, P2, P3, P4), F2(PL P2, P~, P4), ~ (P1 , P~, P3, P4)) <-> f u n c t i o n NEWFUNCT (P_!: ml; P2: m2; PS: mS; P6: ~ ; P7: m7; P3: m3; P4: m4): r ;

i f E_ then CONS(O1, 02, 03) e l s e N~F~CT(N1, N2, NS, N6, N7, N3, N4) end i f ; f u n c t i o n _F (P_!: ml; P2: m2; P3: m3; P 4 : m 4 I{ PC): _r;

NEWFUNCT(M_II, M2, M55, M66, M7, M__33, M4) >-<

[function F1 (Pl: ml; P_22: m2; P3: m3; P4:m4 H PCF1): rl; beg in

f u n c t i o n G1 (PI: ml; P_22i m2; P5: m_55; P3: m3; P4: m4): r l ; if E_ then 0~i else GI(N1, N_22, N~5, N_33, N4) endif;

~(m, M~, MS, ~, m) end~ = USERSHOWN[DEFFI~ A

[function F2 (Pl: ml; P22: m_22; P_33: m_33; P_44:m4 II ~F2): r_22; begin

function G~2 (P_~I: ml; P_22: m_22; P_66: m_66; P_33: m_33; P~4: m4): r_22; if E then 0_22 else G2(NI, N_22, N6, N_33, N_44) endif;

02(~_!1, M~, m~, ~, m) end] = USERSHOWN[DEFF2] A

[ f u n c t i o n F3 (PI: ml; P2: m2; P3: m3; P 4 : m 4 H pCF3): r3 ; beg in

f u n c t i o n ~3 (PI: ml; P_22: m2; P_77: m_7.7; P_33: m3; P 4 : m 4 I I PCG3): r3 ; i f E_ then 0_33 e l s e 03(N1, N_22, N_ff.7, N_33, N~4) end i f ;

~(m, M2, ~_ZT, M~3, m) end] = USERSHOWN[DEFF3] A ~PS__ in E_ A -P_66 in E A -P7 in E A

|NEWFUNCT] = USEEDEFINED[NEWFUNCT] A DETE~4INATE[M1, M2, M3, M4, N1, N2, N~3, N4~

OPERAND COt~UTATION OC

OC-/ f u n c t i o n _F (_P: f u n c t i o n (m_) b; _H: f u n c t i o n (_m) n) : f u n c t i o n ( r ) _s; (P~: r ) : _s;

some SS: s II EQ_S (S_SS,

i f E1 then CO e l s e

i f B2 then PH(E_, _F(P, tt)(K1)) e l s e _F(P, H)(K2) e n d i f where cons t X: u = D

end i f ) <-> f u n c t i o n F (P: f u n c t i o n (m_) b; _H: f u n c t i o n (m) n ) : f u n c t i o n (_r) s_; (RR: E): s ; beg in

f u n c t i o n G_ (Z_: s_): f u n c t i o n (E) _s; (RR: _r): ~;

Page 465: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.4 .3 Change o f r e c u r s i o n 457

s o m e SS: s I! EO_S(SS,

i f B_! t h e n Z e l s e

i f ~_~ t h e n 6(~_~(E_, _Z))(K1) e l s e _G(Z)(K2) e n d i f where c o n s t X: u : D

e n d i f ) ; fi(co) (RRR)

er~d >-< ( [ f i ] = USERDEFINED[Gj ^ [Z] = USERDEFI~DfZ]) A -R_RR i n CO ^ ~ W [ [ , C_] ^ ~SERT[~O_S(P~(A, ~ ( B , Y)), ~ ( B , P~(A, Y))) = t r u e ]

RE-BRACKETING RB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RB-2 function F (PI: ml; P2: m2): r; if _B then E_ else C(A, _F(AI, A2)) endif

function F (Pl: ml; P2: m2): r; begin

function NEWFUNCT (PI: ml; P2: m2; NEWPAR: r): r; if B then NEWPAR else NEWFUNCT(AI, A2, C_(NEWPAR.., _A)) endif;

NEWFUNCT(P1, P2, E) end >-< ASSERT[C(X, C(Y, Z)) : C(C(X, Y), Z)] A ASSERT[C(X, E) : C(E_, X)] ^ [NEWFUNCT] : USERDEFINED[NEWFUNCT] ^ [NEWPAR] -- USERDEFINED[NEWPAR] NEW[~W~UNCT, NEWPAR]

RB-CE4 f u n c t i o n F (PI : _m; P2: _m; P3: m3; P 4 : m 4 II PC): _r;

i f EOP(P1, A) t h e n B_ e l s e C(_F(P1, A, P3, P4) , B) e n d i f

f u n c t i o n _F (PI : m; P2: m; P_~3: m3; P 4 : m 4 }1 PC): _r; b e g i n

f u n c t i o n NEWFUNCT (PI: m; P2: m_; NEWPAR: _r; P3: m3; P4: m4): r ; i f EOP(P1, P2) t h e n NE~AR

e l s e NEWFUNCT(P1, A, C(B_, NEWPAR), P3, P4) e n d i f ;

~WFUNCT(~, A, B_, ~ , ~ ) end >-< ASSERT~C(X, C(Y, Z)) : C(C(X, Y), Z)] A ~NEWFUNCT] : USERDEFINED~NEWFUNCT] A [NEWPAR] : USERDEFINED[NEWPAR] A NEW~WFUNCT, NEWPAR]

END CATALOG R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 466: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

458 V.4 Technical transformation rules

4.4. Unfold, fold, and renaming

=========================================================================================

THIS CATALOG CONTAINS TECHNICAL TRANSFORMATION RULES, SUCH AS UNFOLD, FOLD, OR RENAMING F

AB = ABSTHACTION AL = ALPHA CONVERSION APPL = APPLICATION BECON = BETA CONVERSION DP = DELETE PRECONDITION F = FOLD, FUNCTION IN = INTRODUCTION IP = INTHODUCE PRECONDITION SP = SIMPLIFY ON ACCOUNT OF PRECONDITION UF = UNFOLD

A --

CO -- E = IA = IAT --

R

W =

APPLICATION CONST DECLARATION EXPHESSION/EXISTENTIAL QUANTIFICATION IN APPLICATION IN APPLICATION WHERE THE FUNCTION DEFINITION IS IN THE., STYLE OF ALGEBRAIC TYPES RESTRICTED DOMAIN WHERE EXPRESSION

RULES FOR FOLDING FUNCTIONS ABBREVIATIONS: FFN = FOLD FUNCTION WITH ARITY N

FF_FN_FM = FOLD FUNCTION WITH N FUNCTION PARAMETERS AND M FUNCTION RESULT

FLA = FOLD LAMBDA ABSTRACTION FPFN = FOLD PARTIAL FUNCTION WITH ARITY N

RULES FOR UNFOLDING FUNCTIONS ABBREVIATIONS: UFFN = UNFOLD FUNCTION WITH ARITY N

UFPFN = UNFOLD PARTIAL FUNCTION WITH ARITY N UFF_FN_FM = UNFOLD FUNCTION WITH N FUNCTION PARAMETERS AND M FUNCTION

RESULT UFPFAPCN = UNFOLD PARTIAL FUNCTION AND PRECONDITION WITH ARITY N

FHP_DID2 : FOLD HIGHER-ORDER PROCEDI/RE WITH ARITY n; Di IS THE LIST OF THE DESCRIPTIONS FOR THE PARAMETERS: O: OBJECT-PARAMETER Pi: PROCEDURE WITH ARITY i

Ai: ABSTRACTION WITH ARITY i Fi: FUNCTION WITH ARITY i V: VAR-PARAMETER

FPN_nln2: FOLD PROCEDURE WITH AHITY n; I <= ni <= n IS THE LIST OF var-PARAMETERS

FPPN_nln2: FOLD PARTIAL PROCEDURE WITH ARITY n; I <= ni <= n IS THE LIST OF var-PARAMETERS

ABSTRACTION AB

---->

((X: m): n; ~)(~)

Page 467: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.4.4 Unfold, f o l d , and renaming 459

>-<

~jX] = USERDEFINED[_X] AIm] = USERDEFINEDIm] A e_n] = USERDEFINEDI_n] A E_ isof__submode _n A [G_] = USERSHOWNIG_] A DEFINEDIG_] A

G isof_submode m h ~[~_W] = USERDEFINED[NEW] A -([NEW] = e_X]) A IFF] = E_[NEW for G_] A -X in FF A IF] = FFIX for ~NEW]

AB-21 F <->

(_x: m): n; £(_x) >-<

[X~ = USERDEFINED[_X~ A [m~ -- USERDEFINED[m] A

[_n] = USERDEFINED[_n] A KIND[F] = function(m)n A -_X in E

ALPHA-CONVERSION AL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

AL-AB (X: m): n_; ---->

(_Y: m): n; _F > - <

a'_Y] = USERDEFINED[Y] A NEWIY~ A IF] = E_[Z f o r _X]

AL-AR V (_X: m II PI) iI P2

y (Y_: _m , Q_I) " 02 >-<

[Y_] = USERDEFINED[_Y} /~ NEW[_Y] A [Ql] = PI[_Y for X_] A [Q2] = P2[_Y for _X]

ALE 3X: mIIP -->

::{Y: m{lO >-<

[Y]] = USERDEFINED[_Y] Z~ NEWLY] A [ 0 ] = P_[[Y f o r X]]

AL-ER 3 (x_: m, Pl) n P2 _->

3 (Y: __m It 01) , o_22 >-<

[Y~ = USERDEFINED[Y~ A NEW[Y~ A [QI~ = PI[_Y for _X~ A [Lg_~ = P2[Y for X~

APPLICATION APPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

APPL--/

((~: m): n; E)(fi)

Page 468: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

460 V.4 T e c h n i c a l t r a n s f o r m a t i o n r u l e s

- -> _E >-< DEF_J)ET[G_] A G_ isof_submode m A [E] = F[q for X_]

======================================================================================

BETA CONVERSION BECON

BECX)N ((_X: m_): n; E)f_X) <->

E >-<

[X~ = USERDEFINED[X~ Z~ DEF_DET[X~ A {_X} ~_ KNOWNEE_] ^ [m] = USERDEFINED[m] a _X isof_submode m A In] = USERDEFINED[n] A E isof__submode n

~ = ~ z ~ = ~ = ~ ~ = ~ = = m = = ~ ~ m ~ m ~ m ~ ~ = ~ = ~ = ~

DELETE PRECONDITION DP

DPIA2 if PC____AA then F(P1, P2) endif ---->

F(PI, P2) >-<

[function _F (PF___!I: ml; PF2:m2 H P CC): _n; E_FF] = USERSHOWN [statDF] [PCA] = P__qC[P_!I, P_~2 for PF__!I, PF2]

DPIATI if PCA then F(P1) endif

F(P1) >-< [function F: function (PFI: ml II P_CC) _hi = USERSHOWN [statDF] A [PCA] = PC[PI for PF1]

FOLD F

FA1 (P: m): n; E ---->

>-<

[function _F(PF: _m): n; EF11 = USERSHOWN[statDF~ A EF[P for PFI = rE~

FF-,F2-..F1 E

F(m, P2) >-<

[ f u n c t i o n F (PFI: f u n c t i o n ( m l ) m2; PF2: f u n c t i o n ( m 3 ) m4): f unc t i on (mS) m6; EF] = USERSHOWN[statD F~ A

[EJ = EErie, ~ for PFI, PF2] A (DEFI~D[E~ ~ DEFI~D[E(~, ~)3)

Page 469: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.4.4 Unfold, f o l d , and renaming 461

FF3 E_

F(P1, P2, P3) >-< [function _F (PFI: ml; PF2: m2; PF3: m3): n; EF] = USERSHOWN[statDF] A EF[PI, P2, P3 for PFI, PF2, PF3] : [E_] a (DEFINED[El :~ DEFINED[F(PI, P2, P3)])

FPF3

E(P_I, P2, F3) >-< [ f u n c t i o n F (PFh ml; PF2: m2; PF3 :m3 tl PC): n; EF] = USERSHOWN[statDF] A EF[P_!, P2, P3 f o r PF1, PF2, PF3] : [E_] A PC[P1, P2, P3 f o r PF1, PF2, PF3] : [ ~ ] A ASSERT[NPC] A <DEFINED[El ~ DEFINED[F(PI, P2, P3)])

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

FOLD HIGHER ORDER PROCEDURE FH ======================================================================================

FHP3-A1 P1V s t a t s ---->

c a l l P((XI: m l l ) : m12; PE1, P2, P3) >-< [p rocedure P (PFI: f u n c t i o n ( m l l ) m l 2 ; PF2: p r o c e d u r e ( v a r m21); va r PF3: m3);

statSP] : USERSHOWN[statDP] A [stats_] = statSP[((Xl: mll): m12; PEI), P2, P3 for PFI, PF2, PF3 A IS_VAR_KIND[P3] ^ (DEFINED[stats_] ~ DEFINED[call P((XI: mll): m12; PEI, P2, P3)])

FOLD PROCEDURE FP

FP3-3 stats

call P(PI, P2, P_33) >-< [procedure P (PFl: m_!l; PF__~2: m2; var PF__33: m3); statS P] : USERSHOWN[statD_PP] A [s tats_] : statS~P[P1, P_22, P/3 f o r PF__!I, PF2, PF__33 A IS_VAR_KIND[P3] A (DEFINED[statS] ::> DEFINED[call P(PI, P__22, P__33)])

FPP3--I statS_ ---->

call P(P1, P2, P_33) >-< [procedure _P (var PF_!I: m l; PF_22: m2; PF3:m3 II PC); statSP] : USERSHOWN[statD_PP] A [statS] : statSP[2_!, P_22, P_33 for PF1, PF2, PF__33 A [.~_q] = PC[P1, P22, P_33 for PF__!, PF_22, PF__33]] A ASSERT[NPC] A IS_VAR_KIND[P..fl] A (DEFINED[stats_] ~ DEFINED[call P(PI, P2, P3)])

Page 470: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

462 V.4 Technical t r a n s f o r m a t i o n r u l e s

INTRODUCTION OF CONST DECLARATION INCO

INCO-W

begin E where const C: m = D end >-< [D_] = USERSHOWN[D] A DEFINED[D] A [ C ] = USERDEFINEDIC] A -C in F h -C_ is_bound F ^ -C in D h [m_] = USERDEFINED[m_] A D isof_submode _m A [E_] = F[C_ for D_] A USED[D] c KNOWN[F]

INTRODUCE PRECONDITION IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IP-F4 f u n c t i o n H(XI: m_~l; X_22: m2; X33: m__33; X_44: m4): n; i f B t h e n E e n d i f <-> f u n c t i o n H(XI: re_l; X_22: m2; X~3: m_33; X 4 : m 4 II 13): n_; E_

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SIMPLIFY ON ACCOUNT OF PRECONDITION SP

SP2 f u n c t i o n F ( P h ml; P 2 : m 2 II PC): n__; E_

f u n c t i o n _F (LI: ml; P2: ~___ H PC): _n; D_ >-<

[D_] = E_[true f o r PC]

SP3 f u n c t i o n F (P.!: re_l; P_/2: m2; P 3 : m 3 , P_q): n; i f E0(X, Y) t h e n E1 e l s e E~2 e n d i f - - - - >

f u n c t i o n F (P/l: re_l; P_22: m2; P 3 : m 3 }! PC): n_; i f E_Q(_X, _Y) t h e n D_! e l s e E_/2 e n d i f >-< IS_CONGRUENCE[EQQ] ^ [PC__NN] = P_CCEY for _X] A [DI] = El[true for PC N~

UNFOLD UF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UFF.-F2-F1 E(Pt , ~ )

>-< DEF_DET[P1, P2] ^ [ f u n c t i o n E (PFI: f u n c t i o n ( m 1 ) m2; PF2: f u n c t i o n ( m 3 ) m4): f u n c t l o n ( m 5 ) m6; ~ ] =

USERSHOWN[statDF] a [E ] = EF[P1, P2 f o r PF1, PFZ]

UFF3 £(P1, P~, P~)

Page 471: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

V.4 .4 Unfold , f o l d , and renaming 463

- -> E~ >-< DEF_DET[PI, P__22, P__33] A [function _F (PFI: ml; PF2: m2; PF3: m3): n_; EF] = USERSHOWN[statDF] A [E] : EF[PI, P2, P3 f o r PF1, PF2, PF3]

UFPF3 £(P_!, P2, P3)

E >-(

DEF_DET[PI, P_22, P33] A [function F (PFI: ml; PF2: m2; PF3:m3 II PC): n; EF] =

USERSHOWN[statDF~ A [NPC] = PC[P1, P2, P3 for PFI, PF2, PF3] A ASSERT[NPC~ ^ [E_ 1 = EF P ~ , P2, P3 for PF1, PF2, PF3}

UNFOLD CONST DECLARATION UFCO

UFCO-CO4-E begin

const Cl: ml = DI; const C2:m2 = D22; const C3:m3 = D3; const C4:m4 -- D_44; s!

end ---->

s2 >-<

DEF_DET[D_!I, D2, D_33, D41 ^ [H2~ = D2[DI for CI~ a If{31 = B3[BI, H2 for CI, C/Z] A [H4~ -- D4[DI, }12, H3 for CI, C2, C3~ A [$2~ = S_!l[D_!l, H_22, H_33, H_44 for C_!l, C_~2, C_33, C4]

UFCO-W begin E_ where const C: m = D end --> F >-< DEF_DET[D_] A [_F] = E_[D for C~

UFCO-W2 begin E where const (CI: m/l, C2: m2) = (DI, D2) end

_F >-<

DEF_DET[DI, D2] ^ IF] = E_[DI, D2 for CI, C2]

END CATALOG F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 472: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

PART V I

A SAMPLE INSTANTIATION OF THE SYSTEM FOR A CONCRETE LANGUAGE

This part is intended to show how the abstract system described so far has to be extended to allow handling a concrete object language. I t also serves as the second part of the validation of the specification given in Part I I I , since i t demonstrates that the operations introduced there suffice indeed for coping with a concrete language. In order to keep the treatment surveyable, we have chosen a narrow subset of the language CIP-L consisting of the essential deterministic and algorithmic constructs of the applicative sublanguage of CIP-L.

We first give the abstract syntax of the language by detailing the type LANGUAGE; moreover, we give translation functions between an ALGOL-like concrete and the abstract syntax. In addition, we define a number of attributes and syntactic functions as well as semantic predicates. Finally, we show how the attribute propagation rules as well as the transformation rules listed in Part V can be translated into valid inferences of the system, thus providing a basic stock of catalogs of inferences for our language. By the way, an interpreter for a superset of this language has been given in [Bauer et al. 81].

Page 473: The Munich Project CIP: Volume II: The Program Transformation System CIP-S
Page 474: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

467 VI. I The basic objects and operations of the language

1. The basic objects and operations of the language

The language is defined relative to a universe of basic objects and operations. The properties of these basic entities are specified by the following type UNIVERSE. The sorts obj and opr comprise the basic objects and operations, resp. The distinct objects T and F serve as representations of the boolean values 1~ue and false.

m ~ Fm-i-~--~l sort F~-7 ,

FCl : ~ , f-u~im ~ ( obj ; ~ ) : ~oI ,

imlude EQUIVALENCE(obj, eq-obj) ,

l a s T ~ F ,

function ~ ( opr ; ~r ) : ~I ,

include EqdlVALENCE(opr, eq-opr)

We next give a type MODE specifying operations for obtaining mode information about basic objects and operations. We have the sort rode of identifiers for modes of objects; there should be at least the identifier bool-nw~e for the set of the boolean values.

basedon UNIVERSE ,

sort ~ , F ~ : iBde , fLmctim F e - - ~ (nde ; K l e ) : b ~ ) l ,

include EQUIVALENCE(~, eq-mde) ,

function ~ ( ob~ ) : rode,

l a~ obj-mde(T) i bool-mde , obj-mde(F) m b o 0 1 ~ ,

Page 475: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

468 VI.1 The basic objects and operations of the language

basedm ( I - ~ , -.- ) " ~qU(mde, eq~e) ,

fu~tim I - ~ - ~ ( ~r ) : ~L~, fimctim I - ~ (mr):redes

2. Abstract syntax: The type LANGUAGE

Before giving the abstract syntax of the language we also provide a grammar in extended BNF for the (ALGOL-like) concrete syntax. The grammatical expression <e//t>* stands for a new nonterminal <et> with the productions

<et> : : : ~I <et +> <et+> ::= e I e t <et+> •

Thus each string in the language generated by <et> is a (possibly empty) sequence of e's separated by t 's.

The axiom of the following grammar is the nonterminal <exp>. <exp> ::= <idf> I

<obJ> I <opr> I [ ~xIp ] ( <<exp>ll,>* ) I i f <exp> them <exp> else <exp> f i I ( <<exp>//,>* ) I F<<d~>//,>* ; ~xp>]

<dec> ::= f ~ <idf> • <abs>

<abs> ::= ( <prs> ) ( <<knd>//,>* ) : <exp>

<prs> : := <<par>//,>*

<par> ::= <knd> : <idf>

<knd> ::= <rode> i

( <~nd>//,>* ) I ( <<knd>//,>* ) ( <<knd>//,>* )

The nonterminal <idf> (program identifiers)

is supposed to be defined elsewhere within a type IDF, whereas <obj> (primitive objects) <opr> (primitive operators) <rode> (mode identifiers)

correspond to the sets d~i, opr, and rode as given by the types UNIVERSE and MODE.

Page 476: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

VI.2 Abstract syntax: The type LANGUAGE 469

From this grammar the abstract syntax is obtained in the following w~y: - For each nonterminal <xyz> we introduce a sort identifier xyz (however, the aux17iary nonterminals

associated with the repetition construct < / / > * are dealt with separately). - For every (variant of a) production

<xyz> :: : tO <xl> t l ... <xn> tn with (possibly emp~) terminal strings ti and nonterminals <xj> we introduce an operator with argument sorts xl ... xn and result sort xyz. I f <xj> is a re~lar nonterminal, the corresponding argument sort will be plain; i f i t is an aux17iary nonterminal for a repetition construct, the argument sort will be of variant sequ.

As additional auxlTiary nonterminals we introduce <sti> and <sqi> (set and sequence of identifiers) with the productions

<sti> ::= { <<idf>//,>* } I ( <<sti>//U >* )

<sqi> ::= <<idf>//,>* •

Within the type SORT the sort identifiers are specified as follows:

Next, since every operator also has a name, we need to specify these names. Every object or mode identifier in a program as well as every basic object or operator ~nTl give rise to a unique operator name. This is modelled by unary records for these cases, the components of which are precisely the original entities occurring in pFograms. SinnTarly, each variable or indeterminate for a syntactic class as well as each meta-operater leads to a unique operator identifier. We assume that in the concrete representation these identifiers already indicate the argument and result sorts of the corresponding operators in a suitable w~v; we include operations yielding these entities. Incorporating variables and indeterminates into the syntax amounts to adding a production

<xyz> ::= <~yzvar> I <xyzind> for every (regular or aux17iary) nonterminal <xyz>.

First we specify names for variables and indeterminates:

:

base~ SORT,

f ~ o . ~ ( ~m; ~m) : b~1 , i n c l ~ E@IVALENCE(wm, eq-vnm) , f.nctio. I-~-gzT~7 ( ~m ) : sort

based(m SORT,

flmcti(m ~ ( ibm ; ibm ) : b~l ,

Page 477: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

470 VI.2 Abstract syntax: The type LANGUAGE

include EQUIVALENCE(ira, eq-inm) , flz~-tien ~ ( inn ) : sort

endabsb-~-t1~pe

Moreover, for each n-a~ meta-operator mop a sensible functionali~ mop : x l x ... xxn --> x

gives rise to a grammar production <x> ::= tO<x1> t l ... <xn> tn

with certain terminal strings t i . For our language we have the additional productions <knd> ::= TYPE [F <idf> ]] I KINDF[<exp>ll <sti> ::= KNOWN [F <exp> ll I USED[F<exp>II <sqi> ::= IDSIT<prs>ll <exp> ::= SUBST[[<<exp>//,>*> for <sqi> in <exp>ll I <abs> : := DECLARATION IF <idf>

The meta-operators TYPE, KIND, KNOWN, USED, and DECLAP.ATION attach certain attributes with their argument terms. Of these attributes, KIND and USED are derived and TYPE, KNOWN and DECLARATION are inherited.

TYPE IFx~ gives the kind (as defined by the nonterminal <knd>) attached to x by its declaration ( i f anY). KIND computes the kind of an expression from the kinds of its subexpressions. KNOWN{Fcll gives the set of all identifiers that may be used within c (i.e. the scope of ~/aich contains c). USED[Fc]] gives all (non-local) identifiers which are used in c, i.e. which occur free in c. IDS[Fpsll gives the sequence of identifiers of a formal parameter l ist ps. SUBST is a substitution operator that replaces within its third argumeqt all occurrences of the identifiers in its second argument by the corresponding expressions in its f i rst argument. Finally, DECLAPJ~TIONIFx]] gives the abstraction named by x, i f any.

Now within the type OPERATOR, operator names are specified as follows:

basedon VNA/~Z, INANE,

~me test J is-idf-onn] ~ ~ : id f (eq-idf) endrecord ~est Jis-obj-onmI r-~=T~ ~ : ~ (eq-obj) endrecor(l ~ ]is-opr-onm] recomd ~ : opr (eq-opr) ~est l is-male-oral record ~ : m~ (eq~m~) end~-~ ~ ~ : n (eq-vnm) enm~ord I record ~ : inn (eq-inm) endrecor(l I

We now introduce the operators corresponding to the single productions, thus providing the type LANGUAGE. Again, object and mode identifiers as well as basic objects and operations are treated separately.

Page 478: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

VI.2 Abstract syntax: The type LANGUAGE 471

basedbn (]PERATOR, base~m IDF , base~ MOOE ,

[Ta fu ti mmtio. function

laws idf-op(i) - obj-op(o) - opr-op(f) - mde-op(m) -

( i : i d f ) : operator, ( o : obj ) : operator, ( f : o p r ) :qnera~ ,

prp(idf-onm(i), <>, plain(idf), @) , prp(obj-onm(o), <>, plain(obj), @) , prp(opr-onm(f), <>, plain(opt), @) , prp(mde-onm(m), <>, plain(m~e), @) ,

]aws idex-op = prp(idex-onm, obex-op -- prp(obex-onm, opex-op a prp(opex-onm, apex-op a prp(apex-onm, cdex-op ~ prp(cdex-onm, tpex-op ~ prp(tpex-onm, scex-op ~ prp(scex-onm, decl-op =- prp(decl-onm, abst-op -- prp(abst-onm, prsq-op = prp(prsq-onm, pmt-op - prp(pmt-onm, mdkd-op = prp(mdkd-onm, t~d-op - prp(t~kd-o~,

fckd-op = prp(fckd-onm,

stid-op = prp(stid-onm, unid-op m prp(unid-onm,

<plain(idf)>, plain(exp), <plain(obj)>, plain(exp), <plain(opr)>, plain(exp), <plain(exp), plain(tup)>, plain(exp), <plain(exp), plain(exp), plain(exp)>, plain(exp), <plain(tup)>, plain(exp), <sequ(dec), plain(exp)>, plain(exp), <plain(idf), plain(abs)>, plain(dec), <plain(prs), sequ(knd), plain(exp)>, plain(abs), <sequ(par)>, plain(prs), <plain(knd), plain(idf)>, plain(par), <plain(mde)>, plain(knd), <se~p(knd)>, plain(knd), <secN(knd), sequ(knd)>, plain(knd), <sequ(idf)>, plain(sti ), <sequ(sti )>, plain(sti ),

fx~LtiO, ~ ( i : into ) : ~ ,

1 ~ var-op(i) - vat(i, res-vnm(i), @) , ind-op(i) = ind(i, res-inm(i), @) ,

~) , @), @), @), @), @), @), ~) ~) ~) ~) ~)

~) ~) @>

Page 479: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

472 Vl.2 Abstract syntax: The type LANGUAGE

laws type-op kind-op knwmop used-op i d fs -op subs-op dcln-op

mop(type-onm, 1, plain(knd), @) , mop(kind-ohm, 1, plain(knd), @) , mop(knwn-onm, 1, plain(sti), @) ,

-- mop(used-ohm, 1, plain(sti), @) , -= mop(idfs-enm, 1, plain(sqi), @) ,

mop(subs-ohm, 3, plain(exp), @) , mop(dcln-onm, 1, plain(abs), @)

e n d ~ ~

3. Conversion between extern~ and in te rn~ form: Parser and unparser

We now give a recursive descent parser transfon~ing strings over the alphabet

L(<idf>) U L(<obj>) U L(<opr>) U L(<mde>) U L(<~zvar>) U L(<xyzind>) U { [, ], if, 1~em, else, mdif, , , ; , r ,J , ( , ) , fw dm, - , :, [, }, u, TYPE, KIND, KNOWN, USED, IDS, SUBST, DECLARATION, IT, II, for, in }

into terms as specified in the type TERM.

We represent the alphabet by the following mode S~mb:

t~pe ~b (eq-symb) --

idf-sy trust is-idf-sy record obj-sy test is-obj-sy record opr-sy test is-opr-sy record mde-sy test is-mde-sy record var-sy t~st is-var-sy record

basic-idf : idf (eq-idf) emdma:omd I basic-obj : ¢bj (eq-c6j) endrecord I basic-opr : opt (eq-opr) erldrecord I basic-rode : rode (eq-mde) e n d ~ I var-id : vnm (eq-vnm) endrecord I

ind-sy test is-ind-sy record ind-id : ibm (eq-inm) ~mdrec~ I Ib-sy I rb-sy I if-sy I th-sy I el-sy I fi-sy I cm-sy I sc-sy I bg-~ I ed-sy I Ip-sy I rp-sy I fc-sy I df-sy I co-sy I Ic-sy I rc-sy I un-~y I t~-sY I ki-sy I kn-sy I us-sy I id-sy I sb-sy I dc-~y I Im-sy I rm-sy I fr-sy I in-sy

Page 480: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

VI.3 Parser and unparser 473

Sequences of symbols are obtained by the following instantiation:

base(inn (~ml)s, isy-ss, eq-symbs, ...) ~ SEQU(symb, eq-symb) .

We forego the definition of a scanner that transforms strings of characters into ~yml~.

To give an example, the expression

i f T 1~hen F else [V](x#) en{lif

would be transformed into the

<if-sy, obj-~(T), th-sy, obj-sy(F), el-sy, Ib-sy, opr-sy(V), rb-~, Ip-sy, idf-sy(x), cm-sy, idf-sy(y), rp-sy, fi-~>

which would be parsed into the following term (in which m~e-t(op, <ts1,...,tsn>) is abbreviated to op[tsl ..... tsn]):

cdex-op[<obex-op[<obj -op(T) [ ]> ]>, <obex-op[<obj-op(F)[ ]>]>, <apex-op[<opex-op[<opr-ol)(V)[]>]>,

<idex-op[<idf-op(x) [ ]> ], idex-op[<idf-op(y) [ ]> ]> ]>]

which, in tree form, may be depicted as

cdex-op

cbex-op obex-op

jT(T ) T obj-op(F)

apex-op

Fl -F1 T ....

opex-op idex-op idex-op

T ,df x) T opr-op(V) " - idf-op(y)

We need the following aux17iary functions:

function starts-with-xyz ( s : s~ml)s ) : boo1 ; isy-ss(s) A is-~yz-sy(first(s))

for ~ e {idf, obj, opr, rode} ,

f lmct i~ starts~fith-~z ( st : s o r t ; s : ~ ) : I ~o l ;

isy-ss(s) A is-~rz-~(first(s)) A eq-s(res-~(first(s)), st) for xyz e {var, ind} ,

Page 481: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

474 VI.3 Parser and unparser

function starts-~dth-varind ( st : sort ; s : ~ ) : boo] ; starts-with-var(st, s) V starts-with-ind(st, s) ,

f l l c t im starts-with ( c : s3m~b ; s : s~Wbs ) : Imel ; isy-ss(s) A eq-symb(c, first(s)) ,

f ~ m xyz-tem ( c : ~ II is-~z-sy(c) ) : ~ ; make-t(xyz-op(basic-)lyz(c)), <>)

for xyz e {idf, cbj, opr, rode} ,

function xyz-term ( c : ~ n is-xyz-sy(c) ) : ~ ; make-t(~-op(xyz-id(c)), <>)

for xyz e {var, ind}

Now we are ready to give our parser. To keep the treatment simple, we have decided that erroneous strings will lead to undefined results; error-prepagation proceeds by the strictness of the functions involved. Moreover, we have chosen a grammar that shows the simple-LL(1) property, thus allowing a very schematic and simple recursive descent parsing technique.

We define a function

fumcti(m parse-sort ( st : sort ; s : ~ s ) : (terms, s~Ibs)

such that with (<t>,r) - parse-sort(~yz, s) we have that u = unparse(t) is the longest sequence of symbols in L(<xyz>) that is a prefix of s and that s = u&r, i.e. that r results by deleting that prefix u from s. Sequence sorts corresponding to aux17iary nonterminals are handled by the function parse-sequ. Using this aux17iary function, parse-sort is defined as follows:

function parse-sort ( st : sort ; s : ~ s ) : (tm~s, ~mbs) ; i f is-sequ-s(st)

1}mn parse-sequ(s-snm(st), s) else i f starts-with-varind(st, s)

parse-varind(st, s) else i f ~ isy-ss(s)

t l ~ parse-operator(variant(p-snm(st), first(s)), s) endif

emdif emdif

The function parse-operator serves to parse the single productions of the grammar. The simple-LL(1) property allows us to use the function variant that determines for a sort identifier (i.e. a nonterminal) and a symbol c the operator (i.e. the production) that generates c as its first symbol. For our grammar, variant reads

fumctim variant ( sn : sm ; c : ~ ) : operalzr ; i f eq-snm(sn, exp)

then i f is-idf-sy(c) then idex-op [l is-cbj-sy(c) them obex-op [I is-opr-sy(c) them opex-op

Page 482: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

VI.3 Parser and unparser 475

0 eq-sy(c, Ib-sy) then apex-op [l eq-sy(c, if-sy) then cdex-op D eq-sy(c, Ip-sy) tlmm tpex-op rl eq-~y(c, bg-~) then scex-op 0 eq-sy(c, sb-sy) then subs-op e.dif

[] eq-snm(sn, dec) then decl-op [I eq-~m(sn, abs)

then i f eq-sy(c, Ip-sy) then abst-op [] eq-sy(c, dc-sy) than dcln-op e~dif

0 eq-snm(sn, par) then prmt-op 0 eq-snm(sn, knd)

then i f is-mde-sy(c) then m~kd-op [] eq-sy(c, Ip-~) then tukd-op 0 eq-sy(c, fc-sy) then fckd-op 9 eq-sy(c, ty-sy) then t&~e-op I] eq-sy(c, ki-sy) then kind-op endif

I] eq-snm(sn, st i) i f eq-sy(c, Ic-sy) then stid-op 0 eq-sy(c, Ip-sy) then unid-op 0 eq-sy(c, us-sy) then used-op 0 eq-~y(c, kn-sy) then knwn-op [l eq-sy(c, id-sy) then idfs-op endif

endif

The auxlqiary function parse-varind is given by

f ~ o n parse-varind( st : sort ; s : ~=bs ) : ( Imms, sBmbs) ; i f starts-with-var(st, s)

then (<vat-tern(first(s))>. rest(s)) 0 starts-with-ind(st, s)

then (<ind-term(first(s))>, rest(s)) ondif

The function parse-sequ is parameterized with the syntactic category of the iterated construct; internally, i t uses the function sep to determine the concrete separator.

function parse-sequ ( sn : s,m ; s : ~mbs ) : (imms, ~mbs) ; [-const (tsl : trams, sl : ~Ibs) -=

i f starts-with-varind(sequ(sn), s) t~en parse-varind(sequ(sn), s) else parse-sort(plain(sn), s)

~ f ; i f starts-with(sep(sn), s)

then const (ts2 : terns, s2 : sOmbs) i parse-sequ(sn, rest(sl)) ;

Page 483: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

476 VI.3 Parser and unparser

(tsl&ts2, s2) else (tsl, sl)

endif I

Note that this only works i f any auxllia~ nonterminal <aux> is always followed by a ~ different from sep(<aux>) in the grammar. Moreover, we have exploited that in our gramm~ all iterations of one nonterminal use the same separator. We have

functim sep ( sn : smm) : ~ ; ~f eq-snm(sn, exp) V eq-snm(sn, dec) V eq-snm(sn, par) V eq-snm(sn, mde)

cm-sy [l eq-snm(sn, sti) then un-~ em{lif

We now give the schematic parser for the single productions. I t uses an aux17ia~ function separators that for a production

<~z> ::= tO <xl> t l ... <xn> tn gives the sequence <tO, t l , . . . , tn> of strings of ternTinal symbols separating the nonterminals on the right hand side. This function will also be useful for the sche~tic unparser. The parser for the primitive nonterminals <idf>, <obj>, <opr>, <n~le> is giv~ separately.

function parse-operator ( o : ~ ; s : s)mbs ) : (Imms ; s)mbs) ; i f is-primitive(o)

parse-primitive-operator(o, s) else const (as : args, sl : ~Bml~s) ~ parse-args(s, arg-sorts-o(o), separators(o)) ;

(<make-t(o, as)>, sl) endi f ,

function parse-args ( s : ~ ; ss : sorts ; ssq : ~bs-se~ ~ issq) = )ss) + i ) : (args, ~)mbs) ;

i f Issl -- o (<>, detach(first(ssq),, s))

else const sl : s3ml)s = detach(first(ssq), s) ; c~-~t (ts : ~ , s2 : ~ s ) ~ parse-sort(first(ss), sl) ;

(as : alrgs, s3 : sBflIi)s) -: parse-args(s2, rest(ss), rest(ssq)) ; (<ts> & as, s3)

~ f ,

ftmctim detach ( r : S)~i)s ; s : ~ ) : s~mbs ; i f Irl = 0

i~mns else i f eq-sy(first(r), f irst(s))

detach(rest(r), rest(s)) e ~ f

em(lif,

Page 484: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

VI.3 Parser and unparser 477

function is-primitive ( o : operator ) : bool ; [-o0mst i : ohm • name-o(o) ; is-idf-onm(i) V is-obj-onm(i) V is-opr-onm(i) V is-mde-onm(i)J ,

function separators ( o : operator ) : s~mbs-sequ ; i f eq-o(o, idex-op) then <<>, <>> I] eq-o(o, obex-op) then <<>, <>> fl eq-o(o, opex<~) them <<>, <>> 0 eq-o(o, apex-op) ~ <<Ib-sy>, <rb-sy, Ip-sy>, <rp-sy>> D eq-o(o, cdex-op) them <<if-sy>, <~-sy>, <el-sy>, <fi-sy>> 0 eq-o(o, tpex-op) t~m <<>, <>> [] eq-o(o, scex-op) then <<bg-sy>, <sc-sy>, <ed-sy>> [] eq-o(o, subs-op) them <<sb-sy, Im-sy>, <fr-sy>, <in-sy>, <rm-sy>> 0 eq-o(o, decl-op) then <<fc-sy>, <df-sy>, <>> [] eq-o(o, abst-op) then <<Ip-sy>, <rp-sy, Ip-sy>, <rp-s~, co-sy>, <>> n eq-o(o, dcln-op) then <<dc-sy, Im-sy>, <rm-sy>> [] eq-o(o, prmt-op) then <<>, <>> [] eq-o(o, md(d-op) t;--, <<>, <>> [l eq-o(o, tukd-op) ~ <<Ip-sy>, <rp-sy>> [] eq-o(o, fckd-op) them <<fc-sy, Ip-sy>, <rp-sy, Ip-sy>, <rp-sy>> 0 eq-o{o, type-op) then <<ty-sy, Im-sy>, <m-sy>> [l eq-o(o, kind-op) then <<ki-sy, Im-sy>, <rm-sy>> 0 eq-o(o, stid-op) then <<Ic-sy>, <rc-sy>> 0 eq-o(o, unid-op) then <<Ip-sy>, <rp-sy>> [l eq-o(o, used-op) them <<us-sy, Im-sy>, <rm-sy>> 0 eq-o(o, kmm-op) t~en <<kn-sy, Im-sy>, <m-sy>> II eq-o(o, idfs-op) then <<id-~, Im-sy>, <m-sy>> e~li f ,

function parse-primitive-operator ( o : o p e ~ ; s : s~d>s II is-primitive(o) ) : (terms, sBmbs) ;

~-~-t i : onto ~ name-o(o) ; i f is-idf-~qm(i) /i starts-with-idf(s)

then (<idf-term(first(s))>, rest(s)) 0 is-(bj-onm(i) /~ starts-with-obj{s)

then (<obj-term{first(s))>, rest(s)) 0 is-opr-onm(i) /~ starts-with-opr(s)

then {<opr-~m(first(s))>, rest(s)) [] is-hale-onto(i) A starts-with-rode(s)

then (<male-term(first{s))>, rest(s)) endif _J

Page 485: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

478 VI.3 Parser and unparser

This completes the description of the parser.

We also define an unparser that translates a tern back into ~mbs:

functim unparse ( t : tern) : ~ ; i f is-primitive(optor(t))

then unparse-primiti ve-term(t ) el se unparse-args(args(t), separators (optor(t) ) )

e ~ i f ,

functim unparse-args ( as : args ; ssq : ~bs-seq, Jl Jssqj = jasl + 1 ) : s~mbs ; first(ssq) & i f isy-as(as)

them <> else unparse-sequ(first(as)) & unparse-args(rest(as), rest(ssq))

e ~ i f ,

fumctiaa unparse-secN ( ts : E~1,b ) : ~ S ; i f isy-ts(ts)

then<> else unparse(first-ts(ts)) &

i f isy-ts(rest-ts(ts)) <>

else <sep(snm-s(range-t(first-ts(ts))))> & unparse-sequ(rest-ts(ts)) en~f

emdif,

functim unparse-primitive-term ( t : ~ II is-primitive(optor(t)) ) : sambs ; ~uuv~t i : (ram - name-o(optor(t)) ; i f is-idf-onm(i ) then <idf-sy(basic-idf(i ))> 0 is-d)j-onm(i) then <obj-sy(basic-d)j(i))> 0 is-opt-onto(i) then <opr-sy(basic-opr(i))> [l is-male-ohm(i) ~ <mde-sy(basic-m~e(i))> endif _]

SinnTarly, parsers and unparsers for the other objects in the system, viz. for formulas, clauses, and inferences, can be specified.

4. Syntactic and semantic predicates

In this section we detail the ~zpe PRED-SYMB in order to specify the predicate symbols that are admissible in formulas over our sample language. Besides the syntactic identii~y and its negation there is the semantic equivalence. Moreover, there are a number of auxlliary predicates such as the subset or element relations on sets of identifiers as well as the test whether all elemm~ts of a sequence of identifiers are distinct. The ~ PRED-SYMB has to be supplenmmted by the following facets:

Page 486: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Vl.4 Syntactic and semantic predicates 479

Imm (eq-pnm) = id-pnm I nid-pnm I eqv-pnm I def-pnm I sub-pnm I dst-pnm,

id-prsjanb, nid-prsymb, eqv-prs~, def-prsy~b, sub-prsy~i~, dst-prs~nb : pred-~)~l),

l a w s id-prsymb ~ prsj~nb(id-pnm, 2) , nid-prsymb = prsymb(nid-pnm, 2), eqv-prsymb = prsy~b(eqv-pnm, 2), def-prsymb = prsymb(def-pnm, i ) , sub-prsymb = prsymb(sub-pnm, 2), dst-prsy~b • prsymb(dst-pnm, I ) .

Based on this type, the inference

-~ DEFINED[FEll --> KIND[FEll --" bool

--> F • i fE i : l~FelseFen( l i f

(given in concrete syntax) corresponds to the object

m~ke-inf({m~ke-cl( (~, make-fo(def-prsymb, <<te>>)), make-cl( (~, make-fo(id-prs~rmb, <kind-op[<te>], <md(d-op[<bool-mde>]>) }, make-cl( (~, mg<e-fo(eqv-prsymb, <<tf>, <cdex-op[<te>,<tf>,<tf>]>>))

in the system. To ease readability we give all further formulas, clauses, and inferences in concrete syntax. We denote id-prsymb by -', nid-prsymb by ~, eqv-prsymb by ~, def-prsymb by DEFINED, dst-ps by DISTINCT, and sub-prsJa~b by ~.

Next we give the rules for the (partial) c~osition of predicates by completing the axioms of the type REL-CO~ ~:

function rel-comp ( sl, s2 : prt~i-~¥mb ~ r e l ~ l e ( s l , s2) ) : pred-s)~l) , flmcti(m rel-compable ( sl, s2 : pred-s~md) ) : boo] ,

l a ~ rel-conl~ble(sl, s2) = eq-ps(sl, nid-prsymb) A ~ eq-ps(s2, nid-prsymb) A

(eorps(sl, id-prsynb) V eq-ps(s2, id-prsymb) V (eq-ps(sl, sub-prsymb) ~=~ eq-ps(s2, sub-prsymb))) ,

rel-comp(id-prsymb, sl) - sl l~nmfided ~ eq-ps(sl, nid-prsymb) , rel-comp(sl, id-prsja~b) = sl ~ ( l e ( l ~ eq-ps(sl, nid-prsymb) , rel-comp(sl, sl) = sl pr~id~(l ~ eq-ps(sl, nid-prsyrfo)

5. Generating the contex t condi t ions

The context-free syntax presented in Section 2 allows far too many program sche~. In particular, i t does not express the "static semantics", i.e. that the context conditions given in [Bauer et al. 85] are observed. These conditions are: - Each expression must be well-formed wrt. the modes of its constituents.

Page 487: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

480 VI.5 Generating the context conditions

- Each identifier is used only within its scope (identifiers are bound in parameter lists and in declarations).

- No duplicate identifiers may occur in a parameter l is t or in the declarations of a section. Since we are dealing with program schemes and expressions containing meta-operaters, these conditions cannot always be fully checked. Therefore, instead we generate for each term a set of clauses expressing the static well-formedness of that term; these clauses correspond to the attribute pFopagation rules of the fan.age definition in [Bauer et al. 85]. Upon instantiation of a term the conditions can possibly be simplified (ideally to "true").

We need a n~nber of aux17iary functions for accessing parts of a term:

function sons ( t : tern; i : pnat) : terns ; args(t)[i] ,

fumction son ( t : tern; i : pnat) : term; subtenn-t(t, <pair(i, 1)>) ,

function is-v~iant ( o : operalmr ; t : ~ ) : bool ; eq-o(optor(t), o) ,

function dec-id ( t : tmrm ) : id f ;

i f is-variant(decl-op, t) then basic-idf(optor(son(t, 1))) endi f ,

function par-id ( t : ~ ) : idf ; i f is-variant(pnnt-op, t) then basic-idf(optor(son(t, i ) )) Brldif ,

f1=-Ltlon new-vars ( t : ~ ; st : sort ) : ( opera~or ; opera,or ) ; some ol,o2 : operator II ~ eq-o(ol, o2) A

is-var-o(ol) A eq-s(range-o(ol), st) A ol # used-ops-t(t) A is-vat-o(02) /~ eq-s(range-o(02), st) A 02 # used-ops-t(t)

Now the function computing the context conditions of a term reads as follows:

function context-conditions-t ( t : term ) : set-of-clause ; i f is-variant(idex-op, t)

then o0mst x : id f - basic-idf(optor(son(t, 1))) ; { x e KNOWN[Ft]I }

n is-variant(obex-op, t) V is-variant(opex-op, t) then~

n is-variant(apex-op, t) then const ( t l : term, t2 : b~m) = (son(t, I ) , son(t, 2)) ;

om~t (ak, rk : operaWr) - new-vars(t, sequ(knd)) ; { KI~[[ t2l ] -= tukd-op[~<] --> KIND~Ft]] -= fckd-op[ak, rk] } U context-conditions-t(t) U context-conditions-ts(ts)

D is-variant(cdex-op, t) then const ( t l , t2, t3 : term) ~ (son(t, 1), son(t, 2), son(t, 3)) ;

{ KIND[Ftl]I -= bool-knd , KIND,t211 --" KINDIFt3~ } IJ context-conditions-t(tl) tl context-conditions-t(t2) U context-cond~tions-t(t3)

Page 488: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

VI.5 Generating the context conditions 481

0 is-variant(tpex-op, t) context-condi tions-ts(sons(t, 1) )

[I is-variant(scex-op, t) const (ts : i ~ , t : term) =- (sons(t,1), son(t,2)) ; { DISTINCT~FIDSI[ts~ ~ } U context-conditions-ts(t~) U context-conditions-t(t)

0 is-variant(subs-op, t) then context-conditions-t(son(t, 1)) U context-conditions-t(son(t, 2)) U

centext-conditions-t(son(t, 3) ) 0 is-variant(decl-op, t)

then context-conditi ons-t( sen(t ,2 ) ) is-variant(abst-op, t) then ~-~t (ts : i ~ , t : tern) = (sons(t, I), son(t, 3)) ;

{ DISTINCTIZIDS{[ts~ ~ } U { KI~Ee~ ~ son(t, 2) } U context-conditions-t(t) D is-variant(dcln-op, t) then 0 D is-variant(prmt-op, t) then 0 ~] is-primitive(optor(t)) then (~ [l is-variant(stid-op, t) ~ I] is-variant(unid-op, t) ~ {] is-variant(used-op, t) ~ context-conditions-t(son(t, i)) D is-variant(knwn-op, t) then context-conditions-t(son(t, 1)) I] is-variant(idfs-op, t) ~ context-conditions-t(son(t, 1)) ~m~f

This function is the basis for computing the context conditions for formulas, clauses, and inferences as described in the respective ~es in Part I I I . When an inference is parsed in order to be brought into the system, the set of corresponding context conditions has to be added to the premises of the inference. As long as the resulting inference is only instantiated in such a waY that the instantiated context conditions hold, these additional clauses can always be reduced. Hence, only context-correct instantiations are meaningful.

6. Computing environment information

Another issue concerns the environment information for marked subterms of larger terms. We give for each marked term a collection of formulas expressing how the relevant information about the m~ked part depends on the information of the overall term; again this is just a re-writing of the language definition in [Bauer et al. 85].

We need an auxlqia~ function for accessing part of a m~ked term:

f~ction one-down ( mt : ~ II ~ at-root(nfc) ) : ~ ; F'com~-t son : term - subterm-t(term(m~), <first-tp(tpos(nfc))>) ; set-mark(mark-root(son), rest-tp(tpos(mt)) )

For collecting kind-information about terms we further need the auxlliary operations mde-kind, fct-kind, and tup-kind that transform modes into terms of result sort knd:

Page 489: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

482 Vl.6 Computing environment information

f ~ o n rode-kind ( m : m~ ) : tmrm ; m~d-op[<mde-term(mde-sy(m))>] ,

function fct-kind ( ms1 : m ~ ; ms2 : m ~ ) : i0mrm ; fckd-op[tup-kinds(msl), tup-kinds(ms2)] ,

flmction tup-kinds ( Ins : m ~ ) : ~ ; i f i s-empty-m~s(m)

then<> e l~ <mde-kind(first-mdes(m))> & tup-kinds(rest-mdes(m))

emdif

Moreover, we need kind-lists, i.e. mappings from identifiers to kind-terms. They are obtained by the instantiation

b a ~ ( kind-list, empty-list-k, is-empty-k, put-k, get-k, clear-k, is-in-k ) GREX(idf, term, eq-idf)

(for GREX cf. essentially [Bauer et al. 85], p.79).

We now define a function kind-env that for a marked term and a kind-list computes the kind-list showing the kind assignments to identifiers that are valid at ~ marked part of the term.

f~mctim kind-env (mt : m ~ ; u : kimd-list ) : kimd-list ; i f at-root(rot)

themu e l ~ o ~ t t : ~ i term(rot) ;

i f is-variant(obex-op, t) ~/ is-variant(idex-op, t) V is-variant(opex-op, t) V is-vaFiant(apex-op, t) ~/ is-variant(cdex-op, t) ~/ is-variant(tpex-op, t)

kind-env(one-down(mt), u) [l is-variant(scex-op, t) i ~ kind-env(one-down(mt), extend-decs-k(u, sons(t,1)) [l is-variant(decl-op, t) then kind-env(one-down(mt), extend-dec-k(u, t)) {] is-variant(abst-op, t) then kind-env(one-down(mt), extend-pars-k(u, sons(t,1)) [] is-variant(pn~t-op, t) ~ kind-env(one-down(mt), extend-park(u, t)) elseu endif

emlif

Within a section, the kind-list is extended by entering for the identifiers of the declaration part the kinds of the respective abstractions.

function extend-decs-k ( u : kimd-list ; ts : terms ) : kimd-list ; i f i s-Bnpty-ts(ts)

i ~ u else extend-decs-k(extend-dec-k(u, f irst-ts(ts)), rest-ts(ts)) endif ,

function eximnd-dec-k ( u : kind-l ist ; t : ~ ) : kimi-l ist ; i f is-variant(decl-op, t)

them c ~ i : id f i basic-idf(name-o(optor(son(t, 1)))) ; put-k(u, i , abst-kind(son(t, 2))) emdif,

Page 490: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Vl.6 Computing environment information 483

f ~ t i ( m abst-kind ( t : ~ ) : i ~ ; i f is-variant(abst-op, t)

t l ~ fct-kind(par-modes(sons(t, 1)), ms-modes(sons(t, 2))) emli f ,

fIJ1cti~ par-modes ( ts : ~ ) : ~ ; i f is-emp~-ts(ts)

then <>

else t : ~ - first-ts(ts) ; i f is-variant(pmt-op, t)

m : ~ -- basic-mde(name-o(optor(son(t, 2)))) ; <m> & par-modes(rest-ts(ts)) ~ f e ~ f ,

fumcti(m res-modes ( ts : i ~ ) : ~ ; i f is-e~ty-ts(ts)

<>

else t : i ~ - first-ts(ts) ; i f is-variant(mde~, t)

m : rode • basic-mde(nanL~-o(optor(son(t, 1)))) ; <~ & res-modes(rest-ts(ts)) endif e ~ i f

Within an abstraction the kind-list is extended by the modes of the parameters.

funclcian extend-pars-k ( u : kimd-list ; ts : ~ , ,b ) : kind-list ; i f i s-enl~ty-ts(ts)

lJmnu else extend-pars-k(extend-par-k(u, first-ts(ts)) , rest-ts(ts)) endif,

function extend-par-k ( u : kind-list ; t : term ) : kind-list ; i f is-variant(prmt-op, t)

c~-~t i : idf i basic-idf(name-o(optor(son(t, 1)))) ; put-k(u, i , son(t, 2)) endif

Note that a kind-list also gives infomation about definedness of identifiers, since dbring evaluation of the call kind-env(mt, e~ty-l ist) an identifier obtains a kind binding in the (initially e ~ ) kind-list only i f a construct binding that identifier is passed.

Similarly to kind-lists we need lists of declarations as given by the instantiation

( dec1-1ist, e~ty- l ist-d,. , put-d, get-d, -, is-in-d ) i GREX(idf, i~m, eq-idf) .

We now define a function decl-env that for a m~ked term and a decl-list con~tes the decl-list showing the association of identifiers with abstractions ~at are valid at the marked part of the term.

function decl-env ( mt : m~m~m ; u : ~ l - l i s ~ ) : ~ I - I i ~ ; i f at-root(mt)

~ u

e i g h t : ~ m term(mr) ; i f is-variant(obex-op, t ) V is-variant(idex-op, t ) V is-variant(opex-op, t ) V

Page 491: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

484 VI.6 Computing environment information

endif

is-variant(apex-~o, t) ~/ is-variant(cdex-op, t) V is-variant(tpex-op, t) decl-env(one-down(mt), u)

0 is-variant(scex-op, t) decl-env(one-down(mt), extend-d~cs-d(u, sons(t,1))

[l is-variant(decl-op, t) k~-~t decl-env(one-down(mt), ex~nd-(Loc-d(u, t))

[l is-variant(abst-op, t) V is-variant(prmt-op, t) decl -env (one-down( rot), u)

D is-primitive(optor(t)) ~ u emdif

Within a section, the decl-list is extended by entering for the identifiers of the declaration part the respective abstractions.

flmlction exi0end-decs-k ( u : decl-l ist ; ts : b~,|b ) : dBc1-1ist ; i f is-~mpty-ts(ts)

thenu e19e extend-decs-k(extend-dec-k(u, f i rst-ts(ts)), rest-ts(ts)) endi f ,

functim ex~-d~c-k ( u : decl-l ist ; t : ~ ) : decl-l ist ; i f is-variant(decl-op, t)

c ~ t i : id f - basic-idf(nmne-o(optor(son(t, 1)))) ; put-k(u, i , son(t, 2)) endif

Using kind-lists and decl-lists we can generate the formulas reflecting the environment information for the marked part of a marked term:

f~w~i~ environment (mt : m~u~ ) : set-of-fommJla ; ~ t kl : kind-l ist ~ kind-env(mt, empty-list-k) ; const d l : decl-l ist ~ c~cl-env(mt, empty-list-d) ; convert-to-formulas-k(kl) U { KNOWN~marked-part(mt,1)ll --" stid-op[knownids(kl)] } U convert-to-formal as-d(dl ) ] ,

function convert-to-fon~ulas-k ( kl : kind-l ist ) : set-of-formula ; { TYPE[Fi~ --" get-k(kl, i ) II is-in-k(kl, i ) } ,

fLmction known-ids ( kl : kind-l ist ) : b~.b ; i f is-B~oty-k(kl )

<>

e l s e ~ t i : id f = somei : id f IIis-in-k(kl, i ) ; <idf-op(i)[]> & known-ids(clear-k(kl, i ))

endif ,

Page 492: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

VI.7 Inferences for propagating definedness information 485

function convert-to-fonTulas-d ( d l : decl-list ) : set-of-fonmla ; { DECLARATION[[i~ ~ get-d(dl, i) ~ is-in-d(dl, i ) }

7. Inferences for propagaUng definedness information

In this section we give a number of rules for inferring definedness of certain terms.

(a) Identifier

Let e = idex-op[<idf-op(x)[]>].

-~ DffINED[[ell

(b) Object

Let e = obex-op[<obj-op(o)[]>].

--> DEFINED[[ e]l

(c) Operator

Let e = opex-op[<opr-op(o)[]>].

--> DEFINEDIF eli

(d) Functi.on Application

Let a = apex-op[<f>, ts] and e = tpex-op[ts].

--> DEFINED ~F a ]1 --> DEFINED [[ f l ]

(e) Conditional Expression

Let e = cdex-op[<c>, <el> , <e2> ].

~ DEFINED[[c]I c ~ obex-op[<cbj-tem(T)>] --> DEFINED[[el~

c i cbex-op[<obj-tem(F)>] --> I~INED~e2]]

-->I]ETI~D~a~ ~DEFmEDEe~

-->DEFI~D~e~

Page 493: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

486

VI.7 Inferences for propagating definedness information

(f) Tuple expression:

Let e = tpex-op[<t I . . . . . tn> ].

--> DEFINED {F t l ~

--> DEFINED {F tnll

(g) Section:

Let sc -" scex-op[<dl,...,dn> , <e>J with d i : docl-op[<~df-op(fi)> , <ai> ].

-->DEFINED{FeZ --> DEFINED [[ scl]

Sinn]arly, pmopagation rules for KIND, IDS, and SUBST can be given.

8. Two sample transformation rules

As typical ~.=presentatives for transformation rules expressed as inferences we give the rule for unfolding function calls and a rule for distributing a function call into the branches of a conditional. The corresponding inferences already contain the necessary context conditions as premises. To ease readability we use concrete rather than abstract syntax. In these rules the variables have the following sorts:

F : plain(idf) PS : plain(prs) KQ, LQ, MQ, NO, PQ, QQ, RQ : sequ(knd) C, E : plain(exp) A, El, E2 : seep(exp)

(a) LNFOLD

-~ DECLARATIONITFll --" (PQ)MQ: E --> DEFINED {F (A)]] KI~){F(A)]] -" (KQ) --> KINDS[FFI] ~ ftmct (KQ)MQ --> KIND{FEll -" MQ --> DISTINCT{FIDS{FPSII II

F(A) _]D SLBST{FA for IDS{FPSll in Ell

This inference generalizes the rules UFF_F2_F1 and UFF3 of V.4.4.. Note that the last three premises express the context-conditions which are added automatically when an inference is constructed by the operation make-inf (this was not done by the prototype system). Note also that the expression (A) is always determinate in our restricted sample language.

Page 494: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

VI.8 Two sample transformation rules 487

(b) DISTRIBUTE

KIND[Fif C then (El) else (E2) f i l l -" KQ --> KI~)[FFll --" fumct(KQ)LQ KIND~[C]] --" bool

--> KIND [F (E1) ]I =" KIND[F(E2)II KINDfF(EI)II --" MQ --> KIND[FFII --" funct(MQ)NO KI~[[(E2)ll --" ~ ~ KI~D[FFII --* ftmct(QQ)RQ --> F(if C then (El) e|se (E2) f i ) -- i f C then F(E1) else F(E2) f i

Here all the premises are context conditions and are given as generated by the function context-conditions-t; they could be simplified using the rules of transitivity discussed in Part II . This inference would be obtained by the operation ma~e-inf when applied to the rule CDY F of V.2.2.

Page 495: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

488 References

REFERENCES

[Bauer 81] Bauer, F.L.: Programming as fulfilment of a contract. In: Henderson, P. (ed.): System design. Infotech State of the Art Report_9:6, Maidenhead: Pergamon I~otech Ltd. 1981, p. 165-174

[Bauer, WBssner 82] Bauer, F.L., W~ssner, H.: Algorithmic language and program development. Berlin: Springer 1982

[Bauer et al. 85] Bauer, F.L., Broy, M., Dosch, W., Geiselbrechtinger, F., Hesse, W., Gnatz, R., Krieg-Br~ckner, B., Laut, A., Matzner, T., M611er, B., Nickl, F., Partsch, N., Pepper, P., Same]son, K., Wirsing, M., WBssner, H.: The Munich project CIP. Volume I: The v~de spectrum language CIP-L. Lecture Notes in Computer Science 183. Berlin: Sprir~r 1985

[Birkhoff 67] Birkhoff, G. : Lattice theol. Providence: American Mathematical Socie~ 1967

[Brass et al. 82] Brass, B., Erhard, F., Horsch, A., Riethmayer, H.-O., Steinbr~ggen, R.: CIP-S: An instr~nent for program transformation and rule generation. Institut f~r Informatik der TU M~nchen, TL~4-18211, 1982

[Broy 80] Broy, M.: Transformation parallel ablaufender Programme. Fakult~t f~r Mathematik der TU M~nchen, Dissertation, TUM-18001, 1980

[Broy et al. 80a] Broy, M., Pepper, P., Wirsing, M.: On relations bei~een programs. In: Robinet, B. (ed.): Proc. of the 4th International S ~ u m on Programming, Paris, April 1980. Lecture Notes in Computer Science 83, Berlin: Springer 1980, p. 59-78

[Broy et al. 80b] Broy, M., Partsch, H., Pepper, P., Wirsing, M.: Semantic relations in programming languages. In: Lavingi~n, S.H. (ed.): Information Processing 80. Proceedings of the IFIP Congress 80, Melbourne. Amsterdam: North-Holland 1980, p. 101-106

[Broy et al. 81] Broy, M., Pepper, P., Wirsing, M.: On design principles for programnTing languages: An algebraic approach. In: de Bakker, J.W., van Vliet, J.C. (eds.): Prec. of an International Symposium on Algorithmic Languages, Amsterdam, Oct. 1981. Amsterdam: North-Holland 1981, p. 203-219

[Broy et al. 82] Broy, M., Pepper, P., Wirsing, M.: On the algebraic definition of programming languages. Institut f~r Informatik der TU M~nchen, TUM-18204, 1982. Also ACM TOPLAS (to appear)

Page 496: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

References

489

[Broy 83] Broy, M.: Fixed point theo~ for communication and concurrency. In: Bjorner, D. (ed.): IFIP TC2 Working Conference "Formal Description of Programming Concepts II", Garmisch-Partenkirchen, June 1982. Amsterdam: North-Holland 1983, p. 125-148

[Broy 84] Bay, M.: Algmbraic methods for program construction: The project CIP. In: Pepper, P. (ed.): Program transformation and progranraing environments. NATO ASI Series F: Cow, outer and Systems Sciences, Vol. 8. Berlin: Springer 1984, p. 199-222

[Burstall, Darlington 77] Burstall, R., Darlington, J.: A transformation system for developing recursive pmograms. Journal ACM 2_44:1, 44-67 (1977)

[Cooper 66] Cooper, D.C. : The equivalence of certain computations. Comp. Journal_9, 45-52 (1966)

[de Bakker, de Roever 73] de Bakker, J.W., de Roever, W.P.: A calculus for recursive program schemes. In: Nivat, M. (ed.): Proc. Int. Conf. on Automata, Languages and Programming. Paris, July 1972. Amsterdam: North-Holland 1973, p. 167-196

[Dijkstra 76] Dijkstra, E.W.: WhY naive transformation systems are unlikely to work. Privately circulated manuscript EWD-636, 1976

[Ehler et al. 87] Ehler, H., Paukner, 0., Horsch, A.: Fomal development of operations of the transformation system CIP-S. Institut f~r Informatik der TU M~nchen, March 1987

[Enderton 72] Enderton, H.B. : A mathematical introduction to logic. New York: Academic Press 1972

[Erhard 81] Erhard, F.: Programmtransformation im CIP-System. Fachaussch~2, GI, Bonn 1981, p. 28-46

Notizen mJm Interaktiven Programmieren 6,

[Gentzen 34] Gentzen, G.: Untersuchungen ~ber das logische Schlie~n. Math. Zeitschr. 39, 176-210 (Teil I), 405-431 (Teil II) (1934)

[Goguen et al. 77] Goguen, J.A., Thatcher, J.W., Wagner, E.G.: Initial algebra semantics and continuous algebras. Journal ACM 244:1, 68-95 (1977)

Page 497: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

490

References

[Guttag 75] Guttag, J .V.: The specification and application to programming of abstract data l~mes. Univ. of Toronto, Dept. of Com~. Sc., Ph.D. thesis, Report CSRG-59, 1975

[Hilbert, Bernays 68] Hilbert, D., Bernays, P. : Grundlagen der Mathematik I. Berlin: Springer 1968

[Hitchcock, Park 73] Hitchcock, P., Park, D.: Induction rules and termination proofs. Int. Conf. on Automata, Languages, and Programming, 225-251, 1973.

[Hoare 78] Hoare, C.A.R.: Communicating sequential processes. Comm. ACM 21:8, 666-677 (1978)

[Kleene 52] Kleene, S.C. : Introduction to metamathematics. Amsterdam: North-Holland 1952

[Kupka, Wilsing 73] Kupka, I., Wilsing, N.: Functions describing interactive programming. In: G~nther et al. International Computing Symposium 1973. Amsterdam: North-Holland 1974

(eds.):

[Lorenzen 55] Lorenzen, P.: Einf~hrung in die operative Logik und Mathematik. Berlin: Springer 1955

[Manna 74] Manna, Z.: Mathematical theory of computation. New York: McGraw-Hill 1974

[Manna, Waldinger 81] Manna, Z., Waldinger, R.: Deductive synthesis of the unification algorithm. Science of Co~ter Programming I, 5-48 (1981)

[McCarthy 63] McCa~, J.: A basis for a mathematical theo~ of com~mxtation. In: Braffort, P., Hirschberg, D. (eds.): Computer Programming and Formal Systems. Amsterdam: North-Holland 1963

[Milner 80] Milner, R. : A calculus of communicating systems. Lecture Notes in Computer Science _~, Berlin: Springer 1980

[M~ller 84] MBller, B.: A survey of the project CIP: Con~ter-aided, intuition-guided programming - w~de spectrum language and program transformations. Institut f~r Informatik der TU M~nchen, TUM-18406, 1984

[M~ller et al. 84] M~ller, B., Partsch, H., Pepper, P.: Programming by formal reasoning - an overview of the Munich CIP project. Submitted for publication

Page 498: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

References

491

[Park 69] Park, D.M.R.: Fixpoint induction and proofs of program properties. Machine Intelligence_5, 59-78, Edinburgh University Press 1969

[Partsch 83] Partsch, H.: On the use of algebraic methods for formal requirements definitions. In: Hommel, G., Kr~nig, D. (eds.): Requirements Engineering. Informatik-Fachberichte 74, Berlin: Springer 1983

[Partsch, Laut 82] Partsch, H., Laut, A.: From requirements to their formalization - a case stu~ on the stepwise development of algebraic specifications. In: WBssner, H. (ed.): Programmiersprachen und Programment~4cklung. Informatik-Fachberichte 53, Berlin: Springer 1982

[Partsch, Pepper 83] Partsch, H., Pepper, P.: Abstract data t~pes as a tool for requirements engineering. In: Hommel G., Kr~nig, D. (eds.): Requirements Engineering. Informatik-Fachberichte 74, Berlin: Springer 1983

[Partsch, Pepper 84] Partsch, H., Pepper, P.: Algebraic types as a framework for program transformation. Institut #Jr Informatik der TU M~nchen, TUM-18408, 1984. Also TSI (to appear)

[Partsch, Steinbr~ggen 83] Partsch, H o, Steinbr~ggen, R.: Program transformation systems. ACM Computing Surveys 15, 199-236 (1983)

[Pepper 84] Pepper, P.: Inferential techniques for program development. In: Pepper, P. (ed.): Program transformation and programming environments. NATO ASI Series F: Computer and System Sciences_8. Berlin: Springer 1984

[Pepper 87] Pepper, P.: A simple calculus for program transformations (inclusive of induction). Institut f~r Informatik der TU M~nchen, TUM-18409, 1984. Also SCP (to appear)

[Riethmayer 81] Riethm~er, H.O.: Die Eni~4cklung der BedienungskoB~xmente des CIP-Systems. Notizen mm Interaktiven Programmieren_6, Fachaussch~2, GI, Bonn 1981, p. 47-76

[Riethmayer et al. 85] Riethmayer, H.O., Erhard, F., Ehler, H.: User manual for the CIP-System-Prototype. Institut f[ir Informatik der TU M~nchen, TUM-18511, 1985

[Robinson 65] Robinson, J.A.: A machine-oriented logic based on the resolution principle. Journal ACM 12:1, 23-41 (1965)

Page 499: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

492 References

[Scott 70] Scott, D.: Outline of a mathematical theory of computation. Prec. 4th Annual Princeton Conf. on Information Sciences and Systems, 169-176, 1970

[Shoenfield 67] Shoenfield, J.R.: Mathematical Logic. Reading: Addison-Wesley 1967

[Steinbr~ggen 80] Steinbr~ggen, R.: Pre-algorithmic specifications of the system CIP. Part I. Institut f~r Informatik der TU M~nchen, TUM-18016, 1980

[Steinbr~ggen 81] Steinbr~ggen, R.: The composition of schemes for local program transformation. In: Arato, M., Varga, L. (eds.): Prec. I I I . Hungarian Computer Science Conference. Budapest, January 1981. Budapest: Akademiai-Kiado 1981, p. 111-124

[Steir~r~ggen 82] Steinbr~ggen, R.: Program development using transformational expressions. Institut fur Informatik der TU MQnchen, TUM-18206, 1982

[Stoy 77] Stoy, J.E.: Denotational semantics: The Scott-Strachey approach to programming language theory. Cambridge: MIT Press 1977

[Wile 83] Wile, D.S.: Program developments: formal explanations of implementations. CACM 26:11, 902-911 (1983)

[Wirsing et al. 83] Wirsing, M., Pepper, P., Partsch, H., Dosch, W., Broy, M.: On hierarchies of abstract data t)Imes. Acta Informatica 20, 1-33 (1983)

Page 500: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Appendix : CIP Bibliography (cont.) 493

APPENDIX: BIBLIOGRAPHY OF THE PROJECT CIP (CONT.)

This appendix lists literature authored or co-authored by present and former members of the project CIP since the printing of [BAUER et al. 85].

[ASTESIANO/WIRSING 87] Astesiano, E., Wirsing, M.: An introduction to ASL. In: Meertens, L.G.L.T. (ed.): Proc. IFIP TC 2 Working Conference on Program Specification and Transformation, Bad TBIz, April 14-17, 1986. Amsterdam: North-Holland 1987, p.343-365

[BAUER 82] Bauer, F.L.: From specifications to machine code: Program construction through formal reasoning. Prec. 6th International Conference on Software Engineering, Tokyo, Sept. 13-16, 1982, p. 84-91

[BAUER 85] Bauer, F.L.: Warum abstrakte Datentypen? Informatik-Spektrum_8, 29-36 (1985)

[BAUER 86a] Bauer, F.L.: Ratiocination and intuition in the programming process. In: Zemanek, H. (ed.): A Quarter Century of IFIP. Amsterdam: North Holland 1986

[BAUER 86b] Bauer, F.L.: Logic and computers. In: Proc. 11th Intern. Wittgenstein Symposium. Kirchberg, 12. August 1986, p. 60-67

[BAUER et al. 85] Bauer, F.L., Berghammer, R., Broy, M., Dosch, W., Geiselbrechtinger, F., Gnatz, R., Hangel, E., Hesse, W., Krieg-Br~ckner, B., Laut, A., Matzner, T., MBller, B., Nickl, F., .Partsch, H., Pepper, P., Samelson, K., Wirsing, M., WBssner, H.: The Munich project CIP. Volume I: The wide spectrum language CIP-L. Lecture Notes in Computer Science 183. Berlin: Springer 1985

[BAUER et al. 87] Bauer, F.L., M~ller, B., Partsch, H., Pepper, P.: An overview of the Munich project CIP: Computer-aided, Intuition-guided Programming. IEEE Transactions on Software Engineering (to appear)

[BERGHAMMER 85] Berghammer, R.: On the use of composition in transformational programming. Institut f~r Informatik der TU M~nchen, TUM-18512, 1985. Also in: Meertens, L.G.L.T. (ed.): Proc. IFIP TC 2 Working Conference on Program Specification and Transformation, Bad T~Iz, April 14-17, 1986. Amsterdam: North-Holland 1987, p. 221-242

Page 501: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

494 Appendix : C IP Bibliography (cont.)

[BERGHAMMER 86] Berghammer, R.: A transformational development of several algorithms for testing the existence of cycles in a directed graph. Institut for Informatik der TU MEinchen, TUM-18615, 1986

[BERGHAMMER/Z IERER 85] Berghammer, R., Zierer, H.: Relational algebraic semantics of functional programs. Institut f{ir Informatik der TU MOnchen, TUM-18501, 1985

[BERGHAMMER/ZIERER 86] Berghammer, R., Zierer, H.: Relational algebraic semantics of deterministic and nondeterministic programs. Theoretical Computer Science 4__33, 123-147 (1986)

[BERGHAMMER et al. 87a] Berghammer, R., Ehler, H., Zierer, H.: Towards an algebraic specification of code generation. In: Simon, F. (ed.): Programmspezifikation. Workshop, Midlum/FBhr, May 21-22, 1987. Institut for Informatik und praktische Mathematik der Christian-Albrechts-Universit~t Kiel, Bericht Nr. 8711, 1987. Extended version: Institut for Informatik der TU MOnchen, TUM-18707, 1987

[BERGHAMMER et al. 87b] Berghammer, R., Ehler, H., Zierer, H.: Dev~opment of graph algorithms by program transformation. In: Graph-theoretic concepts in computer science. Internat. Workshop, Banz, June 29 - July 1, 1987 (to appear)

[BROY 83a] Broy, M.: Denotational semantics of communicating processes based on a language for applicative multiprogramming. Information Processing Letters 1_7, 29-35 (1983)

[BROY 83b] Broy, M.: Funktionales Programmieren - Programmieren mit Funktionalen. In: Kupka, I. (ed.): GI - 13. Jahrestagung, Hamburg, 3.-7. Oktober 1983, Proceedings. InformatikFachberichte 73. Berlin: Springer 1983, p. 24-40

[BROY 84a] Broy, M.: Denotational semantics of concurrent programs ~dth shared memory. In: Fontet, M., Melhorn, K. (eds.): Proc. Symposium on Theoretical Aspects of Computer Science 1984. Lecture Notes in Computer Science 182. Berlin: Springer 1984, p. 163-173

[BROY 84b] Broy, M.: Semantics of communicating processes. Information and Control 6__11, 202-246 (1984)

[BROY 84c] Broy, M.: On the Herbrand Kleene universe for nondeterministic computations. In: Chytil, M.P., Koubek, V. (eds.): Mathematical Foundations of Computer Science 1984. Lecture Notes in

Page 502: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Appendix : CIP Bibliography (cont.) 495

Computer Science 176. Be~in: SpOnger 1984, p. 214-222. Extended Version: Theoretical

Computer Science 3__66, 1-19 (1985)

[BROY 84d] Broy, M.: A note on processes. Technische Berichte der Fakult~t f~r Mathematik und Informatik, Universit~t Passau, MIP-8407, 1984

[BROY 85a] Broy, M. (ed.): Control Now and data Now: Concepts of distributed programming. Lecture Notes of the Interna~onal Summer Scho~ at Marktoberdorf 1984. NATO ASI Series, Series F: Computer and System Sciences 14. Be~in: Springer 1985

[BROY 85b] Broy, M.: Extensional behaviour of concurrent, nondeterministic, communicating systems. Technische Berichte der Fakult~t f~r Mathematik und Informa~k, Universit~t Passau, MIP-8507, 1985. Also in [BROY 85a], p. 229-276

[BROY 85c] Broy, M.: Speci~ca~on and top down design of distributed systems. In: Ehrig, H., et al. (eds.): Form~ methods and software dev~opment. Lecture Notes in Computer Science 186. Be~in: Springer 1985, p. 4-28

[BROY 85d] Broy, M.: Algebraic classes of models for X-calculus. Technische Berichte der Fakult~t f~r Mathematik und Informatik, Universit~t Passau, MIP-8508, 1985

[BROY 85e] Broy, M.: Rechnergest~tzte Systeme f~r den Programmentwurf. In: Brauer, W., Radig, B. (eds.): Wissensbasierte Systeme. Informatik-Fachberichte 112. Berlin: Springer 1985, p. 58-69

[BROY 85f] Broy, M.: Trends in programming methodologies: A transformational approach. In: Vacas, F.S. (ed.): Proc VI Congreso de Informatica y Automatica, Madrid, Oktober 1985, p. 3-8

[BROY 85g] Broy, M.: Structured algebraic specifica~on of Backus' functional language. Technique et

Science Informatiques (to appear)

[BROY 85h] Broy, M.: On modularity in programming. Technische Be~chte der Fakult~t fDr Mathematik und Informatik, Universit~t Passau, MIP-8506, 1985. Also in: Zemanek, H. (ed.): IFIP 25th Anniversary Celebra~on. Amsterdam: North-H~land

Page 503: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

496 Appendix : CIP Bibliography (cont.)

[BROY 86a] Broy, M.: A theory for nondeterminism, parallelism, communication. Theore~cal Computer Science 45, 1-61 (1986)

[BROY 86b] Broy, M.:An assessment of programming styles: Assignment-oriented language versus functional and applicative languages. Fundamenta Informaticae--9, 169-204 (1986)

[BROY 87a] Broy, M. (ed.): Logic of programming and calculi of discrete design. Lecture Notes of the International Summer School at Marktoberdorf 1986. NATO ASI Series, Series F: Computer and System Sciences 36. Berlin: Springer 1987

[BROY 87b] Broy, M.: Equational specification of partial higher order algebras. In: [BROY 87a]

[BROYIBAUER 84] Broy, M., Bauer, F.L.: A systematic approach to language constructs for concurrent programs. Science of Computer Programming 4, 103-139 (1984)

[BROY/N ICKL 85] Broy, M., Nickl, F.: On the duality of resumptions and stream-processing functions. Technische Berichte der Fakult~t f~r Mathematik und Informatik, Universit~t Passau, MIP-8509, 1985

[BROY/PEPPER 83] Broy, M., Pepper, P.: On the coherence of programming language and programming method~ogy. In: Bormann, J. (ed.): Proc. IFIP Working Conference on Programming Languages and System Design. Amsterdam: North-H~land 1983, p. 41-53

[BROY/TARLECKI 85] Broy, M., Tarlecki, A.: Algebraic specification of the abstract data type continuum. EATCS Bulletin 266, 32-35 (1985)

[BROY/WIRSING 83a] Broy, M., Wirsing, M.: Algebraic definition of a functional programming language and its semantic models. RAIRO Informatique Theorique 177, 137-161 (1983)

[BROY/WIRSING 83b] Broy, M., Wirsing, M.: Generalized heterogeneous algebras. In: Ausiello, G., Protasi, M. (eds.): Proc. 8th Colloquium on Trees and Algebras in Programming, L'Aquilla 1983. Lecture Notes in Computer Science 159. Berlin: Springer 1983, p. 1-34

Page 504: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Appendix : CIP Bibliography (cont.) 497

[BROY et al. 82a] Broy, M., Pepper, P., Wirsing, M.: On the algebraic definition of programming languages. Institut f~r Informatik der TU M~nchen, TUM-18204, 1982. Also ACM TOPLAS 9:1, 54-99 (1987)

[BROY et al. 82b] Broy, M., Pair, C., Wirsing, M.: A systematic stucLv of models of abstract data types. Centre de Recherche en Informatique de Nancy, Report 81-R-042. Also Theoretical Computer Science 3_33, 139-174 (1984)

[BROY et al. 86] Broy, M., MBller, B., Pepper, P., Wirsing, M.: Algebraic correctness. Science of Computer Programming _7, 35-53 (1986)

Implementations preserve program

[DELGADO KLOOS 86] Delgado Kloos, C.: Towards a form~ization of digital c irc~t design. Fakult~t f~r Mathematik und Informatik der TU M~nchen, Disserta~on. Institut f~r Informatik der TU M~nchen, TUM-18604, 1986

[DELGADO KLOOS 87] Delgado Kloos, C.: Semantics of digital circuits. Lecture Notes in Computer Science 285. Berlin: Springer 1987

[DELGADO KLOOS/DOSCH 87] Delgado Kloos, C., Dosch, W.: Transformational development of digital circuit descriptions: a case study. In: Proebster, W.E., Reiner, H.: VLSI and Computers. First International Conference on Computer Technology, Systems and Applications, Hamburg, May 11-15, 1987. Washington: Computer Science Press of the IEEE 1987, p. 319-326

[DELGADO KLOOS et al. 85] Delgado Kloos, C., Dosch, W., MBller, B.: An algebra of agents. In: Vacas, F.S. (ed.): Actas del Congreso de Informatica y Automatica, Madrid, Oct. 15-18, 1985. Madrid: Servicio de Publicaciones, Escuela Tec. Sup. Ing. de Telecommunicacion 1985, p. 489-493

[DELGADO KLOOS et al. 86] Delgado Kloos, C., Dosch, W., MBller, B.: On the algebraic specification of a language for describing communicating agents. In: Radermacher, F.J., Wirsing, M. (ed.): Berichte aus den Informatikinstituten. 9. Jahrestagung der ~)'sterreichischen Gesellschaft f~r Informatik, Passau, 27.-28. Februar 1986. Fakult~t f~r Mathematik und Informatik der Universit~t Passau, MIP-8604, 1986, p. 53-73

[DELGADO KLOOS et al. 87a] Delgado Kloos, C., Dosch, W., MBller, B.: On the algebraic specification of a language for describing communicating agents. In: Simon, F. (ed.): Programmspezifikation. Workshop,

Page 505: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

498 Appendix : CIP Bibliography (cont.)

Midlum/FBhr, May 21-22, 1987. Institut f~r Informatik und praktische Mathematik der Christian-Albrechts-Universit~t Kiel, Bericht Nr. 8711, 1987

[DELGADO KLOOS et al. 87b] Delgado Kloos, C., Dosch, W., M611er, B.: Algebraic specification of a language for describing communicating agents. Institut for Informatik der TU MOnchen (to appear)

[DOSCH 85] Dosch, W.: Abstrakte Datentypen. LOG INS, 50-52 (1985)

[DOSCH 87] Dosch, W.: On a typed higher order functional calculus. Fakult~t f~r Mathematik und Informatik

der TU MOnchen, Dissertation (to appear)

[DOSCH/Mb'LLER 85] Dosch, W., MSller, B.: Impacts of functional languages on teaching and programming methodology. In: Griffiths, M., Tagg, E.D. (eds.): The role of programming in teaching Informatics. Proc. IFIP TC3 Working Conference on Teaching Programming, Paris, May 7-9, 1984. Amsterdam: North-Holland 1985, p. 111-125

[DOSCH et al. 86] Dosch, W., Ehler, H., MBller, B.: On the speci~ca~on and im~ementa~on of context conditions as homomorphic extensions of the syntax. In: Simon, F. (ed.): Implemen~erung von funktionalen und logischen Programmiersprachen. Workshop, Bad Honnef, April 7-9, 1986. Ins~tut for Informa~k und praktische Mathematik der Christian-Albrechts-Universit~t Ki~, Bericht Nr. 8603, 1986

[EHLER 85a] Ehler, H.: Example of program dev~opment: the Ackermann func~on. Institut for Informatik der TU MOnchen, TUM-I8507, 1985

[EHLER 85b] Ehler, H.: Making formal specifications readable. TUM-18527, 1985

Institut for Informatik der TU M~nchen,

[EHLER 87] Ehler, H.: Ans~tze zur transformationellen Implementierung algebraischer Spezifikationen. In: Simon, F. (ed.): Programmspezifikation. Workshop, Midlum/FBhr, May 21-22, 1987. Institut for Informatik und praktische Mathematik der Christian-Albrechts-Universit~t Kiel, Bericht Nr. 8711, 1987

Page 506: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Appendix : CIP Bibliography (cont.) 499

[EHLER et al. 87] Ehler, H., Paukner, 0., Horsch, A.: Formal development of operations of the transformation system CIP-S. Institut f~r Informatik der TU M~nchen, Internal Report, March 1987

[GNATZ 83] Gnatz, R.: Mechanical Engineering and Informatics. In: Lovis, F.B., Tagg, E.D. (eds.): Informatics education for all students at university level. IFIP WG 3.2 Working Conference, Delft, May 27 - June i , 1983. Amsterdam: North-Holland 1983, p. 137-142

[GNATZ 84] Gnatz, R.: Approaching a formal framework Graphics_8, 39-50 (1984)

for graphics software standards. Computers &

[HORSCH et al. 85] Horsch, A., M~ller, B., Partsch, H., Paukner, 0., Pepper, P.: The Munich project CIP. Volume I f : The program transformation system C IP-S. Part I: Formal Specification (Tentative version). Institut f~r Informatik der TU M~nchen, TUM-18509, 1985

[HUSSMANN 85a]

Hu~ann, H.: Unification in conditional-equational theories. Technische Berichte der Fakult~t f{ir Mathematik und Informatik der Universitaet Passau, MIP-8502, 1985

[HUSSMANN 85b]

Hu~mann, H.: Rapid prototyping for algebraic specifications - RAP system user's manual. Technische Berichte der Fakult~t f~r Mathematik und Informa~k der Universitaet Passau, MIP-8504, 1985

[HUSSMANN 85c] Hu~mann, H.: Unification in conditional-equational theories. In: Caviness, B.F. (ed.): Proc. EUROCAL '85 - European Conference on Computer Algebra, Linz, Austria, April 1985. Vol. 2: Research Contributions. Lecture Notes in Computer Science 204. Berlin: Springer 1985, p. 543-553

[Mb'LLER 85] MBller, B.: On the algebraic specification of infinite objects - Ordered and continuous models of algebraic types. Acta Informatica 22, 537-578 (1985)

[Mb'LLER 87a] MBller, B.: Algebraic specifications with higher-order operators. In: Meertens, L.G.L.T. (ed.):

Proc. IFIP TC 2 Working Conference on Program Specification and Transformation, Bad TBlz, April 14-17, 1986. Amsterdam: North-Holland 1987, p. 367-398

Page 507: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

500 Appendix : CIP Bibliography (cont.)

[MtILLER 87b] MBller, B.: Higher-order algebraic specifications. Fakult~t f~r Mathematik und Informatik der TU M~nchen, Habilitationsschrift 1987

[M{~LLER/DOSCH 86] MBller, B., Dosch, W.: On the algebraic specification of domains. In: Kreowski, H.-J. (ed.): Recent trends in data type specification. Informatik-Fachberichte 116. Berlin: Springer 1986, 178-195

[M•LLER/PARTSCH 87] MBller, B., Partsch, H.: Formal specification of large-scale software. In: Meertens, L.G.L.T. (ed.): Proc. IFIP TC 2 Working Conference on Program Specification and Transformation, Bad TBlz, April 14-17, 1986. Amsterdam: North-Holland 1987, p. 491-515

[M{~LLER/PAUKNER 87] MBller, B., Paukner 0.: Transformation rules for conditional join operations. In: Meertens, L.G.L.T. (ed.): Proc. IFIP TC 2 Working Conference on Program Specification and Transformation, Bad TSlz, April 14-17, 1986. Amsterdam: North-Holland 1987, p. 243-267

[OBERME IER 86] Obermeier, R. : Ordungstheoretische Semantik Approximativer Mathematik und Informatik der TU M~nchen, Dissertation 1986

Berechnung. Fakult~t f~r

[OBERMEIER 87] Obermeier, R.: An approach to the semantics of approximative computation. Institut f~r Informatik der TU M~nchen, TUM-18711, 1987

[PXPPINGHAUS/WIRSING 83] P~ppinghaus, P., Wirsing, M.: Nondeterministic three-valued logics: Isotonic and guarded truth functions. Studia Logica 42, 1-22 (1983)

[PADAWITZ/WIRSING 84] Padawitz, P., Wirsing, Bulletin 24, 88-94 (1984)

M.: Completeness of many-sorted equational logic revisited. EATCS

[PARTSCH 85a] Partsch, H.: Transformational program development in a particular problem domain. - Fakult~t f~r Mathematik und Informatik der TU M~nchen, Habilitationsschrift. Revised version: Institut f~r Informatik der TU M~nchen, TUM-18515. Also in Science of Computer Programming 7, 99-241 ( 1986 )

Page 508: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Appendix : CIP Bibliography (cont.) 501

[PARTSCH 85b] Partsch, H.: Anforderungsde~nition. - LOG IN 5,1985, No.3, S. 38-39.

[PARTSCH 86] Partsch, H.: Algebraic requirements Informatiques_5, 21-36 (1986)

definitions: A case study. Technique et Science

[PARTSCH/M~LLER 87] Partsch, H., MBller, B.: Informa~k-Spektrum (to appear)

Konstruktion korrekter Programme durch Transformation.

[PARTSCH/PEPPER 86] Partsch, H., Pepper, P.: Program transformations expressed by algebraic type manipula~ons. Technique et Science InformatiquesS, 197-212 (1986)

[PARTSCH/STEINBROGGEN 83] Partsch, H., Steinbr~ggen, R.: Program transformation systems. ACM Computing Surveys 15, 199-236 (1983). Translation into Japanese in bit (special issue) 73-106 (1985)

[PARTSCH/STEINBRUGGEN 86a] Partsch, H., Steinbr~ggen, R.: Program transformation systems. In: Agresti, W.W. (ed.): New paradigms for software dev~opment. IEEE Computer Society Press 1986, p. 189-226.

[PARTSCH/STE INBRUGGEN 86b] Partsch, H., Steinbr~ggen, R.: Program transformation systems. In: Arnold, Tutorial on software restructuring. IEEE Computer Society Press 1986, p. 324-361

R.S. (ed.):

[PEPPER 85] Pepper, P.: Applicative languages and modal logics. Fakult~t f~r Mathematik und Informatik der TU M~nchen, Habilitationsschrift, 1985

[PEPPER 87a] Pepper, P.: Application of modal logics to the reasoning about applicative programs. In: Meertens, L.G.L.T. (ed.): Proc. IFIP TC 2 Working Conference on Program Specification and Transformation, Bad TBlz, April 14-17, 1986. Amsterdam: North-Holland 1987, p. 429-449

[PEPPER 87b] Pepper, P.: Specification of distributed systems using modal logic. In: Paul, M. (ed.): GI - 17. Jahrestagung - Computerintegrierter Arbeitsplatz im BOro. Informatik-Fachberichte 156. Berlin: Springer 1987, p. 110-121

Page 509: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

502 Appendix : CIP Bibliography (cont.)

[PEPPER/PARTSCH 84] Pepper, P., Partsch, H.: Algebraic data types as a framework for program transformations. Institut f~r Informatik der TU M~nchen, TUM-18408, 1984

[RIETHMAYER et al. 85]

Riethmayer, H.-O., Erhard, F., Ehler, H.: User manual for the CIP-system-prototype. - Institut f~r Informatik der TU M~nchen, TUM-18511, 1985

[SCHMIDT et al. 86] Schmidt, G., Berghammer, R., Zierer, H.: Describing semantic domains with sprouts. Institut f~r Informatik der TU M{~nchen, TUM-18611, 1986. Also in: Brandenburg, F.J., Vidal-Naquet, G., Wirsing, M. (eds.): Proc. STACS 1987, Passau, Febr. 1987. Lecture Notes in Computer Science 247. Berlin: Springer 1987, p. 299-310

[STEINBRUGGEN 86] Steinbr~ggen, R.: Line-drawing on a discrete g~d. Institut f~r Informatik der TU M~nchen, TUM-18610, 1986

[TARLECKI/WIRSING 85] Tarlecki, A., Wirsing, M.: Continuous abstract data types: Basic machinery and results. In: Budach, L.: Fundamentals of computation theory 1985. Lecture Notes in Computer Science 199. Berlin: Springer 1985, p. 421-441. Extended version in Fundamenta Informaticae_7, 95-126 (1986)

[WIRSING 84] Wirsing, M.: Algebraic semantics - An overview. In: Bjorner, D. (ed.): Proc. Workshop on Formal Software Development Combining Specification Methods, Nyborg, 1984

[WIRSING 85] Wirsing, M.: Denotational semantics for algebraic specification languages. In: Neuhold, E., Chroust, G. (eds.): Formal models in programming. Amsterdam: North-Holland 1985, p. 259-283

[ZIERER et al. 86] Zierer, H., Berghammer, R., Schmidt, G.: An interactive graphical manipulation system for higher objects based on relational algebra. In: Tinhofer, G., Schmidt, G. (eds.): Graph-theoretic concepts in computer science. Internat. Workshop, Bernried, June 17-19, 1986. Lecture Notes in Computer Science 246. Berlin: Springer 1987, p. 68-81

Page 510: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Index I : Key no~ons

INDEX I : KEY NOTIONS

Gentzen 15, 23 Konsequenzkalkuel 23 Lorenzen 15, 23 PL-algebra 16 PROLOG 19 abstract syntax 465, 468

abstract syntax tree 16 activity 48, 54 f . , 182 admissible 22 algebraic specification 205

algebraic type 55, 209, 210 antecedent 19, 192 applicability condition 14, 18, 30 f f . ,

46 f f . , 185 f . , 191, 198,

applicable 193 application 13 application of a rule 184, 189, 194 approximation ordering 17 assumption 34, 55, 183

attribute 17 attribute propagation 465 attribute propagation rule 480 axiom 50 axiomatic inference 185

bound variable 27 calculus 53 case distinction 23 catalog 52 f . , 56, 183 f f .

catalog base 182 claim 35 clause 19, 21, 53, 191, 480

command 47 comment 205 compactification 186 compactification 33, 47, 186 computation structure 209 f f . , 219 computational induction 35 f f . computational structure 46

conclusion 20, 191 concrete syntax 468

503

congruence 210 consequence logic 15, 23 consequent 19, 192 constructor set 39 context 25, 30 context condition 45, 55, 480 f . , 487 continuous 18 contract 47, 194 cut 20 f f . , 201 decoml)osition lemma 39 deduced inference 31 deduction 21, 194 deduction of an inference 184 f f . , 195 deduction sequence 21

defined 18 definedness 485 derivation 25, 47 f f . , 182 f f . derived meta-inference 24 descendant 17, 211 descriptive operation 213

design choice 15 design decision 53 f . , 203

determinate 18, 209 development hi story 33 development tree 55, 189 f f .

direction 190 documentation 46, 49, 387

effect 182 environment information 46, 55, 481 equality predicate 210 f . , 217 equality symbol 17 error message 55 experiences 203, 385 exportation 22 extension 20 f f . external form 56, 472

family tree 55 fold 32 formal 52, 203, 387 formal ization 204

Page 511: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

504

formula 16, 192 fragment 30 free variable 26

generalization of constants 27 generalization rule 26 gerneration principle 39 goal 34 f . , 185, 198

goal reduction 46, 48, 185 ground formula 16 ground substitution 16 group 56, 183 history 55 hold 17

hypothesis 21 Implementaion 210 f f . , 386 implementation rule 216 Importation 22, 24 indefinite rule 31 indeterminate 27 f. indetermination 16 induction 35 inference 14, 20 f . , 30, 45 f . ,

50, 55, 183, 191, 465, 479 f f . inference deduction 50 inference extraction 200 in i t ia l state 186 input scheme 49 input template 30 f . , 46 instance 46 instantiated 481 instantiated output scheme 49 instantiation 13, 16 f f . , 23,

27, 30 f . , 46, 193 f . , 480 interface 206 interface problem 385 internal form 56, 472 interpretation 17 kind 17 knowledge base 49, 52

language independence 55 language-dependent 24 language-independent 24 layout 205

Index I : Key notions

local transformation 26 local universal quantifier 27, 36

marked subterm 49, 481

marked term 188 marking 190 match 30 matching 13, 46, 49, 193 meta-deduction 21 meta-inference 22 f f . , 56

meta-meta-i nference 36 meta-operator 17, 470, 480 mode 218 modular 385 modularization 204 module 46, 219

modus ponens 20, 23 modus tol Iens 23 monotonic 42 monotonici ty 25 movement 191 movement of a marking 49, 184, 189 f. naming convention 205 neutral 48, 54, 182 noetherian 36 nondeterminate 212 notation 205 notational extension 57, 206

object language 465 output template 30 f. overloading 205 parser 472 pending 50, 55 pending activity 49, 182, 201 postponing 186 predicate 46

predicate symbol 16, 192 premise 20, 191

procedure specification 219 program 16, 45 program development 46 program fragment 16 program part 26 program scheme 16, 45, 480

Page 512: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

505 Index I : Key notions

program transformation 13 program verification 19

proof chain 55, 198

proof record 47, 50 proof step 47, 198 f. prototype system 387

prototype transformation system 4 reduced 481 reductio ad absurd~ 23 reduction 25, 34, 48 f f . , 182, 198 requirement 45 rule 13 rule application 46, 49, 192 scheme variable 16, 23, 28, 31, 45 semantic interpretation 16, 19 semantic model 16 f. semantic predicate 17, 30,

42, 55, 465, 478 semantic relation 197 semantic relationship 18 semantical equivalence 17 signature 16 simplification 50 f . , 185 f . , 198 sound 27 stack 55, 182 standard recursion 213 state 48, 53, 182 string-to-tree translation 45 structural induction 35, 39 subgoal 34, 46, 50, 185, 198 substitution 16 f . , 28 substitution theorem 28 synonymous 60 syntactic predicate 17, 42, 478 system core 52, 54 tautology 20, 22 term 16, 473, 478, 480 term induction 39 test operation 55 transformable 14, 19, 30 transformation rule 30, 45 f f . ,

191 f., 385 f., 389, 465, 486 transformation step 30

transformational development 385 transi t i vity 25 tree-to-string-retransl ati on 45 type 46 type transformation 46 unfold 32 universal quantification 26 unparser 472 user command 52 user environment 52, 387 valid 17 f f . validation 182, 204, 465

verification 33, 46 weak 17 well-founded 36

Page 513: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

506

INDEX II : TYPES, SORTS, OPERATIONS

ALL 216

BOOL 57

CAT-COM 83

CATALOG 103

CATALOG-BASE 97

CLAUSE 145

DERIV-COM 69

DERIVATION 117

DEVTREE 127

DEVTREE-COM 73

EFFECT 62

EMAP 108 EX 216

FAP 214

FILTER 214

FORMULA 147

FT 215

GEN-COM 64

GREX 57

GROUP 110 INAME 469

INFERENCE 137

INFO 134

INSTANCE 153

LANGUAGE 169, 471

MAP 107

MODE 467

MOVE-COM 78

MTERM 122

NEUTR-COM 68

OPERATOR 171

PNAT 57

PRED-SYMB 149

PRIMSET 180

RED-COM 80 REDUCTION 112

REL-CO~P 133

SC 215

SCAP 215

SEQU 176

SET 181

SORT 174

STACK 57

STATE 90

STRING 57

SYSTEM-CORE 63 TERM 158

THAT 215

TPOS 168

UNION 214

UNIVERSE 467 VNAME 469

Index I I : Types

Page 514: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Index I I : Sorts

act iv i ty 90 args 158 cat-base 97 catalog 103 clause 145

copy 171 dec-list 483 derivation 117 dev-tree 127 dewnit 127 di r 124 effect 62 entry 110 formula 147

group 110 inference 137

info 134 into 469

inst 153 instance 153

kind- l ist 482 map 107 rode 467

mdes 468 mterm 122 nat 108, 158, 159, 174 obj 467 onto 171, 470 operator 171 opr 467 pnm 479

pp 158, 168 pred-id 149 pred-symb 149 proof-chain 113 proof-step 113

reduction 112 result 62 s-info 134 sequ-m 176 sequ-of-<index, elem> 108 sequ-of-elem 108

sequ-of-index 108

sea-of-totem 117

set-of-c] ause 145 set-of-devunit 127

set-of-formula 147 set-of-inference 137

set-of-instance 155 set-of-m 180 set-of-mterm 117, 122 set-of-oI~raWr 172

set-of-soK 174

set-of-term 155 set-of-tpos 158, 168 snm 174, 469 sort 174

sorts 174 stack 91 stackentry 91 state 90 symb 472 symbs 473 tern 158 terms 159 tpos 158, 168 ~q 15g

469

507

Page 515: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

508

T 124 124

• - 124

--> 124

.&. 113

.+. 108

.+.+. 62

.-. 108

• ~. 108 <.> 113

0 107 0 108

F 467

T 467

abs 469 abst-kind 483

abst-onm 470

abst-op 471

act 91

actual-activity 90

actual-is-not-contract 74

actual-term 117

actual ize 121

add 104, 153

add-activity 91

add-antecedents 141 add-cl 145

add-entry 85

add-env 143

add-fo 147

add-inf 137

add-info 134

add-m 180

add-neutral 93

add-red 95

add-set-cl 91

add-to 99

add-to-cl s-actual 65

add-to-inf-actual 65 add-to-prev-act 92

add-to-tree 128

addable 141, 153

addable-to 99

Index I~ : Operatfons

addabl e-to-cat 85

adding-possible 104 admissible 97

agree 159

agree-s 175

all -anonymous-el ements 106

all-anonymous-elements-of 101

all-elements 106

all-elements-of 101

a l l - f i t 159

all-leaves 121

all-m 216

al l-named-elements 106

al I -named-el ements-of 101

all-names 99, 106

all -names-and-el ements 106

all-names-and-elements-of 102

all-names-of 102

all-sons 121

all-subterm-ts 156

all-subterms-as 156

all-subterms-t 156

anonymous 103, 171

antecedents 145

apex-onm 470 apex-op 471

append-m 177

applicable 70, 143

applicable-modulo-axioms 142

apply-i nf-modul o-axioms 142

apply-rule 143 arb-cl 145

arb-fo 147

arb-i 155

arb-inf 137

arb-m 181

are-in-t 162

arg-sorts-p 171

args 147, 158

args-pos 168

args-pos-tp 163

arity-m 172

arity-ps 149

Page 516: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Index I I : Operations

assu-cat 91

assumption-applicable 70

at-root 123

axs 113 basic-idf 470, 472

basic-mde 470, 472 basic-obj 470, 472

basic-opr. 470, 472

bg-sy 472

binary 150

bool-mde 467

c 134

c-info 134

card-i 155

cat 62 cat-base 90

cat-deletable 84 cat-fusable 85

cat-generable 83

cat-group 99

cat-loadable 84

cat-res 62

cdex-or~n 470

cdex-op 471 chain 112

change 163 change-as 158

change-m 178 change-ts 159

children 164

cinfo 130

cl aim 67

clause 110

clear-k 482

cl s 62

cl s-grp 110

cl s-res 62

cm-sy 472

co-sy 472 collect-infos 131

collect-premises 131

compactabl e 131

compacti fiable 75

con~pacti fication 121

compacti fy 132

compatibl e-gp 110

compatibl e-map 103

compatible-ps 150

compatibl e-sequ 103

composabl e 131

compose 131

conc-as 158

conc-e 108

conc-i 108

conc-m 176

conc-mt 117

conc-p 108

conc-ss 174

conc-tp 158, 168

conc-ts 159

concat 167

conclusion 137

condition-reducible 71

conditions 129 consequent 145

construct-inf 144

contains 100

context-conditions-as 146

context-conditions-cl 146

context-conditions-t 146, 480

context-conditions-ts 146

contract 117 conv-cl s 110

conv-der 110

conv-inf 110

conv-red 110

conv-tpr 110

conv-trm 110

conver t-to-formul as-d 485

convert-to-formul as-k 484 copy-i 171

copy-m 172 copy-o 172

copy-p 171

copy-settabl e 74

copy-v 171

509

Page 517: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

510

cut 139 cutable 139 dc-sy 472 dcln-onm470 dcln-op 472 dec 469 dec-id 480 decl-env 483 decl-onm 470 decl-op 471 deduce-inf 132 deducible 71 deducible-inf 132 def-pnm479

def-prsymb 479 del 97

del-cl 145 del-e 108

del-fo 147

del-front-m 178 del-i 108 del-inf 137 del-m 177, 180

del-mt 117 del-p 108 del-rear-m 179 del-spath 130

del etabl e 120 del etable-from 100 del etabl e-from-cat 86 delete 98, 104, 107 delete-catalog 84

delete-entry86 delete-from 100

delete-subderivation 120

delete-subtree 129 der-grp 110 der-to-act 90

deriv 90, 110 deriv-mode 94

derivation 94 detach 476

dev-tree 117

df-sy 472

di f f -c l 145 diff-dvu 127

di f f - fo 147 d i f f - i 155

d i f f - i n f 137 diff-m 181 diff-mt 122 dif f-o 172 dif f-s 174 di f f - tp 168 domain 109

domain-i 153 down 164

down-ok 164 dst-pnm 479 dst-prsymb 479 ed-sy 472 edit 63 el-sy 472 empty-as 158 empty-cat 104 empty-chain 113

empty-collection 97 empty-list-d 483 empty-list-k 482 empty-ss 174

empty-stack 91 empty-tp 158, 168

empty-ts 159 emptysequ-e 108

emptysequ-i 108 emptysequ-info 134 emptysequ-m 176 emptysequ-mt 117 emptysequ-p 108 emptyset-cl 145 emptyset-fo 147 emptyset-inf 137 emptyset-m 180 emptyset-mt 122 emptyset-o 172

emptyset-s 174

Index II : Opera~ons

Page 518: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Index I I : Opera~ons

511

emptyset-t 155

end-derivation 70

end-neutral 68 end-reduction 80

ent 63

ent-res 63

entry-l ist 109

environment 125, 484

ec-as 160

e(-c 171

ec-ch 113

e(-cl 145 e(-der 117

e(-dev 127

ec-dvu 127 ec-en 110

ec-fo 147 e(-grp 110

e(-i 153 ec-i-e 109

ec-inf 137 e(-info 134

ec-inm 469

e(-mde 467

e(-rot 122

e(-n 108

eq-o 173

eq-obj 467

eq-onm 171, 470

eq-opr 467

eq-pid 149

eq-pnm 479

eq-pp 168

eq-ps 149

eq-pst 113

eq-red 112

eq-s 174

eq-sequ-m 176

eq-set-cl 145 eq-set-dvu 127

eq-set-fo 147

eq-set-i 155

eq-set-inf 137

e(

e{

e( e(

ec

e(

e(

ec

e(

e(

e(

-set-m 181

-set-mt 122

-set-o 172

-set-s 174 -set-tp 168

-sinf 134 -snm 174, 469

-ss 174

-symb 472

-symbs 473

- t 160 eq-tp 158, 168

eq-ts 160

eq-vnm 469

equal-as 158

equal -o 171

equal - t 158

equal -ts 159

eqv-pnm 479

eqv-prsymb 479

ex-m 216 exists-catalog 83

exists-predecessor 77

exists-term 75

exp 469 export 140

exportable 140

extend-clause 146

extend-dec-k 482, 484

extend-decs-k 482, 484

extend-inf 141

extend-par-k 483

extend-pars-k 483

fap-m-n 214

fc-sy 472

fckd-onm 470

fckd-op 471

fct-kind 482

fetch-from 100 fetchable-from 100

fetchabl e-from-cat 86

fi-sy 472

f i l ter-and-instantiate 141

Page 519: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

512

f i l ter-m 214 f i r s t 113 first-as 158 f i rst-m 177 f i rs t - ts 159 f i t -c 173 f i t s 153 fr-sy 472 ft-m 215 fusabl e 98 fuse 98 fuse-catalogs 85 gen-empty 98 generate-empty-catalog 83

generate-tautol ogy 66 get 107, 153 get-activity-level 67 get-actual-term 76 get-al l-anonymous-entries 88 get-al l -catal og-names 85 get-al l-entries 87 get-al l-entry-names 88 get-all-leaves 76 get-al 1-named-entries 88 get-all-names-and-entries 88 get-all-sons 76 get-cat-group 84

get-contract 76 get-d 483 get-devunit 128 get-entry 86 get-front-m 178 get-goal 82 get-k 482 get-op 161 get-predecessor 77 get-rear-m 179 get-subgoal s 82 gl 113 go-to-pred 121

go-to-predecessor 77 goal-reducible 113 goal-reduction 113

Index II : Operations

group 103, 111 grp 62 grp-res 62 has-args 164 has-cat 98 has-copy-t 166 has-entry 87 has-marked-part 122 has-name 104 has-no-indeterminates-as 167 has-no-i ndeterminates-cl 145 has-no-i ndeterminates-fo 147 has-no-i ndeterminates-set-fo 147 has-no-indeterminates-t 167 has-no-indeterminates-ts 167 has-pred 129 has-predecessor 121 has-subterm-t 162 has-term 120 homogeneous 160 id 93 id-pid 149 id-pnm 479 id-prsy~ 150, 479 id-sy 472 i dex-onm 470 idex-op 471 idf 469 idf-onm 470 idf-op 471 idf-sy 472 idf-tem 474 idfs-onm 470 i f-sy 472 ~mport 140 importable 140 I n-range-i 155 i n-sy 472 in-template 143 ind 171 ind-id 472 nd-name 470 nd-onm 470

Page 520: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Index I I : Opera~ons

ind-op 471

ind-sy 472

ind-term 474

inf 62, 113

inf-cat 91

inf-grp 110

inf-res 62

nference 110

inference-deduction 118

inference-extraction 114

info 127

init-cat-base 97

in i t -der ivat ion 117

ini t -devunit 127

init-reduction 113

in i t -s ta te 93

In i t - t ree 128

ins 62

ins-res 62

insert 104

insert-entry 86

insert- into 100

insertable-into 100

insertable-into-cat 86

insertion-possible 104

inst-as 154

inst-clause 146

inst-formula 148

ins t - in f 139

inst-set-clause 146

inst-set-formula 148

nst-t 154

inst- ts 154

intersec-cl 145

intersec-fo 147

~ntersec-inf 137

intersec-o 172

Is-applicable 117

~s-compactifiable 121

is-deducible 118

is-elem 178

is-elem-ss 174

is-empty-as 158

s-empty-k 482

s-empty-ts 159

s-emptychain 113

s-emptysequ-e 108

s-emptysequ-i 108

I s-emptysequ-mt 117

I s-emptysequ-p 108

I s-emptyset-cl 145

i s-emptyset-fo 147

i s-emptyset-inf 137

i s-emptyset-mt 122

i s-emptyset-o 172

i s-emptystack 91

i s-1 df-onm 470

is- idf -sy 472

is- in-d 483

s-in-devtree 127

s-in-k 482

i s - in - t 161

is-ind-o 171

I s-1 nd-sy 472

i s-~nstance 145

i s-mde-onm 470

s-mde-sy 472 I s-mem-m 180

i s-member-cl 145

i s-mon~er-dvu 127

i s-member-fo 147

i s-member-i 155

ls-member-inf 137

i s-me~ber-mt 122

i s-member-o 172

i s-member-s 174

i s-member-tp 168

i s-monotonic 150

I s-mop-o 172

i s-obj-onm 470

i s-obj-sy 472

i s-opr-onm 470 s-opr-sy 472

s-plain-s 174

s-primitive 477

s-prop-t 161

513

Page 521: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

514

Index I I : Operations

i s-proper 63 is-proper-node 128 is-prp-o 171 is-root 128 is-rule 143

is-rule-formula 148 is-rule-ps 150 is-sequ-s 174 i s-sub-m 181 is-sub-t 155

~ s-subset-cl 145 i s-subset-fo 147

I s-subset-i 155 i s-subset-inf 137

I s-subset-mt 122 is-subset-o 172 is-subset-s 174 is-subset-tp 168 is-var-o 171 i s-var-sy 472 is-variant 480 is-y-m 176, 181 isacc 97, 107 i sdef 153 isec-m 181 i spred 128 isy-ss 473

jo in - i - i 154 joinable 154

ki-sy 472 kind-env 482

kind-onm 470 kind-op 472 kn-sy 472 knd 469 known-ids 484 knwn-onm 470 knwn-op 472 last-m 177 last-ss 174

last-tp 158, 168 I b-sy 472

I c-sy 472

I ead-m 177 lead-ss 174 lead-tp 158, 168

leaves 129 le f t 166

I eft-ok 166 legal-mark 78 Iegal -move 78 Iegal -pos 123 Iegal -position 119

length 91 length-as 158 length-e 108 I ength-i 108

length-m 177 I ength-mt 117 I ength-p 108 length-ss 174

length-tp 168 length-ts 159 lhs 148 Im-sy 472 load 98 l oad-catal og 84 l oadabl e 98 Ip-sy 472 m-info 134

makab] e-fo 147 makable-rule 138 makabl e-t 159 make-as 158

make-cat 103 make-cl 145 make-der 117 make-e 108 make-effect 62

make-fo 147 make-i 108 make-inf 138 make-info 134

make-m 176 make-mt 117

make-p 108

Page 522: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Index I I : Operations

515

make-proof-step 113

make-red 112

make-rule 138

make-ss 174 make-state 90

make-t 158

make-tautology 138

make-tp 158, 168

make-ts 159

mark 122

mark-root 123

marked-part 122

match-as 155

match-t 155

match-ts 155 max 164

male 469

mde-kind 482

mde-onm 470

mde-op 471

mde-sy 472

mde-term 474 mdkd-onm 470 mdkd-op 471 rain 164 ~ - i n f 137 mk-sing-cl 145 mk-sing-dvu 127 mk-sing-fo 147 mk-sing-i 155 m~-sing-inf 137 mk-sing-m 181 m~-sing-mt 122 mk-sing-o 172 mk-sing-s 174

mk-sing-tp 168

mop 172

movable 119

movabl e-mt 124 move 119

move-info 134

move-mt 124

mtm 62

mtm-res 62

nam 62

nam-res 62

namable-in 101

namable-in-cat 87

name 105

name-entry 87

name-i 171

name-in 101

name-m 172

name-o 172

name-p 171

name-ps 149

name-v 171

named 103

naming-possibl e 105

neutral 90

neutral-mode 93

new 171

new-pos 134

new-vars 480

nid-pnm 479

nid-prsymb 479

no-result 63

non-redundant-i 155

normal ize-inf 139

n~nber-of-acts 92

o 62

obex-onm 470

obex-op 471 obj 469

obj-mde 467 obj-onm 470 obj-op 471 obj-sy 472 obj-term 474 ol d-pos 134 one-down 481 opex-onm 470 opex-op 471

opr 469

opr-onm 470

opr-op 471

Page 523: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

516 Index I I : Operations

opr-sy 472 opr-tem 474 optor 158 out-template 144 p-snm 174 pair 158, 168 par 469 par-id 480 par-redes 468 par-modes 483 parse-args 476 parse-operator 476 parse-primitive-operator 477 parse-sequ 475 parse-sort 474 parse-varind 475 path 128 perform-actualization 75

perform-all-conditions-reduction 72 perform-antecedent-addition 66 perform-assumption-application 70 per for~compacti f i cation 75 perform-condition-reduction 71 perform-copy-search 74 perform-copy-setting 74 perform-cut 65 perform-exportation 66

perform-extension 66 perform-goal-reduction 81 perform-goal-reduction-with-assumption 81 perform-importation 65

perform-inference-deduction 71 perform-inference-extraction 81 perform-i nstantiation 66 perform-move 78 perform-rule-application 70

perform-subderi vati on-del eti on 74 plain 174 pna 62 pna-res 62 pop 91 posi tion-mt 124 post 127

pre 127 pred 129 pred-symb 147 predecessor 121 prefix-as 158

prefix-ts 159 premises 137 prems 127 prmt-onm 470 prmt-op 471

proper-devunit 127 prp 171 prs 469 prsq-onm 470

prsq-op 471 prsymb 149 push 91 put 97, 107, 153 put-d 483 put-k 482

quit 64 r 62, 134 r- info 134

range 109 range-i 155 range-o 172 range-t 161

rb-sy 472 rc-sy 472 red-grp 110 red-mode 95 red-to-act 90 reduc 90, 110 reduce-al I -condi tions 119 reduce-condition 118 reduci bl e 81 reduction 95 rel 127 rel-comp 133, 479 rel-compable 133, 479

rel -compose 131

rel-insts-as 155 rel -symb 144

Page 524: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Index I I : Opera~ons

rel symbol 130

remove-activity 92

renamabl e- in 101

renamabl e- in-cat 87

rename 105

rename-entry 87

rename-in i01

renaming-possibl e 105

rep lace-act iv i ty 90

replace-cat 99

replace-cat-base 90

replace-marked-part 123

repl ace-stack 90 repl ace-t 162

replaceabl e - t 162

res-inm 470

res-mdes 468

res-modes 483

res-vnm 469

rest 113

rest-as 158

rest-m 177

res t - ts 159

return-inference 67

rhs 148

r igh t 165

r ight-ok 165

rm-sy 472

root 128

rp-sy 472

ru le-appl icat ion 117

ru le - in fo 134

s 62

s-snm 174

sb-sy 472

sbgl s 113

sc-m 215

sc-sy 472

scap-m-n 215

scex-onm 470

scex-op 471

scl 62

scl-res 62

search-copy-der 120

sel-as 158

sel-e 108

se l - i 108

sel-m 177

sel-mt 117

sel-p 108

sel-ss 174

se l - ts 159

select 105

select-cat 97

sen 63

sen-res 63

sep 476

separators 477

sequ 174

sequ-made 175

sequ-pos 168

sequ-pos-tp 163

set-copy-der 120

set-copy-info 134

set-copy-mt 124

set-copy-o 173

set-copy-t 166

set-mark 78, 123

set-pos 119

set-to-sequ 117

setabl e-mt 124

settabl e-copy-der 120

show-result 63

smt 62

smt-res 62

sna 62

sna-res 62

sne 63

sne-res 63

snm-s 175

son 480

sons 129, 480

sort-equal 160

sor t - i 171

sort-m 172

sort-p 171

517

Page 525: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

518 Index I I : Operations

sort-v 171

sqi 469 stack 90 start-deriv 94 start-derivation 69

start-neutral 68 start-reduction 80 start-system 64 starts-with 474

starts-with-idf 473

starts-with-ind 473 starts-with-obj 473 starts-w~th-opr 473 starts-with-var 473

starts-with-varind 474 sti 469 stid-onm470 stid-op 471 stock-m 177

sub-m 178 sub-pnm 479 sub-prsy~b 479 sub-tp 168

sub-ts 159 subgoals 112 subs-onm470 subs-op 472

subterm-t 162 subterms-t 162 term 110, 122 term-replaceable 123

th-sy 472 that-m 215 top 91 tpex-onm 470 tpex-op 471 tpos 122 tpr-grp 110

trapro 110 tr ip le 91

trm62 trm-grp 110

trm-res 62

tukd-onm 470

tukd-op 471 tup-kinds 482

ty-sy 472 type-onm 470

type-op 472 un-sy 472 unid-onm 470 unid-op 471 union 105

union-cl 145 umon-dvu 127 union-fo 147 umon-i 155

union-inf 137 unlon-m 181 umon-m-n 214 union-mt 122

union-o 172 union-possible 105 union-s 174 union-t 155 union-tp 168 unique-copy 74 unique-copy-der 120 unique-copy-mt 124 unitable 97, 108 unite 97, 108 unparse 478 unparse-args 478 unparse-primitive-term478

unparse-sequ 478 up 164

up-ok 164 update-all-conds 129 update-cond 129 update-deriv 94 update-devunit 129

update-red 95 urgoal 112 us-sy 472

used-onm 470

used-op 472

Page 526: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Index I I : Operations

519

used-ops-as 160

used-ops-fo 148

used-ops-set-fo 148

used-ops-t 160 used-ops-ts 160

var 171

var-id 472

var-name 470

var-onm 470

var-op 471

var-sy 472

var-term 474

variant 474

void 153

Page 527: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

520

INDEX I l l : TRANSFORMATION RULES

AB-1 458

AB-FI 459

AB-SASAL 393

AC-ASAL 393

ADM-A 420

ADS-A 421

ADY-A 405

ADY-C 405

AL-AB 459

AL-AR 459

AL-E 459

AL-ER 459

ANO-AR 405

ANO-AR 421

APPL-I 459

AR-M 418

AR-POMO 418

ARCV-U 406

ARM-NE 406

ARM-TR 406

AS-I~< 435

ASH-E 421

ASI-M 433

ASI-M 434

ASO-A 421

ASU-IYL-LZ 436

AY-AAL 393

AY-ASAL 394

AY-ASAR 394

AY-SAAL 394

AY-SASAL 394

BECON 460

CA-AA 394

CC-SA 394

CC-SAAR 394

CCV-H2-V-PS 451

CCY- NS 400

CDY-A 400

CDY-AI 400

CDY-F 400, 487

CDY-F21 400

CDY-F22 401

CDY-F32 401

CH-A-SA 394

CH-I-SI 394

CH-O-SO 395

CH-SA-A 395

CSB-EEH2-A 403

CSH-EE-FT 447

CSH-EE-H2FT 447

CSH-ET-H2FT 447

CSH-ETF-TFT 448

CSI-EC-E 401

CSI-FL 401

CSI-M 433

CSI-QB 401

CSI-TC-T 401

CSI-TR 401

CSI-Y 414

CSU-EFL 401

CSU-ETR 402

CSU-TFL 402

CSU-I-FR 402

CSU-I-FR-EFL 402

CSU-Y-T 436

CV-C-SAONSA 395

CV-EQ-IAI 395

CV-R-W-I 455

CV-R-W-3 455

CV-SA-C 395

CV-WA-V 410

CY-A 395

CY-EQ 395

CY-O 395

CY-SA 395 CY-SASAR 395

DITTD 430

DITTEDES 431

DITTHP 431

DITTIC 431

DITTPC 431

Index I l l : Transformation rules

DITTPRED 431

DITTRC 431

DC 436

DCV-H 421

DCY-C 402

DDY-C 422

DDY-F 402

DDY-F31 402

DF12 436

DFCV-CR 436

DNO-SAL 422

DPIATI 460

DPIA2 460

DRM-Q 422

DSI-TR 402

DSl-V 442

ECV-A 406

ECV-EK 422

ECV-MP 422

ECV-U 406

ECY 406

ECY-EK 423

EDY-A 406

EDY-C 406

EDY-SAC 407

EIM-Q 423

EIN 407

E IN-ESA 407

EIN-T2A 423

EIN-T2SA 423

ENO-AL 407

ENO-AL 423

ENO-AR 407

ENO-AR 424

ENO-SAL 407

ENO-SAR 407

EQT-SY 454

ERAY-RP 407

ERCV-U 408

ERDY-RO 408

ERM-NE 408

Page 528: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

Index I I I : Transformation rules

521

ERM-Q 408

ERM-QSA 408

ERRM-RFL 408

ESI-CQ 418

ESI-PN 418

ESM-Q 424

ESO-E 424

EST-3-111 408

EX-M 414

FAt 460

FCV-G 424 FDP-A-D-I'FS 442

FDP-A-NV-I-TS 443 FDP-A-S-TTS 443

FDP-A-TSAS 444 FDP-AS-TSTS 443

FDP-C 448

FDP-H2-ANA 449

FDP-O 449

FF3 461

FF-F2-F1 460

FHP3-AIPIV 461

FK 437

FNO-P 449 FNO-PSAA 449

FP3-3 461

FPF3 461

FPP3-1 461

FS4-23 410

FSO-S-IYG-TS 444

FSP-FL 449

FSP-M 424

FSP-TR 450

FU-TP3-C 456

GCV-I-T 444

GCV-U 424

GFI2 437 GFCV-CKF 437

GFSI-L 440

GSS-E 425

H2CV-C-QIE 403

H2SH-2-SA 450

H2SH-T-FSA 450

H2SH-T-PS-V 451

H2SH-T-SA 450 H2SU-1-YY 439

HSU-GFSI-DSl 440 I-T 444

I-TS 444

IA-A 410

IA-A-B32 410

IA-WA 411

ICY-FR-AS 445

ICY-RS-AS 445

I I I 430

IIP 430

IN-A 425

IN-C 415

IN-CONST 452

IN-E 425 IN-F 425

IN-S 425

IN-STAT 452

IN-U 425

IN-WA 411

INCO-W 462

INFCEL 430

IP-A 396

IP-F4 462

IP-O 396

IP-SO 396

IY-GFZ 437 IYK 437

IYSI-I-AS 445

IYSI-NIY-GFL 440

KT-I-AS 445

LD-AC-TE 396

LD-CEQ 396 LD-SAA 396

LD-SAC 396

LD-SACI 396

LD-SAO 396 LD-SOSA 396

LK 437 MA-C 411

MA-S2 411

MA-S3 411

MCV-G 426

MCY-U 426

MDY-U 415 MEM-NODES 431

MSI-E 415 MSI-K 415

MT-CTCACTC 397

0C-1 456

OP-r~< 435

PAB-G 413

PAB-G 432

PAB-R 413 PAB-R 432

PI 430 PP 430

PP-CDI 404

PP-CD4 404

PRECEL 430

PSI-M 434

QCV-A-A 415 QCV-A-EL 415

QCV-AM-G 416

QCV-C 438 QCV-DF-GR 440

QCV-H2 439 QCV-O 438

QCV-O-GRL-R 441

QDY-CN-A 437

QKK 438

QKY 438

QL-T 435

QSI-LL 441

QSI-OZ 418

QSI-S 416

QSI-ZZ 419

QY-L 438

QYY 438

RB-2 457

RB-CE4 457

RC-OC-TE 397 RD-AA 397

RD-CA 397

Page 529: The Munich Project CIP: Volume II: The Program Transformation System CIP-S

522 Index I l l : Transformation rules

RELCEL 430

RK 438 RLDM-RS-TS 445

RLDM-RSR-TS 445

RLDM-T-AS 445

RLSI-YY-AS 446

RLSI-YY-TS 446

PJ~-CD3 411

RM-NB 452

PJ~-NB5 453

RM-SA 412

SA 412

SASU-FGF-F 441

SCV-/~I-G 416

SCV-F 426 SCY-E 426

SDP-C 426

SDP-O 427

SDY-A 409

SDY-C 402

SDY-ER 409

SDY-F22 409

SDY-OR 409

SH-ASAA-SAR 399

SI-AFL 397

SI-ASAC-T 399

SI-ATR 397

S I-ATRL 397

SI-EQ 397

SI-EOFL 397

SI-FLA 397

SI-FLO 398

SI-FLSA 398

SI-FLSI 398

SI-NFL 398

SI-OFL 398

SI-SAFL 398 S I-SATR 398

SI-TRA 398 S I-TRSA 398

SO-C-E 404

SP2 462

SP3 462

SQ-A2-2 412

SQ-A3-3 412 SQ-CD4-4 412

SRM-Q 4O9

SSI-EL 416

SSP-FL 427

SSP-Q 427

SU-EQSAR 398

SU-NSA-FL 398 SU-P-LG-G-TS 446

SU-SA-TR 398

SU-SOSA 399 SUT-21A 454

UAY-U 416

UCV-S 427 UCV-S-M 427

UCY-U 427

UDM-V 427

UDS-V 428

UF-ADD 432

UF-DEL 432

UF-EMPTY 432

UF-GET-DEV 432

UF-IS-IN 432

UF-IS-MEM 432

UFCO-CO4-E 463

UFCO-W 463

UFCO-W2 463 UFF3 462, 486

UFF-F2-F1 462, 486

UFPF3 463

UIS-M 428

USI-EL 416

USI-ER 416

USI-U 428

USM-K 428

USO-U 428 USS-E 429

YCV-A 417

YCV-FE 429

YSU-T 417