Multi-Tier Programming - CiteSeerX

Multi-Tier Programming Matthias Neubauer

Dissertation zur Erlangung des Doktorgrades der ¨ Angewandte Wissenschaften der Fakultät fur Albert-Ludwigs-Universität Freiburg im Breisgau 2007

¨ Angewandte Wissenschaften: Dekan der Fakultät fur Prof. Dr. Bernhard Nebel 1. Gutachter: Prof. Dr. Peter Thiemann, Universität Freiburg 2. Gutachter: Prof. Dr. Andreas Podelski, Universität Freiburg Tag der Disputation: 27. April 2007

Zusammenfassung ¨ Multitieranwendungen werden herkommlicherweise im Stile der Client-Server-Architektur entworfen. Bei solch einem Entwurf muss das System typischerweise passend zur anvisierten Zielplattform in Module aufgeteilt werden. Obwohl das modulare Entwerfen unbestritten viele Vorteile besitzt, ist es fraglich, ob die Auswahl einer bestimmten Archi¨ den physikalischen Systementwurf Einfluss auf den logischen Systementwurf tektur fur haben sollte. Des Weiteren geht das manuelle Entwickeln von verteilten Anwendun¨ gen in der Regel mit einer erhohten Systemkomplexität einher, was das Auftreten von ¨ Laufzeitfehlern begunstigt. In der vorliegenden Arbeit präsentieren wir die Grundbausteine zur Realisierung ei¨ ner sequentiellen Multitierprogrammiersprache. Statt wie ublicherweise manuell verteilt zu programmieren, erlaubt es eine solche Programmiersprache Multitieranwendungen sequentiell zu schreiben. Die Modularisierung des Programmcodes in zu den vorgesehenen Schichten passende Programmkomponenten kann somit automatischen — oder zumindest halbautomatisch — mit Hilfe eines Programmierwerkzeugs erfolgen. Der mit dieser Dissertation präsentierte Ansatz zur Umsetzung dieser Idee fußt auf zwei Pfeilern: einem Verfahren zur Berechnung einer optimalen Programmaufteilung ¨ und einem Programmtransformationsschema, das es erlaubt aus einem ursprunglich sequentiell verfassten Programm eine verteile Anwendung mit a¨ quivalenter Bedeutung zu erzeugen. Zur Realisierung des ersten Pfeilers wird in dieser Arbeit der theoretischen Unterbau ¨ eine statische Codeplatzierungsanalyse entwickelt, die sequentiellen Programmen fur Codeplatzierungsvorschriften zuweist. Eine solche Codeplatzierungsvorschrift charak¨ ¨ folgenterisiert eine mogliche Codezuteilung auf Schichten und dient als Eingabe fur de Programmtransformationsschritte. Konkret formalisiert die vorliegende Arbeit eine Zwischensprache, die es erlaubt das Verhalten verteilter Programme zeitbasiert zu un¨ tersuchen, eine constraintbasierte Plazierungsanalyse, und einen Constraintloser zur ¨ Gewinnung gultiger Platzierungsvorschriften. Indem das Worst-Case-Laufzeitverhalten verteilter Programme mit Hilfe eines Kostenmodells abgeschätzt wird, besteht die ¨ Moglichkeit, optimale Platzierungsvorschriften zu berechnen. Zur Realisierung des zweiten Pfeilers wird in dieser Arbeit ein Programmtransformationsschema vorgestellt, das ein sequentielles Programm mit vorliegender Code¨ platzierungsvorschrift uber mehrere Zwischensprachen hinweg in ein verteiltes Pro¨ gramm mit expliziten Kommunikationsprimitiven ubersetzt. Die hierzu verwendeten Zwischensprachen sind unter Zuhilfenahme von operationellen Semantiken und sta¨ tischen Typsystemen mit annotierten Typen definiert. Einzelne Ubersetzungsschritte ¨ ¨ einen der sind durch Gleichheitsregeln oder Ubersetzungsfunktionen spezifiziert. Fur Haupttransformationsschritte des Transformationsschemas, die Umwandlung von einem nachrichtbasierten hin zu einem bidirektionalen, strombasierten Kommunikationsparadigma, präsentiert die vorliegende Arbeit mit Hilfe von Bisimulationsbeweistechniken ein Korrektheitsresultat.

Abstract Multi-tier applications are traditionally designed in the style of a client-server architecture, forcing different parts of the system to be split up into separate modules that are targeted for different platforms. Even though the advantages of a modular design are apparent, it is questionable whether choosing a multi-tier architecture for the physical design of an application should also dictate its logical design. Not to forget that the increase in complexity as the result of manually developing a distributed application can raise the occurrence rate of bugs considerably. In this thesis, we provide the basic building blocks for a sequential multi-tier programming language. Such a language would allow programmers to write multi-tier applications in sequential style instead of having to write distributed code manually. Henceforth, the process of modularizing the program code into components targeted for the specific tiers could be handed over to a (semi-)automatic tool. To realize the process mentioned above, this dissertation proposes an approach based on two pillars: firstly, on an algorithm for computing an optimal modularization, and secondly, on a transformation scheme that generates a distributed program with the same semantics as the original sequential program. The first pillar focuses on the theoretical background of a placement inference system. This system automatically assigns a correct placement to a sequential program, characterizing a potential distribution of code. Such a placement is needed as input for the succeeding steps of transformation. Elements of the first pillar are an intermediate language expressing the timing behavior of distributed programs, a constraint-based placement analysis, and a constraint solver determining all valid placements for a program. Through devising a cost model for distributed programs, it is possible to estimate the worst-case runtime behavior of a program with a given placement. Optimal placements are computable by determining placements with minimal worst-case behavior. The second pillar presents a program transformation scheme which, by going through a series of intermediate languages, transforms a sequential program with the support of a placement into a distributed counterpart that uses explicit communication primitives. The intermediate languages are formally defined by operational semantics and static type systems with annotated types. The transformation steps of the scheme are formally specified by either equational rules or translations between two calculi. For one major step of the transformation scheme, namely the shift from a message-based to a bidirectional stream-based communication paradigm, the thesis provides a formal correctness result using the bisimulation proof method.

Acknowledgments First of all, I wish to thank my advisor, Peter Thiemann, for his guidance in refining my ideas into a qualified form, for his support over all the years in Freiburg, and for urging me to finish when the time was right. Thanks also go to Andreas Podelski for all our valuable discussions on software engineering, for his support during the last year of my Ph.D., and for agreeing to coreview this thesis. Several colleagues accompanied me during my studies and provided very helpful critique on previous versions of this work. Without Mike Sperber and Peter Thiemann I probably would have quit university after studying two semesters of computer science. They both introduced me into the world of functional programming and sparked my interest in the field of programming languages. Furthermore, I want to thank Simon Helsen, Stefan Franck, Markus Degen, Phillip Linkenheil, and Stefan Wehr for all the fruitful discussions, which considerably improved my thesis, as well as for always being great colleagues during my time at Freiburg University. Finally, I am very grateful to a number of friends who encouraged and support me throughout this endeavor. Christoph Mangold and his wife Miriam never hesitated to give me additional input from their perspective as database researchers. Moreover, Ruth Bartholomä and her friends were the one and only reason for living in the worst neighborhood of Freiburg all those years. And of course I also thank the “popsociety crowd”, I would not have survived the last two years in Freiburg without them. I would like to thank my friends from the “Habsburger Strasse”, Franziska Hoffmann, Amelie Geyer, and Markus Oexl, who always made me feel like having a second home in Herdern. Markus Oexl and Verena Teutsch I particular thank for all those pizzas as well as for lending me a functioning bicycle. A very special thank you goes to Amelie Geyer who was brave enough to learn all about multi-tier programming while proofreading the most important bits and pieces of my thesis. However, and last but far from least, my greatest thanks go to my parents and my little brother for their unwavering faith in me. Matthias Neubauer May, 2007

Contents

1

Introduction 1 1.1 An Informal Account of Multi-Tier Programming . . . . . . . . . . . . . . 4 1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2

Background 2.1 Preliminaries . . . . . . . . . 2.2 The IL A Calculus . . . . . . 2.2.1 Syntax . . . . . . . . 2.2.2 Dynamic Semantics . 2.2.3 Static Semantics . . . 2.2.4 Type Safety . . . . . 2.2.5 Bisimilarity . . . . .

3

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

13 13 18 19 20 22 24 32

Program Transformation Scheme 3.1 The ILB Calculus . . . . . . . 3.1.1 Syntax . . . . . . . . . 3.1.2 Dynamic Semantics . . 3.1.3 Static Semantics . . . . 3.1.4 Properties . . . . . . . 3.1.5 Translation . . . . . . . 3.2 The ILC Calculus . . . . . . . 3.2.1 Syntax . . . . . . . . . 3.2.2 Dynamic Semantics . . 3.2.3 Static Semantics . . . . 3.2.4 Properties . . . . . . . 3.2.5 Translation . . . . . . . 3.2.6 Simplification Rules . 3.3 The ILD Calculus . . . . . . . 3.3.1 Syntax . . . . . . . . . 3.3.2 Dynamic Semantics . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

35 36 36 37 39 41 51 52 52 53 55 59 70 71 86 87 87

ix

x

CONTENTS . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

88 90 91 91 92 93 94 97 102

Placement Inference 4.1 The ILS Calculus . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Static Semantics . . . . . . . . . . . . . . . . . . . . 4.1.3 Dynamic Semantics Modeling Locality and Time 4.2 Placement Analysis . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Specification . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Constraint-Based Analysis . . . . . . . . . . . . . . 4.2.3 Solving Constraints . . . . . . . . . . . . . . . . . . 4.3 Determining Optimal Placements . . . . . . . . . . . . . . 4.3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Dynamic Semantics Using Matrices . . . . . . . . 4.3.3 Dynamic Semantics as Linear Transformation . . 4.3.4 Worst-Case Runtime . . . . . . . . . . . . . . . . . 4.3.5 Optimal Placements . . . . . . . . . . . . . . . . . 4.4 Complexity Considerations . . . . . . . . . . . . . . . . . 4.5 Implementation Considerations . . . . . . . . . . . . . . . 4.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

109 110 110 112 115 119 119 138 159 167 168 168 175 179 182 183 188 189

3.4

3.5 4

5

3.3.3 Static Semantics . . . 3.3.4 Translation . . . . . . 3.3.5 Simplification Rules The ILE Calculus . . . . . . 3.4.1 Syntax . . . . . . . . 3.4.2 Dynamic Semantics . 3.4.3 Static Semantics . . . 3.4.4 Translation . . . . . . Related Work . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

Conclusion 191 5.1 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 5.3 Closing Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

List of Figures 1.1 1.2 1.3 1.4 1.5 1.6 1.7

Original sequential code . . . . . . . . . . Code with mandatory annotations added Code after placement — thin client . . . . Code after placement — fat client . . . . . Fat client after channel introduction . . . Fat client after channel pooling . . . . . . Program split up into separate processes .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. 4 . 5 . 7 . 7 . 9 . 10 . 11

2.1 2.2 2.3 2.4 2.5 2.6 2.7

Syntax of IL A . . . . . . . . . . . . Reduction rules for IL A . . . . . . Labeled transition system for IL A Type language of IL A . . . . . . . Typing rules for IL A expressions Typing rules for IL A statements . Typing rules for IL A programs . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

19 21 22 23 23 24 25

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16

Syntax of ILB . . . . . . . . . . . . . . Reduction rules for ILB . . . . . . . . Labeled transition system for ILB . . Type language of ILB . . . . . . . . . Subtyping rules for ILB . . . . . . . . Typing rules for ILB expressions . . . Typing rules for ILB statements . . . Typing rules for ILB programs . . . . Annotation erasure for ILB programs Syntax of ILC . . . . . . . . . . . . . . Reduction rules for ILC . . . . . . . . Labeled transition system for ILC . . Type language of ILC . . . . . . . . . Subtyping of ILC channels . . . . . . Subtyping of ILC types . . . . . . . . Typing rules for ILC expressions . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

37 38 39 40 40 41 42 43 51 53 54 56 57 59 60 60

. . . . . . .

xi

xii

LIST OF FIGURES 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 3.29 3.30 3.31 3.32 3.33 3.34 3.35 3.36 3.37 3.38 3.39

Typing rules for ILC statements . . . . . . . . . . . . . . . . . . Typing rules for ILC programs . . . . . . . . . . . . . . . . . . . Translation C from ILB to ILC . . . . . . . . . . . . . . . . . . . Equational rules for ILC programs specifying channel pooling Syntax of ILD . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reduction rules for ILD . . . . . . . . . . . . . . . . . . . . . . . Labeled transition system for ILD . . . . . . . . . . . . . . . . . Type language of ILD , subtyping and typing of ILD ports . . . Typing rules for ILD statements . . . . . . . . . . . . . . . . . . Typing rules for ILD statements . . . . . . . . . . . . . . . . . . Typing rules for ILD programs . . . . . . . . . . . . . . . . . . Translation D from ILC to ILD . . . . . . . . . . . . . . . . . . . Equational rules for ILD programs specifying port floating . . Syntax of ILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structural equality rules for ILE programs . . . . . . . . . . . . Reduction rules for ILE . . . . . . . . . . . . . . . . . . . . . . . Labeled transition system for ILE . . . . . . . . . . . . . . . . . Typing rules for ILE statements . . . . . . . . . . . . . . . . . . Typing rules for ILE programs . . . . . . . . . . . . . . . . . . . Translation E from ILD to ILE for programs . . . . . . . . . . . Translation E from ILD to ILE for statements . . . . . . . . . . Translation E from ILD to ILE for statements . . . . . . . . . . Translation E from ILD to ILE for expressions . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

61 62 70 72 86 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19

Syntax of ILS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Type language of ILS . . . . . . . . . . . . . . . . . . . . . . . . Typing rules for ILS programs . . . . . . . . . . . . . . . . . . . Time-based reduction rules for ILS expressions . . . . . . . . . Time-based reduction rules for ILS programs . . . . . . . . . . Annotation language of ILS . . . . . . . . . . . . . . . . . . . . Availability assumptions for ILS . . . . . . . . . . . . . . . . . . Rule for ILS singleton availabilities . . . . . . . . . . . . . . . . Subtyping rules for ILS availabilities . . . . . . . . . . . . . . . Rules for ILS availability transfers . . . . . . . . . . . . . . . . . Availability rules for ILS operations . . . . . . . . . . . . . . . . Availability rules for ILS variables . . . . . . . . . . . . . . . . Availability rules for ILS expressions . . . . . . . . . . . . . . . Availability rules for ILS programs . . . . . . . . . . . . . . . . Validity of timed configurations . . . . . . . . . . . . . . . . . . Validity of timed environments . . . . . . . . . . . . . . . . . . Constraint-based availability rules for ILS operations . . . . . Constraint-based availability rules for ILS functions, variables Constraint-based availability rules for ILS expressions . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

111 113 114 117 118 119 120 121 121 122 123 124 125 126 128 129 141 142 143

LIST OF FIGURES 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28

Constraint-based availability rules for ILS programs . . . . . . . . Simplification rules for ILS constraints . . . . . . . . . . . . . . . . Short notation for matrices . . . . . . . . . . . . . . . . . . . . . . . Time-based reduction rules for ILS expression using matrices . . . Time-based reduction rules for ILS expression using matrices . . . Time-based reduction rules for ILS expressions using matrices . . Time-based reduction rules for ILS programs using matrices . . . Time-based reduction rules for ILS expressions as transformations Time-based reduction rules for ILS programs as transformations .

xiii . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

144 161 171 172 173 174 174 176 177

Chapter 1

Introduction This thesis introduces a new programming model for multi-tier applications. Multi-tier applications are traditionally designed in the style of a client-server architecture forcing different parts of the system to be split up into separate modules which are targeted for different platforms or software agents. One typical incarnation of multi-tier architectures is the three-tier architecture, which is used to design enterprise applications. Applications designed in this way consist of three components: a presentation logic component capturing the user interface, a business logic component implementing the business process of the system, and a data access layer capturing the persistent storage of system data. In a traditional deployment of such a system, the user interface runs on a client machine or inside a web browser. In contrast, the business logic layer is implemented using additional middleware software and runs on an application server or a workstation. The data is typically stored using a relational database running on a mainframe or a database server. The advantages of a modular design are apparent. Each component owns a welldefined set of interfaces and can be developed independently. Moreover, it is possible to upgrade a component, to later change the underlying technology of a component, or to individually maintain and test a component without affecting other parts of the system. Multi-tier applications typically scale well because the overhead of running several incarnations of a component simultaneously is manageable and is easily outweighed by the performance gain. Yet, it is questionable whether choosing a multi-tier architecture for the physical design of an application should dictate its logical design. The requirements dictated by the characteristics of distribution must be kept in mind by designers and programmers alike. Local and remote versions of interfaces must be provided and must be kept synchronized, middleware technology has to be selected and integrated into the system, and all sorts of idiosyncratic restrictions have to be catered for to obtain a working system. In addition, the increase in complexity as the result of developing a distributed application manually can raise the occurrence rate of bugs considerably. Last but not 1

2

CHAPTER 1. INTRODUCTION

least, debugging and testing is much more complicated in a distributed setting. Taken together, all these complications impose a lot of additional work on the programmer that is both tedious and painstaking. The goal of this thesis is to alleviate the task of making a program ready for distributed execution. Starting from a well-structured, non-distributed design and implementation, we are to develop the foundations for (semi-)automatic tools transforming the system from a non-distributed version to a distributed one. Consequently, the main development activities can take place in the simpler, non-distributed setting, not shifting to a distributed-setting until later in the software development life cycle. Only integration testing and performance testing (and, of course, final deployment of the application) involves the distributed production setting. Earlier stages work with the non-distributed system. The following work proposes a programming framework that consists of a sequential calculus, a placement analysis, and a transformation scheme consisting of five consecutive transformation steps. In the following, we give an informal overview of the different parts of the framework. Sequential Calculus As a starting point, we assume that a system consists of sequential programs that run concurrently on a single server. Each program runs independently on behalf of a particular client. The programs do not communicate explicitly among themselves; they access and modify common resources on the server through dedicated APIs. Each operation used in the sequential program carries an annotation indicating whether the operation is location dependent. Locations in our sense must be understood as an abstraction over all the different physical places, logical components, platforms, and software agents where tiers of the final application are later supposed to reside. For example, an operation on a primitive data type is location independent whereas modifying a reference or accessing a database is not. Location dependent operations carry a location annotation that indicates where the operation can safely take place. Placement Inference The interplay of all location annotations drives the static placement analysis of the program. Operations on different locations must not interfere with each other. For example, database queries must consequently run on the application server because the database connection is a reference that does not make sense outside of the application server. GUI operations in contrast run on the client because the GUI objects are not present on the server. Usually, there is more than just one way to come up with a placement for the operations of a program because different locations can be assigned to operations that are location independent. The analysis tries to assign those operations to locations primarily by attempting to minimize the expected running time of the resulting concurrent program using a specific cost model to estimate worst-case running times.

3 In principle, it is possible to directly split annotated sequential programs into different pieces each target for a different location, but it would lead to programs sprinkled with short communications. Since repeated connection establishment is expensive, the next two program transformation steps perform resource pooling by reusing established connections between locations. In a sense, they change the style of communication of the program from a message-based style to a stream-based style. Channel Introduction The first transformation step makes the communication explicit by inserting appropriate communication primitives. For each transfer of a value, a translation inserts the consecutive statements: a statement opening a communication channel, a transfer operation that actually transfers the value using the channel opened before, and a statement that closes the channel again. Channel Pooling To avoid repeated connection establishment, the second transformation step joins close and open statements of compatible channels with the objective of reusing one channel for multiple communications. Our final goal is it to extract a program slice for each location out of the sequential program such that running all slices concurrently on their respective locations is equivalent to running the original program. Before we are able to perform the actual splitting, two additional transformation steps have to be accomplished to prepare the program for the last step. Port Introduction First, another transformation step adds a fresh port name to each connection. Port names are later used to refer to the same connection inside different threads. Port Floating Second, all statements introducing port names are moved to the beginning of the program. Splitting Transformation The final transformation step then splits the transformed sequential program into different program slices, where each slice is targeted to run separately on a different location. The final result of the transformation scheme is a program which explicitly uses typed communication primitives that are similar to the primitives found in the socket-based communication paradigm [Ste90]. An implementation would map the communication primitives to the communication architecture provided by the chosen middleware. Alternatively, a direct implementation in terms of the socket API is possible. A web application is a special case of a multi-tier application where one or more tiers run on a web browser. Our framework is applicable to this case as well, given a suitable mediator that implements bidirectional communication channels on top of HTTP. In this special case, the splitting transformation yields a client-side slice and a server-side slice of the application. The client’s slice can be implemented by applets or in JavaScript1 and the server’s slice by arbitrary server-side scripting technology. 1

A language definition for JavaScript was specified as a standard under the name EcmaScript [ECM99].

4

1.1


An Informal Account of Multi-Tier Programming

So how could we picture the development of programs written in a multi-tier programming language? In this section, we show how the process of developing a multi-tier application following our approach conceivably could look like. In order to do so, we take one iteration of the software development life cycle of a multi-tier application and demonstrate the different steps of development. A fictitious web application serves as a running example to demonstrate the different stages of the process. Writing Sequential Code The example we use is a message board application that enables its users to view and post messages which are attached to certain topics on a centrally accessible virtual blackboard. A message either starts a new topic or it is a response to a message in an existing topic. The application draws on two resources in different physical locations: a central database server and a windowing environment handling user interactions. The database is accessible via a textual SQL interface and the windowing environment provides the usual GUI widgets. The database contains a relation msgs of which each tuple describes one message (topic, contents, author, etc). Administrative fields include a topic id (tid) and a flag that indicates whether the message starts a new topic. let rec show_topic (db, tid, topic) = let stmt = string_append_3 ("SELECT * FROM msg WHERE tid=’", tid, "’") in let msgs = sql_exec (db, stmt) in let header = string_append ("Topic ", topic) in let frame = gui_create_frame (header) in let _ = show_rows (db, frame, msgs) in gui_display_frame (frame) and show_rows (db, frame, msgs) = let b = sql_cursor_has_more_elements (db, msgs) in if b then let row = sql_cursor_get_next_row (db, msgs) in let cts = sql_cursor_get_column (db, row, "contents") in let lab = gui_create_label (cts) in let _ = gui_frame_add (frame, lab) in show_rows (frame, msgs) else () in ...

Figure 1.1: Original sequential code Figure 1.1 shows two functions taken from the program.2 A basic operation of the message board is show_topic, which displays a list of messages for a given topic. This 2 The syntax of the example code is loosely based upon the syntax of the OCaml programming language [Ler06]. The underscore _ plays the role of a dummy identifier.

1.1. AN INFORMAL ACCOUNT OF MULTI-TIER PROGRAMMING

5

operation queries the database using an existing database connection, db, for a given topic id, tid, and presents the resulting messages in a new GUI frame. The operation further relies on show_rows to populate the GUI frame with a text label for each message with that topic id. The code relies on several library functions to access the database and to perform GUI operations. In particular, the function sql_exec returns a cursor to the result of an SQL query, the functions sql_cursor_... access the relation underlying the cursor, and the gui_... functions create and manipulate appropriate GUI widgets. Adding Location Annotations Some library functions are location dependent. The sql_... operations depend on the database connection db, which is only available on the server. In contrast, the creation of GUI widgets is location independent, (gui_create_frame, gui_create_label, and gui_frame_add), yet one GUI operation, gui_display_frame, must run on the client machine. Furthermore, other operations, such as string_append_..., are also location independent and can be executed at any location. let rec show_topic (db, tid, topic) = let stmt = string_append_3 ("SELECT * FROM msg WHERE tid=’", tid, "’") in let msgs = sql_exec[S] (db, stmt) in let header = string_append ("Topic ", topic) in let frame = gui_create_frame (header) in let _ = show_rows (db, frame, msgs) in gui_display_frame[C] (frame) and show_rows (db, frame, msgs) = let b = sql_cursor_has_more_elements[S] (db, msgs) in if b then let row = sql_cursor_get_next_row[S] (db, msgs) in let cts = sql_cursor_get_column[S] (db, row, "contents") in let lab = gui_create_label (cts) in let _ = gui_frame_add (frame, lab) in show_rows (frame, msgs) else () in ...

Figure 1.2: Code with mandatory annotations added Figure 1.2 shows the original source code with one addition; namely, that operations having a mandatory location are annotated accordingly. Server operations are indicated by a [S] annotation. Client operations are indicated by a [C] annotation. There are two imaginable sources for location annotations that are added to the original source code. Firstly, location-dependent library functions can be permanently listed in a configuration file. A programming tool could then automatically add such location annotations to the source program without user intervention. Secondly, there is

6


the possibility that a programmer wants to restrict the occurrence of certain values or the execution of certain operations to a specific location. In our example, the string_append operation is location independent. Nevertheless, to make sure that the actual data base query string does not leave the server location, it could be advisable to also annotate the operation with an explicit server location. Inferring a Placement After finishing writing the sequential source code, the placement analysis assigns a set of locations to each subexpression of the program that indicates where the value of the subexpression resides. Starting from the operations with a given, mandatory assignment, location information is propagated through the program, and an “implicit” communication statement x = trans[A -> B] x is inserted whenever data x available at location A is required but not yet available at location B. Because some operations may not be location dependent, they can be placed on different locations. It might even make sense to choose to execute operations at multiple locations to avoid the overhead of transmitting their results. Because of having the choice between different assignments for some operations, the analysis may produce several outcomes. In the following, we look at two results more closely. Figure 1.3 shows an outcome of the analysis that corresponds to a system with a thin client. It resembles a traditional, server-centric CGI application that compute everything on the server. Only the rendering of completely generated GUI frames or web pages happens on the client machine. The example code highlights location annotations for the most interesting cases: functions parameters and operations. All operations that are flexible in their location are placed on the server machine. Only one transfer statement has been inserted into the program; it sends the completely generated user interface stored in the frame variable from the server machine to the client machine. Figure 1.4 shows another possible result of the placement analysis. It corresponds to a system with a fat client. The application tries to compute as much as possible on the client machine. The server only accesses the database and immediately transfers all the data to the client. The client is responsible for generating the complete GUI interface. Both machines concurrently run the show_rows loop. The server iterates over a database table and sends out the content row by row. The client iteratively receives the content, also row by row, and fills up the GUI frame accordingly. There are further ways to validly place operations on locations, some of them even resulting in programs that perform useless data transmissions. The example also shows that there is no obvious notion of optimality or minimality for operation placements. The first placement may perform fewer operations on C whereas the second performs fewer operations on S, but both results are preferable in some situations. It is not clear which placement to choose without giving more information to the placement analysis. While some operations are clearly linked to a particular location (such as the database operations or the rendering of the user interface), there is some leeway for others (such


let rec show_topic (db[S] , tid[S] , topic[S] ) = let stmt = string_append_3[S] ("SELECT * FROM messages WHERE tid=’", tid, "’") in let msgs = sql_exec[S] (db, stmt) in let header = string_append[S] ("Topic ", topic) in let frame = gui_create_frame[S] (frame_header) in let _ = show_rows[S] (db, frame, msgs) in let frame = trans[S -> C] frame in gui_display_frame[C] (frame) and show_rows (db[S] , frame[S] , msgs[S] ) = let b = sql_cursor_has_more_elements[S] (db, msgs) in if b then let row = sql_cursor_get_next_row[S] (db, msgs) in let cts = sql_cursor_get_column[S] (db, row, "contents") in let lab = gui_create_label[S] (contents) in let _ = gui_frame_add[S] (frame, lab) in show_rows[S] (frame, msgs) else ()[S] in ...

Figure 1.3: Code after placement — thin client

let rec show_topic (db[S] , tid[S] , topic[S] ) = let stmt = string_append_3[S] ("SELECT * FROM msg WHERE tid=’", tid, "’") in let msgs = sql_exec[S] (db, stmt) in let topic = trans[S -> C] topic in let header = string_append[C] ("Topic ", topic) in let frame = gui_create_frame[C] (header) in let _ = show_rows[S,C] (db, frame, msgs) in gui_display_frame[C] (frame) and show_rows (db[S] , frame[C] , msgs[S] ) = let b = sql_cursor_has_more_elements[S] (db, msgs) in let b = trans[S -> C] b in if b then let row = sql_cursor_get_next_row[S] (db, msgs) in let cts = sql_cursor_get_column[S] (db, row, "contents") in let cts = trans[S -> C] cts let lab = gui_create_label[C] (cts) in let _ = gui_frame_add[C] (frame, lab) in show_rows[S,C] (frame, msgs) else ()[S,C] in ...

Figure 1.4: Code after placement — fat client

7

8


as arithmetic operations, comparisons, or access to standard libraries) that are available on more than one location. For these operations, there are different tradeoffs in assigning them to a location. An operation may have a different average runtime on each location and the cost of transferring data from one location to the other may vary depending on the placement we choose. Using a static cost model, the placement analysis is able to estimate the worst-case runtime for each valid placement with respect to given cost parameters for operations and data transfers and chooses the placement with the best expected worst-case behavior. Assuming suitable parameters specifying particular operation and transfer costs, the optimal placement for our example delivers a program where the GUI widgets are constructed on the client as shown in Figure 1.4. Introducing Channels At this point, the program in Figure 1.4 could already be split into a client process and a server process. However, doing so would be inefficient because each trans statement builds a connection between client and server to transmit one data item only. The next two transformation steps of our program transformation scheme, channel introduction and channel pooling, address this inefficiency. They join adjacent communications, thus switching from a message-based style to a stream-based style. The main idea of the joining transformation is to introduce explicit channels with open and close operations and then float open operations towards close operations in hope of merging them. Figure 1.5 shows the result of the first step, the channel introduction step. The translation to programs with explicit channels is straightforward. Instead of using an implicit transfer statement, we explicitly open a named channel between two locations (using an open statement), we transfer the data via the channel, and we immediately close the channel again (using a close statement). Expanding and Merging Channels The second transformation step, named channel pooling, carries out the expansion and the merging of channels. Figure 1.6 shows the program code after merging compatible channels. Because both channels in our sample code transfer values between S and C, we are able to join them. We only open the channel once, before transferring the first value from S to C, and keep it open. In order to reuse the channel for the transmission of the database content inside the show_rows function, we have to augment the function with an additional channel argument and pass the open channel as actual channel parameter when calling the function. Because we work with a statically typed language, channels also need to be typed. It is not sufficient to have channels over monomorphic types only, because after joining channels they can be used to transfer values of different types. In our system, channels


9

let rec show_topic (db[S] , tid[S] , topic[S] ) = let stmt = string_append_3[S] ("SELECT * FROM msg WHERE tid=’", tid, "’") in let msgs = sql_exec[S] (db, stmt) in let chan = open[S -> C] in let topic = trans chan (topic) in let close (chan) in let header = string_append[C] ("Topic ", topic) in let frame = gui_create_frame[C] (header) in let _ = show_rows[S,C] (db, frame, msgs) in gui_display_frame[C] (frame) and show_rows (db[S] , frame[C] , msgs[S] ) = let b = sql_cursor_has_more_elements[S] (db, msgs) in let chan = open[S -> C] in let b = trans chan (b) in let close (chan) in if b then let row = sql_cursor_get_next_row[S] (db, msgs) in let cts = sql_cursor_get_column[S] (db, row, "contents") in let chan = open[S -> C] in let cts = trans chan (cts) in let close (chan) in let lab = gui_create_label[C] (cts) in let _ = gui_frame_add[C] (frame, lab) in show_rows[S,C] (frame, msgs) else ()[S,C] in ...

Figure 1.5: Fat client after channel introduction therefore carry more complicated types which allow us to statically express communication patterns of channels on the type level. The statements chan{true} and chan{false} are type applications. They indicate on the type level, which branch of communication pattern specified for the channel is taken. Hence, true and false are not values, but rather communication labels which have a status like record labels. A type application on a channel is operationally irrelevant. Introducing Concurrency Finally, the last three transformation steps, port introduction, port floating, and the splitting transformation, generate a concurrent program. Running the resulting program is equivalent to running the original program. First of all, the channel introduction step introduces communication ports. The transformation step uses a special newPort statement to express the creation of new port names. Then, the following port floating transformation step moves all newPort statements to the beginning of the program. Finally, the splitting transformation step extracts for each location a separate code slice containing those parts of the sequential program that are relevant for each of the locations.

10


let rec show_topic (db[S] , tid[S] , topic[S] ) = let stmt = string_append_3[S] ("SELECT * FROM messages WHERE tid=’", tid, "’") in let msgs = sql_exec[S] (db, stmt) in let chan = open[S -> C] in let topic = trans chan (topic) in let header = string_append[C] ("Topic ", topic) in let frame = gui_create_frame[C] (header) in let _ = show_rows[S,C] [chan] (db, frame, msgs) in let close (chan) in gui_display_frame[C] (frame) and show_rows [chan] (db[S] , frame[C] , msgs[S] ) = let b = sql_cursor_has_more_elements[S] (db, msgs) in let b = trans chan (b) in if b then let chan{true} in let row = sql_cursor_get_next_row[S] (db, msgs) in let cts = sql_cursor_get_column[S] (db, row, "contents") in let cts = trans chan (cts) in let lab = gui_create_label[C] (cts) in let _ = gui_frame_add[C] (frame, lab) in show_rows[S,C] [chan] (db, frame, msgs) else let chan{false} in ()[S,C] in ...

Figure 1.6: Fat client after channel pooling Figure 1.7 contains the final program for our example. It contains two concurrent processes which share a common communication port, p, introduced by a newPort statement. Each process has the same structure because it is essentially a slice of the original program. The server process first opens the server end of a channel associated with port p using listen. The server blocks until the client process connects. Its slice of show_rows first sends a boolean indicating whether further data is following. If that is the case, it sends the first database tuple to the client and attempts to process the next tuple recursively. Otherwise, show_rows exits and the channel is closed. The client process performs exactly converse communications: it first opens the client end of the channel and then receives data as it is sent.

1.2

Contributions

The main contributions of the thesis are listed in the following: • We present a placement analysis that specifies valid placements of operations and valid placements of communication primitives. The analysis is stated in terms of an annotated type system with simple types and annotation subtyping. The

1.2. CONTRIBUTIONS

let p = newPort in // server process let rec show_topic (db, tid, topic) = let chan = listen (p) in let stmt = string_append_3 ("SELECT * FROM messages WHERE tid=’", tid, "’") in let msgs = sql_exec (db, stmt) in let send chan (topic) in let _ = show_rows [chan] (db, msgs) in let close (chan) in () and show_rows [chan] (db, msgs) = let b = sql_cursor_has_more_elements (db, msgs) in let send chan (b) in if b then let chan{true} in let row = sql_cursor_get_next_row (db, msgs) in let cts = sql_cursor_get_column(db, row, "contents") in let send chan (cts) in show_rows [chan] (db, msgs) else let chan{false} in () in ... || // client process let rec show_topic () = let chan = connect (p) in let topic = recv (chan) in let header = string_append ("Topic ", topic) in let frame = gui_create_frame (header) in let _ = show_rows [chan] (frame) in let close (chan) in gui_display_frame (frame) and show_rows [chan] (frame) = let b = recv (chan) in if b then let chan{true} in let cts = recv (chan) in let lab = gui_create_label (cts) in let _ = gui_frame_add (frame, lab) in show_rows [chan] (frame) else let chan{false} in () in ...

Figure 1.7: Program split up into separate processes

11

12

CHAPTER 1. INTRODUCTION type system is proven to be correct with respect to a location-aware operational semantics using a type-soundness argument. • We present a series of intermediate languages each specified by an operational semantics and an annotated type system. • We present a suite of typed equivalence rules and of translation functions that formally specify the transformation steps mentioned above. • We prove that the transformation step, converting a program with message-based communication into a program with bidirectional stream-based communication, preserves the semantics of the program using the bisimulation proof method. • We state an inference system that deduces all valid placements for the operations of a program. We state an algorithm that allows us to rank placements with respect to their expected worst-case running time in a concurrent execution model, where cost estimates for operations and transfer primitives are given, and we prove its correctness. Finally, we show that determining valid placements is a NP-complete problem.

1.3

Overview

The dissertation is divided into five chapters, this introduction being the first. Chapter 2 offers the formal mathematical background that is required for later chapters of the thesis. The presentation begins with common definitions and notational conventions and continues with a simple intermediate language, IL A , which we use to explain proof techniques we later apply. Chapter 3 covers the formal background of a transformation scheme that transforms sequential programs with correct location annotations into behaviorally equivalent, concurrent programs. The chapter covers a series of four program calculi, ILB , ILC , ILD , and ILE , and additionally provides translation functions and equivalence rules that formalize the step-wise process of transformation. Chapter 4 introduces a program calculus, ILS , and develops a static program analysis for that calculus, resulting in an inference scheme for the set of all valid placements. The chapter further concentrates on a methodology to algorithmically rate valid placements based on their expected worst-case program running time. Chapter 5 reviews our work, outlines possible directions for future work, and concludes.

Chapter 2

Background This chapter introduces the formal background we require for the later chapters. This part is neither meant to serve as a profound introduction of these topics nor does it present any new results. It merely serves as a foundation for the rest of the work. In Section 2.1, we introduce common definitions and notational conventions. We begin with definitions about sets, relations, and functions. We continue with a recapitulation of the proof principles of induction and co-induction. Finally, we make some conventions about syntax and fix some notations about matrices. In Section 2.2, we introduce a very simple intermediate language called IL A that will later serve as starting point for our work. By using IL A , we introduce, demonstrate and explain the basic proof techniques we will later apply.

2.1

Preliminaries

Sets and Sequences Let A be a set. We write P ( A) for the set of all subsets of A. We use the notation A ∪ B to denote the union of sets A and B, the notation A ] B to denote the disjoint union of sets A and B, the notation A ∩ B to denote the intersection of sets A and B, and the notation A − B to denote the difference of sets A from B, We use the notation [n] to denote a finite set of natural numbers, [n] = {1, . . . , n}. The notation x stands for an ordered sequence x1 , . . . , xn where n usually arises out of the context. We denote the empty sequence by e. Relations Let R ⊆ A × B and S ⊆ B × C be relations. We write R−1 for the inverse relation, R−1 = {(b, a) | ( a, b) ∈ R}. We write R; S for the composition of the two relations, R; S = {( a, c) | ∃b ∈ B.( a, b) ∈ R ∧ (b, c) ∈ S}. 13

14

CHAPTER 2. BACKGROUND

We often compose a relation, as for example a term rewrite relation, often written with arrow-notation →, with itself. To do so, we define some additional notions over relations R ⊆ A × A. The identity on A, written I A is defined as I A = {( a, a) | a ∈ A}. Exponentiation is defined by R0 = I A and Rn+1 = Rn ; R. The transitive closure of R, S R+ is defined as R+ = n>0 Rn , and the reflexive transitive closure of R is defined as S R ∗ = n ≥0 R n . A binary relation, R on A, is reflexive, if for all a ∈ A, it holds that ( a, a) ∈ R. A relation, R, is symmetric, if ( a, b) ∈ R, then also (b, a) ∈ R. A relation, R, is antisymmetric, if ( a, b) ∈ R and (b, a) ∈ R, it follows that a = b. A relation, R, is transitive, if ( a, b) ∈ R, and (b, c) ∈ R, it also holds that ( a, c) ∈ R. A relation, R, that is reflexive and transitive is called a preorder. A relation, R, that is reflexive, symmetric, and transitive is called equivalence relation. A relation, R, that is reflexive, antisymmetric, and transitive is called a partial order relation. A set, S, equipped with a partial order, v, (S, v), is called a partially ordered set. A partially ordered set (S, v) is a complete lattice, if every subset U of S has both a greatest lower bound and a least upper bound in (S, v). Depending on the lattice, we denote the greatest lower bound (or infimum, meet) of A as either u A or ∩ A), and the lowest upper bound (or supremum, join) of A as either t A or ∪ A. Functions Let A and B be sets. We write A → B for the set of functions from A to B. We write A ,→ B for the set of partial functions from A to B. We define the domain of a function f ∈ A ,→ B as the set dom( f ) = { a ∈ A | ∃b ∈ B. f ( a) = b}. We sometimes use the notation λx 7→ e to denote an anonymous function with formal parameter x and function expression e. The extension of a partial function f ∈ A ,→ B, a ∈ A, and b ∈ B, written f [ a 7→ b] or f , a : b, is a partial function from A to B where ( f [ a 7→ b])( a0 ) = f ( a0 ), if a0 ∈ dom( f ) − { a}, ( f [ a 7→ b])( a0 ) = b, if a = a0 , and undefined otherwise. The domain restriction of a partial function f ∈ A ,→ B to X, written f | X , is a partial function from A to B where ( f | X )( x ) = f ( x ), if x ∈ X ∩ A, and undefined otherwise. The negative domain restriction of a partial function f ∈ A ,→ B to X, written f \ X, is a partial function from A to B where ( f \ X )( x ) = f ( x ), if x 6∈ X, and undefined otherwise. A function between partially ordered sets ( A, v) and ( B, v) is called monotone, if it is a order-preserving function, that is, if a v a0 , then f ( a) v f ( a0 ). Induction and Co-Induction Most proofs we carry out rely on the proof principles of induction and co-induction. We assume in the following that there is a fixed, universal set U, containing “everything in the world” we reason about. Inductive and co-inductive definitions are used to pick out particular subsets of U that we are interested in. We now formally define what we mean

2.1. PRELIMINARIES

15

by such definitions. Our presentation is based on other introductory presentations of induction and co-induction [NNH99, Pie02, Gor99, Hel04]. Definition 2.1 Suppose F is a function on (P (U ), ⊆), and X ⊆ U. (i) X is F-closed, iff F ( X ) ⊆ X. (ii) X is F-dense, iff X ⊆ F ( X ). (iii) X is a fixed point of F, iff F ( X ) = X.

In the following, we often assume that a function F on (P (U ), ⊆) is monotone. We then refer to F as a generating function. Given a generating function F, we distinguish some particular subsets of U, namely the intersection of all F-closed sets and the union of all F-dense sets. Definition 2.2 Suppose F is a monotone function on (P (U ), ⊆). • µF =

T

• νF =

S

{ X | F ( X ) ⊆ X }.

{ X | X ⊆ F ( X )}.

Theorem 2.1 (Knaster-Tarski) Suppose F is a monotone function on (P (U ), ⊆). (i) µF is the least fixed point of F. (ii) νF is the greatest fixed point of F.

We say that µF is the set inductively defined by F, and νF is the set co-inductively defined by F. Corollary of the Knaster-Tarski-Theorem are the following two proof principles. Corollary 2.1 Suppose F is a monotone function on (P (U ), ⊆). (i) Principle of Induction. If X is F-closed, then µF ⊆ X. (ii) Principle of Co-induction. If X is F-dense, then X ⊆ νF.

The intuition lying behind these definitions is that we represent a set X by a characterizing predicate. Set X is specified by all elements of U for which the predicate becomes true.

16


Example 2.1 The natural numbers, N, can be defined as the least fixed point of a generating function combining the singleton set of 0 with successors of elements of X. Thus, F ( X ) = {0} ∪ {i + 1 | i ∈ X } and N = µF.

The induction principle tells us that it is enough to show that a property is closed under F. It then also holds for all elements that are inductively defined by F. The principle of co-induction works dually. To establish a property for an element x of the co-inductively defined set, νF, we only have to find a F-dense set X with x ∈ X. Usually we do not present inductively or co-inductively defined sets by their generating functions. Instead we often use common abbreviations, such as monotone axiomatic deductive system or grammar rules with associated principles of inductions, such as structural induction. Co-inductive definitions are not as widespread as their inductive counterparts; nevertheless, they lie in the heart of many aspects of computer science. We use co-inductive methods to specify data types that describe the recursive communication behavior of communication channels or to prove bisimulation properties for an intermediate language of our transformation scheme. Syntax and Terms There are many ways to define the abstract syntax of a language. We choose to use grammar rules similar in style of the formalism introduced by John Backus and Peter Naur [NBB+ 60] and extensions of it. Such grammars are just a short notation for inductive definitions for sets of trees for each syntactic category we define. For a variable of a certain kind, x, we use the notation x, . . . to denote a countable set of other variables x0 , x1 , x2 . . . of the same kind. We use the ≡ symbol to denote, that two terms (or, in particular, variables) are syntactically identical. To avoid problems where free variables may get bound after substitutions, we disallow such cases altogether. Instead we use Barendregt’s convention of identifying α-congruent terms [Bar84]—that is, we work with terms up to renaming of bound variables—to circumvent such situations. It reads as follows. Convention 2.1 [Pie02]. Terms that differ only in the names of bound variables are interchangeable in all contexts.

The convention allows us to consistently rename bound variables in such situations where their original name gets in the way. We use the symbol ≡α , if two terms are identical up to α-renaming. We commonly abuse the notation ≡ to also denote αconvertible terms. We write t[t0/x ] for the substitution of syntactic phrases t0 for each occurrence of (free) variable x in syntactic phrase t. Note that it is not needed to assure that t0 does not contain any bound variables. By the variable convention from above, this is always the case without loss of generality.

2.1. PRELIMINARIES

17

To define the dynamic semantic of some of our intermediate languages, we need the notion of expressions with “holes”, also known as contexts. We denote holes by a special variable, ·, not occurring in any other set of variables. A context e is an expression e such that fv(e) ⊆ {·}. Contexts are thus those terms where the hole variable is occurring free. We usually write e[·] to denote contexts. If e[·] is a context and e0 an expression, then e[e0 ] denotes placing e0 in the holes of e[·]. Filling a hole of a context differs from substituting a variable. In the act of filling a hole, free variables of e0 may become bound in e[e0 ]. Dioids Dioids are algebraic structures that share properties from semirings and semilattices. On the one hand, dioids adopt combinatorial properties from semirings such as associativity and commutativity of addition, associativity of multiplication and distributivity of multiplication over addition. On the other hand, they can also be considered as an ordered structure (the addition behaves just like an upper bound operation) with an additional operation. What follows is just the basic axiomatization of dioids. More on dioids and theories using them can be found in a standard textbook about algebras for discrete event systems by Baccelli et al. [BCOQ92]. Definition 2.3 A dioid D = (D , ⊗, ⊕, 1, 0) is a set D with operations ⊗ and ⊕, and designated elements 1 and 0 such that for all elements a, b, c it holds that

( a ⊕ b ) ⊕ c = a ⊕ ( b ⊕ c ),

(2.1)

a ⊕ 0 = a,

(2.2)

a ⊕ b = b ⊕ a,

(2.3)

a ⊕ a = a,

(2.4)

( a ⊗ b ) ⊗ c = a ⊗ ( b ⊗ c ),

(2.5)

a ⊗ 0 = 0 ⊗ a = 0,

(2.6)

a ⊗ 1 = 1 ⊗ a = a,

(2.7)

( a ⊕ b ) ⊗ c = ( a ⊗ c ) ⊕ ( b ⊗ c ),

(2.8)

c ⊗ ( a ⊕ b ) = ( c ⊗ a ) ⊕ ( c ⊗ b ).

(2.9)

Most axioms are well-known from ring theory, such as associativity of both operations, existence of neutral elements, and distributivity. However, the idempotency of addition (axiom (2.4)) is a distinguishing property of a dioid. Note that the order of multiplying elements may matter; multiplication need not necessarily be commutative. Addition is always commutative, because distributivity does not work in a semiring with non-commutative addition1 . 1

Otherwise, multiplying out nested terms in different orders might lead to different results.

18


We often elide the multiplication symbol and just juxtapose the factors of a multiplication. Example 2.2 The max-plus algebra (R ∪ {−∞}, +, max, 0, −∞).

´ Example 2.3 Exotic semirings as for example (N ∪ {−∞}, +, max, 0, −∞) [AEI01].

Example 2.4 Boolean algebras, as for example (B, ∧, ∨, 0, 1).

Example 2.5 If D is a dioid, then the set of matrices over D with the usual definitions for matrix multiplication and matrix addition is a dioid as well.

Matrices The notation M = ( a)i× j specifies a matrix with elements taken from a semiring and arranged in i rows and j columns. The element at row i and column j of M is denoted as aij . Row vectors or column vectors, v, are also regarded as matrices with one of their dimensions equal to 1. The notation for the zero element and the unit element of the semiring, 0 and 1, is usually also used to denote the zero and the unit of the induced matrix semiring. Matrix addition and matrix multiplication are written using the same operators as the underlying semiring. The component-wise multiplication of matrices (Hadamard product) is written as •. The transpose of a matrix M is written as M T . A diagonal matrix with diagonal elements v is written as diag(v). A block matrix B = [M1 , . . . , Mi ] is written using the usual matrix notation where Mi denote sub matrices constituting the whole block matrix. A block matrix consisting of blocks Mi on the matrix diagonal and null matrices everywhere else is denoted by diagB(M1 , . . . , Mi ).

2.2

The IL A Calculus

In this section, we introduce a very simple intermediate language, IL A . Looking at IL A serves two purposes. First, the very lightweight intermediate language without much additional clutter that we introduce in this section can be considered as the basis for the other languages we later consider in our work. Second, the section is also meant to explore and to introduce those operational methods and proof techniques that we later make use of.

2.2. THE IL A CALCULUS

19

Z Var POp EOp Op

3 3 3 3 3

i f , g, x, y, z, . . . pfun, . . . op, . . . op ::= op | pfun

Val

3

v

::= |

i rec j f ( x ) = p

Expr

3

e

::=

x|v

Def

3

d

::= |

x=e x = op (e)

Prog

3

p

::= | | |

halt ee let d in p if e then p else p

Figure 2.1: Syntax of IL A The language IL A is meant to be an intermediate language. It can be viewed as the target of a CPS transformation with named continuations of a lambda calculus with integers, effect-free and effectful operations, and recursive functions featuring an applicative order evaluation strategy. It bears strong resemblance to many other functional intermediate languages. In particular, it can be seen as a slightly modified version of Flanagan et al.’s intermediate language of A-normal forms [FSDF93].

2.2.1

Syntax

The syntax of IL A is presented in Figure 2.1. The only primitive values we use are integers, Z. We further assume disjoint denumerable sets of variable names, Var, names of primitive operations, POp, and effectful operations, EOp, respectively. IL A programs are sequences of let-bound statements, d, ending either in a halt instruction, a conditional, or a jump with parameters. A statement either performs a primitive operation (without side effects), an effectful operation, or introduces a new binding. A binding links the result of an expression, e, to a variable name, x. Expressions consist of variables, x and values, v. A value is either a primitive values, i, or a function defined by a group of (possibly recursive) functions. The syntax rec j f ( x ) = p stands for a recursive binding group of functions f i where f j is the main entry point of the binding group.

20


A primitive function pfun( x ) is free of side effects. Nullary primitive functions serve as constants. On the other hand, an operation op( x ) has unspecified side effects. Note that we could have restricted all argument of subterms of statements and programs to variables only. We also allow values as arguments to already take in consideration possible intermediate steps while evaluating a program. The notion of free variables, fv( p), of IL A -programs—and also of programs of all other calculi that will follow—is defined as usual. A program p is called closed, if fv( p) = ∅.

2.2.2

Dynamic Semantics

There are several basic approaches to formalize the semantics of a programming language, namely operational semantics, denotational semantics, or axiomatic semantics. Each approach has its on advantages and disadvantages. Nevertheless, stating the dynamic semantics of a programming language using primarily operational techniques came into vogue on the last two decades or so when exploring programming languages. The reason is simple: the metatheory needed for operational techniques is rather simple compared to other approaches. Especially, it is much easier to express some programming constructs such as nondeterminism and concurrency with operational methods than with other approaches. Furthermore, research in the field demonstrated that powerful and elegant proof techniques known from other approaches have corresponding counterparts in the operational setting. A comparison of different approaches of formalizing semantics of programming languages can be found in a standard textbooks about the semantics of programming languages [NN92, Win93, Mit96]. We will exclusively use operational techniques to formalize the dynamic semantics of the programming languages in our work. More recent results in the field of operational semantics may be found in publications accompanying the HOOTS conference series (see e.g. [GP98, GP99, Jef00]), work by Pitts or Gordon concerning the equivalence of programs (see e.g. [Pit97, Gor99]), or Pierce’s book concerning the relationship to static type systems [Pie02]. We express the dynamic semantics of effect-free computations of IL A programs by means of a small-step reduction relation, −→ ⊆ Prog × Prog. The actual reduction rules are shown in Figure 2.2. There is a beta-value reduction rule (D-A-L ET-VAL), that simplifies value bindings by substitution. The (D-A-PF UN) rule handles primitive functions. The result of the function is determined by a given, partial function, δpfun . The rules handling conditionals, (D-A-I F -T RUE) and (D-A-I F -FALSE), work as expected whereas the integer 0 serves as false value. Function application handled by (D-A-A PP) is done by unfolding. We would like to identify programs that show equivalent behavior with respect their input/output effects. To characterize the I/O behavior, we, in the following, fix the set of effectful operations to two specific operations (read and write) and register specific atomic observations that we can make while executing those operations. We use a labeled transition system to formalize I/O transitions with their accompanying observations.


21

D-A-L ET-VAL

let x = v in p

−→

p[v/x]

−→

p[i/x ]

−→

p1

−→

p2

−→

p j [reci f ( x)= p/ f i ][v/x]

D-A-PF UN

let x = pfun(i ) in p

if i = δpfun (i )

D-A-I F -T RUE

if i then p1 else p2

if i 6= 0

D-A-I F -FALSE

if 0 then p1 else p2 D-A-A PP

(rec j f ( x ) = p) v

Figure 2.2: Reduction rules for IL A The use of a labeled transition system goes back to Milner’s work on CCS [Mil89] to concurrent processes. Separating the dynamic semantics into an effect-free part realized by a regular small-step semantics and into an effectful part using a labeled transition system is due to Crole and Gordon [CG95]. The set of atomic observations and the labeled transition system is shown in Figure 2.3. The observations for I/O operations are similar to actions found in Milner’s CCS: ?i represents the action occurring during a transition from one state to the next state, the input of a number i, and !i represents the action of outputting the number i. In addition, we use the halt observation to signal halting programs to external observers. The following program is used in cases we need a program that diverges. Definition 2.4 Ω ≡ let g = rec f () = f () in g ().

The halt transition rule, (D-A-H ALT) allows us observe halting programs and guarantees that no further observations are possible. The rules (D-A-L ET-R EAD) and (D-A-L ET-W RITE) show transitions concerning I/O operations. They are labeled with corresponding I/O observations. The (D-A-S KIP) rule assures that we can perform arbitrary many reductions before having an observable transition. We talk about the derivation tree of a program as the possibly infinite tree with labeled branches whose nodes are program states and whose branches identify possible transitions labeled with their observations. We then consider two programs to be behaviorally equivalent if their derivation trees match up—that is, their trees are identical ignoring actual program states.

22


D-A-H ALT

halt

halt

−→

Ω

D-A-L ET-R EAD ?i

p[i/x ]

!i

p[0/ ]

let x = read () in p −→ D-A-L ET-W RITE

let = write (i ) in p −→ D-A-S KIP p−→ p0

p0 −→ p00 p −→ p00 α

α

Obs

3

α

::=

halt | ?i | !i

Figure 2.3: Labeled transition system for IL A

2.2.3

Static Semantics

We can come up with a static type system for IL A with simple types by performing a straightforward adaption of a type system with simple types for the lambda calculus of Church [Chu40] and Curry [CF58]. An overview over types and static typing of programming languages can be found in a textbook by Pierce [Pie02]. The type language and type environments are specified in Figure 2.4. The set of base types, BType, contains names representing different primitive values. We use the base type b to represent numerical values. Types, Type, consist of either base types or function types, τ −→ 0. We do not register result types of functions because IL A programs never return values, they either halt or diverge. Type environments are sequences of pairs of variable names and types. We can extend an existing type environment, Γ, by adding a new pair, Γ, x : τ. We further assume that all bindings in a type environment carry different names. To maintain this assumption when extending type environments, we possibly have to apply the variable convention first to rename bound variables. Type environments can thus be considered as finite maps. We abuse the notation Γ( x ) to look up a name in a sequence of bindings. There are three simultaneously defined least relations that specify the type derivations for expressions, statements and programs, respectively. • Γ À e : τ • Γ ` A d ⇒ Γ0 • Γ À p


23

BType Type

3 3

b τ

::=

b | τ −→ 0

base types types

TEnv

3

Γ

::=

∅ | Γ, x : τ

type environments

Figure 2.4: Type language of IL A

S-A-E XPR -VAR

Γ ` A x : Γ( x ) S-A-E XPR -C ONST

Γ À i : b S-A-E XPR -R EC

(∀k) Γ, f i : τi −→ 0, xk : τk ` A pk Γ ` A rec j f ( x ) = p : τj −→ 0 Figure 2.5: Typing rules for IL A expressions

These relations are specified by typing rules that are a standard adaption of the rules for the simply typed lambda calculus (see for example [Pie02]). What differs is that we strictly distinguish expressions, statements, and programs. Figure 2.5 shows the typing rules for expression judgment, Γ ` A e : τ.. The type of a variable is read from the type environment (S - A - EXPR - VAR), integer constants are of base type b (S - A - EXPR - CONST), and a group of recursive functions is typed by resorting to the typing of the function bodies (S - A - EXP - REC). Figure 2.6 shows the typing rules for the statement judgment, Γ ` A d ⇒ Γ0 . A statement d extends a type environment Γ to another type environment Γ0 . The typing of a binding x = e extends the type environment by the type of the expression e provided the expression is typeable (S - A - DEF - EXPR). The typing of primitive functions and operations requires that all arguments are typeable, (S - A - DEF - PFUN) and (S - A - DEF OP ), respectively. The type of arguments and results are restricted to base types in our presentation. Finally, Figure 2.7 shows the typing rules for program judgment, Γ ` A p. A halting program is always type correct (S - A - PROG - HALT). The (S - A - PROG - APP) rule handling jumps guarantees that the function type and the type of the arguments match up. The typing of a let expression combines the typing of its statement and its body (S - A - PROG - LET). The (S - A - PROG - IF) rule assures that conditional expressions are of base type b.

24


S-A-D EF -E XPR Γ À

e:τ Γ ` A x = e ⇒ Γ, x : τ

S-A-D EF -PF UN

Γ

À

(∀i ) Γ ` A ei : b x = pfun(ei ) ⇒ Γ, x : b

S-A-D EF -O P

Γ

À

(∀i ) Γ ` A ei : b x = op A (ei ) ⇒ Γ, x : b

Figure 2.6: Typing rules for IL A statements

2.2.4

Type Safety

As Robin Milner already put it in a concise slogan for the type system of Standard ML, “well typed programs cannot go wrong” [Mil78]. That this is really the case for a programming language is not obvious. A formal type soundness result is necessary to substantiate such a claim. There are several ways to formulate and prove a type soundness result, depending primarily on the style of dynamic semantic one uses. Wright and Felleisen [WF94] relate the different approaches. We follow what they call a syntactic approach using the dynamic semantics to prove a type soundness result for IL A . In particular, we follow Harper’s slogan saying that “safety is progress plus preservation” to formalize what it means that a program cannot go wrong in our setting [Har96]. A preservation result ensures that the property of well-typedness is preserved under reductions and transitions. A progress results is the manifestation of the second part, that such programs never go wrong. It tells us, that a well-typed program always leads to a correct transition unless it has finished. Wright and Felleisen’s original formulation uses the notion of stuck terms instead showing a progress result which can be seen as the contraposition. Before we state and prove the actual type safety result, we first consider some additional properties that we later employ. Lemma 2.1 Γ ` A Ω.

Lemma 2.2 If x 6≡ x 0 , and Γ, x : τ, x 0 : τ 0 ` A p, then Γ, x 0 : τ 0 , x : τ ` A p.

Lemma 2.3 If x 6≡ x 0 , and Γ, x : τ ` A x 0 : τ 0 , then Γ ` A x 0 : τ 0 .


25

S-A-P ROG -H ALT

Γ ` A halt S-A-P ROG -A PP Γ ` A e1 : τ −→ 0 Γ À e

Γ ` A e2 : τ 1 e2

S-A-P ROG -L ET Γ ` A d ⇒ Γ0

Γ

À

Γ0 ` A p let d in p

S-A-P ROG -I F

Γ À e : b Γ p1 Γ ` A p2 A Γ ` if e then p1 else p2

À

Figure 2.7: Typing rules for IL A programs A type inversion lemma tells us something about the structure of type derivations. We exemplarily formulate the inversion result for typings of recursive functions. Lemma 2.4 (Inversion Lemma) If Γ ` A rec j f ( x ) = p : τj −→ 0, then there exists τi , such that, for all i, it holds that Γ, f : τ −→ 0, xi : τi ` A pi .

We also show that typing is preserved when free variables are substituted by expressions of the same type. This property is later needed to prove that typings are preserved under reduction rules. Lemma 2.5 (Substitution Lemma) (i) If Γ, x : τ ` A e0 : τ 0 and Γ ` A e : τ, then Γ ` A e0 [e/x ] : τ 0 . (ii) If Γ, x : τ ` A p and Γ ` A e : τ, then Γ ` A p[e/x].

Proof. By simultaneous induction on the derivation of the typing. • Case (S-A-E XPR -VAR ). If x 6≡ x 0 , the result follows by applying Lemma 2.3. If x ≡ x 0 , then by (S-A-E XPR -VAR), we know that τ ≡ τ 0 . Hence, the result is just a recast of one of the assumptions, Γ ` A e : τ 0 . • Case (S-A-E XPR -C ONST ). Given Γ, x : τ ` A i : b. By (S-A-E XPR -C ONST), it also follows that Γ ` A i : b.

26

CHAPTER 2. BACKGROUND • Case (S-A-E XPR -R EC ). Suppose Γ, x : τ ` A rec j f ( x ) = p : τj −→ 0. We further assume that x 6≡ f , x, by conversion of bound variables. Applying the inversion lemma, we know that there exists τi , such that

(∀ j) Γ, x : τ, f i : τi −→ 0, x j : τ j ` A p j ,

(2.10)

(∀ j) Γ, f i : τi −→ 0, x j : τ j , x : τ ` A p j ,

(2.11)

by Lemma 2.2,

and hence by induction,

(∀ j) Γ, f i : τi −→ 0, x j : τ j ` A p j [e/x].

(2.12)

The result follows by applying (S-A-E XPR -R EC). • Case (S-A-P ROG -H ALT ). Obviously, it always holds that, Γ ` A halt. • Case (S-A-P ROG -A PP ). By inversion, we know that Γ ` A e1 : τ −→ 0

(2.13)

Γ ` A e2 : τ.

(2.14)

Γ ` A e1 [e/x] : τ −→ 0

(2.15)

Γ ` A e2 [e/x] : τ.

(2.16)

and

By induction, it holds that

and

The result follows by applying (S-A-P ROG -A PP) and using the definition of substitutions. • Case (S-A-P ROG -L ET ). By inversion, we know that Γ ` A d ⇒ Γ0

(2.17)

Γ0 ` A p.

(2.18)

and

Depending on the statement rule used, we have different subcases to consider.


27

– Subcase (S-A-Def-Expr). That is, Γ, x : τ ` A x 0 = e0 ⇒ Γ, x : τ, x 0 : τ 0 . By inversion, it holds that, Γ, x : τ ` A e0 : τ 0 ,

(2.19)

Γ ` A e0 [e/x ] : τ 0 ,

(2.20)

Γ ` A x 0 = e0 [e/x] ⇒ Γ, x 0 : τ 0 .

(2.21)


and (by ((S-A-D EF -E XPR ))),

For the second premise, Γ, x : τ, x 0 : τ 0 ` A p, it also holds, that Γ, x 0 : τ 0 , x : τ ` A p.

(2.22)

By induction, we then know, that Γ, x 0 : τ 0 ` A p[e/x].

(2.23)

The result follows by applying (S-A-P ROG -L ET). – Subcase (S-A-Def-PFun) and Subcase (S-A-Def-Op). Analogous to the previous case. • Case (S-A-P ROG -I F ). By inversion we know that Γ ` A e0 : b,

(2.24)

Γ ` A p1 ,

(2.25)

Γ ` A p2 .

(2.26)

Γ ` A e[e/x] : b,

(2.27)

Γ ` A p1 [e/x],

(2.28)

Γ ` A p2 [e/x ].

(2.29)

and

By induction, we follow, that

and

The result follows by applying the (S-A-P ROG -I F) rule again.

28


The following canonical forms lemma is a tool to later show the progress result. It tells us about the syntactical shape of closed terms of a certain type. Lemma 2.6 (Canonical Forms Lemma) (i) If ∅ ` A e : b, then e ≡ i. (ii) If ∅ ` A e : τ −→ 0, then e ≡ rec j f ( x ) = p.

Corollary 2.2 If ∅ ` A e : τ, then e is a value.

The part formalizing type preservation splits up into two parts. The property holds for both reductions and observable transitions. Lemma 2.7 (Type Preservation) (i) If Γ ` A p and p−→ p0 , then Γ ` A p0 . α (ii) If Γ ` A p and p−→ p0 , then Γ ` A p0 .

Proof. (i) We proceed by case analysis of the reduction, p−→ p0 . – Case (D-A-L ET-VAL ). The type judgment looks as follows. Γ ` A let x = v in p.

(2.30)

By inversion, using the (S-A-P ROG -L ET) and (S-A-D EF -E XPR) rules, we also know, that Γ ` A v : τ,

(2.31)

Γ, x : τ ` A p.

(2.32)

and

Applying the substitution lemma yields Γ ` A p[v/x].

(2.33)


29

– Case (D-A-PF UN ). The type judgment looks as follows. Γ ` A let x = pfun(i ) in p.

(2.34)

By inversion, using the (S-A-P ROG -L ET) and (S-A-D EF -PF UN) rules, we also know, that

(∀ j) Γ ` A i j : b,

(2.35)

Γ, x : b ` A p.

(2.36)

and

By using the (S-A-E XPR -C ONST) rule, we are able to deduce Γ ` A i : b.

(2.37)

Applying the substitution lemma yields Γ ` A p[i/x ].

(2.38)

– Case (D-A-I F -T RUE ). The type judgment looks as follows. Γ ` A if i then p1 else p2 .

(2.39)

By inversion, using (S-A-P ROG -I F), we also know, that Γ ` A p1 .

(2.40)

– Case (D-A-I F -FALSE ). Analogous to the previous case. – Case (D-A-A PP ). The type judgment looks as follows. Γ ` A (rec j f ( x ) = p) v.

(2.41)

Γ ` A rec j f ( x ) = p : τj −→ 0

(2.42)

Γ ` A v : τj .

(2.43)

By inversion, it holds that

and

Applying the inversion lemma on the first part tells us, that for all i, it holds that Γ, f : τ −→ 0, xi : τi ` A pi .

(2.44)

By applying (S-A-E XPR -R EC), it also holds for all i, that Γ ` A reci f ( x ) = p : τi −→ 0.

(2.45)

30

CHAPTER 2. BACKGROUND For j, and by possibly renaming bound variable, we are to able to apply Lemma 2.2 resulting in Γ, x j : τj , f : τ −→ 0 ` A p j .

(2.46)

Applying the substitution lemma leads to Γ, x j : τj ` A p j [reci f ( x)= p/ f i ].

(2.47)

Γ ` A p j [reci f ( x)= p/ f i ][v/x ].

(2.48)

and

(ii) We proceed by induction on the derivation of the reduction, p−→ p0 . α

– Case (D-A-H ALT ). The typing Γ ` A Ω follows by Lemma 2.1. – Case (D-A-L ET-R EAD ). The type judgment looks as follows. Γ ` A let x = read () in p

(2.49)

Γ À i : b

(2.50)

Γ, x : b ` A p.

(2.51)

We know that

and, by inversion, also

holds. Applying the substitution lemma leads to the result Γ ` A p[i/x ].

(2.52)

– Case (D-A-L ET-W RITE ). Analogously to the previous case. – Case (D-A-S KIP ). By inversion of the reduction rule, it follows that p−→ p0

(2.53)

α p0 −→ p00 .

(2.54)

and

By induction, it follows that Γ ` A p0 and Γ ` A p00 .

The progress result also very easily follows by using the inversion property and the canonical forms lemma. Lemma 2.8 (Progress) If ∅ ` A p, then there exists p0 with either p−→ p0 or p −→ p0 . α


31

Proof. We proceed by induction on the type derivation. • Case (S-A-P ROG -H ALT ). The (D-A-H ALT) rule applies. • Case (S-A-P ROG -A PP ). By inversion, we know that ∅ ` A e1 : τ −→ 0

(2.55)

∅ ` A e2 : τ.

(2.56)

e1 ≡ rec j f ( x ) = p,

(2.57)

e2 ≡ v.

(2.58)

By Lemma 2.6, it follows that

Hence, rule (D-A-A PP) applies. • Case (S-A-P ROG -L ET ) AND (S-A-D EF -E XPR ). By inversion, we know that ∅ ` A e : τ.

(2.59)

By Corollary 2.2, it follows, that e is a value. Hence, rule (D-A-L ET-VAL) applies. • Case (S-A-P ROG -L ET ) AND (S-A-D EF -PF UN ). By inversion, we know that

(∀ j) ∅ ` A e j : b.

(2.60)

By Lemma 2.6, it follows, that for each j, it holds that e j ≡ i j . Hence, rule (D-APF UN) applies. • Case (S-A-P ROG -L ET ) AND (S-A-D EF -O P ). Analogous to the previous case. Either rule (D-A-L ET-R EAD) or rule (D-A-L ET-W RITE) applies. • Case (S-A-P ROG -I F ). By inversion, we know that ∅ ` A e : b.

(2.61)

By Lemma 2.6, it follows, that e ≡ i. Hence, either rule (D-A-I F -T RUE) or rule (D-A-I F -FALSE) applies.

32

2.2.5


Bisimilarity

Bisimulations are used to formalize the equivalences between (labeled) state transition systems by associating systems that show the same observable behavior. More particular, we say that two systems are bisimilar, if we can simulate each transition step of one system by one of the other system and vice versa. The presentation of bisimilarity we use in our work is based on Milner’s formulation of bisimulations for his process calculus CCS [Mil89] and Crole and Gordon’s adaptation to functional programming languages with imperative features, namely I/O operations [CG95]. In this section, we introduce the ideas and methods of bisimilarity using the intermediate language IL A . For now, we present only some basic definitions. Actual results and applications using bisimilarity for a similar language are presented in a later chapter (see Section 3.2.6) or can be found elsewhere (see for example [CG95, Gor99]). As already mentioned in Section 2.2.2 where we defined the dynamic semantics of IL A , we would like to consider two programs as behaviorally equivalent if their derivations trees both have an identical structure sharing identical observations labeling state transitions. To formalize what it means that two derivation trees share the same structure, we now define two functionals on the binary relations over programs that help us to pin down a specification of our intuition of two derivation trees of identical structure. Definition 2.5 The functions, d·e, [·] ∈ BinProgRel → BinProgRel, where BinProgRel = P (Prog × Prog), are defined as follows.

dRe

=

{( p1 , p2 ) | if p1 −→ p10 , α then there exists a p20 with p2 −→ p20 and ( p10 , p20 ) ∈ R}

[R]

=

dRe ∩ dR−1 e−1

α

The dRe function helps to identify those states of a derivation tree that reach after one simulation step two states that are related by a given relation R. The [R] function allows us to also consider the other simulation direction; it captures the symmetric closure of dRe. We could now be content to just say that we call every relation that is a fixed point of function [·] a behavioral equivalence. Unfortunately, this is not a good enough specification, because—as you can easily check—even the empty relation fulfills our criterion. What we really want is, as Milner already noted in his work about CCS, we want to call equal as many programs as possible as long as they just also obey the bisimulation criterion from above. In other words, what we are really looking for is the greatest relation that obeys our specification. More formally, this is defined as follows. Definition 2.6 The bisimilarity relation, ≈∈ BinProgRel is the union of all [·]-dense relations.


33

The Knaster-Tarski theorem now immediately tells us that the ≈ relation exactly coincides with the greatest fixed point of function [·]. Also we now know that bisimilarity admits proofs by using the principle of co-induction. Using the principle of co-induction, it is straightforward to prove that bisimilarity is also an equivalence. It is important to note that the choice of the observation language and the choice of the labeled transition system determines the properties of the induced equivalence relation. Considering only some observations as important and considering others as silent when defining a program equivalence is sometimes called weak bisimulation. For applicative bisimilarity, on the other hand, only applicative contexts are considered to register observations. There are other approaches to define the equality of programs that we do not pursue in our work. It is also common to relate programs via a mapping into a denotational model. Another approach considers programs equal if they cannot be told apart by any program context whatsoever, known as contextual equivalence [Mor68] or observational congruence [MC88, Mil89]. It is also common to show the soundness (and completeness) of bisimilarity with respect to another notion of equality such as contextual equivalence or a denotational model. Note, however, that in case of our intermediate languages contexts are not enough to tell programs apart with different I/O behavior. Crole and Gordon use, besides observations, a denotational semantics to relate imperative programs with I/O effects [CG95].

34


Chapter 3

From Sequential Programs to Multi-Tier Applications by Program Transformation In this chapter, we develop the formal background of a transformation scheme that transforms a sequential program with correct location annotations into a behaviorally equivalent, concurrent program that, when executed, runs separate processes on each location and communicates via statically typed channels. In the first section of this chapter, in Section 3.1, we start with specifying the source language of our transformation scheme, ILB . The ILB calculus is an extension of IL A . More precisely, ILB enriches IL A operations by location annotations and adds explicit data transfer statements to the language. The language is formalized by giving a formal syntax and semantics. Section 3.2 formalizes the channel introduction step and channel pooling step of the transformation scheme. We introduce a first intermediate language, ILC , that adds explicit communication channels to the language instead of “one-shoot” data transfer operations. Besides the formal syntax and semantics of the language, we show how to translate ILB programs into ILC , and develop an equational theory for ILC that enables us to simplify ILC programs. In addition to a standard type soundness result, we also prove a soundness result of our equational theory using bisimulations. Section 3.3 formalizes the port introduction step and port floating step of the transformation scheme. The intermediate language ILD , which we introduce in this section, is a slight extension of ILC . It extends ILC by explicit port names. We later use port names to address a channel coming from two different locations. In addition to the formal syntax and semantics, we also state an equational theory for ILD that helps us to simplify port constructs of the language. Finally, Section 3.4 formalizes the splitting transformation step of the transformation scheme. The section starts with a specification of the target language, ILE . The ILE calculus is a concurrent programming language with explicit synchronized channels between processes running on different locations. A translation from ILD into ILE is 35

36

CHAPTER 3. PROGRAM TRANSFORMATION SCHEME

given that splits up ILD programs into program slices that each run on a different location and only executes those operations necessary for continuing the computation on each particular location. We conclude the chapter by discussing related work. A preliminary version of this chapter has been published before in collaboration with Thiemann [NT05].

3.1

The ILB Calculus — Sequential Programming with Locations

Programs written in IL A solely express computations with side effects. In IL A , no provision is made to express on which locations certain values reside or on which locations certain operations are supposed to execute. In this section, we extend IL A to ILB . The additional feature of the ILB calculus allows us to express that certain computations run on specific locations (i.e., tiers). In ILB , only one program is executing with one centralized locus of control. However, at each location only a subset of the program’s effect will be visible. Values of variables are only available on a subset of locations, some operations are only available at specific locations, and data must be moved explicitly from one location to another. In the rest of this section, we first introduce the dynamic semantics of ILB in terms of a labeled transition system. Next, we present a type system with effect annotations that tracks possible locations of values in addition to their actual type. The type system extends the system of simple types presented in Section 2.2 with location annotations and annotation subtyping. Besides other properties of the system, we prove a type soundness result for ILB and show that an annotation erasure function preserves typing, as well.

3.1.1

Syntax

The syntax for the ILB calculus is derived from the IL A calculus. There is an additional statement expressing the transfer of values and one additional modification, the addition of location annotations. Grammar rules of ILB are presented in Figure 3.1. Locations are members of a denumerable set of location names, N , and are typically denoted by A or B. Sets of locations are denoted by N. Each effectful operation is clearly marked where it executes. The statement x = op A (e) performs effectful operation op on location A. The actual parameters, e, must be available at A to execute the operation. Afterwards, the result of the operation is available at location A only. Likewise, the side effect of op A (e) is visible on location A but not on any other location. If we want to execute an operation on a certain location, A, but not all of its arguments are available on that particular location, we will first have to transfer the missing arguments to A. The second addition to the source language permits us to do so. The statement x = trans[ A;B] e transmits the value of e from location A to location B. The value of e must be available at A to transmit it to B. Afterwards, the value is available through x at location B as well as at all locations at which it was available

3.1. THE ILB CALCULUS

37

N P (N )

3 3

A, B, . . . N, . . .

Z Var FIndex POp EOp Op

3 3 3 3 3 3

i, . . . f , g, x, y, z, . . . j, . . . pfun, . . . op, . . . op ::= op A | pfun

Val

3

v

::= |

iN rec j f ( x ) = p

Expr

3

e

::=

x|v

Def

3

d

::= |

x=e x = op (e)

Prog

3

p

|

x = trans[ A;B] e

::= | | |

halt ee let d in p if e then p else p

Figure 3.1: Syntax of ILB through y. Typically, the trans statement is used with x ≡ y so that it just extends the availability of x to include B. Only base values can be transmitted between locations. Functions or pointers (references) cannot be transmitted. A value can be either a constant i annotated with a set of locations N, which indicates where the value is available, or it can be a function consisting of a set of mutually recursive function definitions and one designated entry function f j (indicated by a subscript j). Functions do not carry a set of locations because they are assumed to be available at all locations.

3.1.2

Dynamic Semantics

To express the dynamic semantics of ILB , we first define a small-step reduction relation, −→ ⊆ Prog × Prog. The reduction rules representing effect-free computation steps are shown in Figure 3.2. Besides a beta-value reduction rule (D-B-L ET-VAL), there is a rule to handle primitive functions (D-B-PF UN). The reduction rules assure that a result is only available on a location where all arguments are available. The result of the function is determined by a

38


D-B-L ET-VAL

let x = v in p −→ p[v/x] D-B-PF UN

let x = pfun(i N ) in p −→ p[i N/x ] T

if i = δpfun (i ) and

T

N 6= ∅

D-B-I F -T RUE

if i 6= 0 and N 6= ∅

if i N then p1 else p2 −→ p1 D-B-I F -FALSE

if N 6= ∅

if 0 N then p1 else p2 −→ p2 D-B-A PP

(rec j f ( x ) = p) v −→ p j [reci

f ( x )= p/ f i ][v/x ]

D-B-T RANS

let x = trans[ A;B] (i N ) in p −→ p[i N ∪{B}/x]

if A ∈ N

Figure 3.2: Reduction rules for ILB

partial function, δpfun , as long as at least on one location the calculation is possible. The rules handling conditionals and function application, (D-B-I F -T RUE), (D-BI F -FALSE) and (D-B-A PP), work almost as before. The rules handling conditionals additionally assure that a condition value is available at some locations. The (D-B-T RANS) rule handling communication changes location annotations according to the given transfer instruction. To examine the behavioral equivalence of programs, we fix the set of effectful operations we consider to two I/O operations, read and write. We use a labeled transition system indexed by atomic observations that may be observed of a program. The set of observations, Obs, and transition rules are shown in Figure 3.3. The labeled transition α system comprises a family of relations indexed by observations, −→⊆ Prog × Prog, which are the least relations defined by these rules. An halt observation indicates that a program reached the halt state, ?i A , that a number i is read on location A, and !i A an output of i on location A. With locs(α), we denote the set of locations involved in observation α. That is, locs(halt) = ∅, and locs(?i A ) = { A}. The (D-B-H ALT) rule makes a transition to Ω ensuring that no further observations are possible. The (D-B-L ET-R EAD) and (D-B-L ET-W RITE) rules specify transitions with I/O effects. Note that outputting a number on location A is only possible if the value is available on location A. By convention, outputting a number always returns the 0 value. The last rule, (D-B-S KIP), allows to perform arbitrary regular reductions before doing an observable transition.


39

D-B-H ALT halt

−→

halt D-B-L ET-R EAD

?i A

let x = read A () in p −→ D-B-L ET-W RITE

!i A

let x = write A (i N ) in p −→

Ω p[i{ A}/x] p[0{ A}/x]

if A ∈ N

D-B-S KIP α p−→ p0 p0 −→ p00 α p −→ p00

Obs

3

α

::=

halt | ?i A | !i A

Figure 3.3: Labeled transition system for ILB

3.1.3

Static Semantics

The type system for ILB is an adaptation of the static semantics for IL A , as well. The type system now has to model two facets of each value: its shape and the locations where it is available. It keeps track of the shape using the existing simply-typed system and adds location annotations and effects to keep track of the locations. Additionally, annotation subtyping is employed to produce more precise analysis results [TJ95]. The type language and type environments are given by the grammars shown in Figure 3.4. An annotated type, τ, is either a base type b paired with a set of locations N or a function type with a location set N as latent effect. The meaning of an annotation N is that the associated data item must be present at all locations in N. The effect on a function type indicates the set of locations that may execute operations when the function is applied. We denote by locs(τ ) the location annotation of a type, that is locs(b N ) = N and N

locs(τ −→ 0) = N. There are four, inductively defined, typing judgments. • ` B τ ≤ τ specifies a subtyping relation. • Γ ` B e : τ infers the type for an expression found in argument position. • Γ ` B d ⇒ Γ0 ! N states that d transforms Γ to Γ0 and may perform operations at locations N.

40


BType

3

b

base types N

AType

3

τ

::=

bN

TEnv

3

Γ

::=

∅ | Γ, x : τ

| τ −→ 0

annotated types type environments

Figure 3.4: Type language of ILB S UB -B-B ASE

N1 ⊇ N2 ` B b N1 ≤ b N2 S UB -B-F UN `B τ2 ≤ τ1 N1 ` B τ 1 −→ 0

N2 ⊇ N1 N

2 ≤ τ 2 −→ 0

Figure 3.5: Subtyping rules for ILB • Γ ` B p ! N states that p may need variables in Γ and may perform operations at locations N. Subtyping in the system, presented in Figure 3.5, is structural and induced solely by the location annotations. The judgment ` B τ ≤ τ 0 expresses that a value that is present at location set N can substitute for a value that is only expected at a subset N 0 ⊆ N. Also, the effect annotation of a subtype must be included in the annotation of the supertype. Figures 3.6, 3.7, and 3.8 show the typing rules for expressions, statements and programs, respectively. The (S-B-E XPR -R EC) rule types groups of recursive functions. Each body of a function of a recursive group must be typeable assuming suitable function types for all other functions of the recursive group. Effects, that is possible locations, of a body are registered as latent effect on the function type. The resulting type of the whole group agrees with the type of the entry function of the whole group. A subsumption rule, (S-B-E XPR -S UB), is also present allowing us to type typeable expressions with supertypes as well. The rules for primitive functions, operations and transfer operations, (S-B-D EF PF UN), (S-B-D EF -O P) and (S-B-D EF -T RANS), reflect their operational semantics but use subtyping to intersect the location sets implicitly. The x = trans[ A;B] e statement copies the value of e (which must be available at location A) to location B and binds it to x with appropriately changed type. Only effectful operations result in a non-empty location effect. The halt expression has neither requirements nor does it perform an effect at any location (S-B-P ROG -H ALT).


41

S-B-E XPR -VAR

S-B-E XPR -C ONST

Γ ` B x : Γ( x )

Γ `B i N : bN

S-B-E XPR -R EC N

i 0, xk : τk ` B pk ! Nk (∀k) Γ, f i : τi −→

Nj

Γ ` B rec j f ( x ) = p : τj −→ 0 S-B-E XPR -S UB Γ `B e : τ

Γ

`B

τ ≤ τ0 e : τ0

Figure 3.6: Typing rules for ILB expressions The rule for function application, (S-B-P ROG -A PP), additionally unleashes the latent location effect of the function registered on the function type. The effect of a let statement, specified by (S-B-P ROG -L ET), is the union of the effects of the statement and the body expression. A conditional, (S-B-P ROG -I F), needs only be executed on a location if one of the branches contains code to be executed on that location. Hence, the value of the condition needs only be available on the locations mentioned in the effect of the branches.

3.1.4

Properties

Before we turn to a type soundness result for the ILB calculus, we first state some additional, useful properties. The properties can by proven by simple induction. Lemma 3.1 Γ ` B Ω ! ∅.

Lemma 3.2 If x 6≡ x 0 , and Γ, x : τ, x 0 : τ 0 ` B p ! N, then Γ, x 0 : τ 0 , x : τ ` B p ! N.

Lemma 3.3 If x 6≡ x 0 , and Γ, x : τ ` B x 0 : τ 0 , then Γ ` B x 0 : τ 0 .

To be able to later prove that types are preserved under reductions we continue with an inversion result for expression typings. Lemma 3.4 (Inversion Lemma) 0

(i) If Γ ` B i N : b N , then N ⊇ N 0 .

42


S-B-D EF -E XPR

Γ

`B

Γ `B e : τ x = e ⇒ Γ, x : τ ! ∅

S-B-D EF -PF UN

(∀i ) Γ ` B ei : b N N 6= ∅ Γ ` B x = pfun(ei ) ⇒ Γ, x : b N ! ∅ S-B-D EF -O P

(∀i ) Γ ` B ei : b{ A} Γ ` B x = op A (ei ) ⇒ Γ, x : b{ A} ! { A} S-B-D EF -T RANS

Γ

`B

Γ `B e : bN A∈N [ A;B ] x = trans e ⇒ Γ, x : b N ∪{ B} ! ∅

Figure 3.7: Typing rules for ILB statements Nj0

(ii) If Γ ` B rec j f ( x ) = p : τj0 −→ 0, then there exists τi , Ni , such that, N

• for all i, it holds that Γ, f : τ −→ 0, xi : τi ` B pi ! Ni , • τj0 ≤ τj , Nj0 ⊇ Nj .

Next is a substitution lemma. It is almost identical to the one we formulated for IL A (Lemma 2.5). Location effects are the only addition. Lemma 3.5 (Substitution Lemma) (i) If Γ, x : τ ` B e0 : τ 0 , and Γ ` B e : τ, then Γ ` B e0 [e/x] : τ 0 . (ii) If Γ, x : τ ` B p ! N, and Γ ` B e : τ, then Γ ` B p[e/x] ! N.

Proof. By simultaneous induction on the derivation of the typing judgment. • Case (S-B-E XPR -VAR ). If x 6≡ x 0 , the result follows by applying Lemma 3.3. If x ≡ x 0 , then by (S-B-E XPR -VAR), we know that τ ≡ τ 0 . Hence, the result is just a recast of one of the assumptions, Γ ` B e : τ 0 . • Case (S-B-E XPR -C ONST ). Given Γ, x : τ ` B i N : b N . By (S-B-E XPR -C ONST), it also follows that Γ ` B i N : b N .


43

S-B-P ROG -H ALT

Γ ` B halt ! ∅ S-B-P ROG -A PP N

Γ ` B e2 : τ Γ ` B e1 : τ −→ 0 B Γ ` e1 e2 ! N S-B-P ROG -L ET Γ ` B d ⇒ Γ0

Γ

`B

! Nd Γ 0 ` B p ! Np let d in p ! Nd ∪ Np

S-B-P ROG -I F Γ `B e :

bN N1 , N2 ⊆ N 6= ∅ Γ p1 ! N1 Γ ` B p2 ! N2 B Γ ` if e then p1 else p2 ! N1 ∪ N2

`B

Figure 3.8: Typing rules for ILB programs N0

j • Case (S-B-E XPR -R EC ). Suppose Γ, x : τ ` B rec j f ( x ) = p : τj0 −→ 0. We further

assume that x 6≡ f , x, by conversion of bound variables. Applying the inversion lemma, we know that there exists τi , such that N

i (∀ j) Γ, x : τ, f i : τi −→ 0, x j : τ j ` A p j ,

(3.1)

by Lemma 3.2, N

i 0, x j : τ j , x : τ ` A p j , (∀ j) Γ, f i : τi −→

(3.2)

and hence by induction, N

i (∀ j) Γ, f i : τi −→ 0, x j : τ j ` A p j [e/x].

(3.3)

By applying (S-B-E XPR -R EC), it follows that Nj

Γ ` B rec j f ( x ) = p[e/x ] : τj −→ 0

(3.4)

The result follows by applying (S UB -B-F UN) and (S-B-E XPR -S UB). • Case (S-B-E XPR -S UB ). By inversion, we know that Γ, x : τ ` B e0 : τ 00

(3.5)

` B τ 00 ≤ τ 0 .

(3.6)

and

44

CHAPTER 3. PROGRAM TRANSFORMATION SCHEME By induction, it follows that Γ ` B e0 [e/x] : τ 00 .

(3.7)

The result follows by (S-B-E XPR -S UB). • Case (S-B-P ROG -H ALT ). Obviously, it always holds that, Γ ` B halt ! ∅. • Case (S-B-P ROG -A PP ). By inversion, we know that N

Γ ` B e1 : τ −→ 0

(3.8)

Γ ` B e2 : τ.

(3.9)

and

By induction, it holds that N

Γ ` B e1 [e/x] : τ −→ 0

(3.10)

Γ ` B e2 [e/x ] : τ.

(3.11)

and

The result follows by applying (S-B-P ROG -A PP) and using the definition of substitutions. • Case (S-B-P ROG -L ET ). By inversion, we know that Γ, x : τ ` B d ⇒ Γ0 ! Nd

(3.12)

Γ 0 ` B p ! Np .

(3.13)

and

Depending on the statement rule used, we have different subcases to consider. – Subcase (S-B-Def-Expr). That is, Γ, x : τ ` B x 0 = e0 ⇒ Γ, x : τ, x 0 : τ 0 ! ∅. By inversion, it holds that, Γ, x : τ ` B e0 : τ 0 ,

(3.14)

Γ ` B e0 [e/x] : τ 0 ,

(3.15)

Γ ` B x 0 = e0 [e/x] ⇒ Γ, x 0 : τ 0 ! ∅.

(3.16)


and (by ((S-B-D EF -E XPR ))),


45

The second premise, Γ, x : τ, x 0 : τ 0 ` B p ! Np , is equivalent to Γ, x 0 : τ 0 , x : τ ` B p ! Np .

(3.17)

By induction, we then know, that Γ, x 0 : τ 0 ` B p[e/x] ! Np .

(3.18)

The result follows by applying (S-B-P ROG -L ET). – Subcase (S-B-Def-PFun), Subcase (S-B-Def-Op), and Subcase (S-B-Def-Trans). Analogous to the previous case. • Case (S-B-P ROG -I F ). By inversion we know that Γ ` B e0 : b N ,

(3.19)

Γ ` B p1 ! N1 ,

(3.20)

Γ ` B p2 ! N2 .

(3.21)

Γ ` B e[e/x] : b N ,

(3.22)

Γ ` B p1 [e/x] ! N1 ,

(3.23)

Γ ` B p2 [e/x] ! N2 .

(3.24)

and

By induction, we follow, that

and

The result follows by applying the (S-B-P ROG -I F) rule again.

To be later able to prove that well-typed programs never get stuck we also prove a canonical forms lemma for ILB . Lemma 3.6 (Canonical Forms Lemma) (i) If ∅ ` B e : b N , then e ≡ i M for some i, M. N

(ii) If ∅ ` B e : τ −→ 0, then e ≡ rec f ( x ) = p.

Corollary 3.1 If ∅ ` B e : τ, then e is a value.

46


Both the reduction relation and also the labeled transition system obey a type preservation result. The proof is similar to the proof for IL A . Additionally, subtyping must be taken into account on several points. Location effects in the judgments of the conclusions are possibly smaller than in the assumptions which is due to the lack of an explicit subeffecting rule. Lemma 3.7 (Type Preservation) (i) If Γ ` B p ! N and p−→ p0 , then Γ ` A p0 ! N 0 and N ⊇ N 0 . α (ii) If Γ ` B p ! N and p−→ p0 , then Γ ` B p0 ! N 0 , N ⊇ N 0 , and locs(α) ⊆ N.

Proof. (i) We proceed by case analysis of the reduction, p−→ p0 . – Case (D-B-L ET-VAL ). The type judgment looks as follows. Γ ` B let x = v in p ! Np .

(3.25)

By inversion, using the (S-B-P ROG -L ET) and (S-B-D EF -E XPR) rules, we also know that Γ `B v : τ

(3.26)

Γ, x : τ ` B p ! Np .

(3.27)

and

Applying the substitution lemma yields Γ ` B p[v/x] ! Np .

(3.28)

– Case (D-B-PF UN ). The type judgment looks as follows. Γ ` B let x = pfun(i N ) in p ! Np .

(3.29)

By inversion, using the (S-B-P ROG -L ET) and (S-B-D EF -PF UN) rules, we also know that

(∀ j) Γ ` B i j Nj : b N

(3.30)

Γ, x : b ` B p ! Np .

(3.31)

and


47

The inversion lemma tells us that

(∀ j) Nj ⊇ N. Hence,

T

(3.32)

Nj ⊇ N, and Γ `B i

T

Nj

: bN .

(3.33)

Γ ` B p[i/x ] ! Np .

(3.34)

Applying the substitution lemma yields

– Case (D-B-I F -T RUE ). The type judgment looks as follows. Γ ` B if i N then p1 else p2 ! N1 ∪ N2 .

(3.35)

By inversion, using (S-B-P ROG -I F), we also know that Γ ` B p1 ! N1

(3.36)

N1 ⊆ N1 ∪ N2 .

(3.37)

and clearly

– Case (D-B-I F -FALSE ). Analogous to the previous case. – Case (D-B-A PP ). The type judgment looks as follows. Γ ` B (rec j f ( x ) = p) v ! Nj0 .

(3.38)

The inversion lemma applied to the first premise tells us that, for all i, it holds that N

i Γ, f : τ −→ 0, xi : τi ` B pi ! Ni ,

(3.39)

τj0 ≤ τj ,

(3.40)

Nj0 ⊇ Nj .

(3.41)

By inversion, it also holds that Γ ` B v : τj0 .

(3.42)

By applying (S-B-E XPR -R EC), it also holds for all i, that N

i Γ ` B reci f ( x ) = p : τi −→ 0.

(3.43)

For j, and by possibly renaming bound variable, we are to able to apply Lemma 2.2 resulting in N

Γ, x j : τj , f : τ −→ 0 ` B p j ! Nj .

(3.44)

48

CHAPTER 3. PROGRAM TRANSFORMATION SCHEME Applying the substitution lemma leads to Γ, x j : τj ` B p j [reci f ( x)= p/ f i ] ! Nj .

(3.45)

Γ ` B p j [reci f ( x)= p/ f i ][v/x ] ! Nj .

(3.46)

and

– Case (D-B-T RANS ). The type derivation looks as follows. Γ ` B let x = trans[ A;B] i N in p ! Np .

(3.47)

By inversion, we know that Γ ` B i N : b N1 , Γ, x : b

N1 ∪{ B}

(3.48)

B

` p ! Np .

(3.49)

The first premise tell us that N ⊇ N1 , hence N ∪ { B} ⊇ N1 ∪ { B}. By subtyping, it holds that Γ ` B i N ∪{ B} : b N1 ∪{ B} .

(3.50)

The result follows by applying the substitution lemma. (ii) We proceed by induction on the derivation of the reduction, p−→ p0 . α

– Case (D-B-H ALT ). The typing Γ ` B Ω ! ∅ follows by Lemma 3.1. – Case (D-B-L ET-R EAD ). The type judgment looks as follows. Γ ` B let x = read A () in p ! { A} ∪ Np

(3.51)

Γ ` B i { A} : b{ A}

(3.52)

Γ, x : b{ A} ` B p ! Np .

(3.53)

We know that

and, by inversion, that

Applying the substitution lemma leads to the result Γ ` B p[i/x ] ! Np .

(3.54)

Np ∪ { A } ⊇ Np ,

(3.55)

locs(α) = locs(?i A ) = { A} ⊆ { A} ∪ Np .

(3.56)

It obviously holds that

and


49

– Case (D-B-L ET-W RITE ). Analogously to the previous case. – Case (D-B-S KIP ). By inversion of the reduction rule, it follows that p−→ p0

(3.57)

α p0 −→ p00 .

(3.58)

and

By induction, it follows that Γ ` B p0 ! N 0 ,

(3.59)

0

(3.60)

N⊇N and

Γ ` B p00 ! N 00 ,

(3.61)

N 0 ⊇ N 00

(3.62)

locs(α) ⊆ N 0 .

(3.63)

Hence Γ ` B p00 ! N 00 ,

(3.64)

N ⊇ N 00

(3.65)

locs(α) ⊆ N.

(3.66)

A progress result holds as well. Well-typed programs never terminate, they either reduce forever or can further react to I/O operations. Lemma 3.8 (Progress) If ∅ ` B p ! N, then there exists p0 with either p−→ p0 or p −→ p0 . α

Proof. We proceed by induction on the type derivation. • Case (S-B-P ROG -H ALT ). The (D-B-H ALT) rule applies. • Case (S-B-P ROG -A PP ). By inversion, we know that N

∅ ` B e1 : τ −→ 0

(3.67)

∅ ` B e2 : τ.

(3.68)

e1 ≡ rec j f ( x ) = p,

(3.69)

e2 ≡ v.

(3.70)

By Lemma 3.6, it follows that

Hence, rule (D-B-A PP) applies.

50

CHAPTER 3. PROGRAM TRANSFORMATION SCHEME • Case (S-B-P ROG -L ET ) AND (S-B-D EF -E XPR ). By inversion, we know that ∅ ` B e : τ.

(3.71)

By Corollary 3.1, it follows that e is a value. Hence, rule (D-B-L ET-VAL) applies. • Case (S-B-P ROG -L ET ) AND (S-B-D EF -PF UN ). By inversion, we know that

(∀ j) ∅ ` B e j : b N ,

(3.72)

N 6= ∅.

(3.73) N

By Lemma 3.6, it follows that for each j, it holds that e j ≡ i j j . Hence,

(∀ j) Nj ⊇ N 6= ∅,

(3.74)

and \

Nj ⊇ N 6= ∅.

(3.75)

Hence, rule (D-B-PF UN) applies. • Case (S-B-P ROG -L ET ) AND (S-B-D EF -O P ). Analogous to the previous case. Either rule (D-B-L ET-R EAD) or rule (D-B-L ET-W RITE) applies. • Case (S-B-P ROG -L ET ) AND (S-B-D EF -T RANS ). By inversion, we know that ∅ `B e : bN ,

(3.76)

A ∈ N.

(3.77)

By Lemma 3.6, it follows, that 0

e ≡ i N , N 0 ⊇ N.

(3.78)

Hence, A ∈ N 0 , and rule (D-B-T RANS) applies. • Case (S-B-P ROG -I F ). By inversion, we know that ∅ `B e : bN ,

(3.79)

N 6= ∅.

(3.80)

0

By Lemma 3.6, it follows, that e ≡ i N and N 0 ⊇ N. Hence, either rule (D-B-I F T RUE) or rule (D-B-I F -FALSE) applies.


51

AJb N K

=

b

=

AJΓ, x : τK

=

AJτK −→ 0

N

AJτ −→ 0K

AJΓK, x : AJτK

AJi N K

= =

AJxK

i rec j f ( x ) = AJpK

=

x

= = = = = = =

halt AJe0 K AJei K let x = AJeK in AJpK let x = pfun(AJei K) in AJpK let x = op (AJei K) in AJpK let x = AJeK in AJpK if AJeK then AJp1 K else AJp2 K

AJrec j f ( x ) = pK

AJhaltK AJe0 ei K AJlet x = e in pK AJlet x = pfun(ei ) in pK AJlet x = op A (ei ) in pK AJlet x = trans[ A;B] e in pK AJif e then p1 else p2 K

Figure 3.9: Annotation erasure for ILB programs

3.1.5

Translation

Comparing a ILB program with its underlying IL A program requires an erasure function, A, that maps a ILB program to a IL A program by forgetting about locations and removing all trans statements. On types, the erasure function strips away all location sets and all effects. The actual mapping of types, type assignments, values, expressions, and programs, respectively, can be found in Figure 3.9. Erasure has the following properties with respect to the underlying unannotated calculus, IL A . They are both proven by simultaneous induction on the type derivation of type judgments that belong to the premises. For the first direction, we construct a derivation along the result of the erasure function. Lemma 3.9 (i) If Γ0 ` B e0 : τ 0 , then AJΓ0 K ` A AJe0 K : AJτ 0 K. (ii) If Γ0 ` B p0 ! N 0 , then AJΓ0 K ` A AJp0 K.

For the second direction, we construct a derivation carrying a uniform location annotation, A, to prevent the need for transfer statements or subtyping. Lemma 3.10

52

CHAPTER 3. PROGRAM TRANSFORMATION SCHEME (i) If Γ ` A e : τ, then there exists some Γ0 , e0 , and τ 0 such that Γ0 ` B e0 : τ 0 and AJΓ0 K ≡ Γ, AJe0 K ≡ e, and AJτ 0 K ≡ τ.

(ii) If Γ ` A p, then there exists some Γ0 , p0 , and N 0 such that Γ0 ` B p0 ! N 0 and AJΓ0 K ≡ Γ and AJp0 K ≡ p.

3.2

The ILC Calculus — Sequential Programming with Channels

The “multi-tier” calculus, ILC , is our first calculus with explicit communication instructions. In the previous calculus, ILB , the statement x = trans[ A;B] e just states the necessity of a communication between nodes A and B in a declarative way. In contrast, ILC augments x = trans[ A;B] e with a channel argument and provides primitives to explicitly open and close a communication channel. In this section, we start with introducing the formal syntax and dynamic semantics of the ILC calculus. As before, we use a small-step reduction semantics to model effect-free reduction steps, and a labeled transition system to give I/O operations some meaning. The static semantics for ILC uses session types to model the communication behavior of communication channels. Besides stating and proving a standard type soundness result for ILC , we further give a simple, type-preserving translation from ILB to ILC and present an equational theory for ILC . The section ends with a proof that the equational rules of our equational theory obey a notion of bisimilarity.

3.2.1

Syntax

The syntax of ILC extends ILB by constructs for the aforementioned features of ILC , namely explicit channel primitives. The grammar rules of ILC can be found in Figure 3.10. The main extension of this calculus with respect to IL A consists of statements to open a channel (open), to transfer data via a connection (trans), and close the connection (close). In comparison to ILB , the trans statement obtains a channel parameter and functions receive additional channel parameters c. A channel value cannot be bound to a normal variable because the channel changes its type with every communication step. Channel variables are treated linearly to simplify the tracking of the change of type. Channel variables, c, are members of a separate syntactic category, CVar. In addition, the statement, c{l1 }, applies a channel, c, to a statically known label, l1 . Like a type application in System F [Gir72], it has no operational effect. It is used to change the static type of a channel. Section 3.2.3 explains more about its role in typing. The definition of the dynamic semantics requires the extension of the syntax with the same values as for ILB in Section 3.1.2. Note that recursive functions now also carry along channel arguments, c, and, accordingly, function applications are extended with channel arguments.

3.2. THE ILC CALCULUS

53

N P (N ) Z Var FIndex CVar CLab POp EOp Op

3 3 3 3 3 3 3 3 3 3

A, B, . . . N, . . . i, . . . f , g, x, y, z, . . . j, . . . c, . . . l, . . . pfun, . . . op, . . . op ::= op A | pfun

Val

3

v

::= |

iN rec j f [ c ]( x ) = p

Expr

3

e

::=

x|v

Def

3

d

::= |

x=e x = op (e)

Prog

3

p

|

c = open[ A;B]

|

x = trans[ A;B] c(e)

| |

close[ A;B] (c) c{l }

::= | | |

halt e [c] e let d in p if e then p else p

Figure 3.10: Syntax of ILC Again, the notion of free variables, fv( p), of ILC -programs is defined as usual. In addition, we also introduce the notion of free channel variable, fcv( p), registering free channel variables of CVar of a program p.

3.2.2

Dynamic Semantics

The dynamic semantics of ILC is expressed by two small-step reduction relations. The first one, −→ ⊆ Prog × Prog specifies reductions that do not involve communication channels. The actual rules are shown in the first part of Figure 3.11. They match the corresponding rules of ILB . To be able to specify reductions that are involved in communication, we have to register open channels in separate channel environments. Channel environments are

54


D-C-L ET-VAL

let x = v in p

−→

p[v/x]

let x = pfun(i j Nj ) in p

−→

p [i

−→

p1

if i 6= 0 and N 6= ∅

−→

p2

if N 6= ∅

−→

p j [reci f [c]( x)= p/ f i ][c0/c][v/x]

D-C-PF UN T

Nj

/x]


T

Nj 6= ∅

D-C-I F -T RUE

if i N then p1 else p2 D-C-I F -FALSE

if 0 N then p1 else p2 D-C-A PP

(rec j f [c]( x ) = p) [c0 ] v

D-C-C TX

p−→ p0 σ, p−→σ, p0 D-C-L ET-O PEN

σ, let c = open[ A;B] in p

−→

σ[c 7→ { A, B}], p

−→

σ, p[i N ∪{B}/x]

if σ (c) = { A, B}, A∈N

−→

σ\{c}, p

if σ(c) = { A, B}

−→

σ, p

D-C-L ET-T RANS

σ, let x = trans[ A;B] (c, i N ) in p D-C-L ET-C LOSE

σ, let close[ A;B] (c) in p D-C-C HAN -A PP

σ, let c{l } in p

Figure 3.11: Reduction rules for ILC

if c ∈ dom σ


55

defined as follows. Definition 3.1 A channel environment, σ ∈ Chans = CVar ,→ P (N ), is a partial function mapping channel names of open channels to sets of locations, the locations of the communication partners.

The second reduction relation, −→ ⊆ Chans × Prog × Chans × Prog, therefore specifies reductions that involve communication. The associated reduction rules are shown in the second half of Figure 3.11. Opening a channel (D-C-L ET-O PEN) registers the channel name in the channel environment. The transmission of a value through a channel (D-C-L ET-T RANS) is only possible if the channel connects appropriate locations. ILC channels are bidirectional. Once opened from A to B, it is possible to transfer values in both directions. Closing a channel amounts to the removal of the channel binder for c (D-C-L ET-C LOSE). The application of a label to a channel (D-C-C HAN -A PP) has no operational effect. It merely checks that the channel in question is opened. As for ILB , we specify the I/O behavior of ILC programs using a labeled transition system. Again, we consider read and write as the only primitives that are engaged in I/O effects. Channel operations are not considered as observable in our setting. The set of observations, Obs, and the labeled transition system are shown in Figure 3.12. The labeled transition system this time consists of two families of relations indexed by observations. α The former, −→⊆ Prog × Prog, deals with basic I/O and halting operations. The latter, α −→⊆ Chans × Prog × Chans × Prog, incorporates channel environments and regular, effect-free reductions. The set of observations is unchanged with respect to the definition in Section 3.1.2 (Figure 3.3). The first three rules, (D-C-H ALT), (D-C-L ET-R EAD) and (D-C-L ET-W RITE) are also taken over unchanged from the previous section. The second family of relations incorporates channel environments. The (D-C-C TX -2) rule lifts transitions of the previous relation into the current. The (D-C-S KIP) rule corresponds to the (D-B-S KIP) rule from before. It now also registers the current state of the channel environment.

3.2.3

Static Semantics

Because we now use explicit channels to communicate values between locations, the static type system is also supposed to reflect properties of channels, registering of course properties that are statically derivable. To this end, we add a special type language for channels to our type language that enables us to express possible communication patterns of channels. We use a regular language to do so, known as session types in the literature [Nie93, GH99, GVR03]. The type language including types of channels and channel type environments are presented in Figure 3.13.

56


D-C-H ALT halt

−→

halt D-C-L ET-R EAD

?i A

let x = read A () in p −→ D-C-L ET-W RITE

!i A


Ω p[i{ A}/x] p[0{ A}/x]

if A ∈ N

D-C-C TX -2 α

p −→ p0 α σ, p −→ σ, p0

D-C-S KIP α σ, p−→σ0 , p0 σ0 , p0 −→ σ00 , p00 α σ, p −→ σ00 , p00

Obs

3

α

::=

halt | ?i A | !i A

Figure 3.12: Labeled transition system for ILC A session type, γ, denotes an ω-regular language that describes the sequence of types that the rest of the session communicates over on the channel. The type ε indicates that no further communication takes place over a channel, (b, γ) sends a base value and continues according to γ, and (b, γ) receives a base value and continues as specified by γ. The type hl1 → γ1 , l2 → γ2 , . . . i is a conditional session type guarded by labels l1 , l2 , . . . . The channel application c{li } changes the type of c to γi . The νβ.γ construct creates a recursive session type. It is a recursive binding construct; the ν operator names the whole session type by a type variable, β. There is one additional restriction. Each application of the recursion operator must be expansive, that is, a well-formed session type does not have subterms of the form νβ 1 . . . νβ n .β 1 . Such subterms cannot be straightforwardly expanded, and thus cannot be reasonably interpreted as representations of tree types [GLP02]. Example 3.1 A session type specifying the communication behavior of the stream-based version of the message board example of Chapter 1 (Figure 1.6) could look as follows:

(string, νβ.(boolean, hltrue → (tuple, β) | lfalse → εi)).


BType

3

b

STVar SType

3 3

β γ

AType

3

TEnv

3

57

base types session type variables session types

::= | | | | |

ε (b, γ) (b, γ) h l i → γi i β νβ.γ

τ

::=

b N | [χ]τ −→ 0

annotated types

Γ

::=

∅ | Γ, x : τ

type environments channel types channel type environments

N

CType

3

χ

::=

γ[ A;B]

SEnv

3

Θ

::=

∅ | Θ, c : χ

Figure 3.13: Type language of ILC It denotes the language

∪

{string boolean (tuple boolean)n | n ∈ N} {string boolean (tuple boolean)ω }

saying that the communication over the channel starts with the reception of a string value, followed by a boolean value, and either finite or infinite repetitions of receptions of a tuple value and a boolean value.

γ[ A;B] ,

Channel types, χ, are session types annotated with a pair of locations, specifying the communication pattern over the channel, its starting point, and its ending point. Channel type environments, Θ, register channel types for open channel variables. In some cases, we want to look at a session from the perspective of the other side of the communicating partners. The following definition formalizes the concept of a mirrored session type. Definition 3.2 The mirrored session type, γ, of a session type, γ, is defined as follows. ε (b, γ) (b, γ) h l i → γi i β νβ.γ

= = = = = =

ε (b, γ)

(b, γ) h l i → γi i β νβ.γ

58


In the session type of the receiver’s session, communications work exactly the opposite way: instead of sending values, the receiver receive values, and instead of receiving values, the receiver sends values. There are seven judgments specifying the typing rules for ILC . • `C γ ≤ γ specifies subtyping between session types. • `C χ ≤ χ specifies subtyping between channel types. • `C τ ≤ τ specifies subtyping between annotated types. • Γ `C e : τ specifies the type for expression e with respect to a type environment Γ. • Θ; Γ `C d ⇒ Θ0 ; Γ0 ! N states that d transforms Γ to Γ0 , Θ to Θ0 , and may perform operations at locations N. • Θ; Γ `C p ! N specifies the typing of program p under environments Γ and Θ with possible effects on locations N. • Θ; Γ `C σ, p ! N specifies the typing of channels σ and program p under environments Γ and Θ resulting in effects on locations N. Our type system is designed in such a way that each channel variable is used exactly once for one particular channel type assignment. By keeping this invariant, we can guarantee that for each channel exactly one instance of the specified communication pattern runs over it at the same time. To achieve such a linear type discipline we follow an approach described by Walker [Wal05]: we make sure that channel variables are used exactly once along every control-flow path by carefully managing channel type environments Figure 3.14 shows the rules specifying the subtyping relation of session types and channel types. To also capture infinite session, we define the subtyping of session types as the greatest relation specified by the rules above. The (SUB - C - EMPTY) tells us that a specified session, γ, can always be abandoned early. The rules (SUB - C - SEQ -1), (SUB - C SEQ -2) and ( SUB - C - GUARD ) guarantee that subtypes can be extended with a common prefix. The (SUB - C - NU -1) and (SUB - C - NU -2) rules specify the main property of ν-types, ν-folding. The (SUB - C - CHAN) rule lifts subtyping to channel types. Figure 3.15 presents the subtyping of annotated types. The rules correspond to the rules introduced for ILB . We further added contravariant subtyping of channel arguments in argument positions of functions (SUB - C - FUN). Figure 3.16 shows the typing rules for expressions. The rules handling expressions match the rules for ILB . The (S-C-E XPR -R EC) rule handling groups of recursive functions also has to deal with channel types. Figure 3.17 shows the typing rules for annotated statements. The original rules do not change significantly, but additional rules exist to handle new communication primitives.


59

S UB -C-E MPTY

`C γ ≤ ε S UB -C-S EQ -1 `C γ ≤

γ0 C ` (b, γ) ≤ (b, γ0 )

S UB -C-S EQ -2 `C γ ≤

`C

γ0 (b, γ) ≤ (b, γ0 )

S UB -C-G UARD

`C S UB -C-N U -1 `C γ ≤ γ0 [νβ.γ0/β]

`C γ ≤ νβ.γ0

(∀i ) `C γi ≤ γi0 hli → γi i ≤ hli → γi0 i S UB -C-N U -2 `C γ[νβ.γ/β] ≤ γ0 `C νβ.γ ≤ γ0

γ0 6≡ ε, γ0 6≡ νβ0 .γ00

S UB -C-C HAN `C γ

≤ γ0 `C γ[ A;B] ≤ γ0[ A;B]

Figure 3.14: Subtyping of ILC channels The (S-C-D EF -O PEN) rule adds a new channel type to the channel environment. The (S-C-D EF -T RANS -1) and (S-C-D EF -T RANS -2) rules guarantee that transmission over a channels fit to declared channel types. The direction of communication is insignificant. The closing of an empty channel also works in both directions (S-C-D EF -C LOSE -1) and (S-C-D EF -C LOSE -2). The (S-C-D EF -CA PP) rule selects the suitable session type out of a conditional session type. Throughout, subtyping of channel types is used to unroll session types and to prematurely abandon sessions. Figure 3.18 contains the annotated typing rules for programs. The rules reflect the previous rule set for ILB and impose additional demands on the use of channels. In particular, the (S-C-P ROG -A PP) guarantees that channels are passed to a function linearly and that let statements change channel environments accordingly (S-C-P ROG -L ET). The (S-C-P ROG -C HAN) rule assures that open channels are typed correctly by the channel environment in context, Θ.

3.2.4

Properties

Because we specified session subtyping co-inductively it is not immediately apparent, that session type subtyping is also a preorder. The preorder properties of subtyping are later needed to show type preservation. The following lemma shows that this is indeed the case. Lemma 3.11 The session subtyping relation for ILC is reflexive and transitive. That is,

60


S UB -C-B ASE

N1 ⊇ N2 `C b N1 ≤ b N2 S UB -C-F UN

N1 ⊇ N2

`C τ2 ≤ τ1

` C [ χ2 ] ≤ [ χ1 ]

N1

N

2 `C [χ1 ]τ1 −→ 0 ≤ [χ2 ]τ2 −→ 0

Figure 3.15: Subtyping of ILC types

S-C-E XPR -VAR

S-C-E XPR -C ONST

Γ `C x : Γ( x )

Γ `C i N : b N

S-C-E XPR -R EC N

(∀i ) ci : χi ; Γ, f : [χ]τ −→ 0, xi : τi `C pi ! Ni N

Γ `C rec j f [c]( x ) = p : [χ]τ −→ 0 S-C-E XPR -S UB Γ `C e : τ

Γ

`C

`C τ ≤ τ 0 e : τ0

Figure 3.16: Typing rules for ILC expressions (i) `C χ ≤ χ, and (ii) if `C χ ≤ χ0 and `C χ0 ≤ χ00 , then `C χ ≤ χ00 .

Proof. By using the principle of co-induction, following the proofs of Gapeyev et al. [GLP02].

We first state some useful lemmas that we later use to prove other results. They are proven by simple induction over typing derivations. Lemma 3.12 If Γ `C e : τ, then fcv(e) = ∅.

Lemma 3.13 If Θ; Γ `C p ! N, then fcv( p) = dom Θ.


61

S-C-D EF -E XPR

Γ `C e : τ Θ; Γ `C x = e ⇒ Θ; Γ, x : τ ! ∅ S-C-D EF -P FUN

(∀i ) Γ `C ei : b N Θ; Γ `C x = pfun(ei ) ⇒ Θ; Γ, x : b N ! ∅ S-C-D EF -OP

Θ; Γ

`C

(∀i ) Γ `C ei : b{ A} x = op A (ei ) ⇒ Θ, Γ( x : b{ A} ) ! { A}

S-C-D EF -O PEN

Θ; Γ `C c = open[ A;B] ⇒ Θ, c : γ[ A;B] ; Γ ! ∅ S-C-D EF -T RANS -1 `C

Θ, c : χ; Γ

`C

S-C-D EF -T RANS -2 `C

Θ, c : χ; Γ

`C

χ ≤ (b, γ)[ A;B] Γ `C e : b N A∈N [ A;B ] x = trans c(e) ⇒ Θ, c : γ[ A;B] ; Γ, x : b N ∪{ B} ! ∅ χ ≤ (b, γ)[ B;A] Γ `C e : b N A∈N [ A;B ] [ B;A ] x = trans c(e) ⇒ Θ, c : γ ; Γ, x : b N ∪{ B} ! ∅

S-C-D EF -C LOSE -1

Θ, c : χ; Γ

`C χ ≤ ε[ A;B] close[ A;B] (c) ⇒ Θ; Γ ! ∅

`C

S-C-D EF -C LOSE -2

Θ, c : χ; Γ

`C χ ≤ ε[ B;A] close[ A;B] (c) ⇒ Θ; Γ ! ∅

`C

S-C-D EF -CA PP `C

χ ≤ hli → γi i[ A;B]

Θ, c : χ; Γ

c{l j } ⇒ Θ, c : γ j

`C

[ A;B]

;Γ!∅

Figure 3.17: Typing rules for ILC statements

62


S-C-P ROG -H ALT

Θ; Γ `C halt ! ∅ S-C-P ROG -A PP N

Γ `C e1 : [χ]τ −→ 0 Θ≡c:χ Θ; Γ `C e1 [c] (e2 ) ! N

Γ ` C e2 : τ

S-C-P ROG -L ET Θ; Γ `C d ⇒

Θ0 ; Γ0 ! Nd Θ 0 ; Γ 0 `C p ! Np C Θ; Γ ` let d in p ! Nd ∪ Np

S-C-P ROG -I F Γ `C e

: bN N1 , N2 ⊆ N 6= ∅ Θ, Γ p1 ! N1 Θ, Γ `C p2 ! N2 C Θ, Γ ` if e then p1 else e2 ! N1 ∪ N2

`C

S-C-P ROG -C HAN

dom Θ = fcv( p)

(∀c) Θ(c) = γ[ A;B] ⇔ σ(c) = { A, B} Θ `C σ, p

S-C-P ROG Θ `C σ,

p Θ; Γ `C p ! N C Θ; Γ ` σ, p ! N

Figure 3.18: Typing rules for ILC programs Ω is typeable in ILC as well. Lemma 3.14 ∅; Γ `C Ω ! ∅.

The inversion lemma, which we prove next, extends the result for ILB by also incorporating appropriate channel type arguments. Lemma 3.15 (Inversion Lemma) 0

(i) If Γ `C i N : b N , then N ⊇ N 0 . Nj0

(ii) If Γ `C rec j f [c]( x ) = p : [χ0j ]τj0 −→ 0, then there exists χi , τi , Ni , such that, N

• for all i, it holds that ci : χi ; Γ, f : [χ]τ −→ 0, xi : τi `C pi ! Ni , • χ0j ≤ χ j , τj0 ≤ τj , Nj0 ⊇ Nj .


63

Proof. Straightforward induction on the typing derivation for expressions, using transitivity (Lemma 3.11.)

Lemma 3.16 (Substitution Lemma — Expressions and Programs) (i) If Γ, x : τ `C e0 : τ 0 , Γ `C e : τ, then Γ `C e0 [e/x] : τ 0 . (ii) If Θ; Γ, x : τ `C p ! N, Γ `C e : τ, then Θ; Γ `C p[e/x] ! N.

Proof. Simultaneous induction on the typing derivation for expressions and programs. Nj0

• Case (S-C-E XPR -R EC ). Suppose Γ, x : τ `C rec j f [c]( x ) = p : [χ0j ]τj0 −→ 0. The inversion lemma tells us that N

(∀i ) ci : χi ; Γ, x : τ, f : [χ]τ −→ 0, xi : τi `C pi ! Ni ,

(3.81)

χ0j ≤ χ j ,

(3.82)

τj0 ≤ τj , Nj0 ⊇ Nj .

(3.83)

(∀i ) ci : χi ; Γ, f : [χ]τ −→ 0, xi : τi `C pi [e/x] ! Ni .

(3.85)

(3.84)

By induction, we further know that N

Applying (S-C-E XPR -R EC) and the subsumption rule yields the result. • The other cases are proven similarly, following the proof of ILB .

Lemma 3.17 (Substitution Lemma — Channel Names) If Θ, c : χ; Γ dom Θ, then Θ, c0 : χ; Γ `C p[c0/c] ! n.

`C

p ! N, and

c0

6∈

Proof. By straightforward induction on the type derivation using Lemma 3.12.

Lemma 3.18 (Weakening of Channels — Definitions) If Θ; Γ `C d ⇒ Θ0 ; Γ0 ! N and c 6∈ fcv(d) ∪ dom Θ, then Θ, c : χ; Γ `C d ⇒ Θ0 , c : χ; Γ0 ! N.

Proof. By case analysis of the type derivation.

64


Lemma 3.19 (Weakening of Channels — Programs) If `C χ ≤ χ0 , and Θ, c : χ0 ; Γ `C p ! N, then Θ, c : χ; Γ `C p ! N.

Proof. By straightforward induction on the type derivation using Lemma 3.11 and Lemma 3.18.

By mirroring a channel, a program still stays typeable. Lemma 3.20 (Mirroring of Channels) If Θ, c : γ[ A;B] ; Γ `C p ! N, then Θ, c : γ[ B;A] ; Γ `C p ! N.

Proof. By straightforward induction on the type derivations. The case for trans uses the fact that there are two rules handling trans statements, one for the sending case, and a second, for the mirrored, receiving case.

It is also matter of a routine calculation to prove the following canonical forms lemma. Lemma 3.21 (Canonical Forms Lemma) (i) If ∅ `C e : b N , then e ≡ i M for some i, M. N

(ii) If ∅ `C e : [χ]τ −→ 0, then e ≡ rec j f [c]( x ) = p.

Corollary 3.2 If ∅ `C e : τ, then e is a value.

Lemma 3.22 (Type Preservation) (i) If Θ; Γ `C σ, p ! N, and p−→ p0 , then Θ; Γ `C σ, p0 ! N 0 and N ⊇ N 0 . (ii) If Θ; Γ `C σ, p ! N, and σ, p−→σ0 , p0 , then Θ0 ; Γ `C σ0 , p0 ! N 0 and N ⊇ N 0 . (iii) If Θ; Γ `C σ, p ! N, and p−→ p0 , then Θ; Γ `C σ, p0 ! N 0 , N ⊇ N 0 , and locs(α) ⊆ N. α

α (iv) If Θ; Γ `C σ, p ! N, and σ, p−→σ0 , p0 , then Θ0 ; Γ `C σ0 , p0 ! N 0 , N ⊇ N 0 , and locs(α) ⊆ N.

Proof.


65

(i) We proceed by case analysis of the reduction, p−→ p0 . – Case (D-C-A PP ). The type judgment looks as follows. Θ; Γ `C (rec j f [c]( x ) = p) [c0 ] v ! Nj0 .

(3.86)

The inversion lemma applied to the first premise and applying then the (S-CE XPR -R EC) rule, tells us, that for all i, it holds that N

i Γ `C (reci f [ci ]( xi ) = pi ) : [χi ]τi −→ 0

χ0j

(3.87)

≤ χj ,

(3.88)

τj0 ≤ τj ,

(3.89)

Nj0 ⊇ Nj .

(3.90)

By inversion, it also holds that Γ `C v : τj0 ,

(3.91)

χ0j

(3.92)

Θ≡

c0

:

For the jth element of the recursive group, we are able to apply the substitution lemma for expressions leading to c j : χ j ; Γ, x j : τj `C p j [reci f [c]( x)= p/ f i ] ! Nj .

(3.93)

Further, applying Lemma 3.19 and the substitution lemma for channel names leads to Θ; Γ, x j : τj `C p j [reci f [c]( x)= p/ f i ][c0/c] ! Nj .

(3.94)

Finally, using the (S-C-E XPR -S UB) rule and applying the substitution lemma for expressions again leads to Θ; Γ `C p j [reci f [c]( x)= p/ f i ][c0/c][v/x] ! Nj .

(3.95)

– The other cases are analogous to cases found in the proof of the ILB result. (ii) By case analysis on the derivation of σ, p−→σ0 , p0 . – Case (D-C-L ET-O PEN ). The type judgment looks as follows. Θ; Γ `C σ, let c = open[ A;B] in p ! Np

(3.96)

By inversion we further know that Θ `C σ C

Θ; Γ ` c = open

[ A;B]

⇒ Θ, c : γ

[ A;B]

(3.97)

;Γ!∅

(3.98)

Θ, c : γ[ A;B] ; Γ `C p ! Np

(3.99)

66

CHAPTER 3. PROGRAM TRANSFORMATION SCHEME Hence, it also holds that Θ, c : γ[ A;B] `C σ [c 7→ { A, B}]

(3.100)

Θ, c : γ[ A;B] ; Γ `C σ0 , p ! Np .

(3.101)

and thus

– Case (D-C-L ET-T RANS ). The type judgment looks as follows. Θ; Γ `C σ, let x = trans[ A;B] (c, i N ) in p ! Np

(3.102)

By inversion, we know that either the rule (S-C-D EF -T RANS -1) or the rule (S-C-D EF -T RANS -2) applied. We now only consider the second subcase. The other subcase works accordingly. Hence, with Θ ≡ Θ0 , c : χ, Θ `C σ (3.103) Θ0 , c : χ; Γ `C x = trans[ A;B] c(i N ) ⇒ Θ0 , c : γ[ B;A] ; Γ, x : b N1 ∪{ B} ! ∅ (3.104) Θ0 , c : γ[ B;A] ; Γ, x : b N1 ∪{ B} `C p ! Np (3.105) and consequently, by inversion on the second premise, also

`C χ ≤ (b, γ)[ B;A] , C N

Γ` i

:b

N1

(3.106)

,

(3.107)

A ∈ N.

(3.108)

Thus, Γ `C i N ∪{ B} : b N1 ∪{ B}

(3.109)

By applying the substitution lemma on the third premise, we get Θ0 , c : γ[ A;B] ; Γ `C p[i N ∪{B}/x] ! Np

(3.110)

Because it obviously also holds that Θ0 , c : γ[ B;A] `C σ the assumption follows.

(3.111)


67

– Case (D-C-L ET-C LOSE ). The type judgment looks as follows. Θ; Γ `C σ, let close[ A;B] (c) in p ! Np

(3.112)

By inversion, we further know that—assuming that the (S-C-D EF -C LOSE -1) rule applied and that Θ ≡ Θ0 , c : χ,— Θ `C σ 0

C

Θ , c : χ; Γ ` close

[ A;B]

0

(c) ⇒ Θ ; Γ ! ∅ 0

C

Θ ; Γ ` p ! Np

(3.113) (3.114) (3.115)

Hence, it also holds that Θ0 `C σ\{c}

(3.116)

Θ 0 ; Γ `C σ 0 , p ! Np .

(3.117)

and thus

The other subcase, considering the (S-C-D EF -C LOSE -2) rule, works similarly. – Case (D-C-C HAN -A PP ). This case is analogous to the case handling (D-CL ET-T RANS). – Case (D-C-C TX ). By inversion of the reduction rule, we know that p−→ p0 .

(3.118)

and the type derivation tells us that Θ `C σ,

(3.119)

C

(3.120)

Θ, Γ ` p ! N. Applying statement (i) leads to the result Θ; Γ `C σ, p0 ! N 0 ,

(3.121)

N ⊇ N0.

(3.122)

(iii) By case analysis of the reduction, p−→ p0 . α

– Case (D-C-H ALT ). Immediate by Lemma 3.14. – Case (D-C-L ET-R EAD ). By inversion of the typing Θ; Γ `C σ; let x = read A () in p ! { A} ∪ Np ,

(3.123)

68

CHAPTER 3. PROGRAM TRANSFORMATION SCHEME we know that Θ `C σ, C

A

Θ; Γ ` x = read () ⇒ Θ; Γ, x : b Θ; Γ, x : b

{ A}

{ A}

(3.124)

! { A}

(3.125)

` p ! Np

(3.126)

C

Because Γ `C i { A} : b{ A} ,

(3.127)

we can follow by the substitution lemma, that Θ; Γ `C p[i{a}/x] ! Np .

(3.128)

– Case (D-C-L ET-W RITE ). Analogous to the previous case. (iv) By induction on the derivation σ, p−→σ0 , p0 . α

– Case (D-C-C TX -2). Suppose Θ; Γ `C σ, p ! N. By inversion of the reduction α relation, we know that p −→ p0 . The result follows by part (iii). – Case (D-C-S KIP ). Suppose Θ; Γ `C σ, p ! N. By inversion of the reduction relation, we know that σ, p −→ σ0 , p0 , 0

0

α

00

(3.129)

00

σ , p −→ σ , p .

(3.130)

Applying the result of part (ii) yields, that there exists a Θ0 with Θ0 ; Γ `C σ 0 , p0 ! N 0 ,

(3.131)

N ⊇ N0.

(3.132)

The result follows by then applying the induction hypothesis, that is there exists a Θ00 such that Θ00 ; Γ `C σ00 , p00 ! N 00 ,

(3.133)

N 0 ⊇ N 00 ,

(3.134)

0

locs(α) ⊆ N .

(3.135)

and transitivity.

Again, we are able to prove a progress result for ILC programs. Lemma 3.23 (Progress) Suppose Θ; ∅ `C σ, p ! N, then there exists σ0 and p0 with either α σ, p−→σ0 , p0 or σ, p −→ σ0 , p0 .


69

Proof. By inversion of the type derivation we know that Θ `C σ,

(3.136)

C

(3.137)

Θ; ∅ ` p ! N. We now proceed by induction on the type derivation of the program p. • Case (S-C-P ROG -H ALT ). The (D-C-H ALT) rule applies. • Case (S-C-P ROG -A PP ). By inversion, we know that N

∅ `C e1 : [χ]τ −→ 0,

(3.138)

Θ ≡ c : χ,

(3.139)

C

∅ ` e2 : τ.

(3.140)

By the canonical forms lemma, it follows that e1 ≡ rec j f [c]( x ) = p,

(3.141)

e2 ≡ v.

(3.142)

Hence, rule (D-C-A PP) applies. • Case (S-C-P ROG -L ET ) AND (S-C-D EF -O PEN ). The (D-C- LET- OPEN) rule applies. • Case (S-C-P ROG -L ET ) AND (S-C-D EF -T RANS -1). By inversion, we know that, Θ `C c : (b, γ)[ A;B] C

N

(3.143)

∅` e:b ,

(3.144)

A ∈ N.

(3.145)

and thus, by the canonical forms lemma, 0

e ≡ iN , 0

N ⊇ N.

(3.146) (3.147)

Consequently, A ∈ N 0 , σ (c) = { A, B} (by inspecting the (S-C-P ROG -C HAN) rule), and reduction (D-C-L ET-T RANS) applies. • The other cases are either analogous to the previous case ((S-C-D EF -T RANS -2), (S-C-D EF -C LOSE -1), (S-C-D EF -C LOSE -2), and (S-C-D EF -A PP)) or are proven according to the proof of the progress result for ILB .

70


C Jb N K

=

b

C Jτ −→ 0K

=

C JΓ, x : τK

=

[]C JτK −→ 0

C Ji N K

= =

C JxK

iN rec j f []( x ) = C JpK

=

x

C JhaltK C Je0 ei K C Jlet x = e in pK C Jlet x = pfun(ei ) in pK C Jlet x = op A (ei ) in pK C Jlet x = trans[ A;B] e in pK

= = = = = =

C Jif e then p1 else p2 K

=

halt C Je0 K [] C Jei K let x = C JeK in C JpK let x = pfun(C Jei K) in C JpK let x = op A (C Jei K) in C JpK let c = open[ A;B] in let x = trans[ A;B] c (C JeK) in let close[ A;B] (c) in C JpK if C JeK then C Jp1 K else C Jp2 K

N

C Jrec j f ( x ) = pK

N

C JΓK, x : C JτK

Figure 3.19: Translation C from ILB to ILC

3.2.5

Translation

Up to now, we just introduced the new calculus, ILC , but we did not connect it to our starting point, ILB . A na¨ıve translation from ILB to ILC is very simple, however. Figure 3.19 formally states the channel introduction translation C from ILB to ILC . The translation replaces each occurrence of a trans statement by a sequence of statements that, first, open an explicit channel, c, between locations A and B, then, transmit the current value of e from A to B over v, bind the value to x, and finally close the connection again. Translating a program using C preserves typings as we state next. The results are proven by induction over the type derivations. Lemma 3.24 (i) If Γ0 ` B e0 : τ 0 , then, ∅; C JΓ0 K `C C Je0 K : C Jτ 0 K. (ii) If Γ0 ` B p0 ! N 0 , then ∅; C JΓ0 K `C C Jp0 K ! N 0 .

Lemma 3.25 (i) If Γ `C e : τ, then there exists some Γ0 , e0 , and τ 0 such that Γ0 ` B e0 : τ 0 .


71

(ii) If Θ; Γ `C p ! N, then there exists some Γ0 and p0 , such that Γ0 ` B p0 ! N.

3.2.6

Simplification Rules

The transformation C specified in the previous section works correctly, but it produces inefficient programs. Whenever a value from location A is needed at location B, the program sends a datagram: it opens a channel from A to B, sends the value, and closes the channel, again. The inefficiency lies in the cost of connection establishment. Because this cost is much higher than the cost of transmitting one value, it would be better if the cost for connection establishment were amortized across as many value transmissions as possible. To avoid repeated connection establishment, we define a set of equational rules on ILC programs specifying the channel pooling transformation. The set of rules allows to join close and open statements for a channel with the goal of reusing the channel for multiple communications. Essentially, using the equational rules in a program transformation turns a sequence of datagram transmissions between two hosts into a stream connection. Figure 3.20 presents the equalities in terms of a typed relation, = ˆ . The first rules, (E Q -C-R EFL), (E Q -C-S YMM), and (E Q -C-T RANS), assure that relation = ˆ is an equivalence. The (E Q -C-B ETA) rule renders two programs equal if there is a reduction step from the first program to the second program available that leaves the channel environment unchanged. The other rules are equalities that relate programs that syntactically differ in the way how they manipulate channels but nevertheless exhibit identical behaviors. The rules express • that it does not matter in which direction we open a channel (E Q -C-O PEN -O PEN), • that we can leave out altogether the opening of a channel immediately followed the closing of a similar channel (E Q -C-C LOSE -O PEN), • that opening a channel and immediately closing it again can always be inserted or removed(E Q -C-O PEN -C LOSE), • that we can swap open statements with other statements, if the opened channel name does not occur in the second statement (E Q -C-L ET-O PEN), and • that instead of opening a similar channel at the beginning of both branches of an if statement, it is possible to instead open a channel before the conditional. Additional channel selectors (with no runtime effects) must be added to select the correct branches of occurring conditional session types (E Q -C-I F -O PEN).

72


E Q -C-R EFL

Θ; Γ `C σ, p ! N Θ; Γ `C σ, p = ˆ σ, p ! N E Q -C-T RANS Θ; Γ `C σ,

E Q -C-S YMM Θ; Γ `C σ,

Θ; Γ

`C

p= ˆ σ0 , p0 ! N = ˆ σ, p ! N

σ0 , p0

p= ˆ σ0 , p0 ! N Θ; Γ `C σ0 , p0 = ˆ σ00 , p00 ! N C 00 00 Θ; Γ ` σ, p = ˆ σ ,p !N

E Q -C-B ETA Θ; Γ `C σ,

p!N σ, p−→σ, p0 C Θ; Γ ` σ, p = ˆ σ, p0 ! N

E Q -C-O PEN -O PEN

Θ `C σ, p Θ, c : γ[ A;B] ; Γ `C p ! N Θ; Γ `C σ, let c = open[ A;B] in p = ˆ σ, let c = open[ B;A] in p ! N E Q -C-C LOSE -O PEN Θ, c : χ `C

Θ, c : χ; Γ

`C

σ, p `C χ ≤ γ[ A;B] Θ, c : γ[ A;B] ; Γ `C p ! N [ A;B ] σ, let close (c) in let c = open[ A;B] in p = ˆ σ, p ! N

E Q -C-O PEN -C LOSE

Θ; Γ

`C

Θ `C σ, p Θ; Γ `C p ! N c 6∈ fv( p) [ A;B ] in let close[ A;B] (c ) in p = σ, let c = open ˆ σ, p ! N

E Q -C-L ET-O PEN Θ `C σ, p Θ; Γ

`C d ⇒ Θ0 ; Γ0 ! Nd Θ0 , c : γ[ A;B] ; Γ0 `C p ! N Θ; Γ `C σ, let d in let c = open[ A;B] in p = ˆ σ, let c = open[ A;B] in let d in p ! N

c 6∈ fcv(d)

E Q -C-I F -O PEN

Θ `C σ, p [ A;B] Θ, c : γ1 ;Γ C Θ; Γ `

`C

p1 ! N1

Θ, c :

Γ `C e : b N [ A;B] γ2 ;Γ

`C p2 ! N2

N1 , N2 ⊆ N

σ, if e then (let c = open[ A;B] in p1 ) else (let c = open[ A;B] in p2 ) = ˆ σ, let c = open[ A;B] in if e then (let c{l1 } in p1 ) else (let c{l2 } in p2 ) ! N1 ∪ N2 Figure 3.20: Equational rules for ILC programs specifying channel pooling


73

A possible strategy for applying the equalities as transformation steps in a compiler is to float each open statement upwards in a list of statements until one of the following holds. 1. The open meets a close with matching (or reversed) locations. In this case, the two channels are joined together and both statements are eliminated. 2. Standard inlining [PL91] or unfolding of the recursive function (using (E Q -C-B ETA) can transport the open to all call sites of the function. The transformation stops at functions that are not inlineable (e.g., certain top-level functions). 3. The open reaches the top of a branch of a conditional. There are two possibilities. If the other branch has a matching open, then the transformation rule first inserts a channel application c{l } with label lt in the true-branch and l f in the false-branch. If γt and γ f are the original types of the channels in the true- and the false-branch, then their type becomes hlt → γt , l f → γ f i so that the channels can be joined and hoisted in front of the conditional. If no matching open is available in the other branch, then a transformation rule may introduce a new channel between the source and destination host that is opened and immediately closed. Then joining takes place as before. Typed Relations and Open Extensions Before we examine the equation rules we stated in the previous section more precisely, we first define a general notion for relations that talk about typed ILC programs and consider some properties of them. Some definitions in this section are adaptations of definitions made elsewhere [Hel04]. The notion of a typed relation adds the suitable static contexts to two programs to relate. Definition 3.3 A typed relation of ILC ,

R ∈ P (SEnv × TEnv × Chans × Prog × Chans × Prog × P (N )), is a set of tuples, (Θ, Γ, σ, p, σ0 , p0 , N ). We usually write Θ; Γ `C σ, p R σ0 , p0 ! N, if (Θ, Γ, σ, p, σ0 , p0 , N ) ∈ R.

By adding a well-formedness criterion to typed relations, we assure that both programs are well-typed under the same static contexts with respect to our type system and that effects statically derived for both programs subsume each other. Definition 3.4 A typed relation, R, is well-formed, if the following condition holds: if Θ; Γ `C σ, p R σ0 , p0 ! N, then (i) Θ; Γ `C σ, p ! N1

74


(ii) Θ; Γ `C σ0 , p0 ! N2 , (iii) N1 ⊆ N, N2 ⊆ N, (iv) Θ; Γ `C σ, p R σ0 , p0 ! N1 ∪ N2 .

Definition 3.5 A typed relation, R, is called closed, if Θ; Γ `C σ, p R σ0 , p0 ! N implies that Γ = ∅. The set of all closed, typed relations is denoted as ClosedTypedRelC.

To be later able to extend closed typed relations to arbitrary pairs of programs, we introduce the notions of iterated substitutions and open extensions. Definition 3.6 An iterated substitution, ξ = [v/x], is a sequence of value substitutions where e( p) (ξ, [v/x])( p)

= =

p ξ ( p[v/x]).

Definition 3.7 An iterated substitution, ξ, completes, Γ, iff Γ ξ, where is the least relation defined by the following pair of rules. C OMP -C-E MPTY

∅e

C OMP -C-E XT Γ `C v : τ

Γξ Γ, x : τ ξ, [v/x ]

Lemma 3.26 If Θ; Γ `C p ! N, and Γ ξ, then Θ; ∅ `C ξ ( p) ! N.

Proof. By induction on the iterated substitution. The case dealing the empty sequence follows trivially. The case dealing with an extended iterated substitution follows by applying Lemma 3.16 and the induction hypothesis.

We talk about an open extension, R◦ , of a closed, typed relation, R, if the application of all iterated substitutions that complete open programs are members of the original relation. Definition 3.8 An open extension, R◦ , of a well-formed, closed typed relation, R, is a wellformed, typed relation R◦ , such that Θ; Γ `C σ, p R◦ σ0 , p0 ! N iff for all ξ where Γ ξ it holds that Θ; ∅ `C σ, ξ ( p) R σ0 , ξ ( p0 ) ! N.


75

Lemma 3.27 Θ; ∅ `C σ, p R◦ σ0 , p0 ! N iff Θ; ∅ `C σ, p R σ0 , p0 ! N.

Proof. By simply expanding the definitions and using Lemma 3.26.

Lemma 3.28 If R is a well-formed, closed typed relation, Θ; Γ, x : τ `C σ, p R◦ σ0 , p0 ! N, and Γ `C v : τ, then Θ; Γ `C σ, p[v/x] R◦ σ0 , p0 [v/x ] ! N.

Proof. Without loss of generality, we assume that x 6∈ dom Γ. Let ξ be with Γ ξ. By the definition of completion, it also holds that Γ, x : τ ξ, [v/x]. The first assumption tells us—applying the definition of open extensions—, that Θ; ∅ `C σ, (ξ, [v/x])( p) R σ0 , (ξ, [v/x])( p0 ) ! N. Because, by the definition of iterated substitutions it holds that (ξ, [v/x])( p) = ξ ( p[v/x]), it also follows that, Θ; ∅ `C σ, ξ ( p[v/x]) R σ0 , ξ ( p0 [v/x ]) ! N.

Simulation and Bisimulation Following precursor work that considers the equality of programs in general, and I/O effects in particular, we use an adoption of Milner’s CCS-style bisimilarity as the natural operational equivalence of ILC programs. [Mil89, CG95, Gor99]. Bisimilar ILC programs are programs that lead to similar derivation trees regarding the labeled transition system for ILC we defined earlier. We first define two functionals that are bijections on the set of closed, typed relations. Definition 3.9 The functions, d·e, [·] ∈ ClosedTypedRelC → ClosedTypedRelC, are defined as follows.

dRe

=

{(Θ, ∅, σ1 , p1 , σ2 , p2 , N )

[R]

=

dRe ∩ dR−1 e−1

|

if σ1 = σ2 , and σ1 , p1 −→ σ10 , p10 , α then σ2 , p2 −→ σ20 , p20 , and Θ0 ; ∅ `C σ10 , p10 R σ20 , p20 ! N 0 } α

The two functions extend two typed, open relations with one extra simulation or bisimulation step, respectively. Because the functionals are monotone functions, stated in the next lemma, and by applying Knaster-Tarski’s Theorem 2.1, we are able to define simulations and bisimulations as the greatest fixed points of functionals d·e and [·].

76


Lemma 3.29 The functions d·e and [·] are monotone functions on the complete lattice of closed typed relations, (ClosedTypedRelC, ⊆).

Definition 3.10 (i) A well-formed, closed typed relation, R, which is d·e-dense, that is, R ⊆ dRe, is called a simulation. The similarity relation, >, is defined as the union of all simulations. (ii) A well-formed, closed typed relation, R, which is [·]-dense, that is, R ⊆ [R], is called a bisimulation. The bisimilarity relation, ≈, is defined as the union of all bisimulations.

Following Milner [Mil89], we also define the following, refined notion of bisimilarity. Definition 3.11 A well-formed, closed typed relation, R, which is [≈; ·; ≈]-dense, that is, R ⊆ [≈; R; ≈], is called a bisimulation up to ≈.

Using the notion of bisimulation up to ≈ is helpful sometimes, because the following basic property holds [Mil89]. Proposition 3.1 If R is a bisimulation up to ≈, then R is also a bisimulation.

Theorem 3.1 The open extension of bisimilarity, ≈◦ , is a well-formed equivalence relation.

Proof. • Well-formedness. Trivially holds by the definition of bisimilarity and open extensions. • Reflexivity. Consider the relation

R = {(Θ, ∅, σ, p, σ, p, N ) | Θ; ∅ `C σ, p ! N }.

(3.148)

We trivially see that R is well-formed and [·]-dense (by using Lemma 3.22 and Lemma 3.23). Hence, by co-induction, it follows that ≈ is reflexive. By inspection of the definition of open extensions, we see that the property also holds for ≈◦ .


77

• Symmetry. Consider the relation

R = {(Θ, ∅, σ, p, σ0 , p0 , N ) | Θ; ∅ `C σ0 , p0 ≈ σ, p ! N }.

(3.149)

We now show that R ⊆ [R]. By co-induction it follows that R ⊆≈, hence ≈ is symmetric. Suppose (Θ, ∅, σ, p, σ0 , p0 , N ) ∈ R, that is Θ; ∅ `C σ0 , p0 ≈ σ, p ! N. Given σ1 , p1 −→ σ10 , p10 , we know by bisimulation that σ2 , p2 −→ σ20 , p20 . From α

α

the last observation follows, again by simulation, that σ1 , p1 −→ σ100 , p100 and σ20 , p20 ≈ σ100 , p100 hold. By Lemma 3.32, we know that σ10 = σ100 and p10 = p100 , hence Θ; ∅ `C σ10 , p10 R σ2 , p20 ! N. α

The symmetry of ≈◦ again follows immediately. • Transitivity. Similar to the previous case, this time considering the relation

R = {(Θ, ∅, σ, p, σ00 , p00 , N ) |

there exists σ0 , p0 such that Θ; ∅ `C σ, p ≈ σ0 , p0 ! N and Θ; ∅ `C σ0 , p0 ≈ σ00 , p00 ! N }.

(3.150)

Additional Properties Before we consider properties of the equational theory, we first prove some additional properties of the dynamic semantics and the transitions of ILC that we later need. Reductions are stable under value substitutions. Lemma 3.30 If p −→ p0 , then p[v/x ] −→ p0 [v/x ].

Proof. By a simple case analysis using the definitions of substitutions.

It is safe to add open channels to a channel environment, if the new channel name does not occur in the next statement. Lemma 3.31 If σ, let d in p −→ σ0 , p0 , and c is not already defined in d, i.e. c 6∈ fcv(d), then σ [c 7→ { A, B}], let d in p −→ σ0 [c 7→ { A, B}], p0 .

Proof. By a simple inspection of the relevant reduction rules.

Both reductions and labeled transitions with the same label are deterministic.

78

CHAPTER 3. PROGRAM TRANSFORMATION SCHEME α

α

Lemma 3.32 If σ, p −→ σ1 , p1 and σ, p −→ σ2 , p2 , then σ1 = σ2 and p1 = p2 .

Proof. By induction on the derivations.

It is also safe to exchange a channel environment with another one, that is similar to the original one concerning on all free channel variables of the program. Lemma 3.33 If σ1 , p −→ σ10 , p0 and σ1 |fcv( p) = σ2 |fcv( p) , then σ2 , p −→ σ20 , p0 exists with σ10 |fcv( p) = σ20 |fcv( p) . α

α

Proof. By simultaneous induction on the reduction relation and the transition relation.

The Equational Theory To substantiate that our equational theory makes some sense, we now prove that the theory is included in bisimilarity. We state several lemmas each proving the claim for one of the equational rules. Lemma 3.34 If Θ; Γ `C σ, p ! N, and σ|fcv( p) = σ|0fcv( p) , then Θ; Γ `C σ0 , p ! N.

Proof. By induction on the type derivation using the static properties of channel environments assured by (S-C-P ROG -C HAN).

Lemma 3.35 If Θ; Γ `C σ, p ! N, and p−→ p0 , then Θ; Γ `C σ, p ≈◦ σ, p0 ! N.

Proof. We consider the relation

R = {(Θ, ∅, σ, p, σ, p0 , N ) | Θ; ∅ `C σ, p ! N and p−→ p0 }.

(3.151)

Relation R is well-formed, because by applying the type preservation result, it also follows that Θ, ∅ `C σ, p0 ! N 0 and N ⊇ N 0 . First, we prove that R ⊆ d≈e. Assume that Θ; ∅ `C σ, p R σ, p0 ! N,

(3.152)

σ, p −→ σ0 , p00 .

(3.153)

α


79

Because the reduction rules and the observation rules of ILC are deterministic, we know by inversion (rule (D-C-S KIP) that σ, p−→σ, p0

α σ, p0 −→ σ0 , p00 .

(3.154)

Hence, it also holds that α σ, p0 −→ σ0 , p00

(3.155)

0

(3.156)

σ ,p

00

0

00

≈ σ ,p .

Second, we prove, that R ⊆ d≈−1 e−1 . Assume that Θ; ∅ `C σ, p R σ, p0 ! N,

(3.157)

σ, p0 −→ σ0 , p00 .

(3.158)

α

By (D-C-S KIP), it follows that α σ, p −→ σ0 , p00 ,

(3.159)

0

(3.160)

σ ,p

00

0

00

≈ σ ,p .

The result for ≈◦ follows by considering the definition of open extensions and applying Lemma 3.26 and Lemma 3.30.

Lemma 3.36 If (i) Θ `C σ, p and (ii) Θ, c : γ[ A;B] ; Γ `C p ! N, then Θ; Γ `C σ, let c = open[ A;B] in p ≈◦ σ, let c = open[ B;A] in p.

Proof. Define

R=

{ |

(Θ, ∅, σ, let c = open[ A;B] in p, σ, let c = open[ B;A] in p, N ) Θ `C σ, p, and Θ, c : γ[ A;B] ; ∅ `C p ! N }.

(3.161)

Relation R is well-formed, using Lemma 3.20. We first prove, that R ⊆ d≈e. Assume that Θ; ∅ `C σ, let c = open[ A;B] in p R σ, let c = open[ B;A] in p ! N,

(3.162)

σ, let c = open[ A;B] in p −→ σ10 , p10 .

(3.163)

α

80


By inversion of the transition, we know that σ, let c = open[ A;B] in p −→ σ[c 7→ { A, B}], p,

(3.164)

σ [c 7→ { A, B}], p −→ σ10 , p10 .

(3.165)

σ, let c = open[ B;A] in p −→ σ[c 7→ { B, A}], p.

(3.166)

α

Likewise, it holds that

Because σ[c 7→ { A, B}] = σ[c 7→ { B, A}], it follows by Lemma 3.32, that α σ [c 7→ { B, A}], p −→ σ20 , p10 ,

σ10

=

(3.167)

σ20 ,

(3.168)

hence, Θ; ∅ `C σ10 , p R σ20 , p ! N 0 .

(3.169)

The second inclusion, R ⊆ d≈−1 e−1 , is proven analogously to the first inclusion. Hence, R ⊆ ≈. Extending the result to ≈◦ works as before.

Lemma 3.37 If (i) Θ, c : χ `C σ, p, (ii) `C χ ≤ γ[ A;B] , and (iii) Θ, c : γ[ A;B] ; Γ `C p ! N, then Θ; Γ `C σ, let close[ A;B] (c) in let c = open[ A;B] in p ≈◦ σ, p ! N.

Proof. Define

R=

{ |

(Θ, ∅, σ, let close[ A;B] (c) in let c = open[ A;B] in p, σ, p, N ) Θ, c : χ `C σ, p, `C χ ≤ γ[ A;B] , and Θ, c : γ[ A;B] ; ∅ `C p ! N }.

(3.170)

Relation R is well-formed. A typing for the right hand side is deducible by using Lemma 3.19. We first prove, that R ⊆ d≈e. Assume that Θ; ∅ `C σ, let close[ A;B] (c) in let c = open[ A;B] in p R σ, p ! N,

(3.171)

σ, let close[ A;B] (c) in let c = open[ A;B] in p −→ σ10 , p10 .

(3.172)

α


81

By inversion of the transition, we know that σ, let close[ A;B] (c) in let c = open[ A;B] in p −→

(3.173)

σ \{c}, let c = open[ A;B] in p −→

(3.174)

α

σ[c 7→ { A, B}], p −→

(3.175)

σ10 , p1 .

(3.176)

The type derivation of the channel environment tells us, that σ (c) = { A, B},

(3.177)

σ = σ[c 7→ { A, B}].

(3.178)

that is,

It trivially follows that the following transition also holds α σ, p −→ σ10 , p10 ,

(3.179)

Θ; ∅ `C σ10 , p ≈ σ10 , p ! N 0 .

(3.180)

hence,

The second inclusion, R ⊆ d≈−1 e−1 , is proven analogous to the first inclusion. Hence, R ⊆ ≈. Extending the result to ≈◦ works as before.

Lemma 3.38 If (i) Θ `C σ, p, (ii) Θ; Γ `C p ! N, and (iii) c 6∈ fv( p), then Θ; Γ `C σ, let c = open[ A;B] in let close[ A;B] (c) in p ≈◦ σ, p ! N.

Proof. Define

R=

{ |

(Θ, ∅, σ, let c = open[ A;B] in let close[ A;B] (c) in p, σ, p, N ) Θ `C σ, p, Θ; ∅ `C p ! N, and c 6∈ fcv( p).}.

(3.181)

Relation R is well-formed. A typing for the left hand side is deducible by using Lemma 3.13.

82

CHAPTER 3. PROGRAM TRANSFORMATION SCHEME We first prove, that R ⊆ d≈e. Assume that Θ; ∅ `C σ, let c = open[ A;B] in let close[ A;B] (c) in p R σ, p ! N,

(3.182)

σ, let c = open[ A;B] in let close[ A;B] (c) in p −→ σ10 , p10 .

(3.183)

α

By inversion of the transition, we know that σ, let c = open[ A;B] in let close[ A;B] (c) in p −→ σ [c 7→ { A, B}], let close

[ A;B]

(c) in p −→ α

(3.184) (3.185)

σ\{c}, p −→

(3.186)

σ10 , p10 .

(3.187)

Because c 6∈ fcv( p),

(3.188)

we know by well-formedness of the channel environment that c 6∈ dom Γ, and

(3.189)

c 6∈ dom σ.

(3.190)

It follows by Lemma 3.32, that α σ, p −→ σ20 , p10 ,

(3.191)

σ10

(3.192)

=

σ20 .

Hence, Θ; ∅ `C σ10 , p10 ≈ σ20 , p10 ! N 0 .

(3.193)

The second inclusion, R ⊆ d≈−1 e−1 , is proven analogously to the first inclusion. Hence, R ⊆ ≈. Extending the result to ≈◦ works as before.

Lemma 3.39 If (i) Θ `C σ, p, (ii) Θ; Γ `C d ⇒ Θ0 ; Γ0 ! Nd , (iii) Θ0 , c : γ[ A;B] ; Γ0 `C p ! Np and (iv) c 6∈ fcv(d), then Θ; Γ `C σ, let d in let c = open[ A;B] in p ≈◦ σ, let c = open[ A;B] in let d in p ! N.


83

Proof. Define

R = { (Θ, ∅, σ, let d in let c = open[ A;B] in p, σ, let c = open[ A;B] in let d in p, N ) | Θ `C σ, p, Θ; ∅ `C d ⇒ Θ0 ; Γ0 ! Nd , Θ0 , c : γ[ A;B] ; Γ0 `C p ! Np , and c 6∈ fcv(d).}.

(3.194)

Relation R is well-formed, which is trivially shown using Lemma 3.18. Now, assume that Θ; ∅ `C σ, let d in let c = open[ A;B] in p R σ, let c = open[ A;B] in let d in p ! N,

(3.195)

and σ, let d in let c = open[ A;B] in p −→ σ1 , p1 . α

(3.196)

When inverting the transition, there are two cases to consider regarding the last transition rule that applies. • Subcase (D-C-Ctx-2). The transition step on the left hands side looks as follows, σ, let d in let c = open[ A;B] in p −→ σ, let c = open[ A;B] in p, α

(3.197)

if and only if, on the right hand side, we have σ, let c = open[ A;B] in let d in p −→ σ[c 7→ { A, B}], let d in p, α

σ [c 7→ { A, B}], let d in p −→ σ[c 7→ { A, B}], p.

(3.198) (3.199)

It trivially also holds that Θ; ∅ `C σ, let c = open[ A;B] in p ≈ σ[c 7→ { A, B}], p ! N 0 ,

(3.200)

by examining the transition on the left hand side again. Note that channel environments never change in this particular evaluation context. • Subcase (D-C-Skip). The transition steps on the left hands are as follows. σ, let d in let c = open[ A;B] in p −→ σ0 , let c = open[ A;B] in p, 0

σ , let c = open

[ A;B]

0

(3.201)

in p, −→ σ , [c 7→ { A, B}] p,

(3.202)

σ0 , [c 7→ { A, B}] p, −→ σ1 , p1 ,

(3.203)

α

84

CHAPTER 3. PROGRAM TRANSFORMATION SCHEME if and only if, on the right hand side, we have σ, let c = open[ A;B] in let d in p −→ σ[c 7→ { A, B}], let d in p, (3.204) σ[c 7→ { A, B}], let d in p −→ σ0 [c 7→ { A, B}], p, σ0 [c 7→ { A, B}], p −→ σ1 , p1 , (3.205) α

because c 6∈ fcv(d) and Lemma 3.31. It obviously also holds that Θ; ∅ `C σ1 , p1 ≈ σ1 , p1 .

(3.206)

Hence, R ⊆ ≈. Extending the result to ≈◦ again works as before.

Lemma 3.40 If (i) Θ `C σ, p, (ii) Γ `C e : b N , [ A;B]

; Γ `C p1 ! N1 ,

[ A;B]

; Γ `C p2 ! N2 , and

(iii) Θ, c : γ1 (iv) Θ, c : γ2

(v) N1 , N2 ⊆ N, then Θ; Γ `C σ, if e then (let c = open[ A;B] in p1 ) else (let c = open[ A;B] in p2 ) ≈◦ σ, let c = open[ A;B] in if e then (let c{l1 } in p1 ) else (let c{l2 } in p2 ) ! N1 ∪ N2 .

Proof. Define

R = { (Θ, ∅, σ, if e then (let c = open[ A;B] in p1 ) else (let c = open[ A;B] in p2 ), σ, let c = open[ A;B] in if e then (let c{l1 } in p1 ) else (let c{l2 } in p2 ), N ) | Θ `C σ, p, ∅ `C e : b N , [ A;B] Θ, c : γ1 ; ∅ `C p1 ! N1 , [ A;B] Θ, c : γ2 ; ∅ `C p2 ! N2 , and N1 , N2 ⊆ N }. (3.207)


85

By straightforward deduction steps, it is easy to see that relation R is well-formed. We use a conditional session type, hl1 → γ1 , l2 → γ2 i, as common session type on the derivation on the right hand side. Assume that Θ; ∅ `C σ, if e then (let c = open[ A;B] in p1 ) else (let c = open[ A;B] in p2 ) R σ, let c = open[ A;B] in if e then (let c{l1 } in p1 ) else (let c{l2 } in p2 ), N ), (3.208) σ, if e then (let c = open[ A;B] in p1 ) else (let c = open[ A;B] in p2 ) −→ σ0 , p0 . (3.209) α

The transition steps on the left hand side looks as follows—where, without loss of 0 generality e ≡ 0 N , N 0 ⊇ N— σ, if e then (let c = open[ A;B] in p1 ) else (let c = open[ A;B] in p2 )

−→ σ, (let c = open σ, (let c = open

[ A;B]

[ A;B]

(3.210)

in p2 ),

(3.211)

in p2 ) −→ σ[c 7→ { A, B}], p2 ,

(3.212)

0

α

0

σ[c 7→ { A, B}], p2 −→ σ , p ,

(3.213)

if and only if, the transition steps on the right hand side look as follows σ, let c = open[ A;B] in if e then (let c{l1 } in p1 ) else (let c{l2 } in p2 )

(3.214)

−→ σ[c 7→ { A, B}], if e then (let c{l1 } in p1 ) else (let c{l2 } in p2 ),

(3.215)

σ [c 7→ { A, B}], if e then (let c{l1 } in p1 ) else (let c{l2 } in p2 )

(3.216)

−→ σ[c 7→ { A, B}], (let c{l2 } in p2 ),

(3.217)

σ[c 7→ { A, B}], (let c{l2 } in p2 ) −→ σ[c 7→ { A, B}], p2 ,

(3.218)

σ[c 7→ { A, B}], p2 −→ σ0 , p0 .

(3.219)

α

It obviously also holds that Θ; ∅ `C σ0 , p0 ≈ σ0 , p0 ,

(3.220)

hence, R ⊆ ≈. Extending the result to ≈◦ again works as before.

The equational rules of = ˆ specify a well-formed equivalence relation and a bisimulation relation. Lemma 3.41 The relation = ˆ is well-formed.

Lemma 3.42 The relation = ˆ is an equivalence relation.

86


N P (N ) Z Var CVar PVar Ports = P (PVar) CLab POp EOp Op

3 3 3 3 3 3 3 3 3 3 3

A, B, . . . N, . . . i f , g, x, y, z, . . . c, . . . s, . . . π, . . . l, . . . pfun, . . . op, . . . op ::= op A | pfun

Val

3

v

::= |

iN rec j f [c]( x ) = p

Expr

3

e

::=

x|v

Def

3

d

::= |

x = e | x = op (e) s = newPort

| | Prog

3

p

::= | | |

c = open[ A;B] (s) | close[ A;B] (c) x = trans[ A;B] c(e) | c{l } halt e [c] e let d in p if e then p else p

Figure 3.21: Syntax of ILD

Theorem 3.2 = ˆ ⊆ ≈◦ .

Proof. By induction, using Theorem 3.1 and Lemmas 3.35 to 3.40.

3.3

The ILD Calculus — Sequential Programming with Ports and Channels

Our goal is to transform ILC programs by extracting a program slice for each location such that running all slices concurrently on their respective locations is equivalent to

3.3. THE ILD CALCULUS

87

running the original program. Before we are able to do so, one additional ingredient is missing: we introduce global port names for types of connections such that different processes can reference a connection under that name. Otherwise it would be impossible to reliably refer to the same connection type from two different locations. In this section, we first introduce formal syntax and semantics of ILD , an augmentation of ILC by ports. Again, we use a small-step reduction semantics to model the effect-free part of the semantics and a labeled transition system to model I/O interactions. The static semantics we then present is only a slight extension of the static semantics of ILC . In addition to the semantics, we present a type-preserving translation of ILC programs to ILC . Equational rules are stated that allow to aggregate the handling of ports to the beginning of a program.

3.3.1

Syntax

The syntax of ILD is shown in Figure 3.21. It is based on the syntax of the previous intermediate language, ILC . There is one additional statement, s = newPort, that introduces a fresh port name. Port names are members of a separate syntactic category, PVar. Sets of used port names, π ∈ Ports, are subsets of the set of all port names. Also, the open statement now opens a channel with a specific channel type prescribed by port p. Opening channels with the same port ensures that the channels’ session types and locations match even if they occur in different places in the program. Freshness of port names ensures that each port value occurs at most once during the run of a program. Free variables and free channel variables of a program p are denoted again by fv( p) and fcv( p), respectively. Free port names of a program p are denoted by fpv( p).

3.3.2

Dynamic Semantics

Again, we split up the dynamic semantics of ILD into two parts, small-step reduction relations specifying the effect-free program transitions, and a second family of relations, specifying effectful state transitions in terms of a labeled transitions system. The first reduction relation, −→ ⊆ Prog × Prog, unrelated to any state informations, has been taken over unchanged from ILC and is not shown again (shown in the first part of Figure 3.11). The second reduction relation, −→ ⊆ Ports × Chans × Prog × Ports × Chans × Prog, extends the reductions related to channels found in ILC by a new port component, registering the set of port names already in use, π. The actual transition rules are shown in Figure 3.22. Most of the rules are analogous to the rules for ILC with the addition of threading through an unchanged set of used port names. The (D-D-L ET-N EWPORT) handles the new newPort statement by registering the new port name in the set of used port names. The side condition of the rules assures that we only generate fresh port names. A newPort statement with an already used port name can always be avoided by α-conversion. The

88


D-D-C TX

p−→ p0 π, σ, p−→π, σ, p0 D-D-L ET-N EWPORT

π, σ, let s = newPort in p

−→

π ∪ {s}, σ, p

if s 6∈ π

−→

π, σ[c 7→ { A, B}], p

if s ∈ π

−→

π, σ, p[i N ∪{B}/x ] if σ (c) = { A, B}, A ∈ N

−→

π, σ\{c}, p

−→

π, σ, p

D-D-L ET-O PEN

π, σ, let c = open[ A;B] (s) in p D-D-L ET-T RANS

π, σ, let x = trans[ A;B] (c, i N ) in p D-D-L ET-C LOSE

π, σ, let close[ A;B] (c) in p

if σ (c) = { A, B}

D-D-C HAN -A PP

π, σ, let c{l } in p

if c ∈ dom σ

Figure 3.22: Reduction rules for ILD (D-D-L ET-O PEN) rule now also checks, that the opening of a channel refers to an already opened port name, s. The labeled transition system specifying the I/O behavior of ILD programs is a straightforward extension of the system for ILC augmented by a state component of used port names. The rules for ILC are shown in Figure 3.23.

3.3.3

Static Semantics

The type language and the typing system for ILD must take into account the additional feature of ILD , namely ports. For each port name that occurs in a typing context, we statically register its port type. Port types register types of channels that are supposed to be associated with a port name. The addition to the type language and to the type environments are shown at the beginning of Figure 3.24. A port type, φ, wraps a channel type of possible channels that can be opened using a certain port. Type environments, Γ, now also register port types under port names besides annotated types under term variables. The rest of the type languages, such as the type language for annotated types and channel types is kept unchanged with respect to ILC and is not repeated again. The type system of ILD consists of the following nine typing judgments. • ` D γ ≤ γ specifies subtyping between session types. • ` D χ ≤ χ specifies subtyping between channel types.

3.3. THE ILD CALCULUS

89

D-D-H ALT halt

−→

halt D-D-L ET-R EAD

?i A

let x = read A () in p −→ D-D-L ET-W RITE

!i A

let = write A (i N ) in p −→

Ω p[i{ A}/x ] p[0{ A}/ ]

if A ∈ N

D-D-C TX -2

p −→ p0 α π, σ, p −→ π, σ, p0 α

D-D-S KIP

π, σ, p−→π 0 , σ0 , p0 π 0 , σ0 , p0 −→ π 00 , σ00 , p00 α π, σ, p −→ π 00 , σ00 , p00 α

Obs

3

α

::=

halt | ?i A | !i A

Figure 3.23: Labeled transition system for ILD • ` D τ ≤ τ specifies subtyping between annotated types. • ` D φ ≤ φ specifies subtyping between port types. • Γ ` D s : φ specifies the type for port name s under type environment Γ. • Γ ` D e : τ specifies the type for expression e with respect to a type environment Γ. • Θ; Γ ` D d ⇒ Θ0 ; Γ0 ! N states that d transforms Γ to Γ0 , Θ to Θ0 , and may perform operations at locations N. • Θ; Γ ` D p ! N specifies the typing of program p under environments Γ and Θ with possible effects on locations N. • Θ; Γ ` D π, σ, p ! N specifies the typing of a channels σ and program p under environments Γ and Θ resulting in effects on locations N. The first three subtyping relations are the same as for ILC and are not shown again. The subtyping of port types, ` D φ ≤ φ, is specified by co-variantly resorting to subtyping of channels types. The typing rule is shown in the middle part of Figure 3.24.

90


PType

3

φ

::=

Port χ

port types

TEnv

3

Γ

::=

∅ | Γ, x : τ | Γ, s : φ

type environments

S UB -D-P ORT `D χ

1 ≤ χ2 ` D Port χ1 ≤ Port χ2 S-D-P ORT-VAR

Γ ` D s : Γ(s) S-D-P ORT-S UB Γ `D s : φ

Γ

`C

` D φ ≤ φ0 s : φ0

Figure 3.24: Type language of ILD , subtyping and typing of ILD ports

The bottom part of Figure 3.24 shows the typing rules for port names specifying the relation Γ ` D s : φ. The rules for port names are similar to the rules for channel names except that port names are registered in the type environment Γ. The (S-D-P ORTVAR) rule looks up a port type associated to port name s in type environment Γ. The (D - S - PORT- SUB) rule adds port type subtyping to the port name lookup. The typing rules specifying Θ ` D c : χ and Γ ` D e : τ are unchanged to the rules specified for ILC and are not shown again. Figures 3.25 and 3.26 show the adapted typing rules for annotated statements, specifying Θ, Γ ` D d ⇒ Θ0 , Γ0 ! N. The typing rules specifying the typing are basically the rules for ILC . The (D-D-D EF -N EWPORT) associates a port type to the new port name s. The rule handling open statements now also take the port name s into account (S-D-D EF -O PEN). The typing rules for programs specifying Θ; Γ ` D p ! N are similar to the rules for ILC and are therefore not repeated again. Figure 3.27 shows the typing rules for programs states including the typing of port names and channel environments, Θ; Γ ` D π, σ, p ! N. The (S-D-P ROG -C HAN) rule additionally assures that the ports names registered in the type environment correlate with the port names occurring free in a program.

3.3.4

Translation

Translating ILC programs to ILD , the port introduction transformation, is straightforward. We just generate a new port name by using a newPort statement just before every open statement. The formalization of translation D is shown in Figure 3.28.

3.4. THE ILE CALCULUS

91

S-D-D EF -E XPR

Θ; Γ

`D

Γ `D e : τ x = e ⇒ Θ; Γ, x : τ ! ∅

S-D-D EF -P FUN

Θ; Γ

`D

(∀i ) Γ ` D ei : b N x = pfun(ei ) ⇒ Θ; Γ, x : b N ! ∅

S-D-D EF -OP

(∀i ) Γ ` D ei : b{ A} Θ; Γ ` D x = op A (ei ) ⇒ Θ, Γ( x : b{ A} ) ! { A} Figure 3.25: Typing rules for ILD statements

3.3.5

Simplification Rules

To prepare programs for the final transformation step, we apply another set of simplification rules to ILD programs. They are expressed by the set of equational rules shown in Figure 3.29 and specify the port floating transformation step. The idea of this transformation step is to float newPort statements to the beginning of the program. This is expressed by the equational rules (E Q -D-L ET-N EWPORT) and (E Q D-N EWPORT). The former rule states that two programs are equal when we exchange a leading newPort statement with a following, second, definition provided the program is well typed and the port name s does not already occur in the second statement, d. The other equational rules guarantee that programs that are convertible by a state-invariant reduction are equal, and that this typed-relation indeed is an equality relation. Note that colliding port names can always be eliminated by using α-conversion. Applying the (E Q -D-L ET-N EWPORT) rule multiple times from left to right together with canonical program transformations using (E Q -D-B ETA) followed by multiple applications of (E Q -D-N EWPORT) from left to right, allows us to transform most programs to equivalent counterparts without explicit newPort statements.

3.4

The ILE Calculus — Concurrent Programming with Channels

The final step of our transformation scheme consists of splitting the transformed ILD program into program slices that are targeted to run separately on the different locations. The calculus we finally develop therefore explicitly models concurrent computations that communicate via channels. To avoid complicating the calculus with notions like hostnames or ambients, the ends of a communication channel are chosen nondeterministically. That is, connecting a new client to a port establishes a connection with one of the servers that listen on that port.

92


S-D-D EF -N EW P ORT

Θ; Γ ` D s = newPort ⇒ Θ; Γ, s : φ ! ∅ S-D-D EF -O PEN

Θ; Γ ` D S-D-D EF -T RANS -1 `D

Θ, c : χ; Γ

`D

S-D-D EF -T RANS -2 `D

Θ, c : χ; Γ

`D

Γ ` D s : Port γ[ A;B] c = open[ A;B] (s) ⇒ Θ, c : γ[ A;B] ; Γ ! ∅

χ ≤ (b, γ)[ A;B] Γ `D e : bN A∈N [ A;B ] x = trans c(e) ⇒ Θ, c : γ[ A;B] ; Γ, x : b N ∪{ B} ! ∅ χ ≤ (b, γ)[ B;A] Γ `D e : bN A∈N [ A;B ] x = trans c(e) ⇒ Θ, c : γ[ B;A] ; Γ, x : b N ∪{ B} ! ∅

S-D-D EF -C LOSE -1

` D χ ≤ ε[ A;B] Θ, c : χΓ ` D close[ A;B] (c) ⇒ Θ; Γ ! ∅ S-D-D EF -C LOSE -2

Θ, c : χ; Γ

` D χ ≤ ε[ B;A] close[ A;B] (c) ⇒ Θ; Γ ! ∅

`D

S-D-D EF -CA PP `D

χ ≤ hli → γi i[ A;B] [ A;B]

Θ, c : χ; Γ ` D c{l j } ⇒ Θ, c : γ j

;Γ!∅

Figure 3.26: Typing rules for ILD statements The communication primitives of ILE can be considered as typed variants of traditional socket communication primitives. We replace the multi-location communication operations of ILD by operations that just “run” on one location. For example, the x = trans[ A;B] c(y) statement of ILD specifies sending of y at location A and receiving of x at location B (via channel c) at the same time. Also, the open[ A;B] and close[ A;B] (c) statements, used in the previous calculus, perform operations at two locations. Subsequently, statements in the final setting are annotated with at most one location.

3.4.1

Syntax

Figure 3.30 presents the syntax of the final calculus, ILE . As mentioned, the syntax of ILD differs from ILC in two major ways. First there is the additional program construct, p1 || p2 , that specifies the interleaved execution of p1 and p2 . Second, there are the one-


93

S-D-P ROG -C HAN

dom Γ ∩ PVar = fpv( p) ⊆ π dom Θ = fcv( p) (∀c) Θ(c) = γ[ A;B] ⇔ σ(c) = { A, B} Θ `C π, σ, p S-D-P ROG Θ `C π, σ,

p Θ; Γ `C p ! N C Θ; Γ ` π, σ, p ! N

Figure 3.27: Typing rules for ILD programs sided versions of the previous communication statements. Instead of an unspecific open statement for establishing a channel between two locations, there are now listen and connect statements to create a server end and a client end of a channel for a specific port. In the same manner, there are separate communication operations to send an outbound message and to recv an inbound message over an established channel. The additional skip statement denotes a statement without side effect. There is another minor simplification. We now assume that there is one global port environment of all needed port names, π, instead of allowing the dynamic creation of new port names using an explicit newport construct. The simplification steps to obtain a global port name environment are described in Section 3.3.5.

3.4.2

Dynamic Semantics

Besides having two parts for the specification of the dynamic semantics, a relation specifying effect-free reductions and a set of labeled transitions specifying effectful state transitions, we additionally add a third relation, ≡s , specifying structural congruence rules of parallel processes to transport reducible processes to first position, as first suggested by Berry and Boudol in a similar fashion for the definition of the chemical abstract machine (CHAM) [BB92]. Figure 3.31 shows the rules specifying the least relation, ≡s ⊆ Prog × Prog, for two programs to be structurally equal with respect to parallel composition as associative (D-E-S TRUCT-A SSOC) and commutative (D-E-S TRUCT-C OMM) operator with identity halt (D-E-S TRUCT-I D). The reduction relation, −→ ⊆ Prog × Prog, specifying reductions independent of any program state is adopted unchanged and is shown again in the first part of Figure 3.32. Additionally, skip statements are skipped when executed. Reductions dependent on the program state, −→ ⊆ Ports × Chans × Prog × Ports × Chans × Prog, are shown in the second part of Figure 3.32. First, the rules incorporate simple reductions reductions (D-E-C TX -1) and the structural equivalence relation (D-E-C TX -2) into stateful reductions.

94


D Ji N K D Jrec j f [c]( x ) = pK

= =

iN rec j f [c]( x ) = D JpK

=

x

D JhaltK D Je0 [c] ei K D Jlet x = e in pK D Jlet x = pfun(ei ) in pK D Jlet x = op A (ei ) in pK D Jlet c = open[ A;B] in pK

= = = = = =

D Jlet x = trans[ A;B] c e in pK D Jlet close[ A;B] (c) in pK D Jif e then p1 else p2 K

= = =

halt D Je0 K [c] D Jei K let x = D JeK in D JpK let x = pfun(D Jei K) in D JpK let x = op (D Jei K) in D JpK let s = newPort in let c = open[ A;B] (s) in D JpK let x = trans[ A;B] c (D JeK) in D JpK let close[ A;B] (c) in D JpK if D JeK then D Jp1 K else D Jp2 K

D JxK

Figure 3.28: Translation D from ILC to ILD There is one additional congruence rule, the (D-E- PAR) rule that states that, when dealing with several parallel processes, we are able to freely choose one process to perform the next reduction. The side conditions of the rule guarantee that parallel reductions do not interfere with respect to new channels names created. Note that it is always possible to rename channel names in advance by α-conversion. The (D-E-L ET-L ISTEN -C ONNECT) specifies the pairing of a listen command and a connect command for the same port resulting in a new channel between the two locations the statements are running on. If the channel name, c, of the statements does not match, it maybe possible to in advance match up the name by α-conversion. A pair of send/recv statements on the the same channel, c, results in transferring the value v from one end to the other (D-E-L ET-S END -R ECV). Closing both ends of a channel amounts to dropping the channel entirely (D-E-L ETC LOSE -C LOSE). Applications of channels to channel labels have to proceed synchronized on both ends of the channels (D-E-C HAN -A PP). The labeled transition system specifying the I/O behavior of ILE programs works exactly like the system for ILD . The actual rules are shown again in Figure 3.33.

3.4.3 Static Semantics The type language for ILE does not have to be changed compared to the type language for ILD . All distinct features of the type language of ILD as for example session types, channel types and port types can be taken over unchanged. What changes are the typing


95

E Q -D-R EFL

Θ; Γ ` D π, σ, p ! N Θ; Γ ` D π, σ, p = ˆ π, σ, p ! N E Q -D-T RANS Θ; Γ ` D π, σ,

E Q -D-S YMM Θ; Γ ` D π, σ,

Θ; Γ

`D

p= ˆ π 0 , σ0 , p0 ! N = ˆ π, σ, p ! N

π 0 , σ0 , p0

p= ˆ π 0 , σ0 , p0 ! N Θ; Γ ` D π 0 , σ0 , p0 = ˆ σ00 , p00 ! N D 00 00 00 Θ; Γ ` π, σ, p = ˆ π ,σ , p ! N

E Q -D-B ETA Θ; Γ ` D π, σ,

Θ; Γ

`D

p!N π, σ, p−→π, σ, p0 π, σ, p = ˆ π, σ, p0 ! N

E Q -D-N EW P ORT

Θ; Γ

`D

Θ ` D π, σ, p Θ; Γ, s : φ ` D p ! N π, σ, let s = newPort in p = ˆ π ∪ {s}, σ, p ! N

E Q -D-L ET-N EW P ORT Θ ` D π, σ, p Θ; Γ

` D d ⇒ Θ0 ; Γ0 ! Nd Θ0 ; Γ0 , s : φ ` D p ! N Θ; Γ π, σ, let d in let s = newPort in p = ˆ π, σ, let s = newPort in let d in p ! N

s 6∈ fpv(d)

`D

Figure 3.29: Equational rules for ILD programs specifying port floating rules specifying the type relations for statements and for program—they are now also geared towards concurrency—and the modified communication primitives. Consequently, the type system again consists of the following nine typing judgments. • ` E γ ≤ γ specifies subtyping between session types. • ` E χ ≤ χ specifies subtyping between channel types. • ` E τ ≤ τ specifies subtyping between annotated types. • ` E φ ≤ φ specifies subtyping between port types. • Γ ` E s : φ specifies the type for port name s under type environment Γ. • Γ ` E e : τ specifies the type for expression e with respect to a type environment Γ. • Θ; Γ ` E d ⇒ Θ0 ; Γ0 ! N states that d transforms Γ to Γ0 , Θ to Θ0 , and may perform operations at locations N. • Θ; Γ ` E p ! N specifies the typing of program p under environments Γ and Θ with possible effects on locations N. • Θ; Γ ` E π, σ, p ! N specifies the typing of a channels σ and program p under environments Γ and Θ resulting in effects on locations N.

96


N P (N ) Z Var CVar PVar CLab POp EOp Op

3 3 3 3 3 3 3 3 3 3

A, B, . . . N, . . . i f , g, x, y, z, . . . c, . . . s, . . . l, . . . pfun, . . . op, . . . op ::= op A | pfun

Val

3

v

::= |

iN rec j f [c]( x ) = p

Expr

3

e

::=

x|v

Def

3

d

::= |

x = e | x = op (e) c = listen A (s) | c = connect A (s)

| | | | Prog

3

p

::= | | | |

send A c(e) | x = recv A (c) close A (c) c{l } A skip halt e [c] e let d in p if e then p else p p || p

Figure 3.30: Syntax of ILE We present and comment on the typing rules for statements and for programs. The specification of the other type relations is kept unchanged and thus not repeated again. Figure 3.34 shows the adapted typing rules for annotated statements, specifying Θ, Γ ` E d ⇒ Θ0 , Γ0 ! N. Because the communication primitives changed, we also had to adapt the typing rules concerning communication statements. Basically, the new rules are just one-sided counterparts of the previously presented rules. Instead of a single open rule, we now have two similar rules, (S-E-D EF -L ISTEN) and (S-E-D EF -C ONNECT), for both sides of a channel. The rule for listen assigns a mirrored channel type to the opened channel reflecting the mirroring of the port on the type level. Figure 3.35 shows the typing rules for programs, specifying Θ, Γ ` E π, σ, p ! N.


97

D-E-S TRUCT-R EFL

p ≡s p || halt D-E-S TRUCT-C OMM

p1 || p2 ≡s p2 || p1 D-E-S TRUCT-A SSOC

p1 || ( p2 || p3 ) ≡s ( p1 || p2 ) || p3 Figure 3.31: Structural equality rules for ILE programs Most of the rules are similar to the rules of ILD . The rule for concurrent execution, (S-E-P ROG -A LT), splits the channel environment into two parts, one for each subprocess. Adding to channel environments guarantees, that if two channel occur in both environment, they both must carry identical port types.

3.4.4

Translation

For the final step of our transformation scheme, the splitting transformation, we translate a simplified ILD program to ILE in such a way that we get separate processes for each location. The transformation E , shown in Figure 3.36, is defined as a function on derivations of typing judgments. It makes use of the locations annotations derived for each subexpression and each subprogram. To formalize the translations, we define the following additional notation for naming derivations. Definition 3.12 We write (i) D :: ` E γ ≤ γ to mean “D is a derivation tree with conclusion ` E γ ≤ γ”, (ii) D :: ` E χ ≤ χ to mean “D is a derivation tree with conclusion ` E χ ≤ χ”, (iii) D :: ` E τ ≤ τ to mean “D is a derivation tree with conclusion ` E τ ≤ τ”, (iv) D :: ` E φ ≤ φ to mean “D is a derivation tree with conclusion ` E φ ≤ φ”, (v) D :: Γ ` E s : φ to mean “D is a derivation tree with conclusion Γ ` E s : φ”, (vi) D :: Γ ` E e : τ to mean “D is a derivation tree with conclusion Γ ` E e : τ”, (vii) D :: Θ; Γ ` E d ⇒ Θ0 ; Γ0 ! N to mean “D is a derivation tree with conclusion Θ; Γ ` E d ⇒ Θ0 ; Γ0 ! N”, (viii) D :: Θ; Γ ` E p ! N to mean “D is a derivation tree with conclusion Θ; Γ ` E p ! N”, and

98


D-E-L ET-VAL

let x = v in p

−→

p[v/x]

let x = pfun(i j Nj ) in p

−→

p [i

−→

p1

if i 6= 0 and N 6= ∅

−→

p2

if N 6= ∅

−→

p j [reci f [c]( x)= p/ f i ][c0/c][v/x]

−→

p

D-E-PF UN T

Nj

/x]


T

Nj 6= ∅

D-E-I F -T RUE

if i N then p1 else p2 D-E-I F -FALSE

if 0 N then p1 else p2 D-E-A PP

(rec j f [c]( x ) = p) [c0 ] v D-E-S KIP

let skip in p

D-E-C TX -1

D-E-C TX -2

p−→ p0 π, σ, p−→π, σ, p0

p1 ≡ s p2

π, σ, p2 −→π 0 , σ0 , p20 π, σ, p1 −→π 0 , σ0 , p3

p20 ≡s p3

D-E-PAR

π, σ1 , p1 −→π 0 , σ10 , p10 if dom σ10 ∩ dom σ2 = ∅ π, σ1 ] σ2 , p1 || p2 −→π 0 , σ10 ] σ2 , p10 || p2 D-E-L ET-L ISTEN -C ONNECT

π, σ, let c = listen A (s) in p1 || let c = connectB (s) in p2 −→ π, σ[c 7→ { A, B}], p1 || p2 if s ∈ π, c 6∈ dom σ D-E-L ET-S END -R ECV

π, σ, let send A c(i N ) in p1 || let x = recvB (c) in p2 −→ π, σ, p1 || p2 [i N∪{B}/x] if σ(c) = { A, B}, A ∈ N D-E-L ET-C LOSE -C LOSE

π, σ, let close A (c) in p1 || let closeB (c) in p2 −→ π, σ\{c}, p1 || p2 if σ (c) = { A, B} D-E-C HAN -A PP

π, σ, let c{l } A in p1 || let c{l } B in p2 −→ π, σ, p1 || p2

if σ(c) = { A, B}

Figure 3.32: Reduction rules for ILE


99

D-E-H ALT halt

−→

halt D-E-L ET-R EAD

?i A

let x = read A () in p −→ D-E-L ET-W RITE

!i A


Ω p[i{ A}/x] p[0{ A}/x]

if A ∈ N

D-E-C TX -3

p −→ p0 α π, σ, p −→ π, σ, p0 α

D-E-S KIP

π, σ, p−→π 0 , σ0 , p0 π 0 , σ0 , p0 −→ π 00 , σ00 , p00 α π, σ, p −→ π 00 , σ00 , p00 α

Obs

3

α

::=

halt | ?i A | !i A

Figure 3.33: Labeled transition system for ILE (ix) D :: Θ; Γ ` E π, σ, p ! N to mean “D is a derivation tree with conclusion Θ; Γ ` E π, σ, p ! N”.

We start with a derivation tree D :: Θ, Γ ` D π, σ, p, !N for a program p where all newPort statements are eliminated in advance. The transformation extracts for each Ai ∈ N the slice of operations for location Ai , and puts them in parallel. The resulting program has the form σ, π, p10 || . . . || p0m . The actual slices for each location are generated by translation E A . Depending whether a 0 or generate a slice is really needed for a location or not, we either apply translation E A 0 halting program, halt. Translation E A is defined inductively over the type derivation of program p by resorting to two other translations, E A , one for statements and one for expressions. Figures 3.37 and 3.38 present the part of the translation handling statements. When generating a statement for slice A, it depends whether the statement is relevant for location A. In case the statement is irrelevant, we generate a skip statement. Expres-

100


S-E-D EF -E XPR

Γ È e : τ Θ; Γ ` E x = e ⇒ Θ; Γ, x : τ ! ∅ S-E-D EF -P FUN

(∀i ) Γ ` E ei : b N Θ; Γ ` E x = pfun(ei ) ⇒ Θ; Γ, x : b N ! ∅ S-E-D EF -OP

Θ; Γ

È

(∀i ) Γ ` E ei : b{ A} x = op A (ei ) ⇒ Θ, Γ( x : b{ A} ) ! { A} S-E-D EF -S KIP

Θ; Γ ` E skip ⇒ Θ; Γ ! ∅ S-E-D EF -L ISTEN

Θ; Γ

È

Γ ` E s : Port γ[ A;B] c = listen A (s) ⇒ Θ, c : γ[ B;A] ; Γ ! ∅

S-E-D EF -C ONNECT

Γ ` E s : Port γ[ A;B] Θ; Γ ` E c = connectB (s) ⇒ Θ, c : γ[ A;B] ; Γ ! ∅ S-E-D EF -S END Θ, c : χ ` E

c : (b, γ)[ A;B] Γ È e : b N A∈N E A Θ, c : χ; Γ ` send c(e) ⇒ Θ, c : γ[ A;B] ! ∅

S-E-D EF -R ECV

Θ, c : χ ` E c : (b, γ)[ A;B] Γ È e : b N A∈N E B Θ, c : χ; Γ ` x = recv (c) ⇒ Θ, c : γ[ A;B] ; Γ, x : b N ∪{ B} ! ∅ S-E-D EF -C LOSE

Θ, c : χ ` E c : ε[ A;B] Θ, c : χ; Γ ` E close A (c) ⇒ Θ; Γ ! ∅ S-E-D EF -CA PP

Θ, c : χ ` E c : hli → γi i[ A;B] [ A;B]

Θ, c : χ; Γ ` E c{l j } A ⇒ Θ, c : γ j

;Γ!∅

Figure 3.34: Typing rules for ILE statements


101

S-E-P ROG -H ALT

Θ; Γ ` E halt ! ∅ S-E-P ROG -A PP N

Θ≡c:χ Γ ` E e1 : [χ]τ −→ 0 Θ; Γ ` E e1 [c] (e2 ) ! N

Γ ` E e2 : τ

S-E-P ROG -L ET Θ; Γ ` E d ⇒

Θ0 ; Γ0 ! Nd Θ 0 ; Γ 0 ` E p ! Np E Θ; Γ ` let d in p ! Nd ∪ Np

S-E-P ROG -I F Γ È e

: bN N1 , N2 ⊆ N 6= ∅ Θ, Γ p1 ! N1 Θ, Γ ` E p2 ! N2 E Θ, Γ ` if e then p1 else e2 ! N1 ∪ N2

È

S-E-P ROG -A LT Θ1 ` E p1 ! N1 Θ1 , Θ2 ` E p1

Θ2 ` E p2 ! N2 || p2 ! N1 ∪ N2

S-E-P ROG -C HAN

dom Γ ∩ PVar = fpv( p) ⊆ π dom Θ = fcv( p) (∀c) Θ(c) = γ[ A;B] ⇔ σ(c) = { A, B} Θ ` E π, σ, p S-E-P ROG Θ ` E π, σ,

p Θ; Γ ` E p ! N E Θ; Γ ` π, σ, p ! N

Figure 3.35: Typing rules for ILE programs

sions and operations are only generated, if the value of an expression or an primitive function is needed later or the effectful operation has to be executed on this particular location. For open statements we either generate a listen or a connect statement depending on the side of the communication channel we are dealing with. Accordingly, for trans statements, we either generate send or recv statements. For close statements and channel applications, code is generated on both ends of the channel. Finally, the part of the translation handling expressions is shown in Figure 3.39. We again translate expression by induction on the type derivation resorting to the translation of programs for function bodies.

102


} D1 :: Θ ` D π, σ, p D E v D2 :: Θ; Γ ` p ! N ~ Θ; Γ ` D π, σ, p ! N

=

q y E A D :: Θ; Γ ` D p ! N

=

u

π, σ, E A1 JD2 K || . . . || E An JD2 K where Ai ∈ N ( E A0 JD K if A ∈ N

halt otherwise q y E A0 D :: Θ; Γ ` D halt ! ∅ = halt u } N D :: Γ ` D e1 : [χ]τ −→ 0 w 1 w Θ≡c:χ E A0 w = E A JD1 K [c] (E A JD2 K) D v ~ D2 :: Γ ` e2 : τ Θ; Γ ` D e1 [c] (e2 ) ! N u } D1 :: Θ; Γ ` D d ⇒ Θ0 ; Γ0 ! Nd 0 0 D 0 ~ = D2 :: Θ ; Γ ` p ! Np let E A JD1 K in E A JD2 K EA v Θ; Γ ` D let d in p ! Nd ∪ Np u } D1 :: Γ ` D e : b N N1 , N2 ⊆ N 6= ∅ D D 0 D3 :: Θ, Γ ` p2 ! N2 ~ = E A v D2 :: Θ, Γ ` p1 ! N1 Θ, Γ ` D if e then p1 else e2 ! N1 ∪ N2 if E A JD1 K then E A JD2 K else E A JD3 K Figure 3.36: Translation E from ILD to ILE for programs

3.5

Related Work

The literature of work related to the different aspects of our transformation scheme is extensive. We can only give a brief overview of the most relevant and most recent work that is related to ours. For clarity, we structure the following discussion into different categories. We first consider work related to our static location analysis, and then more closely look at other approaches of employing session types. We discuss different approaches of how to relate equivalent programs with I/O effects, describe different ways to model concurrent computations, and finally put our work of splitting programs into perspective to the technique of program slicing. Static Analyses There is a plethora of work that considers specific static program analyses or type-andeffect systems that statically deduce program properties that go beyond simple types. A good introduction to standard techniques of static program analyses and type and effect systems can be found in the textbook of Nielson et al. [NNH99]. Binding-time analyses—used in the area of partial evaluation— [JGS93, Hen91] can

3.5. RELATED WORK

103

{ D1 :: Γ ` D e : τ = Θ; Γ x = e ⇒ Θ; Γ, x : τ ! ∅ ( x = E A JD1 K if A ∈ locs(τ ) skip otherwise s { (∀i ) Di :: Γ ` D ei : b N EA = Θ; Γ ` D x = pfun(ei ) ⇒ Θ; Γ, x : b N ! ∅ ( x = pfun(E A JDi K) if A ∈ N skip otherwise t | 0 (∀i ) Di :: Γ ` D ei : b{ A } EA = 0 0 Θ; Γ ` D x = op A (ei ) ⇒ Θ, Γ( x : b{ A } ) ! { A0 } ( x = op A (E A JDi K) if A = A0 skip otherwise

EA

s

`D

Figure 3.37: Translation E from ILD to ILE for statements be seen as a restricted case of location analysis. Our trans construct is closely related to lifting. It is also used to coerce the type annotations of values. However, a bindingtime analysis distinguishes two modes of computation (static and dynamic)—or more generally, a linearly ordered set of binding-times—, whereas a location analysis lets us handle n incomparable locations leading to 2n different modes. There are several calculi that track the secure information flow of values attached with security levels taken from a lattice. The idea of a model using a lattice of security information goes back to Denning [Den76]. There are several type systems that use the lattice model of security levels to model secure information flow, the systems of Volpano and Smith [VS97], of Heintze and Riecke [HR98], and of Zdadencewic and Myers [ZM01, ZM02] being a prominent example of them. Abadi et al. [ABHR99, Aba06] introduce a general framework, the dependency core calculus, that can be viewed as general model for calculi that express dependencies by information lattices. The basic idea of all those calculi is to annotate values with security levels. A type system is then used to statically guarantee the non-interference of different parts of a program. The type language using annotations taken from a lattice of such systems is similar to the one in our location analysis, although the objective is a different one. Systems for information flow typically want to guarantee a non-interference property for the values of the program. We focus on the locations the effects of the operations are visible on, and would like to guarantee that those effects stay unchanged under program transformations. Our calculus may be also viewed as an instance of the capability calculus [WCM00]

104


r z E A D :: Θ; Γ ` D c = open[ B;C] (s) ⇒ Θ, c : γ[ B;C] ; Γ ! ∅ =  A if A = B  c = listen (s) c = connect A (s) if A = C   skip otherwise | t D1 :: Θ, c : χ ` D c : (b, γ)[ B;C] D2 :: Γ ` D e : b N B∈N = EA Θ, c : χ; Γ ` D x = trans[ B;C] c(e) ⇒ Θ, c : γ[ B;C] ; Γ, x : b N ∪{C} ! ∅  A  send c(E A JD2 K) if A = B x = recv A (c) if A = C   skip otherwise t | D2 :: Γ ` D e : b N B∈N D1 :: Θ, c : χ ` D c : (b, γ)[C;B] EA = Θ, c : χ; Γ ` D x = trans[ B;C] c(e) ⇒ Θ, c : γ[C;B] ; Γ, x : b N ∪{C} ! ∅  A  send c(E A JD2 K) if A = B x = recv A (c) if A = C   skip otherwise r z = E A D :: Θ, c : χ; Γ ` D close[ B;C] (c) ⇒ Θ; Γ ! ∅ ( close A (c) if A = B ∨ A = C skip otherwise r z = E A D :: Θ, c : χ; Γ ` D close[ B;C] (c) ⇒ Θ; Γ ! ∅ ( close A (c) if A = B ∨ A = C skip otherwise r z [ B;C ] E A D :: Θ, c : χ; Γ ` D c{l j } ⇒ Θ, c : γ j ;Γ!∅ = ( c{l j } A if A = B ∨ A = C skip otherwise Figure 3.38: Translation E from ILD to ILE for statements

3.5. RELATED WORK

105

q y E A D :: Γ ` D x : Γ( x ) q y E A D :: Γ ` D i N : b N } u N D p !N c : χ ; Γ, f : [ χ ] τ −→ 0, x : τ ` (∀ i ) D :: i i i i i i i ~ EA v N Γ ` D rec j f [c]( x ) = p : [χ]τ −→ 0

EA

s

D1 :: Γ ` D e : τ D2 :: ` D Γ `D e : τ0

{ τ ≤ τ0

=

x

=

iN

=

rec j f i [ci ]( xi ) = E A JDi K

=

E A JD1 K

Figure 3.39: Translation E from ILD to ILE for expressions restricted to simple types and specialized to particular resources (channels and locations). The specialized view however enables us to exploit properties and further code transformations beyond the reach of the capability calculus. Session Types Session types first occurred under the name of regular types in a type language for objects [Nie93]. Nierstrasz used them to model regular communication patterns of objects in object oriented programming. Honda et al. used a similar approach to type communication sessions via channels for a π-calculus with a regular type language [THK94, HVK98]. Since then, similar type languages, now generally called session types [GH99], have emerged as an expressive typing discipline for heterogeneous, bidirectional communication channels and communication protocols, both in the context of functional programming [GH99, VRG04, NT04a, NT04b, VRG06] and of object-oriented programming [DCMYD06]. Program Equivalences with I/O Using operational techniques for proving program equivalences in program calculi is an old idea. The notion of a contextual equivalence or observational congruence relation goes back to Morris [Mor68]. Contextual equivalent programs are programs that cannot be told apart by any context they are plugged in. Amongst others, Plotkin further popularized the definition of contextual equivalence in his seminal work about different evaluations strategies for the λ calculus [Plo75]. Certain variations and simplifications of the original definition exist. Milner [Mil78] showed that is enough to consider evaluation contexts in call-by value languages, which is also known as Milner’s context lemma. It is not appropriate to consider contexts only for programming languages with I/O effects, because context cannot tell apart programs that only differ in the effect they produce. Rather, it is common to relate programs that show similar and bisimilar, possibly

106


infinite, derivation trees that are additionally labeled by observable I/O actions. This view was pioneered by Milner is his work about a process calculus for concurrent computations, CCS [Mil89]. Our work can be considered an adaption of Crole and Gordon’s work about proving program equivalences for a simple strict functional programming language with input and output using bisimilarity [CG95]. Building some additional context properties in the bisimilarity relation of programs, like we did modulo channel directions, is known from previous work about bisimilarity for concurrent calculi. Examples are Sangiogi’s notion of open bisimulation for the π-calculus [San96], or Boreale at el.’s bisimulation results for the join-calculus [BFL98]. Another approach to show the equality of effectful programs is to consider their denotations in a denotational model, possibly with respect to a (denotational) metalanguage following Moggi’s approach to modularize a denotational semantics with effects by monads [Mog91]. Crole and Gordon developed, beside the operational results, a denotational model using a monadic metalanguage and showed the adequacy of their translation with respect to the operational semantics [CG95, CG99]. Last but not least, approaches that use logical partial equivalence relations (PER) to model the semantics of programming languages with effects came to a wider adoption recently [SS01, BKHB06]. Models of Concurrent Computations The line of research that tries to model concurrent computations is almost as old and extensive as the work on the lambda calculus and its descendants. There are several process calculi that can be considered cornerstones on the way to a foundational basis to concurrent programming, namely Hoare’s Communicating Sequential Processes (CSP) [Hoa85], Milner’s Calculus of Communicating Systems (CCS) [Mil89], and Milner et al.’s π-calculus [MPW92]. Our approach of modeling the concurrent calculus of Section 3.4 is influenced and inspired by various precursory approaches to model concurrent computations. The way we use a structural congruence relation to identify structurally equivalent concurrent processes is known from Milner’s work predating the π-calculus [Mil90]. Parallel composition of processes is modeled with reduction rules according to most operational semantics for CCS or the π-calculus. There are significant differences of our calculus to the usual formulations of the π-calculus though. We have a strict separation of communication operations and effectful operations. Additionally we have introduced locations to explicitly mark the locality of operations. Unlike the π-calculus, channels are not completely first-class objects in our setting; they are not transferable. Our model is closer to CCS in this respect. The original formulations for process algebras were untyped. First approaches to add types to the π-calculus—often called sorts in this setting—are due to Pierce and Sangiorgi [PS93], Gay [Gay93], and Vasconcelos and Honda [VH93], however those system do not prescribe a certain communication order to channels. What followed were type systems that also used a linear typing discipline to enforce some multiplicity

3.5. RELATED WORK

107

constraints on communication opportunities testified for example by work of Kobayashi et al. [KPT96]. Concurrent calculi that have a type system that is most similar to ours and also prescribe certain communication patterns are π-calculi with session types already mentioned in the previous section. Program Slicing The splitting transformation of Section 3.4 is closely related to program slicing [Tip95]. Recent advances in slicing deal with concurrent programs [NR00, Kri03], however, while slicing does not introduce new operations, our transformation maps a sequential program into a multi-threaded program. Another difference is that slicing is usually driven by the program dependency graph, whereas our transformation is driven by location analysis which includes dependency information through the typing rule for the conditional. Secure program partitioning (SPP) [ZZNM02] is a closely related transformation that maps a sequential program to a distributed program. However, the goals of SPP are quite different. SPP starts from a program with confidentiality and integrity annotations for functions, data, and a number of hosts. From these annotations, SPP partitions the program such that each host runs the part of the program for which its credentials are appropriate. The partition further ensures that the host only receives data up to its confidentiality level and that data from the host is only trusted up to its integrity level. In an extension of that work [ZCMZ03], the authors use replication to increase the scope of SPP. Both publications do not contain a formal justification of the program transformation the authors describe. Our work can also be considered as a formal justification to secure program partitioning.

108


Chapter 4

Placement Inference for Multi-Tier Applications In the last chapter, we presented an intermediate language with location annotations and developed a transformation scheme for it. The whole chapter dealt with correctly transforming and partitioning programs written in this intermediate language. The starting point of such a transformation sequence was a program that already carried valid location annotations. It is not immediately clear how to come up with such an assignment, that is, how and where to correctly introduce trans statements into a program. In this chapter, we develop a static program analysis that allows us to statically infer all valid placements—that is, location annotations for operations. We further develop a methodology to algorithmically rate valid placements based on their expected worst-case program running time. When estimating the worst-case running time of programs, it is our intention to arrive at a conservative estimate of durations of computations, without prematurely committing to a particular (physical) way of measuring duration (such as measuring clock ticks, resource consumption, milliseconds, . . . ). The duration of a sequential computation shall be the sum of its constituent durations and the duration of parallel computations shall be some upper bound of its constituents’ durations. To this end, we treat durations as elements of an abstract algebra with two operations. We use certain algebraic structures called dioids to model durations. Dioids, formally introduced in Section 2.1, exhibit the properties we demanded above. In the first section of this chapter, we start with specifying the source language for which we define the static placement analysis. The ILS calculus we introduce is a simplified version of ILB . It features only top-level recursive functions. Instead of carrying annotations with concrete locations as in ILB , programs of ILS are annotated with placement labels. The language is formalized by stating a formal syntax and timed semantics that expresses durations as elements of a dioid. 109

110

CHAPTER 4. PLACEMENT INFERENCE

Valid placements for a program are specified in Section 4.2. We first state a formal system of specifying valid placements and prove the correctness of the system with respect to the dynamic semantics. We then present a second, constraint-based version of the system targeted to deduce constraints for a program that express all valid placements. Subsequently, soundness and completeness of the second system is proven with respect to the original system. The section concludes with a constraint solving procedure for constraints generated for ILS programs which is proven to be sound and complete. In Section 4.3, we define the notion of worst-case running time for a (possibly nonterminating) program and a given placement with respect to a given dioid structure. The notion of worst-case running-time allows us to judge valid placements. Two complexity results are provided with respect to determining optimal placements, one for effect-free programs and one for effectful programs running on at least three locations. We conclude the chapter by briefly discussing possible implementations of the placement analysis we specified and giving an overview over related work.

4.1

The ILS Calculus

The ILS calculus is a slight variation of ILB , the calculus we used as starting point in the previous chapter. We do not consider first-class recursive functions anymore. We only consider top-level recursive program schemes with primitive operations, conditionals and explicit transfer operations instead. Various techniques—such as Reynold’s defunctionalization [Rey72], closure conversion [Ste78], and lambda lifting [Joh85]—are known in the literature to transform programs with first-class recursive functions into programs similar to ILS programs. We start with a description of the syntax of the ILS calculus. We then formulate a monomorphic type system for the ILS calculus serving as reference for other static analyses. In the end, we present a dynamic semantic for ILS . The denotation of programs is expressed in terms of an abstract notion of locations (representing the locality of operations) and in terms of dioid elements (representing durations of running time instead of other runtime values).

4.1.1

Syntax

The syntax for the ILS calculus is presented in Figure 4.1. We take for granted five disjoint and denumerable sets, Var, FVar, SVar, POp, and EOp, that are used to represent variable identifiers, function names, placement labels, names of pure operations, and names of effectful operations, respectively. An operation name, op, is either represented by a name of a pure operation or a name of an effectful operation. Different to most other intermediate languages, expressions of ILS do not produce a final value. Instead, they all either end with a halt expression or control is transferred by jumping to another top level function, f s x. Values that are intended as arguments for

4.1. THE ILS CALCULUS

111

Var FVar SVar POp EOp Op

3 3 3 3 3 3

x, y, z, . . . f , g, . . . s, . . . pfun, . . . op, . . . op ::= op | pfun

Expr

3

e

::= | | | |

halts fs x let x = ops ( x ) in e ifs x then e else e transs x in e

Def

3

d

::=

f (x) = e

Prog

3

p

::=

de

Figure 4.1: Syntax of ILS

operators, conditionals, or jumps must be bound to variables first, because arguments are restricted to variable identifiers only. Compound expressions sequence the evaluation of expressions. The expression let x = ops ( x ) in e first executes a primitive operation (either with or without additional side effects) before continuing with the following expression. The conditional expression ifs x then e else e allows to express a branching execution that depends on a condition variable x and, depending on that, continues with one of the following two branches. The transfer expression transs x in e expresses that certain values bound by variables x are transferred before continuing with expressions e. All headers of a compound expression carry placement label annotations, s, which will later allow us to associate certain properties or operations to specific expression headers. A program consists of a sequence of mutually recursive function definitions, d, followed by a single expression that serves as the main entry point of the program. We assume that no two function definitions carry the same defining name.

Definition 4.1 The head point of an expression and of a program, respectively, is a function

112


that maps an expression or a program to the placement labels of its head component, i.e. headSVar headSVar(halts ) headSVar( f s x ) headSVar(let x = ops ( x ) in e) headSVar(ifs x then e else e) headSVar(transs x in e)

∈ = = = = =

Expr → SVar s s s s s

headSVar headSVar(d e)

∈ =

Prog → SVar headSVar(e)

Notation 4.1 We usually write s e and s p for short, if headSVar(e) = s and headSVar( p) = s, respectively.

4.1.2

Static Semantics

The type system presented in this section serves as a starting point for further analyses of ILS programs that we present in the following. The type system is a straightforward adaption of a monomorphic type system for an applied lambda calculus. The syntax of the type language is presented in Figure 4.2. The set of base types, BType, is left unspecified—we only require that the set includes at least the type Bool representing boolean values. Operation types, OType and function types, FType, are restricted to the first-order case. Operation types act on base types in both the argument and the result position. Because functions never return in ILS programs, function types do not have an explicit return type and 0 serves as a general placeholder, however, any type will do. To be prepared to state the typing rules for ILS programs we need the following kind of type assumptions. Definition 4.2 A signature, Σ, is a finite mapping from operator names to operation types. A function environment, ∆, is a finite mapping from function names to function types. A value environment, Γ, is a finite mapping from variable names to base types, hence, Σ ∆ Γ

∈ ∈ ∈

Op ,→ OType, FVar ,→ FType, Var ,→ BType.

signature function environment value environment


BType OType FType

3 3 3

B G F

113

::= ::= ::=

Bool | . . . B × . . . × B −→ B B × . . . × B −→ 0

base types operation types first-order function types

Figure 4.2: Type language of ILS

The actual static semantics for programs of the ILS calculus is expressed in terms of the judgment Σ; ∆; Γ ` p. Its intended meaning is that program p is typeable under signature Σ, function environment ∆, and value environment Γ. The judgment for programs resorts to additional judgments. The actual typing rules for the judgment about programs as well as the typing rules for the other judgments are listed in Figure 4.3. Operators, functions names, and variable names are typed with special rules (S-SO P), (S-S-F UN), and (S-S-VAR), respectively, looking up the type in the appropriate environment. The typeability of expressions is witnessed by the judgment Σ; ∆; Γ ` e. Again, an expression e is typeable with respect to a signature Σ, a function environment ∆, and a value environment Γ. A halt expression is typeable under all contexts as expressed by the (S-S-H ALT) rule. For jumps to other top level functions, f s x, it is required (S-S-J UMP), that the base types for the arguments registered in the value environment match the types at argument position of the function type associated with the called function. The (S-S-L ET) rule specifies the typeability of operator applications as part of let expressions. The rule first guarantees that the operator arguments match to types in argument position of the appropriate function type found in the signature, and, second, that the body is typeable under an extended value environment. The (S-S-I F) rule types if expressions. It requires that the condition variable, x is of type Bool, and both branches are typeable as well. Typeable transfer operations (S-S-T RANS) require only that the values being transfered are correctly typed by the value environment, Γ, and that the body is also typeable. In case of transfer operations and also of the other compound expressions, placement labels do not affect static typing. Function definitions, d, are typed by another judgment, Σ; ∆ ` d. Definitions are considered with respect to a signature Σ and function environment ∆. The typing of a definition (S-S-D EF) assures that the function type registered in the function environment permits to type the function body under a value environment corresponding to the function type. Finally, the typeability of a program p under signature Σ, function environment ∆ and value environment Γ is witnessed by the judgment Σ; ∆; Γ ` p. To hold, all definitions and the initial expression must be typeable (S-S-P ROG).

114


S-S-O P

S-S-F UN

Σ(op) = G Σ ` op : G

S-S-VAR

∆( f ) = F ∆` f :F

Γ( x ) = B Γ`x:B

S-S-H ALT

Σ; ∆; Γ ` halts S-S-J UMP

∆ ` f : B1 × . . . × Bn −→ 0 (∀i ) Γ ` xi : Bi Σ; ∆; Γ ` f s x S-S-L ET

Σ ` op : B1 × . . . × Bn → B0 (∀i ) Γ ` xi : Bi Σ; ∆; Γ ` let x0 = ops ( x ) in e

∆; Γ, x0 : B0 ` e

S-S-I F

Γ ` x : Bool Σ; ∆; Γ ` e0 Σ; ∆; Γ ` e1 Σ; ∆; Γ ` ifs x then e0 else e1 S-S-T RANS

(∀i ) Γ ` xi : Bi Σ; ∆; Γ ` e Σ; ∆; Γ ` transs x in e

S-S-D EF

∆ ` f : B1 × . . . × Bn −→ 0 Σ; ∆; x1 : B1 , . . . , xn : Bn ` e Σ; ∆ ` f ( x ) = e S-S-P ROG

(∀i ) Σ; ∆ ` di Σ; ∆; Γ ` e Σ; ∆; Γ ` d e Figure 4.3: Typing rules for ILS programs


4.1.3

115

Dynamic Semantics Modeling Locality and Time

In this section, we specify a dynamic semantics for ILS programs. The denotation of of programs is expressed in terms of an abstract notion of locations (representing locality) and in terms of dioid elements (representing durations of computations). We formulate the dynamic semantics as a small step operational semantics specified by a reduction relation. Different to most accounts of dynamic semantics for programming languages, we do not model the resulting values or the effects of computations at all. All that matters to us is the (maximal) time period or duration a computation distributed on a certain location takes up for execution. Such durations are modeled as elements of an arbitrary, but henceforth fixed dioid structure, D . Before we specify how to evaluate programs in a timed manner, we first specify the notion of timed configurations, the contexts under which we evaluate ILS programs. Definition 4.3 (Timed Configurations) A timed configuration, χ = (L, κ, τ, ξ op , ξ tr ), is a tuple consisting of a set of locations, L, calculation costs, κ, transfer costs, τ, an operation placement, ξ op , and a transfer placement, ξ tr , where

`

∈

L

κ τ

∈ ∈

Op → L → D L→L→D

ξ op ξ tr

∈ ∈

Op ,→ SVar ,→ P (L) SVar ,→ Var ,→ L ,→ L

locations, calculation costs, transfer costs, operation placements, transfer placements.

A set of locations, L, models different physical or logical entities where computations can take place. Computations can take place simultaneously on more than one location. Most of the time, we make no further assumptions about the set of locations. Sometimes, we use the notation Ln to denote a more specific set of locations with locations labeled with numbers from 1 to n, Ln = {1, . . . , n}. Calculation costs, κ, are mappings from operation names and locations to durations. The duration κ (op)(`) tells us how long it takes to execute op on location `. Transfer costs, τ, are mappings from pairs of locations to durations. The duration τ (`1 )(`2 ) denotes the period of time to send a value from location `1 to `2 . Because there is an absorbing element, 0, in every dioid structure (axiom (2.6)), we conveniently use duration 0 for operations that are unavailable on certain locations or for transfer operations that are not effective between two particular locations. Using 0 for unavailable operations guarantees that we do not falsify an overall running time by an operation that is not even possible to execute. By modeling calculation and transfer costs in the way we do, we deliberately make a concession on modeling the actual timing behavior of distributed computations. Our

116


model simplifies the timing behavior of distributed systems in at least the following two points: • each operation always delays a computation by the same amount of time—that is, the duration of an operation is independent of its run-time arguments and other external factors (such as a machine state, memory delays, etc.)—, and • transfers between two locations always take the same amount of time—that is, transfers of values are independent of the (type of) values transfered and are independent of other external factors (such as different routing times, conduction delays, etc). We intentionally chose this simplified model to keep the formal presentation manageable. The cost function defined above can be considered as general cost declarations for all operations and all transfers. The following kinds of components later serve as specific placements of operations and transfers defining which operations and transfers are actually chosen to be executed. Operation placements, ξ op , are partial functions from operator names and placement labels to a set of locations. The set ξ op (op)(s) testifies, on which set of locations the operation op is executed, if annotated by placement label s. Transfer placements, ξ tr , are partial functions from placement labels, variable names and locations to locations. More specifically, the location `0 = ξ tr (s)( x )(`) states that— assuming transfer placements placement ξ tr —, a transfer operation labeled with s has to transfer argument x designated for location ` from location `0 . During the evaluation of a program we additionally have to track when values are available at different locations and when values are available for specific arguments. Definition 4.4 (Timed Environments) A clock environment, ϑc , is a mapping from locations to durations. An arrival environment, ϑv , is a mapping from variables and locations to durations. Thus, ϑc ∈ L → D , and ϑv ∈ Var → L → D .

A clock environment, ϑc , expresses for a specific state of evaluation the time elapsed on each location. A arrival environment, ϑv , tells for each variable and each location from which point in time forward the variable will be bound and available. The dynamic semantics is formulated as a small step operational semantics defined by a reduction relation, χ | ϑc , ϑv , e −→ f ϑc0 , ϑv0 , e0 , which expresses that a state transition with respect to a fixed timed configuration, χ = (L, κ, τ, ξ op , ξ tr ), goes from an expression e with given current clocks ϑc and current


117

arrival environment ϑv , to an expression e0 and updated clocks ϑc0 and durations for variables ϑv0 . The reduction relation is specified as the least relation generated by the reduction rules found in Figure 4.4.

T-S-O P

( ϑc0 (`)

=

κ (op)(`) · ( ϑc (`)

L, κ, τ, ξ op , ξ tr

L

j

ϑv (y j )(`) ⊕ ϑc (`))

if ` ∈ ξ op (op)(s)

otherwise ϑv0 = ϑv [z 7→ ϑc0 ] | ϑc , ϑv , let z = ops (y j ) in e, −→ f ϑc0 , ϑv0 , e

T-S-I F -T HEN

( ϑc0 (`)

=

κ (if)(`) · (ϑv ( x )(`) ⊕ ϑc (`))

if ` ∈ ξ op (if)(s)

ϑc (`) otherwise L, κ, τ, ξ op , ξ tr | ϑc , ϑv , ifs x then e1 else e2 −→ f ϑc0 , ϑv , e1

T-S-I F -E LSE

( ϑc0 (`)

=

κ (if)(`) · (ϑv ( x )(`) ⊕ ϑc (`))

if ` ∈ ξ op (if)(s)

ϑc (`) otherwise L, κ, τ, ξ op , ξ tr | ϑc , ϑv , ifs x then e1 else e2 −→ f ϑc0 , ϑv , e2

T-S-T RANS

( ϑv0 ( x )(`)

=

τ (`0 )(`) · ϑv ( x )(`0 )

if x ∈ x, `0 = ξ tr (s)( x )(`)

ϑv ( x )(`) otherwise L, κ, τ, ξ op , ξ tr | ϑc , ϑv , transs x in e −→ f ϑc , ϑv0 , e

Figure 4.4: Time-based reduction rules for ILS expressions The reduction of let expressions is handled by the (T-S-O P) rule. For an expressions that first performs an operation op during its execution, the updated clock environment ϑc0 arises as follows: for each location the operation is placed on (specified by ξ op ) we block until each argument of the operation and also the location itself is available; after that, we let pass by the duration specified by the operation costs, κ, for the actual operation on the current location. The arrival environment for the subsequent expression, the body expression, results by updating the current environment by adding durations for the new binding. Because we are not modeling actual runtime values, reducing a conditional is handled

118


T-S-E XP

χ | ϑc , ϑv , e −→ f ϑc0 , ϑv0 , e0 χ | ϑc , ϑv , d e −→ f ϑc0 , ϑv0 , d e0

T-S-J UMP

d j ≡ f j (x) = ej (∀i ) ϑv0 ( xi ) = ϑv (zi ) χ | ϑc , ϑv , d f js z −→ f ϑc , ϑv0 , d e j Figure 4.5: Time-based reduction rules for ILS programs nondeterministically by two transition rules, (T-S-I F -T HEN) and (T-S-I F -E LSE), each rule handling one of the possible continuation branches. The update of the clock environment is similar to the previous rule. Instead of blocking on multiple operation arguments and the current clock, we now block until the condition x and the current clock is available. For conditionals, we assume that calculation costs are registered under the name if. Hence, we calculate the clocks of the subsequent state by “adding” the delays for conditionals found in κ (by using the · operation). The subsequent arrival environment stays unchanged because bindings are not modified. The (T-S-T RANS) rule handles transfer expressions. In case of reducing a transfer operation, the clock environment stays unchanged because we are modeling transfers as asynchronous communications. Issuing a transfer command is comparable to a nonblocking send operation in more explicit concurrent programming models. As witnessed by the previous rules, modeling the blocking nature of reads of transferred values is done by delaying the execution of operations until all operator arguments are available. The new arrival environment, ϑv0 is constructed by delaying the current values of ϑv by appropriate transfer costs of τ following the given transfer placement ξ tr . The reduction of ILS programs is expressed by the relation χ | ϑc , ϑv , d e −→ f ϑc0 , ϑv0 , d e0 which states that a state transition with respect to a fixed timed configuration, χ = (L, κ, τ, ξ op , ξ tr ), takes a program p with current clocks ϑc and current arrival environment ϑv , to another program p0 and updated clocks ϑc0 and durations for variables, ϑv0 . The actual rules specifying the relation are presented in Figure 4.5. On the one hand, a program is being reduced by reducing its expression in evaluation position without resorting to the context of function definition. The (T-S-E XP) rule manifests this kind of context rule. On the other hand, in case we find a jump to another function in evaluation position, the reduction is handled by the (T-S-J UMP) rule. Calling a function leads to updating

4.2. PLACEMENT ANALYSIS

N LSVar

3 3

M, N, . . . α, β, . . .

Avail

3

A

FAvail

3

H

::= ::=

119

sets of locations location set variables α|N

availabilities A,A0

A × . . . × A −−→ 0

function availabilities

Figure 4.6: Annotation language of ILS the arrival environment according to the durations of the arguments passed and to substituting the current expression by the body of the function being called.

4.2

Placement Analysis

In the previous section, we introduced the notion of timed configurations to specify contexts where ILS programs are evaluated under. In particular, two of the components of a timed configuration specify the actual placement of operations and transfers to locations. Up to now, we have not specified, which kind of placements are actually sensible to run a program with. If we used an inappropriate placement, it could happen that not all arguments for an operation present at the location the operation is supposed to run on, or it could happen that an operation is placed to run on a location but at the same time does not even is available on that same location. In this section, we develop a static semantics for ILS that helps us to statically identify all sensible placements for a program. We therefore call our static semantics placement analysis in the following. After stating the formal system specifying valid placements and proving the correctness of the system with respect to the dynamic semantics, we present a second, constraint-based version of the system targeted to deduce constraints for a program that express all valid placements. Subsequently, soundness and completeness of the second system is proven with respect to the original system. We conclude the section with a constraint solving procedure for the constraints generated for ILS programs which we also prove to be sound and complete.

4.2.1

Specification

The static analysis presented in this section specifies which placements specifying locations assigned to operations and transfer commands make sense for a program. The type system we later develop can be considered as the annotation part and the effect part of a type-and-effect system that accompanies the simple type system for ILS already specified in Section 4.1.2. The annotations we employ approximate sets of locations where possible values reside. The syntax of the type language—which in this setting is better called annotation language—is presented in Figure 4.6.

120


Υ Π Σ Θ

∈ ∈ ∈ ∈

P (N ) P (N × N ) Op ,→ N P (N × N )

singleton availabilities availability containment availability signature availability transfer opportunities

Ξop Ξtr ∆ Γ

∈ ∈ ∈ ∈

Op ,→ SVar ,→ Avail SVar ,→ Var ,→ Avail × Avail FVar ,→ FAvail Var ,→ Avail

availability operation placement availability transfer placement function availability assumptions availability assumptions

Figure 4.7: Availability assumptions for ILS Our analysis uses names, M, N, . . ., to represent sets of locations. The names we use are taken from a denumerable set of names, N , each representing a (possibly different) aggregation of real physical or logical locations. Besides the fixed sets of locations carrying a name, we use location set variables α, β as placeholders for arbitrary sets of locations. We denote sets of location set variables by A. Availabilities, A, specify possible locations for values of a base type and are either specified by a name, N, identifying a particular set of locations, or are left unspecified and named by a location set variable, α. Function availabilities specify locations annotations of top level functions. An annoA0 ,A00

tation A −−−→ 0 states that arguments of a function must be available on locations A, at least locations A0 are needed to run the function, and effects are possibly visible on locations A00 . To state rules specifying valid placements, we assume the additional kind of availability assumptions shown in Figure 4.7. A set of singleton availabilities, Υ, identifies those sets of locations that only represent a single location. An availability containment, Π, states whether a set of locations contains another set of locations. An availability signature, Σ, is a finite mapping from operator names to availabilities, specifying the availability of operations on certain locations. An availability transfer opportunity, Θ, specifies pairs of sets of locations that always allow to communicate between arbitrarily chosen communication partners of their sets of locations. That is, for each pair of sets of locations, it is possible to transfer values from an arbitrary locations of the first set to an arbitrary locations of the second set. An availability operation placement, Ξop , is a finite mapping from operator names and placement labels to availabilities specifying a specific static placement assignment for all operations of a program. An availability transfer placement, Ξtr , is a finite mapping from placement labels and variable names to a pair of availabilities specifying a static placement assignment


121

A-S-S INGLE

N∈Υ Υ`N Figure 4.8: Rule for ILS singleton availabilities

S UB -S-B ASIC

( N1 , N2 ) ∈ Π Π ` N1 ≤ N2 S UB -S-R EFL

ΠÀ≤A S UB -S-T RANS

Π ` A ≤ A0 Π ` A0 ≤ A00 Π ` A ≤ A00 Figure 4.9: Subtyping rules for ILS availabilities determining on how values are transferred between locations. A function availability assumption, ∆, is a finite mapping from function symbols to function availabilities. An availability assumption, Γ, is a finite mapping from variable names to availabilities. The type system deducing availabilities is built up from nine judgments: ΥÀ ΠÀ≤A ΘÀ;A Υ; Π; Σ; Ξop ` ops : A s Θ; Ξtr ` x : A ; A ∆` f :F Π; Γ ` x : A Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` e ! A0 Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆ ` d Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` p ! A0

singleton availability availability subtyping transfer possibility access operator placement access transfer placement access function availability access variable availability access expression availabilities definition availabilities program availabilities

The singleton availability judgment, Υ ` A, shown in Figure 4.8, specifies availabilities, A, that identify single locations. The availability subtyping judgment, Π ` A ≤ A0 , states whether an availability A is subtype of another availability A0 considering specific availability containment assumption Π. The actual rules are shown in Figure 4.9. The judgment Π ` A ≤ A0

122


A-S-T RANSFER -B ASIC

( N1 , N2 ) ∈ Θ Θ ` N1 ; N2 Figure 4.10: Rules for ILS availability transfers expresses that a value that is present at a set of locations A can substitute for a value that is only present at a subset of locations, A0 , resorting on a given availability containment Π. Besides making use of given pairs of containment (S UB -S-B ASIC), the subtyping relation is a reflexive and transitive ((S UB -S-R EFL) and (S UB -S-T RANS) respectively). The transfer possibility access judgment Θ ` A ; A0 expresses whether it is possible to transfer values from all locations of A to all locations of A0 assuming given availability transfer possibilities Θ. The (A-S-T RANSFER -B ASIC) specifying the judgment is shown in Figure 4.10. By specifying availabilities and their properties in an abstract fashion, we make it possible to analyze a system multiple times, each time with different transfer and different memory characteristics, without the need for reanalyzing program dependencies. The placement analysis stays unchanged for each iteration, we only have to assume different availability assumptions. The following two examples show two typical transfer patterns and their rendition as availability assumptions. We will make use of both transfer patterns in a later section. Example 4.1 (Unrestricted Transfer Between Locations With Session State) The following availability configuration specifies a characteristics where multiply transfers of values between arbitrary locations are possible.

N Υ Π Σ Θ

= = = = =

{ NS | S ∈ P (Ln )} { N{1} , . . . , N{n} } {( NS , NS0 ) | S ⊇ S0 } λop 7→ N{1,...,n} N ×N

The sets of locations that describe possible locations of an availability are all subsets of a finite set of n locations. Singleton availabilities are denoted by just one location, that is, a singleton set, and availability containment is denoted by superset relation. Operations are allowed to run everywhere, and it is possible to transfer values between arbitrary locations. Such a setting implies the existence of some kind of interaction state on each locations because (pseudo) transfers on constant locations are allowed.

Example 4.2 (Transfer Restricted to Single Locations without Session State) The following availability configuration specifies a characteristics where transfers of values are


123

A-S-EO P

A-S-PO P

Ξop (pfun)(s) = A Σ(pfun) = Apfun Π ` Ac ≤ A Π ` Apfun ≤ A Υ; Π; Σ; Ξop ; Ac ` pfuns : A

Ξop (op)(s) = A Σ(op) = Aop Π ` Ac ≤ A Π ` Aop ≤ A ΥÀ Υ; Π; Σ; Ξop ; Ac ` ops : A

A-S-P LACE

Ξtr (s)( x ) = ( A1 , A2 ) Θ ` A1 ; A2 s Θ; Ξtr ` x : A1 ; A2 Figure 4.11: Availability rules for ILS operations only possible between different, single locations.

N Υ Π Σ Θ

= = = = =

{ NS | S ∈ {∅, {1}, . . . , {n}, Ln }} { N{1} , . . . , N{n} } {( NS , NS0 ) | S ⊇ S0 } λop 7→ N{1,...,n} {( NS , NS0 ) | S 6= S0 , |S| = |S0 | = 1}

In this example, possible sets of locations are either empty, singleton sets or the set containing all of a finite number of locations. Their containment properties and the availability of operations is assumed exactly as in the previous example. In this setting, however, it is prescribed that transfer operations are only allowed between two different, single locations. Even a transfer operation that functions as a noop and does not transfer values at all is not allowed in this setting. Such a setting implies that the handling of interaction state on locations is unnecessary because (pseudo) transfers on constant locations are impossible. Values always have to be transfered back and forth between locations without the possibility of locally storing them.

The operator placement access judgment, Π; Σ; Ξop ` ops : A, and the transfer placement s

access judgment, Θ; Ξtr ` x : A ; A, are specified by rules presented in Figure 4.11. The (A-S-PO P) and (A-S-EO P) rules specify possible availabilities, A, for operations, pfun and op respectively, that are annotated with placement label s and considered under static placement assignment Ξop . They both require that the availabilities match to the static placement assumptions, Ξop , that they adhere to the generally available locations Ac , and the locations suitable for the operation Aop in particular. The (AS-EO P) rule poses an additional requirement for operations with effects: availability,

124


A-S-F UN

∆ ` f : ∆( f ) A-S-VAR

Γ( x ) = A0 Π ` A0 ≤ A Π; Γ ` x : A Figure 4.12: Availability rules for ILS variables A, must represent exactly one location which we assure by resorting to the singleton availabilities, Υ. The (A-S-P LACE) rule specifies valid availabilities, A1 and A2 , used for a transfer operation with placement label s under a transfer placement Ξtr . It requires that such a transfer is both possible resorting to Θ, and also is registered in placement Ξtr under placement label s. The judgments ∆ ` f : F and Π; Γ ` x : A, shown in Figure 4.12, govern how valid assignments for function names and for variables names are assigned. The (A-S-F UN) rule is just a lookup rule assigning the right function availabilities registered in the function availability assumptions, ∆, for a function name f . The (A-S-VAR) rules works accordingly for variable names, x, with respect to availability assumptions, Γ. It incorporates subsumption of availabilities. Because the application of the (A-S-VAR) rule is restricted to argument positions of first-order function, we do not need to specify a separate subsumption rule. Instead we tie the application of subtyping to one rule keeping our system syntax-directed. The Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` e ! A0 judgment specifies valid availability assignments for expressions, shown in Figures 4.13 and 4.14. It states valid availabilities for an expression e possibly producing side effects at most on locations A0 while assuming singleton availabilities Υ, an availability containment Π, an availability signature Σ, availability transfer possibilities Θ, an operation placement Ξop , an transfer placement Ξtr , function availability assumptions ∆, variable availability assumptions Γ and available locations A. The (A-S-H ALT) rule for halt expressions poses no restrictions on the context. The (A-S-L ET) rule handling let expressions assures that the applications of the operations are only allowed on locations, A0 , where all arguments are available, and where, at the same time, locations A0 fit to the current placement for the operator op, and it also assures that the body fits to availabilities adapted to the result of the operation. It also assures that the availabilities A0 are subsumed by the set of locations, A0 , expressing the effects of the whole expression. The (A-S-I F) rule for conditionals are similar to the rule for operations, except that two continuations are handled, one for each branch of the conditional. There are additional requirements for conditionals. The rule demands that the conditional is placed on


125

A-S-H ALT

Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` halts ! A0 A-S-L ET

(∀i ) Π; Γ ` xi : A0 Υ; Π; Σ; Ξop ; A ` ops : A0 Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ, x0 : A0 ; A ` e ! A0 Π ` A 0 ≤ A0 Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` let x0 = ops ( x ) in e ! A0 A-S-I F

Π; Γ ` x : A0 Υ; Π; Σ; Ξop ; A ` ifs : A0 Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ, x : A0 ; A ` e1 ! A1 Π ` A0 ≤ A1 Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ, x : A0 ; A ` e2 ! A2 Π ` A0 ≤ A2 Π ` A 0 ≤ A0 Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` ifs x then e0 else e1 ! A0 A-S-T RANS s

(∀i ) Π; Γ ` xi : Ai Θ; Ξtr ` xi : Ai ; Ai0 Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ, x : A0 ; A ` e ! A0 Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` transs x in e ! A0 A-S-J UMP A00 ,A0

Π ` A ≤ A00 ∆ ` f : A −−−→ 0 (∀i ) Π; Γ ` xi : Ai Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` f s x ! A0 Figure 4.13: Availability rules for ILS expressions locations, A0 , which subsume all locations of the rest of the computation, A0 , guaranteeing that control information reaches all locations possibly involved in computations that later depend on them. The (A-S-T RANS) rule assigns valid availabilities to transfer operations. It assures that it is possible to transfer arguments of the transfer operation from locations Ai to locations Ai0 specified by the transfer placement Ξtr , and that the body is typeable under extended availabilities. The (A-S-J UMP) rule handles function calls. It assures that the function availabilities registered in the function availability assumptions, ∆, match the argument availabilities found in the availability assumptions, Γ. Subtyping is applied to the availabilities we assume, A, and to the argument availabilities, A, to make functions calls in more than on context result in more precise availability assignments.

126


A-S-D EF A,A0

Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; x : A; A ` e ! A0 ∆ ` f : A −−→ 0 Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆ ` f ( x ) = e A-S-P ROG

(∀i ) Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆ ` di Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` e ! A0 Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` d e ! A0 Figure 4.14: Availability rules for ILS programs The Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆ ` d judgment specifies the validity of availability assignments for definitions, shown in Figure 4.14. Its only rule, (A-S-D EF), connects the function availability assumption registered for a function symbol f with valid availabilities assigned to the body of the function definition. Finally, the Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆ : A ` p ! A0 judgment specifies the validity of availability assignments for programs, also shown in Figure 4.14. The (A-S-P ROG) rule assures that, under the current context, each function definition of the program itself and also the initial program expression are typeable. To be able to relate evaluation states with valid availability statements, we need to define a semantics of availabilities in terms of locations. Definition 4.5 An availability assignment, ι, is a finite map from availabilities to subsets of locations, that is, ι ∈ Avail → P (L).

Further, we define a second, more abstract view on evaluation configurations and on evaluation states that disregards actual durations. Instead, we just register whether a certain value is available on a specific location or not. In a sense, we define max-plus homomorphisms of the components of timed configurations into the boolean algebra mapping 0 to 0 and everything else to 1. Definition 4.6 (i) For calculation costs, κ, the calculation possibilities, κ ∗ ∈ Op ,→ P (L), are defined as

` ∈ κ ∗ (op) ⇐⇒ κ (op)(`) 6= 0. (ii) For transfer costs, τ, the transfer possibilities, τ ∗ ∈ L × L, are defined as

(`, `0 ) ∈ τ ∗ ⇐⇒ τ (`)(`0 ) 6= 0.


127

(iii) For a clock environment, ϑc , the set of clock locations, ϑc∗ ∈ P (L), is defined as

` ∈ ϑc∗ ⇐⇒ ϑc (`) 6= 0. (iv) For an arrival environment, ϑv , the availability environmentavailability environment, ϑv∗ ∈ Var ,→ P (L), is defined as

` ∈ ϑv∗ ( x ) ⇐⇒ ϑv ( x )(`) 6= 0. By using those abstractions, we are now able to to define the validity of a timed configuration with respect to one of its static counterparts. Definition 4.7 The validity of a timed configuration with respect to an availability assignment, χ, ι |= Π; Θ; Ξop ; Ξtr ; Σ; ∆, is defined in Figure 4.15.

We demand that, in turn, the availability assignment agrees with the availability containment, Π, the calculation costs, κ, agree with the availability signature, Σ, the transfer costs, τ agree with the availability transfer possibilities, Θ, the operation placement, ξ op , agrees with the availability operation placement, Ξop , and the transfer placement, ξ tr , agrees with the availability transfer placement, Ξtr . Validity of an availability assignment, ι |= Π, means, that for all pairs of availabilities registered in the availability containment relation, Π, it holds that they are supersets under the availability assignment, ι. Validity of calculation costs, κ, ι |= Σ, assures, that for all mapping in the availability signature, Σ, the locations of the current calculation possibilities, κ ∗ , always correctly approximate their static counterparts Validity of transfer costs, τ, ι |= Θ, assures, that for all pairs of availabilities registered in availability transfer possibilities, Θ, a transfer of values from each assigned location of the first availability to each assigned location to the second location under the possibilities of the current configuration, τ ∗ . Validity of operation placements, ξ op , ι |= Ξop , guarantees that the mapping of an operation placement, ξ op , matches up for all mappings registered in the availability operation placement, Ξop , considering the availability assignment ι. Validity of transfer placements, ξ tr , ι |= Ξtr , likewise guarantees, that for all mappings found in the availability transfer placement, Ξtr , approximates all locations mapped by the transfer placement ξ tr considering the availability assignment ι. After defining the validity of configurations, we now turn to environments.

128


(L, κ, τ, ξ op , ξ tr ), ι |= Π; Σ; Θ; Ξop ; Ξtr iff ι |= Π and κ, ι |= Σ and τ, ι |= Θ and ξ op , ι |= Ξop

and

ξ tr , ι |= Ξtr

ι |= Π iff (∀ A, A0 ∈ Avail) : ( A, A0 ) ∈ Π =⇒ ι( A) ⊇ ι( A0 ) κ, ι |= Σ iff (∀op ∈ Op, ∀ A ∈ Avail) : Σ(op) = A =⇒ κ ∗ (op) ⊇ ι( A) τ, ι |= Θ iff (∀ A, A0 ∈ Avail) : ( A, A0 ) ∈ Θ =⇒ ∀` ∈ ι( A).∀`0 ∈ ι( A0 ).(`, `0 ) ∈ τ ∗ ξ op , ι |= Ξop iff (∀op ∈ Op, ∀s ∈ SVar, ∀ A ∈ Avail) : Ξop (op)(s) = A =⇒ ξ op (op)(s) = ι( A) ξ tr , ι |= Ξtr iff (∀s ∈ SVar, ∀ x ∈ Var, ∀ A, A0 ∈ Avail, ∀` ∈ L) : Ξtr (s)( x ) = ( A, A0 ) ∧ ` ∈ ι( A0 ) =⇒ ξ tr (s)( x )(`) ∈ ι( A) Figure 4.15: Validity of timed configurations Definition 4.8 The validity of timed environments with respect to an availability assignment, ϑc , ι |= Π; A, and ϑv , ι |= Π; Γ, respectively, is defined in Figure 4.16.

Validity of clock environments, ϑc , ι |= Π; A, states that, besides the validity of the availability assignment, ι, the clock locations of ϑc , ϑc∗ , correctly approximate the meaning of availability A. Validity of arrival environments, ϑv , ι |= Π; Γ, ensures that, besides the validity of availability assignments, all mappings found in the availability assumptions, Γ, correctly approximate corresponding mappings of the duration environment, ϑv , considering the locations assigned by ι. Auxiliary Lemmas Before we prove the correctness of the placement analysis with respect to the timed semantics, we prove some auxiliary lemmas that later help us to establish the results.


129

ϑc , ι |= Π; A iff ι |= Π and ϑc ∗ ⊇ ι( A) ϑv , ι |= Π; Γ iff ι |= Π and (∀ x ∈ Var, ∀ A ∈ Avail) : Π; Γ ` x : A =⇒ ϑv ∗ ( x ) ⊇ ι( A) Figure 4.16: Validity of timed environments We begin with a simple property about chains of sets of locations. Definition 4.9 A sequence of sets of locations, Nn , is called a chain of sets of locations, iff (i) ∀ 1 ≤ i ≤ n − 1.( Ni , Ni+1 ) ∈ Π, and (ii) ∀ i, j.i 6= j =⇒ Ni 6≡ Nj . In the following, we write Π ` Nn for a chain of sets of locations, Nn .

Given two consecutive chains of sets of locations, we are able to construct a unified one. Lemma 4.1 If Π ` N, M, N 0 and Π ` N 0 , M0 , N 00 , then there exists M00 such that Π ` N, M00 , N 00 .

Proof. By simple induction on the length of M.

We later need an inversion property for availability subtyping. Lemma 4.2 If Π ` A ≤ A0 , then either (i) A ≡ A0 ≡ α, or (ii) A ≡ A0 ≡ N, or (iii) A ≡ N, A0 ≡ N 0 , and there exists N 00 with N 6= N 00 , ( N, N 00 ) ∈ Π, and Π ` N 00 ≤ N 0 .

Proof. By induction on the subtyping derivation. • Case (S UB -S-B ASIC ). By the hypothesis, A ≡ N,A0 ≡ N 0 , and ( N, N 0 ) ∈ Π hold. If N = N 0 , then (ii) applies. If N 6= N 0 , then (iii) applies with N 00 = N 0 and using (A-S-R EFL).

130


• Case (S UB -S-R EFL ). Either premise (i) or premise (ii) applies. • Case (S UB -S-T RANS ). By applying the induction hypothesis on each of the two subderivations individually, we have different subcases to consider. – Subcase (i) on first subderivation, (i) on second subderivation. A ≡ A00 ≡ A0 ≡ α, thus premise (i) holds. – Subcase (ii) on first subderivation, (ii) on second subderivation. A ≡ A00 ≡ A0 ≡ N, thus premise (ii) holds. – Subcase (ii) on first subderivation, (iii) on second subderivation. Premise (iii) follows from the second subderivation. – Subcase (iii) on first subderivation, (ii) on second subderivation. Premise (iii) follows from the first subderivation. – Subcase (iii) on first subderivation, (iii) on second subderivation. The first subderivation yields, that N 6= N 00 and ( N, N 00 ) ∈ Π. Applying the transitive rule on the rest of the result of the first subderivation and the result of the second subderivation completes premise (iii). – All other subcases lead to contradictions.

Combining the addition of chains with the inversion result, we obtain the following lemma. Lemma 4.3 If Π ` A ≤ A0 , then either (i) A ≡ A0 ≡ α, or (ii) A ≡ A0 ≡ N, or (iii) A ≡ N, A0 ≡ N 0 , N 6≡ N 0 , and there exists M with Π ` N, M, N 0 .

Proof. Analogous to the proof of the inversion result. In doing so we additionally apply Lemma 4.1.

To prove a correctness result for the (static) availability system with respect to the timed semantics, we formulate two auxiliary lemmas that later help us with the proof. The first lemma states that availability subtyping generally induces a subset relationship on the meaning of availabilities assuming a valid availability assignment. Lemma 4.4 If Π ` A ≤ A0 and ι |= Π, then ι( A) ⊇ ι( A0 ).


131

Proof. By simple induction on the derivation of availability subtyping.

Next, we prove a weakening result for valid availability judgments for expressions. Lemma 4.5 If Υ; Π; Σ; Ξop ; A0 ` ops : A0 , and A ≤ A0 , then Υ; Π; Σ; Ξop ; A ` ops : A0 .

Proof. Immediate by (A-S-EO P).

Lemma 4.6 If Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A0 ` e ! A00 , A ≤ A0 , then Π; Ξop ; Ξtr ; ∆; Γ; A ` e ! A00 .

Proof. By simple induction of the type derivation using Lemma 4.5.

Preservation Preservation states that whenever a reduction is possible from a typed configuration, that is, the availability assignment is valid and also the timed configuration agrees with the static assignment, then the resulting configuration is typeable as well. Lemma 4.7 (Preservation) If Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` d e ! A0 χ, ι |= Π; Σ; Θ; Ξop ; Ξtr , ϑv , ι |= Π; Γ, ϑc , ι |= Π; A, and χ | ϑc , ϑv , d e −→ f ϑc0 , ϑv0 , d e0 then there is some Γ0 and some A00 with Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ0 ; A ` d e0 ! A00 , ϑv0 , ι |= Π; Γ0 , ϑc0 , ι |= Π; A, Π ` A0 ≤ A00 .

132


Proof. Our hypotheses are Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` d e ! A0 ,

(4.1)

χ, ι |= Π; Σ; Θ; Ξop ; Ξtr ,

(4.2)

ϑv , ι |= Π; Γ,

(4.3)

ϑc , ι |= Π; A.

(4.4)

By inversion with (A-S-P ROG), the premises of (4.1) are Σ ` Ξop

(4.5)

Θ ` Ξtr

(4.6)

(∀i ) Υ; Π; Ξop ; Ξtr ; ∆ ` di

(4.7)

0

(4.8)

Υ; Π; Ξop ; Ξtr ; ∆; Γ; A ` e ! A

We proceed by case analysis on the last of rule applied to the derivation of (4.8). • Case (A-S-H ALT ). e ≡ halts . No reduction rule applies. • Case (A-S-L ET). e ≡ let x0 = ops ( x ) in e0 . Because the reduction relation is syntax-directed, we know by inspection of e, that the two last derivation steps are (T-S-E XP) and (T-S-O P). By inversion, we know that the premises include Υ; Π; Ξop ; Ξtr ; ∆; Γ, x0 : A0 ; A ` e0 ! A0 . With

Γ0

≡ Γ, x0 : A0 , and

A00

≡

A0 ,

(4.9)

the first and the last conclusion follow.

By the definition of (4.3), we have ι |= Π

(4.10)

(∀ x ∈ Var, ∀ A ∈ Avail) Π; Γ ` x : A =⇒ ϑv ∗ ( x ) ⊇ ι( A)

(4.11)

By inversion (A-S-L ET), it also holds that

(∀i ) Π; Γ ` xi : A0 s

(4.12)

Π; Ξop ; A ` op : A0

(4.13)

(∀i ) ϑv∗ ( xi ) ⊇ ι( A0 ),

(4.14)

By (4.11) we have that

by (A-S-PO P) or (A-S-EO P), and thus, Π ` A ≤ A0 ,

(4.15)

Ξop (op)(s) = A0 ,

(4.16)

Π ` Σ(op) ≤ Ξop (op)(s).

(4.17)


133

By soundness of operations and static placement assignments, it follows that there exists A2 with ξ op (op)(s) = ι( A0 )

(4.18)

∗

κ (op) ⊇ ι( A2 )

(4.19)

ι ( A2 ) ⊇ ι ( A0 )

(4.20)

ι ( A ) ⊇ ι ( A0 ),

(4.21)

and by the soundness of the clock environment ϑc∗ ⊇ ι( A).

(4.22)

Let x ∈ Var, A1 ∈ Avail with Π; Γ0 ` x : A1 . – Subcase x 6≡ x0 . Because Γ0 ( x ) = Γ( x ) and ϑv0 ( x ) = ϑv ( x ), by (4.11), it follows ∗ that ϑv0 ( x ) ⊇ ι( A1 ). – Subcase x ≡ x0 . Then, by (A-S-VAR), Γ 0 ( x0 ) = A0 ,

(4.23)

Π ` A0 ≤ A1 .

(4.24)

ι ( A0 ) ⊇ ι ( A1 ).

(4.25)

hence

Because, (α) ` ∈ ξ op (op)(s). If ` ∈ ι( A0 ), then by (4.18)-(4.22) and (T-S-O P), ` ∈ ϑc0∗ , (β) ` 6∈ ξ op (op)(s). If ` ∈ ι( A0 ), then by (4.22) and (T-S-O P), ` ∈ ϑc0∗ , ϑc0∗ ⊇ ι( A0 )

(4.26)

ϑv0∗ ( x0 ) ⊇ ι( A1 ).

(4.27)

Hence, by (T-S-O P) and (4.25),

Combining both subcases gives ϑv0 , ι |= Π; Γ0 . Let ` ∈ A. Because, (α) ` ∈ ξ op (op)(s). By (4.18)-(4.22) and (T-S-O P), ` ∈ ϑc0∗ , (β) ` 6∈ ξ op (op)(s). By (4.22), ` ∈ ϑc∗ . Hence, by (T-S-O P), ` ∈ ϑc0∗ ,

(4.28)

134

CHAPTER 4. PLACEMENT INFERENCE ϑc0∗ ⊇ ι( A),

(4.29)

ϑc0 , ι |= Π; A.

(4.30)

resulting in

• Case (A-S-I F). e ≡ ifs x then e2 else e3 . Because the reduction relation is syntaxdirected, we know by inspection of e that the two last derivation steps are (T-S-E XP), and either (T-S-I F -T HEN) or (T-S-I F -E LSE). We consider (T-S-I F -T HEN) for now. The other case works analogously. By inversion, we know that the premises include Π; Ξop ; Ξtr ; ∆; Γ, x : A0 ; A ` e1 ! A1

(4.31)

Π ` A 0 ≤ A1

(4.32)

With Γ0 ≡ Γ, x : A0 and A00 ≡ A1 , the first and the last conclusion follow. By the definition of (4.3), we have ι |= Π

(4.33)

(∀ x ∈ Var, ∀ A ∈ Avail) Π; Γ ` x : A =⇒ ϑv ( x ) ⊇ ι( A)

(4.34)

∗

By inversion (A-S-I F), it also holds that Π; Γ ` xi : A0 s

(4.35)

Π; Ξop ; A ` if : A0

(4.36)

ϑv∗ ( x ) ⊇ ι( A0 ),

(4.37)

By (4.34) we have that

by (A-S-PO P) or (A-S-EO P), and by (A-S-O P -C ONS), Π ` A ≤ A0 ,

(4.38)

Ξop (if)(s) = A0 ,

(4.39)

Π ` Σ(if) ≤ Ξop (if)(s)

(4.40)

By soundness of operations and static placement assignments, it follows that there exists A2 with ξ op (if)(s) = ι( A0 )

(4.41)

∗

κ (if) ⊇ ι( A2 )

(4.42)

ι ( A2 ) ⊇ ι ( A0 )

(4.43)

ι ( A ) ⊇ ι ( A0 ),

(4.44)

and by the soundness of the clock environment ϑc∗ ⊇ ι( A). Let x 0 ∈ Var, A1 ∈ Avail with Π; Γ0 ` x 0 : A1 .

(4.45)


135

– Subcase x 0 6≡ x. Because Γ0 ( x 0 ) = Γ( x 0 ) and ϑv0 ( x 0 ) = ϑv ( x 0 ), by (4.34), it ∗ follows that ϑv0 ( x 0 ) ⊇ ι( A1 ). – Subcase x 0 ≡ x. Then, by (A-S-VAR), Γ 0 ( x 0 ) = A0 ,

(4.46)

Π ` A0 ≤ A1 .

(4.47)

ι ( A0 ) ⊇ ι ( A1 ).

(4.48)

ϑv0∗ = ϑv∗

(4.49)

ϑv0∗ ( x 0 ) ⊇ ι( A0 ) ⊇ ι( A1 ).

(4.50)

hence

Because, by (T-S-I F -T HEN),

it follows ((4.37) and (4.48))

Combining both subcases gives ϑv0 , ι |= Π; Γ0 .

(4.51)

Let ` ∈ A. Because, (α) ` ∈ ξ op (op)(s). By (4.41)-(4.45) and (T-S-I F -T HEN), ` ∈ ϑc0∗ , (β) ` 6∈ ξ op (op)(s). By (4.45), ` ∈ ϑc∗ . Hence, by (T-S-I F -T HEN), ` ∈ ϑc0∗ , ϑc0∗ ⊇ ι( A),

(4.52)

ϑc0 , ι |= Π; A.

(4.53)

resulting in

• Case (A-S-T RANS). e ≡ transs x in e0 . Because the reduction relation is syntaxdirected, we know by inspection of e, that the two last derivation steps are (T-S-E XP) and (T-S-T RANS). By inversion, we know that the premises include Υ; Π; Ξop ; Ξtr ; ∆; Γ, x : A0 ; A ` e0 ! A0 .

(4.54)

With Γ0 ≡ Γ, x : A0 and A00 ≡ A0 the first conclusion and the last conclusion follow. By the definition of (4.3), we have ι |= Π

(4.55)

(∀ x ∈ Var, ∀ A ∈ Avail) Π; Γ ` x : A =⇒ ϑv ( x ) ⊇ ι( A)

(4.56)

∗

Let x ∈ Var, A1 ∈ Avail with Π; Γ0 ` x : A1 .

136

CHAPTER 4. PLACEMENT INFERENCE – Subcase x 6∈ x. Because Γ0 ( x ) = Γ( x ) and ϑv0 ( x ) = ϑv ( x ), by (4.56), it follows ∗ that ϑv0 ( x ) ⊇ ι( A1 ). – Subcase x ∈ x, i.e., x ≡ xi for some i. Then, by (A-S-VAR), Γ0 ( xi ) = Ai0 ,

(4.57)

Π ` Ai0 ≤ A1 .

(4.58)

ι( Ai0 ) ⊇ ι( A1 ).

(4.59)

hence

By inversion of (A-S-T RANS), it also holds that Π; Γ ` xi : Ai , s

Ξtr ` xi : Ai ;

Ai0 .

(4.60) (4.61)

By the definition of (4.3), we then know that ϑv∗ ( xi ) ⊇ ι( Ai ),

(4.62)

by (A-S-P LACE) and by (A-S-T RANS -C ONS) Ξtr (s)( xi ) = ( Ai , Ai0 ),

(4.63)

Θ ` Ai ; Ai0 .

(4.64)

Let ` ∈ ι( Ai0 ). By soundness of the transfer placement assumption and by soundness of transfers, it follows that there exists a `0 ∈ L with

`0 = ξ tr (s)( xi )(`),

(4.65)

` 0 ∈ ι ( A i ),

(4.66)

0

∗

(`, ` ) ∈ τ .

(4.67)

thus, by the (T-S-T RANS) rule using (4.62), (4.66), and (4.67), we know that

` ∈ ϑv0∗ ( xi ),

(4.68)

ϑv0∗ ( xi ) ⊇ ι( Ai0 )

(4.69)

ϑv0∗ ( xi ) ⊇ ι( A1 ).

(4.70)

thus

and by transitivity


137

Combining both subcases gives ϑv0 , ι |= Π; Γ0 .

(4.71)

By the definition of the fourth hypotheses, (4.4), we know that ϑc∗ ⊇ ι( A).

(4.72)

By the (T-S-T RANS) rule, it follows that ϑc0∗ = ϑc∗ ,

(4.73)

ϑc0∗ ⊇ ι( A).

(4.74)

ϑc0 , ι |= Π; A.

(4.75)

hence

leading to the result

• Case (A-S-J UMP). e ≡ f is z. Because the reduction relation is syntax-directed, we know by inspection of e, that the last derivation step is (T-S-J UMP). By inversion of (A-S-D EF), we know that the premises include A00 ,A0

∆ ` f i : A −−−→ 0 00

0

Π; Ξop ; Ξtr ; ∆; x : A; A ` ei ! A .

(4.76) (4.77)

By inversion of (A-S-J UMP), we further know that

(∀i ) Π; Γ ` zi : Ai , 00

ΠÀ≤A .

(4.78) (4.79)

With Γ0 ≡ xi : Ai and A00 ≡ A0 , and applying Lemma 4.6 on (4.77) and (4.79), the first and the last conclusion follow. Let x ∈ Var, A1 ∈ Avail with Π; Γ0 ` x : A1 . By the (A-S-VAR) rule, we know that there exists some i with x ≡ xi , x ∈ x, and Γ 0 ( xi ) = Ai ,

(4.80)

Π ` A i ≤ A1 ,

(4.81)

ι ( A i ) ⊇ ι ( A1 ).

(4.82)

hence

138

CHAPTER 4. PLACEMENT INFERENCE By inversion of the (A-S-J UMP) derivation step, we also know that, Π; Γ ` zi : Ai ,

(4.83)

ϑv∗ (zi ) ⊇ ι( Ai ).

(4.84)

i.e., by the definition of (4.3),

Because of the definition of (T-S-J UMP), we know that ϑv0∗ ( xi ) = ϑv∗ (zi ),

(4.85)

ϑv0∗ ( xi ) ⊇ ι( A1 ),

(4.86)

ϑv0 , ι |= Π; Γ0 .

(4.87)

and we finally conclude that

hence

By the definition of the fourth hypotheses, (4.4), we know that ϑc∗ ⊇ ι( A).

(4.88)

By the (T-S-J UMP) rule, it follows that ϑc0∗ = ϑc∗ ,

(4.89)

ϑc0∗ ⊇ ι( A).

(4.90)

ϑc0 , ι |= Π; A.

(4.91)

hence

leading to the result

4.2.2

Constraint-Based Analysis

This section presents a second version of the placement analysis. It can be considered as an algorithmic version of the system we presented in the previous section. Given a program, p, and preassigned availabilities for functions, variables and static placements, ∆, Γ, Ξop , and Ξtr , respectively, the system calculates a set of constraints. The generated constraints express necessary conditions that must hold for an availability assignments to become valid availability assignments. Because we would like to be able to determine different—if not all—availability assignments for a program, we typically do not generate constraints using a fixed set of names of sets of locations as input availabilities, but we instead make use of locations set variables as placeholders for arbitrary sets of locations. A specific solution for an availability problem can then be obtained by substituting actual sets of locations for location set variables. The formal definition of availability substitutions follows.


139

Definition 4.10 An availability substitution, σ ∈ LSVar ,→ Avail, is a finite mapping from location set variables to availabilities. Availability substitutions are extended to availabilities and function availabilities in the following way. ( σ(α) if α ∈ dom σ σ(α) = α otherwise σ( N ) = N A,A0

σ ( A),σ( A0 )

σ( A −−→ 0) = σ ( A) −−−−−−→ 0 The application of availability substitutions to placements and to assumptions, σΞop , σΞtr , σ∆, and σΓ, respectively, acts pointwise on every element of their codomains.

In order to relate a solution of the constraint-based system with an assignment of the declarative system, we define the notion of solutions of (declarative) availability problems using availability substitutions. Solutions for an availability problem depend on a given availability containment, an availability signature, and availability transfer possibilities. Formally, they are defined as follows. Definition 4.11 A (Υ; Π, Σ, Θ)-solution for an availability problem (Ξop , Ξtr , ∆, Γ, p) is a triple (σ, A, A0 ) such that Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ; A ` p ! A0 .

Constraints To express relationships between certain availabilities, we use the following constraint language.

C

::=

?

A 6 A | A 99K A | op A | single A | A = A

simple constraints

A constraint, A 6 A0 , expresses a subtyping relation between two availabilities, A 99K A0 , demands the transfer possibility between two availabilities, and op A expresses the availability of an operation on certain locations, single A demands that A represents a ?

single location, and A = A0 demands that A and A0 denote the same set of locations. A constraint set C is a set of simple constraints C. A constraint set, C , is solvable by an availability substitution, σ, with respect to given availability containment, an availability signature, and availability transfer possibilities, if for each simple constraint, adequate subtyping or access judgments hold. Definition 4.12 An availability substitution σ is a (Υ; Π, Σ, Θ)-solution of a constraint set C , written σ |=Υ,Π,Σ,Θ C , if for all C ∈ C , it holds that,

140


(i) if C ≡ A 6 A0 , then Π ` σ( A) ≤ σ( A0 ), (ii) if C ≡ A 99K A0 , then Θ ` σ ( A) ; σ( A0 ),

(iii) if C ≡ op A, then Π ` Σ(op) ≤ σ( A), (iv) if C ≡ single A, then Υ ` σ ( A), and ?

(v) if C ≡ A = A0 , then σ( A) ≡ σ( A0 ).

Constraint availability rules The constraint-based variant of the availability system consists of the following eight judgments.

`α;α|C Ξop ; A ` ops | C , α Ξtr ` x s : C , α, α ∆` f |F Γ`x:α|C Ξop ; Ξtr ; ∆; Γ; A ` e ! α0 | C ; A Ξop ; Ξtr ; ∆ ` d | C ; A Ξop ; Ξtr ; ∆; Γ; A ` p ! α0 | C ; A

transfer possibility access with constraints operator placement access with constraints transfer placement access with constraints function availability access with constraints variable availability access with constraints expression availabilities with constraints definition availabilities with constraints program availabilities with constraints

All judgments are specified as rules, that, when read from bottom to top, can also be understood as procedures that take availability problems as input and generate constraint sets specifying solutions. When read from bottom to top, the rules describe a procedure that, given a subtyping problem with variable types or the type environment, a variable name an the result set, respectively, calculates constraints that express the demanded relationship between the location set variable given and the set of fresh location set variables needed for that. Figure 4.17 shows the rules belonging to the constraint-based variants of the access judgments. The (C-S-T RANSFER) rule for the judgment for transfer possibility access with constraints, ` α ; α | C , relates a transfer constraint to a given pair of location set variables. The (C-S-PO P) rule, the first rule of the judgment handling operator placement access with constraints, Ξop ; Ac ` ops | C , α, specifies the constraints for a pure operation pfun at placement label s with available locations Ac . The (C-S-EO P) rule specifies the constraints for an effectful operation op at placement label s with available locations Ac . It corresponds to the previous rule but also assures by a singleton availability constraint, that operation op is placed on exactly one location.


141

C-S-T RANSFER

C = {α1 99K α2 } ` α1 ; α2 | C

C-S-PO P

Ξop (pfun)(s) = α C = { Ac 6 α, pfun α} Ξop ; Ac ` pfuns | C , α C-S-EO P

Ξop (op)(s) = α C = { Ac 6 α, op α, single α} Ξop ; Ac ` ops | C , α C-S-P LACE

Ξtr (s)( x ) = (α1 , α2 ) ` α1 ; α2 | C Ξtr ` x s | C , α1 , α2 Figure 4.17: Constraint-based availability rules for ILS operations The (C-S-P LACE) rule for the judgment for transfer placement access with constraints, Ξtr ` x s | C , α1 , α2 , generates transfer constraints for a variable x annotated with placement label s. Accordingly, the judgments for functions and variables are shown in Figure 4.18. The (C-S-F UN) rule for the judgment for function availability access with constraints, ∆ ` f | ∆( f ), specifies the lookup of function availabilities suitable to a specific function name. The (C-S-VAR) rule for the judgment for variable availability access with constraints judgment, Γ ` x : α | C , results in s subtyping constraints specifying subtyping of variable lookup. The generation of constraints for expression is shown in Figure 4.19. The judgments for function definitions and programs are shown in Figure 4.20. Availabilities for expressions are constrained by the judgment, Ξop ; Ξtr ; ∆; Γ; A ` e ! α0 | C ; A. It associates constraints C to an expression e, static placement assignments, Ξop and Ξtr , and assignments, ∆ and Γ using a supply of fresh location set variables, A. The rules are a straightforward transformation of the declarative system substituting subtyping or access subjudgments either by subjudgments generating the right kind of constraints or by the right kind of constraints itself. Note, however, that the rules dictate a restricted set of contexts and assumptions as input containing only location set variables and skeletons of function availabilities also consisting only of location set variables.

142


C-S-F UN

∆ ` f | ∆( f ) C-S-VAR

Γ( x ) = A0 C = { A0 6 α} Γ`x:α|C Figure 4.18: Constraint-based availability rules for ILS functions, variables Analogously, we have two additional judgments dealing with function definitions and programs. The generation of constraints for function definitions is expressed by the judgment A; Ξop ; Ξtr ; ∆ ` d | C . The generation of constraints for programs is expressed by the judgment A; Ξop ; Ξtr ; ∆; A ` p ! A0 | C . So far, the judgment generating constraints for a program merely produces constraints that state necessary restrictions on the input availabilities. Solutions of an availability problem for a program are solutions of the constraints generated. Definition 4.13 Suppose that Ξop ; Ξtr ; ∆; Γ; A ` p ! α0 | C ; A. A (Υ, Π, Σ, Θ)-solution for the constraint availability problem (Ξop , Ξtr , ∆, Γ, A, p, A0 , C) is a triple (σ, A1 , A10 ) such that the following holds (i) σ |=Υ,Π,Σ,Θ C , (ii) σ ( A) = A1 , and (iii) σ (α0 ) = A10 .

We now have two characterizations for solutions of availability problems, and hence, two possible ways to verify solutions of availability problems. On the one hand, given a solution, we can check, whether the solution is admissible by applying the solution to the availability assumptions of the problem and check the solution by resorting to the specification of valid availabilities given by the declarative system. On the other hand, we can use the algorithmic system to first generate a set of constraints for the program and check afterwards by checking whether the solution satisfies the generated set of constraints. In the following, we show that those two different characterizations for solutions of availabilities problems are indeed equivalent. We proceed in two steps. First, we show that every solutions of the constrained based system is also a valid solution of the declarative system. First, we show that every solution of the declarative system also solves constraints generated by the algorithmic variant.


143

C-S-H ALT

α0 6∈ Ξop , Ξtr , ∆, Γ, { A} Ξop ; Ξtr ; ∆; Γ; A ` halts ! α0 | ∅; {α0 } C-S-L ET

Ξop ; A ` ops | Cop , α0 (∀i ∈ [m]) Γ ` xi : α0 | Ci Ξop ; Ξtr ; ∆; Γ, x0 : α0 ; A ` e ! α0 | C0 ; A C 0 = { α 0 6 α0 } C = C1 ∪ . . . ∪ Cm ∪ Cop ∪ C0 ∪ C 0 Ξop ; Ξtr ; ∆; Γ; A ` let x0 = op ( x ) in e ! α0 | C ; A C-S-I F

Ξop ; A ` ifs | Cif , α0 Γ ` x : α0 | C0 A = { α 0 , α1 , α2 } ] A1 ] A2 α0 , α1,2 6∈ Ξop , Ξtr , ∆, Γ, { A} Ξop ; Ξtr ; ∆; Γ, x : α0 ; A ` e1 ! α1 | C1 ; A1 Ξop ; Ξtr ; ∆; Γ, x : α0 ; A ` e2 ! α2 | C2 ; A2 C 0 = { α0 6 α1 , α0 6 α2 , α 0 6 α0 } C = C0 ∪ C1 ∪ C2 ∪ Cif ∪ C 0 Ξop ; Ξtr ; ∆; Γ; A ` if x then e1 else e2 ! α0 | C ; A C-S-T RANS

(∀i ∈ [m]) Ξtr ` xis | Ci0 , αi , αi0 Γ ` xi : αi | Ci Ξop ; Ξtr ; ∆; Γ, xi : αi0 ; A ` e ! α0 | C0 ; A C = C1 ∪ . . . ∪ Cm ∪ C10 ∪ . . . ∪ Ci0 ∪ C0 Ξop ; Ξtr ; ∆; Γ; A ` transs x in e ! α0 | C ; A C-S-J UMP α00 ,α000

∆ ` f | αi −−−→ 0 (∀i ∈ [m]) Γ ` xi : αi | Ci0 α0 6∈ Ξop , Ξtr , ∆, Γ, { A} ?

C 0 = { A 6 α00 , α000 = α0 } 0 ∪ C0 C = C10 ∪ . . . ∪ Cm s Ξop ; Ξtr ; ∆; Γ; A ` f x ! α0 | C ; {α0 } Figure 4.19: Constraint-based availability rules for ILS expressions

144


C-S-D EF α,α0

∆ ` f | αi −−→ 0 Ξop ; Ξtr ; ∆; xi : αi ; α ` e ! α0 | C ; A Ξop ; Ξtr ; ∆ ` f ( x ) = e | C ; A C-S-P ROG

˙ 0 A = i Ai ∪A (∀i ∈ [m]) Ξop ; Ξtr ; ∆ ` di | Ci ; Ai Ξop ; Ξtr ; ∆; Γ; A ` e ! α0 | C0 ; A0 C = C1 ∪ . . . ∪ Cm ∪ C0 Ξop ; Ξtr ; ∆; Γ; A ` d e ! A0 | C ; A U

Figure 4.20: Constraint-based availability rules for ILS programs Auxiliary Lemmas Before we begin with the actual theorems, we formulate some auxiliary lemmas that later help us. The lemmas state that the various judgments of the declarative system are stable under availability substitutions. Lemma 4.8

If Π ` A ≤ A0 , then Π ` σA ≤ σA0 .

Lemma 4.9 If Θ ` A ; A0 , then Θ ` σA ; σA0 .

Lemma 4.10 A0 ,A00

σA0 ,σA00

(i) If ∆ ` f : A −−−→ 0, then σ∆ ` f : σA −−−−−→ 0. (ii) If Π; Γ ` x : A, then Π; σΓ ` x : σA.

Lemma 4.11 If Υ; Π; Σ; Θ; Ξop ; Ξtr ; ∆; Γ; A ` e ! A0 , then Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ; σA ` e ! σA0 .

Proof. Straightforward induction of availability derivation, using Lemmas 4.8, 4.9 and 4.10.


145

Soundness We first prove soundness of the access rules. Lemma 4.12 Suppose Ξop ; Ac ` ops | C , α. If σ |=Υ,Π,Σ,Θ C , then Υ; Π; Σ; σΞop ; σAc ` ops : σα.

Proof. We proceed by inversion of the hypotheses. There are two deduction rules to consider. • Case (C-S-EO P ). The premises of the rule tell us, that Ξop (op)(s) = α

(4.92)

C ≡ { Ac 6 α, op α, single α}

(4.93)

Because σ |=Υ,Π,Σ,Θ C , we know that

Π ` σAc ≤ σα,

(4.94)

Π ` Σ(op) ≤ σα,

(4.95)

Υ ` σα,

(4.96)

and because

(σΞop )(op)(s) = σ(Ξop (op)(s)) = σα0 ,

(4.97)

the premise follows by applying (A-S-EO P). • Case (C-S-P OP ). Analogous to the previous case.

Lemma 4.13 Suppose Γ ` x : α | C . If σ |=Υ,Π,Σ,Θ C , then Π; σΓ ` x : σ(α).

Proof. By inversion of the hypotheses we know that Γ( x ) = A0 , 0

(4.98)

C ≡ { A 6 α }.

(4.99)

Π ` σA0 ≤ σα,

(4.100)

(σΓ)( x ) = σ(Γ( x )) = σA0 ,

(4.101)

Because σ solves C , we know that

and because

the premise follows by applying (A-S-VAR).

146


s

Lemma 4.14 Suppose Ξtr ` x s | C , α1 , α2 . If σ |=Υ,Π,Σ,Θ C , then Θ; σΞtr ` x : σα1 ; σα2 .

Proof. By inversion of the hypotheses we know that Ξtr (s)( x ) = (α1 , α2 ),

(4.102)

C ≡ {α1 99K α2 }.

(4.103)

Because σ solves C , we know that

and because

Θ ` σα1 ; σα2

(4.104)

(σΞtr )(s)( x ) = σ(Ξtr (s)( x )) = (σα1 , σα2 )

(4.105)

the premise follows by applying (A-S-P LACE).

Before proving soundness of programs, we formulate a soundness result for expressions. Lemma 4.15 Suppose Ξop ; Ξtr ; ∆; Γ; A ` e ! α0 | C ; A. If σ |=Υ,Π,Σ,Θ C , then Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, σA ` e ! σα0 .

Proof. We proceed by induction on the constraint-based derivation of availabilities. We consider the different cases for the expression rule last applied. • Case (C-S-H ALT ). The premise follows immediately by (A-S-H ALT). • Case (C-S-L ET ). By inversion of the last rule applied, we know that Ξop ; A ` ops | Cop , α0

(4.106)

(∀i ) Γ ` xi : α0 | Ci

(4.107)

Ξop ; Ξtr ; ∆; Γ, x0 : α0 ; A ` e ! α0 | C0 ; A

(4.108)

0

0

C = { α 6 α0 }

(4.109)

C = C1 ∪ . . . ∪ Ci ∪ Cop ∪ C0 ∪ C 0

(4.110)

Because σ |=Υ,Π,Σ,Θ C , it also solves all subsets of C , hence, Π ` σα0 ≤ σα0 .

(4.111)

It also follows, by applying Lemma 4.12, that, Π; σΞop ; σA ` ops : σα0 ,

(4.112)


147

by applying Lemma 4.13 that,

(∀i ) Π; σΓ ` xi : σα0 ,

(4.113)

and, by applying the induction hypothesis, that Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, x0 : σα0 ; σA ` e ! σα0 .

(4.114)

The premise follows by applying the (A-S-L ET) rule. • Case (C-S-I F ). By inversion of the last rule applied, we know that Ξop ; A ` ifs | Cif , α0

(4.115)

Γ ` x : α0 | C0

(4.116)

˙ 2 A = {α1 , α2 } ] A1 ∪A

(4.117)

Ξop ; Ξtr ; ∆; Γ, x : α0 ; α ` e0 ! α1 | C1 ; A1

(4.118)

Ξop ; Ξtr ; ∆; Γ, x : α0 ; α ` e1 ! α2 | C2 ; A2

(4.119)

C 0 = { α0 6 α1 , α0 6 α2 , α 0 6 α0 }

(4.120)

0

(4.121)

C = C0 ∪ C1 ∪ C2 ∪ Cif ∪ C Because σ |=Υ,Π,Σ,Θ C , it also solves all subsets of C , hence,

Π ` σα0 ≤ σα1 , Π ` σα0 ≤ σα2 , 0

0

0

Π ` σα ≤ σα0 , Π ` σα ≤ σα1 , Π ` σα ≤ σα2 .

(4.122) (4.123)

It also follows, by applying Lemma 4.12, that, Π; σΞop ; σA ` ifs : σα0 ,

(4.124)

by applying Lemma 4.13 that, Π; σΓ ` x : σα0 ,

(4.125)

and by applying the induction hypothesis, that Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, x : σα0 ; σA ` e1 ! σα1 ,

(4.126)

Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, x : σα0 ; σA ` e2 ! σα2 .

(4.127)

The premise follows by applying the (A-S-I F) rule. • Case (C-S-T RANS ). Analogous to the previous cases, but this time we apply Lemma 4.14.

148


• Case (C-S-J UMP ). By inversion of the last rule applied, we know that α00 ,α000

∆ ` f | αi −−−→ 0

(4.128)

Ci0

(4.129)

0

=α}

(4.130)

0

(4.131)

(∀i ) Γ ` xi : αi | 0

00

C = {A 6 α , α C=

C10

000 ?

∪ . . . ∪ Ci0

∪C

Because σ |=Υ,Π,Σ,Θ C , it also solves all subsets, thus, Π ` σA ≤ σα00 ,

(4.132)

000

(4.133)

σα

0

≡ σα ,

and by inversion of (C-S-F UN) and applying (A-S-F UN) σα00 ,σα000

σ∆ ` f : σαi −−−−→ 0.

(4.134)

The application of Lemma 4.13 leads to

(∀i ) Π; σΓ ` xi : σαi .

(4.135)

The premise follows by applying the (A-S-J UMP) rule.

Theorem 4.1 (Soundness of Constraint-Based Availabilities) Suppose Ξop ; Ξtr ; ∆; Γ; A ` p ! α0 | C ; A. If (σ, B, B0 ) is a (Υ, Π, Σ, Θ)-solution of (Ξop , Ξtr , ∆, Γ, A, p, α0 , C), then (σ, B, B0 ) also is a (Υ, Π, Σ, Θ)-solution of (Ξop ; Ξtr ; Σ; Γ; p). Or, differently, if σ |=Υ,Π,Σ,Θ C , then Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, σA ` p ! σα0

Proof. By inversion of (C-S-P ROG) for the hypotheses, we know that

A=

]

˙ 0 Ai ∪A

(4.136)

i

(∀i ) Ξop ; Ξtr ; ∆ ` di | Ci ; Ai

(4.137)

Ξop ; Ξtr ; ∆; Γ; A ` e ! α0 | C0 ; A0

(4.138)

C = C1 ∪ . . . ∪ Ci ∪ C0

(4.139)

Consequently, by inversion of (C-S-D EF) we also know that for each di ≡ f i ( x ) = ei ∈ p it holds αi ,α0

i 0 ∆ ` f i | αi −−→

(4.140)

Ξop ; Ξtr ; ∆; xi : αi ; αi ` ei ! αi0 | Ci ; Ai

(4.141)


149

Using the definitions of (C-S-F UN) and (A-S-F UN) and applying Lemma 4.15, respectively, it follows that σα,σα0

σ∆ ` f i : σαi −−−→ 0,

(4.142)

e I ! σαi0 ,

(4.143)

Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; xi : σαi ; σαi ` hence by (A-S-D EF) rule

(∀i ) Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆ ` di .

(4.144)

Applying Lemma 4.15 to (4.138) leads to Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ; σA ` e ! σα0

(4.145)

The premise follows by applying the (A-S-P ROG) rule.

Completeness Lemma 4.16 If Γ ` x : α | C , then fv(C) ⊆ fv(Γ) ∪ {α}.

Lemma 4.17 If Ξop ; A ` ops | C , α, then fv(C) ∪ {α} ⊆ fv(Ξop ) ∪ fv( A).

Lemma 4.18 If Ξtr ` x s | C , α, α0 , then fv(C) ∪ {α, α0 } ⊆ fv(Ξtr ).

Lemma 4.19 If Ξop ; Ξtr ; ∆; Γ; A ` e ! α0 | C ; A, then fv(Ξop ) ∩ A = fv(Ξtr ) ∩ A = fv(∆) ∩ A = fv(Γ) ∩ A = fv( A) ∩ A = ∅.

Lemma 4.20 If Ξop ; Ξtr ; ∆; Γ; A ` e ! α0 | C ; A, then fv(C) ⊆ fv(Ξop ) ∪ fv(Ξtr ) ∪ fv(∆) ∪ fv(Γ) ∪ fv( A) ∪ A.

Lemma 4.21 If Ξop ; Ξtr ; ∆; Γ; A ` e ! α0 | C ; A, then α0 ∈ A.

Lemma 4.22 If σ |=Υ,Π,Σ,Θ C and σ|0fv(C) = σ|fv(C) , then σ0 |=Υ,Π,Σ,Θ C .

150


Lemma 4.23 Suppose Γ ` x : α | C . If there is a σ such that Π; σΓ ` x : σα, then σ |=Υ,Π,Σ,Θ C.

Proof. By inversion of the constraint-based judgment using (C-S-VAR), we know that Γ( x ) = A

(4.146)

C ≡ { A 6 α}

(4.147)

By inversion of the static placement judgment using (A-S-VAR), we also know that

(σΓ)( x ) = B = σA

(4.148)

Π ` σA ≤ σα

(4.149)

Hence, σ |=Υ,Π,Σ,Θ C .

Lemma 4.24 Suppose Ξop ; A ` ops | C , α. If there is a σ such that Υ; Π; Σ; σΞop ; σA ` ops : B, then σα ≡ B, and σ |=Υ,Π,Σ,Θ C .

Proof. We proceed by case analysis on the derivation of operator placement access. • Case (C-S-EO P ). By inversion on the operator placement access judgment we know that Ξop (op)(s) = α,

(4.150)

C = { Ac 6 α, op α, single α}.

(4.151)

(σΞop )(op)(s) = B,

(4.152)

Σ(op) = Aop ,

(4.153)

Π ` σA ≤ B,

(4.154)

Π ` σAop ≤ B,

(4.155)

Υ ` B.

(4.156)

Also, by inversion of the (A-S-EO P) rule, we further know, that

The first hypotheses show, that σα ≡ B;

(4.157)

the remaining ones prove, that σ |=Υ,Π,Σ,Θ C . • Case (C-S-PO P ). Analogous to the previous case.


151 s

Lemma 4.25 Suppose Ξtr ` x s | C , α, α0 . If there is a σ such that Θ; σΞtr ` x : A ; A0 , then σα ≡ A, σα0 ≡ A0 , and σ |=Υ,Π,Σ,Θ C .

Proof. By inversion of the transfer placement access judgment, (C-S-P LACE), we know that Ξtr (s)( x ) = (α, α0 ),

(4.158)

C ≡ {α 99K α0 }.

(4.159)

By inversion of the (A-S-P LACE) rule, we also know, that

(σΞtr )(s)( x ) = ( A, A0 ),

(4.160)

Θ ` A ; A0 .

(4.161)

The first premises yield σα ≡ A and well.

σα0

≡

A0 .

(4.162)

By definition, then σ |=Υ,Π,Σ,Θ C holds as

We first formulate the completeness result for expressions. Lemma 4.26 Suppose Ξop ; Ξtr ; ∆; Γ; A ` e ! α0 | C ; A. If there is a σ such that Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, σA ` e ! A0 , and dom σ ∩ A = ∅, then there exists a σ0 with (i) σ0 |=Υ,Π,Σ,Θ C , (ii) σ0 \A = σ, (iii) σ0 α0 = A0 .

Proof. Let σ an availability substitution such that Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, σA ` e ! σA0 , We proceed by induction of the constraint-based derivation of availabilities. We consider the different cases for the expression rule applied last. • Case (C-S-H ALT ). The premise follows immediately, because C ≡ ∅. • Case (C-S-L ET ). By inversion of the last rule applied of the constraint-based typing derivation, we know that Ξop ; A ` ops | Cop , α0

(4.163)

(∀i ) Γ ` xi : α0 | Ci

(4.164)

Ξop ; Ξtr ; ∆; Γ, x0 : α0 ; A ` e ! α0 | C0 ; A

(4.165)

C 0 = { α 0 6 α0 }

(4.166)

C = C1 ∪ . . . ∪ Ci ∪ Cop ∪ C0 ∪ C 0

(4.167)

152

CHAPTER 4. PLACEMENT INFERENCE By inversion of the last rule applied of the type-based derivation we also know that Υ; Π; Σ; σΞop ; σA ` ops : B0

(4.168)

(∀i ) Π; σΓ ` xi : B0

(4.169)

Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, x0 : B0 ; σA ` e ! A0

(4.170)

0

Π ` A ≤ B0

(4.171)

By Lemma 4.24, it follows that, σα0 ≡ B0 ,

(4.172)

σ |=Υ,Π,Σ,Θ Cop .

(4.173)

On (4.164) and (4.169), we are able to apply Lemma 4.23 leading to σ |=Υ,Π,Σ,Θ Ci for each Ci . Consequently, it is valid to apply the induction hypothesis on (4.165) and (4.170), hence there exists a σ0 with σ0 |=Υ,Π,Σ,Θ C0 ,

(4.174)

σ0 \A = σ,

(4.175)

0

0

σ0 α = A .

(4.176)

By Lemma 4.16, Lemma 4.21, and Lemma 4.19, we know that fv(Ci ) ∩ A = ∅, hence (4.175) leads to σ0,|fv(Ci ) = σ|fv(Ci ) . Thus, by Lemma 4.22, σ0 |=Υ,Π,Σ,Θ Ci . Accordingly, by Lemma 4.17 and Lemma 4.19, we know that fv(Cop ) ∩ A = ∅, hence (4.175) also leads to σ0,|fv(Cop ) = σ|fv(Cop ) . Thus, by Lemma 4.22, σ0 |=Υ,Π,Σ,Θ Cop . By (4.171), it also follows, that σ |=Υ,Π,Σ,Θ σ0 α0 ≤ σ0 α0 , that is, σ0 |=Υ,Π,Σ,Θ C 0 . Finally, by (4.167), we conclude, that σ0 |=Υ,Π,Σ,Θ C holds as well. • Case (C-S-I F ). By inversion of the last rule applied of the constraint-based typing derivation, we know that Ξop ; A ` ifs | Cif , α0

(4.177)

Γ ` x : α0 | C0

(4.178)

˙ 2 A = {α0 , α1 , α2 } ] A1 ∪A

(4.179)

0

α , α1,2 6∈ Ξop , Ξtr , ∆, Γ, { A}

(4.180)

Ξop ; Ξtr ; ∆; Γ, x : α0 ; A ` e1 ! α1 | C1 ; A1

(4.181)

Ξop ; Ξtr ; ∆; Γ, x : α0 ; A ` e2 ! α2 | C2 ; A2

(4.182)

0

0

C = { α0 6 α1 , α0 6 α2 , α 6 α0 }

(4.183)

C = C0 ∪ C1 ∪ C2 ∪ Cif ∪ C 0

(4.184)


153

By inversion of the last rule applied of the type-based derivation we also know that Υ; Π; Σ; σΞop ; σA ` ifs : B0

(4.185)

Π; σΓ ` x : B0

(4.186)

Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, x : B0 ; σA ` e1 ! B1

(4.187)

Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, x : B0 ; σA ` e2 ! B2

(4.188)

Π ` B0 ≤ B1

Π ` B0 ≤ B2

(4.189)

0

(4.190)

Π ` A ≤ B0 By Lemma 4.24 on (4.177) and (4.185), it follows that, σ |=Υ,Π,Σ,Θ Cif ,

(4.191)

σα0 = B0 .

(4.192)

By Lemma 4.23 on (4.178) and (4.186). it also follows that, σ |=Υ,Π,Σ,Θ C0 .

(4.193)

By applying the induction hypothesis on (4.181) and (4.187), and (4.182) and (4.188), respectively, we know that there exists a σ1 and σ2 such that, σ1 |=Υ,Π,Σ,Θ C1 ,

(4.194)

σ1 \A1 = σ,

(4.195)

σ1 α1 = B1 ,

(4.196)

σ2 |=Υ,Π,Σ,Θ C2 ,

(4.197)

σ2 \A2 = σ,

(4.198)

σ2 α1 = B2 .

(4.199)

and

Let σ0 be the following substitution   α1 7→ B1       α2 7→ B2  α0 7→ A0 σ0 :  α 7→ σ1 α     α 7→ σ2 α     α 7→ σα

if α ∈ A1 if α ∈ A2 otherwise

154

CHAPTER 4. PLACEMENT INFERENCE By the definition of σ0 , it obviously follows that σ0 α0 = A0 , 0

σ \A = σ.

(4.200) (4.201)

From (4.177), it follows by Lemma 4.17, that fv(Cit ) ∪ {α0 } ⊆ fv(Ξop ) ∪ fv( A).

(4.202)

By applying Lemma 4.19 to (4.181) and (4.182), we know that, fv(Cit ) ∩ A1 = ∅,

(4.203)

fv(Cit ) ∩ A2 = ∅.

(4.204)

Using (4.180), we also know that, fv(Cit ) ∩ {α0 , α1 , α2 } = ∅,

(4.205)

fv(Cit ) ∩ A = ∅.

(4.206)

σ|0fv(Cit ) = σ|fv(Cit ) ,

(4.207)

hence

By (4.201), it then follows, that

hence, by (4.191) and Lemma 4.22, that σ0 |=Υ,Π,Σ,Θ Cif .

(4.208)

From (4.177), it follows by Lemma 4.17, that α0 ∈ fv(Ξop ) ∪ fv( A).

(4.209)

From (4.178), it follows by Lemma 4.16, that fv(C0 ) ⊆ fv(Γ) ∪ fv(α0 ).

(4.210)

fv(C0 ) ⊆ fv(Γ) ∪ fv(Ξop ) ∪ fv( A).

(4.211)

Hence,

By applying Lemma 4.19 to (4.181) and (4.182), we know that, fv(C0 ) ∩ A1 = ∅,

(4.212)

fv(C0 ) ∩ A2 = ∅.

(4.213)

Using (4.180), we also know that, fv(C0 ) ∩ {α0 , α1 , α2 } = ∅,

(4.214)


155

hence fv(C0 ) ∩ A = ∅.

(4.215)

σ|0fv(C0 ) = σ|fv(C0 ) ,

(4.216)

By (4.201), it then follows, that

hence, by (4.191) and Lemma 4.22, that σ0 |=Υ,Π,Σ,Θ C0 .

(4.217)

If α ∈ fv(C1 ) and α ∈ A1 , then σ0 (α) = σ1 (α) by the definition of σ0 . If α 6∈ fv(C1 ) and α ∈ A1 , by applying Lemma 4.19 and Lemma 4.20 (4.181) and (4.182), it follows that α 6 ∈ A2 .

(4.218)

α 6 ∈ { α 0 , α1 , α2 },

(4.219)

α 6 ∈ A.

(4.220)

Further, using (4.180) also leads to

thus

We are now able to conclude, by using (4.201) and (4.195), that σ 0 ( α ) = σ ( α ),

(4.221)

σ1 (α) = σ(α),

(4.222) (4.223)

hence σ0 (α) = σ1 (α).

(4.224)

σ|0fv(C1 ) = σ|fv(C1 ) ,

(4.225)

Combing both subcases yields

hence, by (4.194) and Lemma 4.22, that σ0 |=Υ,Π,Σ,Θ C1 .

(4.226)

Analogously, we are able to conclude that σ0 |=Υ,Π,Σ,Θ C2 .

(4.227)

156

CHAPTER 4. PLACEMENT INFERENCE By inspecting the definition of σ0 and using (4.189) and (4.190), we know that σ0 |=Υ,Π,Σ,Θ C 0 .

(4.228)

σ0 |=Υ,Π,Σ,Θ C ,

(4.229)

The last premise,

then follows simply by using (4.184). • Case (C-S-T RANS ). By inversion of the last rule applied of the constraint-based typing derivation, we know that

(∀i ) Ξtr ` xis | Ci0 , αi , αi0

Γ ` xi : αi | Ci

(4.230)

0

Ξop ; Ξtr ; ∆; Γ, xi : αi0 ; A ` e ! α | C0 ; A

C=

C1 ∪ . . . ∪ Ci ∪ C10

∪ . . . ∪ Ci0

(4.231)

∪ C0

(4.232)

By inversion of the last rule applied of the type-based derivation we also know that s Θ; σΞtr ` xi : Bi ; Bi0

(∀i ) Π; σΓ ` xi : Bi

Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, x : B0 ; σA ` e ! A

0

(4.233) (4.234)

By Lemma 4.25, if follows, that σ |=Υ,Π,Σ,Θ Ci0 ,

(4.235)

σαi ≡ Bi , σαi0 ≡ Bi0 .

(4.236)

σ |=Υ,Π,Σ,Θ Ci .

(4.238)

(4.237)

By Lemma 4.23, it also follows, that

Consequently, it is valid to apply the induction hypothesis on (4.231) and (4.234), hence there exists a σ0 with σ0 |=Υ,Π,Σ,Θ C0 , 0

(4.239)

σ \A = σ,

(4.240)

σ0 α0 = A0 .

(4.241)

By Lemma 4.16, Lemma 4.18, and Lemma 4.19, we know that fv(Ci ) ∩ A = ∅, hence (4.240) leads to σ|0fv(C ) = σ|fv(Ci ) . Thus, by Lemma 4.22, σ0 |=Υ,Π,Σ,Θ Ci . i By Lemma 4.18 and Lemma 4.19, we also know that fv(Ci0 ) ∩ A = ∅, hence (4.240) leads to σ|0fv(C 0 ) = σ|fv(C 0 ) . Thus, by Lemma 4.22, σ0 |=Υ,Π,Σ,Θ Ci0 . i

i

Finally, σ0 |=Υ,Π,Σ,Θ C then follows by (4.232).


157

• Case (C-S-J UMP ). By inversion of the last rule applied of the constraint-based typing derivation, we know that α00 ,α0

∆ ` f | αi −−→ 0

(4.242)

Ci0

(4.243)

C 0 = { A 6 α00 , α = A0 }

(4.244)

0

(4.245)

(∀i ) Γ ` xi : αi | 0 ?

C=

C10

∪ . . . ∪ Ci0

∪C

By inversion of the last rule applied of the type-based derivation we also know that

(∀i ) Π; σΓ ` xi : Bi

(4.246)

B00 ,B0

σ∆ ` f : B −−−→ 0 Π ` σA ≤ B

00

0

(4.247)

0

B ≡ σA .

(4.248)

By inversion of (4.242) and (4.246), it follows that α00 ,α000

B00 ,B000

∆( f ) = αi −−−→ 0(σ∆)( f ) = Bi −−−→ 0

(4.249)

σ (αi ) = Bi ,

(4.250)

hence

00

00

(4.251)

0

(4.252)

σ(α ) = B , 0

σ(α ) = B .

Applying Lemma 4.23 on (4.243) and (4.246) tells us that σ |=Υ,Π,Σ,Θ Ci0 for all Ci0 . By applying (4.251) and (4.252) to (4.248), it follows that Π ` σA ≤ σα00 ,

(4.253)

0

(4.254)

0

σα ≡ σA . ?

Hence, σ also is a (Π, Σ, Θ)-solution of C 0 ≡ { A 6 α00 , α0 = A0 }. Thus, by (4.245), σ |=Υ,Π,Σ,Θ C as well.

Theorem 4.2 (Completeness of Constraint-based Availabilities) Suppose A; Ξop ; Ξtr ; ∆; Γ; A ` p ! A0 | C . If there is a σ such that Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ, σA ` p ! σA0 , then σ |=Υ,Π,Σ,Θ C .

158


Proof. By inversion of (C-S-P ROG) for the hypotheses, we know that ]

˙ 0 Ai ∪A

(4.255)

(∀i ) Ai ; Ξop ; Ξtr ; ∆ ` di | Ci

(4.256)

A=

i

0

A0 ; Ξop ; Ξtr ; ∆; Γ; A ` e ! A | C0

(4.257)

C = C1 ∪ . . . ∪ Ci ∪ C0

(4.258)

Consequently, by inversion of (C-S-D EF) we also know that for each di ≡ f i ( x ) = ei ∈ p it holds α,α0

∆ ` f i | αi −−→ 0

(4.259)

0

Υ; Ξop ; Ξtr ; ∆; xi : αi ; α ` ei ! α | Ci

(4.260)

Also, by inversion of (A-S-P ROG) for the second hypotheses, we know that

(∀i ) Π; Σ; Θ; σΞop ; σΞtr ; σ∆ ` di , 0

Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; σΓ; σA ` e ! σA ,

(4.261) (4.262)

hence, by inversion of (A-S-D EF), we know that for all function definitions, it holds that A,A0

σ∆ ` f i : A −−→ 0 0

Υ; Π; Σ; Θ; σΞop ; σΞtr ; σ∆; x : A; A ` ei ! A .

(4.263) (4.264)

By applying Lemma 4.26 to (4.257) and (4.262), it follows that σ is a (Π, Σ, Θ)-solution of C0 . For each definition, di , we know, by inversion of (4.256), that α,α0

∆( f i ) = αi −−→ 0

(4.265)

and, by inversion of (4.261), that, A,A0

(σ∆)( f i ) = Ai −−→ 0,

(4.266)

σαi = Ai

(4.267)

σα = A,

(4.268)

hence,

0

0

σα = A .

(4.269)

Consequently, we are able to apply Lemma 4.26 to (4.260) and (4.264), it follows that σ is a (Π, Σ, Θ)-solution for each Ci . The premise follows because σ is (Π, Σ, Θ)-solution of all subsets.


4.2.3

159

Solving Constraints

In the previous section, we developed an algorithmic version of the placement analysis. We specified a system that generates constraints expressing the properties of all solutions to the availability assignments problem. We further showed, that solutions of the generated constraints correspond to solutions of the original, specifying system. But, up to now, we do not know, how to find a solution for a set of generated constraints. In this section, we present a constraint solving procedure and prove its soundness and completeness. In order to solve constraints, we add another form of constraints to our constraint language that express partial solutions of subtyping constraint problems. C

::= |

... N, N 6 N

conditional subtyping constraints

Conditional subtyping constraints demand the subtyping between to sets of locations without resorting to a sequence of other sets of locations to prove it. We also extend the notion of (Υ, Π, Σ, Θ)-solutions (Definition 4.12) to conditional subtyping constraints. Definition 4.14 An availability substitution σ is (Υ, Π, Σ, Θ)-solution of conditional subtyping constraint N, N 0 ≤ N 00 , written σ |=Υ,Π,Σ,Θ N, N 0 6 N 00 , if { N, N 0 } is a chain, N 00 6∈ N, and either • the N 0 ≡ N 00 , or • there exists a chain, M, such that Π ` N 0 , M, N 00 and ∀ M ∈ M.M 6∈ N.

Next, we give the definition for constraints that are in solved form. If a constraint or a set of constraint is in solved form, we are able to immediately read of a solution for them. ?

Definition 4.15 A constraint, C, is in solved form, if C ≡ α = N. That is, a constraint is in solved form, if it is syntactically equivalent to an equality constraint with a location set variable α on the left hand side. Accordingly, we call a set of constraints, C , in solved form, if each of its members is in solved form and all location set variables on the left hand side, α, are distinct.

Notation 4.2 For each set of constraints, C , in solved form, we denote the corresponding availability substitution by σC .

Notation 4.3 With C [α 7→ A] we denote a constraint, C 0 , that is syntactically equivalent to C except for every occurrence of α is substituted by availability A.

160


Lemma 4.27 Suppose σ(α) = A. Then the following two statements are equivalent: (i) σ |=Υ,Π,Σ,Θ C, (ii) σ |=Υ,Π,Σ,Θ C [α 7→ A].

Proof. By a simple case analysis on the different forms of constraints applying the definition of (Υ, Π, Σ, Θ)-solutions of constraints.

The simplification procedure for a set of constraints of our constraint language with respect to given assumptions Υ, Π, Σ, and Θ is defined by a deduction system. The deduction system is specified by deduction rules shown in Figure 4.21. We write C Υ,Π,Σ,Θ C 0 (or even C C 0 ), if C 0 can be deduced from C . To keep the presentation manageable, we use the notation C Υ,Π,Σ,Θ C10 | . . . | Cn0 as abbreviation for a set of n rules sharing a common premise, C . The (CS-S-S UB -1) rule dismisses a trivially solvable subtyping constraint between two identical availabilities. The (CS-S-S UB -2) rule infers different constraint sets containing conditional subtyping constraints instead of a subtyping constraint between two sets of locations, N and N 0 . Instead of requiring subtyping between N and N 0 , we demand subtyping between direct supertypes of N, Ni . In case there is a subtyping constraint involving a location set variable, α, the (CS-S-S UB -3) and (CS-S-S UB -4) maintain solvability by reducing the subtyping problem to problems each handling one possible substitution for the location set variable. The (CS-S-O P) rule substitutes an operation constraint with a subtyping constraint using the appropriate location set associated with operation op in availability signature Σ. The rules handling transfer constraints are similar to the rules handling subtyping constraints. The (CS-S-T RANS -1) rule handles transfers between fixed availabilities, the (CS-S-T RANS -2) and (CS-S-T RANS -3) rules handle transfer constraints involving location set variables by substituting possible candidates. The (CS-S-E Q) rule eliminates equality constraints between two identical sets of locations. It only applies for the proof of completeness of the deduction system. The (CS-S-C OND -1) rule and the (CS-S-C OND -2) rule infer constraint sets from a constraint set that involves a conditional subtyping constraint. A conditional subtyping constraint between two identical sets of constraints is eliminated if the conditions are consistent, that is, previously applied sets of locations are disjoint from the set of locations in question. The solvability of conditional subtyping constraint between to non-identical sets of locations, N 0 and N 00 , is maintained by inferring different new conditional subtyping constraints between those successors of N 0 , Ni , and N, that still maintain the invariant of conditional subtyping constraints of disjoint conditional sets of locations.


161

CS-S-S UB -1

C, A 6 A C CS-S-S UB -2

C , N 6 N0 N 6= N 0 , ( N, Ni ) ∈ Π, N 6= Ni C , { N, N1 } 6 N 0 | . . . | C , { N, Nn } 6 N 0 CS-S-S UB -3

C, N 6 α α = N0 , C[α 7→ N0 ], N 6 N0 | . . . | α = Nn , C[α 7→ Nn ], N 6 Nn CS-S-S UB -4

C, α 6 A A 6= α α = N0 , C[α 7→ N0 ], N0 6 A | . . . | α = Nn , C[α 7→ Nn ], Nn 6 A CS-S-T RANS -1

CS-S-O P

C , N1 99K N2 ( N1 , N2 ) ∈ Θ C

C , op A Σ(op) = N0 C , N0 6 A CS-S-T RANS -2

C , N 99K α α = N0 , C[α 7→ N0 ], N 99K N0 | . . . | α = Nn , C[α 7→ Nn ], N 99K Nn CS-S-T RANS -3

C , α 99K A A 6= α α = N0 , C[α 7→ N0 ], N0 99K A | . . . | α = Nn , C[α 7→ Nn ], Nn 99K A CS-S-S INGLE -1

C , single N N∈Υ C CS-S-S INGLE -2

C , single α α = N0 , C[α 7→ N0 ], single N0 | . . . | α = Nn , C[α 7→ Nn ], single Nn CS-S-E Q ?

C, N = N C

CS-S-C OND -1 C , { N, N 0 }

6 N0

C

{ N, N 0 } disjoint

CS-S-C OND -2

C , { N, N 0 , N1 }

C , { N, N 0 } 6 N 00 6 N 00 | . . . | C , { N, N 0 , Nn } 6 N 00

N 0 6≡ N 00 , ( N 0 , Ni ) ∈ Π, Ni 6∈ N, Ni 6≡ N 0

Figure 4.21: Simplification rules for ILS constraints

162


Before we prove soundness and completeness of the deduction system solving constraints, we first show that a single deduction step preserves solutions of sets of constraints. Lemma 4.28 (Preservation of Constraint Solving) For a single deduction step, C Π,Σ,Θ C1 | . . . | Cn , the following two statements are equivalent: (i) σ |=Π,Σ,Θ C , (ii) σ |=Π,Σ,Θ Ci , for some i.

Proof. We proceed by case analysis on the different deduction rules. It suffices to show preservation of a solution, σ, for the actual constraint rewritten by the deduction rule, because the remaining constraints always stay unchanged. Exemplarily, we show the proof of three, more involved, cases. The other cases either are trivial or work accordingly. • Case (CS-S-S UB -2). “⇒”. Suppose σ |=Υ,Π,Σ,Θ N 6 N 0 and N 6≡ N 0 . By Lemma 4.3, we know that

∃ M.Π ` N, M, N 0 .

(4.270)

– Subcase (i) M ≡ ∅. That is, Π ` N, N 0 , hence ( N, N 0 ) ∈ Π. Choosing Ni ≡ N 0 , it holds that Π ` { N, N 0 } ≤ N 0 . – Subcase (ii) M ≡ M1 , M0 . That is, Π ` N, M1 , M, N 0 , hence N 6≡ N1 and ( N, M1 ) ∈ Π. It also holds that Π ` M1 , M0 , N 00 and ∀ M ∈ M0 .M 6≡ N, it follows that Π ` { N, M1 } ≤ N 0 . “⇐”. Suppose N, Ni ≤ N 0 , N 6≡ N 0 , ( N, Ni ) ∈ Π, N 6≡ Ni . By the definition of solvability of conditional subtyping constraints, it either follows – Subcase (i) Ni ≡ N 0 . That is, ( N, N 0 ) ∈ Π, hence Π ` N ≤ N 0 . – Subcase (i) Ni 6≡ N 0 . Then, ∃ M.Π ` Ni , M, N 0 , hence Π ` Ni ≤ N 0 . By transitivity together with ( N, N 0 ) ∈ Π, it follows that Π ` N ≤ N 0 . • Case (CS-S-S UB -3). “⇒”. Suppose σ |=Υ,Π,Σ,Θ C , N 6 α, that is, Π ` N ≤ σα.

(4.271)

There exists a Ni with σα = Ni . Applying Lemma 4.27 leads to ?

σ |=Υ,Π,Σ,Θ α = Ni ,

(4.272)

σ |=Υ,Π,Σ,Θ C[α 7→ Ni ],

(4.273)

σ |=Υ,Π,Σ,Θ N 6 Ni .

(4.274)


163

“⇐”. Suppose ?

σ |=Υ,Π,Σ,Θ α = Ni ,

(4.275)

σ |=Υ,Π,Σ,Θ C[α 7→ Ni ], and

(4.276)

σ |=Υ,Π,Σ,Θ N 6 Ni .

(4.277)

Solvability of the equality constraint tells us that σα = Ni ,

(4.278)

σ |=Υ,Π,Σ,Θ C ,

(4.279)

thus, by Lemma 4.27, (4.280) and σ |=Υ,Π,Σ,Θ N 6 α.

(4.281) (4.282)

• Case (CS-S-C OND -2). “⇒”. Suppose σ |=Υ,Π,Σ,Θ N, N 0 ≤ N 00 and N 0 6≡ N 00 . Then, by definition of solvability, we know that N, N 0 is a disjoint sequence, 00

(4.283)

N 6∈ N,

(4.284)

N 0 6≡ N 00 , and

(4.285)

∃ M.Π ` N 0 , M, N 00 and ∀ M ∈ M.M 6∈ N. N 00 ,

– Subcase (i) M ≡ ∅. Then, by choosing Ni ≡ we know that, and N, N 0 , N 00 is also a disjoint sequence. Hence, σ |=Υ,Π,Σ,Θ N, N 0 , N 00 6 N 00 .

(4.286)

( N 0 , N 00 )

∈Π

(4.287)

– Subcase (ii) M ≡ M1 , M0 . That is, Π ` N 0 , M1 , M0 , N 00 ,

(4.288)

∀ M ∈ M0 , M 6∈ N, and

(4.289)

M1 6∈ N.

(4.290)

It follows, that N, N 0 , M1 is a disjoint sequence, 00

(4.292)

00

(4.293)

N 6∈ N, N , M1 6≡ N , Π ` M1

, M0 , N 00 ,

(4.291)

0

and

(4.294)

∀ M ∈ M0 , M 6∈ N, and M 6≡ N 0 ,

(4.295)

164

CHAPTER 4. PLACEMENT INFERENCE thus, σ |=Υ,Π,Σ,Θ N, N 0 , M1 6 N 00 .

(4.296)

“⇐”. Suppose σ |=Υ,Π,Σ,Θ N, N 0 , Ni 6 N 00 , 0

(4.297)

00

N 6≡ N ,

(4.298)

0

( N , Ni ) ∈ Π, and

(4.299)

Ni 6∈ N, N 0 .

(4.300)

Then, by definition of solvability, we also know that, N, N 0 , Ni is a disjoint sequence, 00

0

N 6∈ N, N ,

(4.301) (4.302) (4.303)

– Subcase (i) Ni ≡ N 00 . That is, ( N 0 , N 00 ) ∈ Π, hence with M ≡ ∅, it holds that Π ` N 0 , M, N 00 . – Subcase (i) Ni 6≡ N 00 . That is

∃ M.Π ` N 0 , M, N 00 and ∀ M ∈ M.M 6∈ N, N 0 .

(4.304)

With the side conditions of the deduction rule, we also know that with M0 ≡ Ni , M, it also holds that, Π ` N 0 , Ni , M, N 00 , and

(4.305)

∀ M ∈ M0 .M 6∈ N.

(4.306)

That is, for both subcases, we yield σ |=Υ,Π,Σ,Θ N, N 0 6 N 00 .

(4.307)

A progress result also holds for constraint solving. Lemma 4.29 (Progress of Constraint Solving) If σ |=Υ,Π,Σ,Θ C , then either (i) C is in solved form, or (ii) a deduction step C Π,Σ,Θ C 0 applies.

Proof. Suppose σ |=Υ,Π,Σ,Θ C. We proceed by case analysis over the syntax of the constraint, C.


165

• Case C ≡ A 6 A0 . – Subcase (i) A ≡ N, A ≡ N 0 , N 6≡ N 0 . By Lemma 4.2, we know that there exists ( N, N 00 ) ∈ Π such that (CS-S-S UB -2) applies. – Subcase (ii) Otherwise. One of the rules (CS-S-S UB -1), (CS-S-S UB -3), or (CSS-S UB -4) immediately applies. • Case C ≡ op A. (CS-S-O P) applies. • Case C ≡ A 99K A0 .

– Subcase (i) A ≡ N, A ≡ N 0 . By definition of solvability of constraints, we know that Θ ` N ; N 0 , hence ( N, N 0 ) ∈ Θ and (CS-S-T RANS -1) applies.

– Subcase (ii) Otherwise. One of the two remaining rules, (CS-S-T RANS -2) and (CS-S-T RANS -3), immediately applies. ?

• Case C ≡ A = N. C is either in solved form, or (CS-S-EQ) applies. • Case C ≡ { N, N 0 } 6 N 00 . By solvability of conditional subtyping constraints, we know that N, N 0 disjoint

(4.308)

N 00 6∈ N

(4.309) (4.310)

– Subcase (i) N 0 ≡ N 00 . (CS-S-C OND -1) applies. – Subcase (i) N 0 6≡ N 00 . That is, there exists M, with Π ` N 0 , M, N 00

(4.311)

∀ M ∈ M.M 6∈ N.

(4.312)

If M ≡ ∅, we know also that ( N 0 , N 00 ) ∈ Π and N 00 6∈ N, hence (CS-S-C OND 2) applies. If M ≡ M1 M0 , that is Π ` N 0 , M1 , M0 , N 00

∀M ∈

M0 .M

6∈ N and M1 6∈ N.

(4.313) (4.314)

That is, because we also know that ( N 0 , M1 ) ∈ Π and M1 6≡ N 0 , (CS-S-C OND 2) also applies. .

Next we prove termination of the deduction system.

166


Lemma 4.30 (Termination of constraint solving) For any finite multiset of constraints C , and any finite set of names of sets of locations, N , with |N | = n, every deduction sequence

terminates.

C C1 C2 . . .

Proof. We first define a complexity measure (n1 , n2 , n3 , n4 , n5 , , n6 , n7 , M8 ) on multisets of constraints, ordered by the well-founded lexicographic ordering on eight-tuples with n1 = number of distinct variables in C without counting variables of constraints in solved form, n2 = number of constraints in C of the form op A,

n3 = number of constraints in C of the form A 99K A0 , n4 = number of constraints in C of the form single A, ?

n5 = number of constraints in C of the form A = A0 , n6 = number of constraints in C of the form A 6 A0 , and n7 = number of constraints in C of the form A 6 N, and M8 = multiset of numbers, where d ∈ M6 , if Ni 6 N 0 in C with d = n − i. Each rule of the deduction system reduces the complexity of the constraint set C .

The first of our major results about the constraint solving procedure of this section shows that deduction sequences ending with constraints in solved form indeed lead to solutions of the initial constraint problem. 0 0 Theorem 4.3 (Soundness of constraint solving) If C + Π,Σ,Θ C , and C is in solved form, then σC 0 |=Υ,Π,Σ,Θ C .

Proof. By simple induction over deduction steps using Lemma 4.28.

The second major result shows that every solution of a constraint problem is indeed reached by finite number of steps of our deduction system. Theorem 4.4 (Completeness of constraint solving) If σ |=Υ,Π,Σ,Θ C , then there exists a 0 0 finite deduction sequence C + Π,Σ,Θ C where C is in solved form, and σC 0 ⊆ σ.

4.3. DETERMINING OPTIMAL PLACEMENTS

167

Proof. We first prove the existence of a solved form for solvable constraints in case only finite deduction sequence exists. The assumption then follows by Lemma 4.30. We prove the following hypothesis by induction over n: If σ |=Υ,Π,Σ,Θ C , and for all C 0 , either C 6∗ C 0 , or there exists m with m ≤ n and C m C 0 , then there exists C 0 with C ∗Π,Σ,Θ C 0 , C 0 is in solved form, and σC 0 ⊆ σ.

• Case n = 0. By the second premise, we know that there does not exists a deduction sequence originating from C . By Lemma 4.29, it follows that C is in solved form. ?

Suppose σC 6⊆ σ. Then, there exists a α = N ∈ C and σ (α) 6= N which contradicts the solvability of C . • Case n > 0. – Subcase (i) C already in solved form. Analogous to the previous case. – Subcase (ii) C not in solved form. By Lemma 4.29, we know that there exists a deduction step C Ci . By applying preservation of constraint solving (Lemma 4.28), we know that there exists a Ci such that σ |=Υ,Π,Σ,Θ Ci . The assumptions follows by applying the induction hypothesis on Ci .

The last two theorems also let us conclude that, supposing we consider a finite set of locations to place the parts of the program on, the set of all placements we possibly could receive from a placement algorithm is always finite. A simple simplification step of a constraint set always only leads to a finite number of follow-up constraint sets, and the proof of Lemma 4.30 tells us that we can always compute an upper bound on the length of all deduction sequences. Nevertheless, as already the simplest programs shows, there usually is not just one, unique solution solving the generated constraint set of a program, but several ones.

4.3

Determining Optimal Placements

The previous section showed, given a program and predetermined calculation cost and transfer cost functions, how to determine the set of all possible placements for that program. In generally, we do not know, which placement is the best to choose. In this section, we define the notion of worst-case runtime for an ILS programs with a given placement. Worst-case runtime can be computed effectively by relating durations of programs to matrices over dioids and using results of the spectral theory of matrices over dioids to calculate them. The notion of worst-case runtime allows us to identify optimal placements for a program, that is, those placements that have the smallest worst-case run-time of all valid placements. To be able to use a matrix representation to succinctly describe the timing behavior of a program, we must ensure that each distinct subexpression of the program carries a unique placement label. The following definition formally defines the notion of uniquely

168


labeled programs. We also assume for the rest of this section that all programs we consider are uniquely labeled. 0 Definition 4.16 A program p is called uniquely labeled, if the following holds: if s e, s e0 are subexpressions of p, and s ≡ s0 , then e ≡ e0 .

4.3.1

Syntax

We further specialize sets of variables, operation names and locations. Var FVar SVar Op L

= = = = =

{ x1 , . . . , x n v } { f 1 , . . . , f nf } { s1 , . . . , s n s } {if} ] {op2 , . . . , opnop } {`1 , . . . , `nl }

For the rest of this section, we assume that those sets are finite sets indexed by natural numbers with the highest index on variables, nv , the highest index on function names, nf , the highest index on placement labels, ns , the highest index on operations, nop , and the highest index on locations, nl . We sometimes address conditionals, if, as special operator carrying index 1.

4.3.2

Dynamic Semantics Using Matrices

Because we would like to consider the worst-case running time of programs, we have to consider the transitive closure of the one-step reduction relation of the timed dynamic semantics of ILS introduced in Section 4.1.3. It is very convenient to express program states and program transitions as vectors and matrices over the dioid we work with instead of using (partial) functions. Typical tasks such as considering the composition or the transitive closure of relations now just amounts to applying matrix operations and applying results of the spectral theory of matrices. In the following, we use another, alternative presentation for timed configurations, χ = (L, κ, τ, ξ op , ξ tr ) and for timed environments, ϑc and ϑv . cj T

∈ ∈

D nl D nl ×nl

calculation cost vector transfer cost matrix

O j,k Sk,l

∈ ∈

D nl ×nl D nl ×nl

operation placement matrix transfer placement matrix

Instead of the calculation cost functions, κ, we now use a family of duration vectors indexed by numbers representing operations, c = (c j ) j∈[nop ] . Each vector, called calculation cost vector, represents the calculation durations for a particular operation. The counterpart of a transfer cost function, τ, is a cost matrix, T.


169

An operation placement function, ξ op , is now represented as family of operation placement matrices, O = (O j,k ) j∈[nop ],k∈[ns ] , and a transfer placement functions, ξ tr , is represented as family of transfer placement matrices, S = (Sk,l )k∈[ns ],l ∈[nv ] . Accordingly, timed environments, ϑc and ϑv , are also represented as vectors. We use a combined vector, d, to represent both environments at the same time. d

∈

D nl +nv nl

environment vector

The mappings from the previous representations to the representation using vectors and matrices are formalized in the following.

Calculation costs, κ, are translated to a vector representation by function cJ·K. cJ·K ∈ (Op → L → D) → Op → D nl   κ (op j )(`1 )   ..  cJκKop j = κ (op j )(ì ) =    . i κ (op j )(`nl ) Transfer costs, τ, are translated to a matrix representation by function TJ·K. TJ·K ∈ (L → L → D) → D nl ×nl  τ (1)(1) . . .  .. .. TJτK = (τ ( j, i ))i,j =  . . τ (1)(nl ) . . .

 τ (nl )(1)  ..  . τ (nl )(nl )

Operation placements, ξ op , are translated to a matrix representation by function OJ·K. OJ·K ∈ (Op ,→ SVar ,→ P (L)) → Op → SVar → D nl ×nl   d1 0 . . . 0    d1 ..  .. ..   . . .   .  0 OJξ op Kop j sk = diag( .. ) =   .. ..  ..  . . . 0 d nl 0 . . . 0 d nl ( 1 if ì ∈ ξ op (op j )(sk ) where di = 0 otherwise

170


Transfer placements, ξ tr , are translated to a matrix representation by function SJ·K. SJ·K ∈ (SVar ,→ Var ,→ L ,→ L) → SVar → Var → D nl ×nl   d1,1 . . . d1,nl  . ..  .. SJξ tr Ksk xl = di,j =  .. . .  i,j

dnl ,1

( where

di,j =

...

dnl ,nl

ξ tr (sk )( xl )(` j ) = ì

1

if

0

otherwise.

The duration state during evaluation of function f i is represented by a single duration vector instead of using two separate mappings, ϑc and ϑv . The translation is formalized by function dJ·K dJ·K ∈ ((L → D) × (Var → L → D)) → D (1+nv )nl   ϑc (`1 )   ..   .    ϑ (` )    c nl    ϑv ( x1 )(`1 )    ..     .  dJϑc , ϑv K =   ϑv ( x1 )(`n )  l     ..   .      ϑv ( xnv )(`1 )    ..     . ϑv ( xnv )(`nl ) The original reduction relation, −→ f , translated into the new setting, −→m , now reads as follows c; T; O; S | d, e −→m d0 , e0 . A reduction step reduces a environment vector, d, presenting the current program state, into a new environment vector, d0 . The evaluation environment is presented by a family of calculation cost vectors, c, a transfer cost matrix, T, a family of operation placement matrices, O, and a family of transfer placement matrices, S. Before we present the actual reduction rules, we introduce abbreviations for the zero matrix, Z, for the identity matrix, I, and for some block matrices we often make use of in the following. Figure 4.22 shows the short notations. The matrix Mc is used to project out the clock environment part of an environment vector, d. Accordingly, the matrix Mv is used to project out the arrival environment part of an environment vector, d.


0 .  .. 0  1   0 . . . 0 I  Z   Z . . . Z h Z h I

I=

Mc =

Mv =

M3,y = M4,y = Py,z =

M5,y =

... .. . ...

 0 ..  ∈ D nl ×nl . 0  0 ... 0 . .. .. . . ..    ∈ D nl ×nl .. ..  . . 0 ... 0 1 Z . . . Z ∈ D nl ×(1+nv )nl  I Z ... Z . .. .. . . ..  Z   ∈ D nv nl ×(1+nv )nl .. . . ..  . . . Z Z ... Z I i . . . Z I Z . . . Z ∈ D nl ×nv nl if y ≡ xi i i . . . I Z I . . . I ∈ D nl ×nv nl if y ≡ xi i ( I if yi ≡ x j ∧ zi ≡ xk P j,k ∈ D nv nl ×nv nl where P jk = j,k Z otherwise   Z .   ..    Z       I i ∈ D nv nl ×nl if y ≡ xi   Z     ..  .  

Z=

171

Z 

  I Z   M 6 =  .  ∈ D ( n v +1) n l × n l  ..  Z

Z I    M7 =  Z   .. . Z

Z Z .. . .. . ...

... ... .. . .. . Z

 Z Z  ..   .  ∈ D ( n v +1) n l × n v n l   Z I

Figure 4.22: Short notation for matrices

172


M-S-O P

dc dv i b e d0c d0v d0

= = = = = = = =

Mc d c = (c j ) j∈[nop ] Mv d O = (O j,k ) j∈[nop ],k∈[ns ] M3,y1 dv ⊕ . . . ⊕ M3,ym dv i ⊕ dc Cb C = diag(c j ) O j,k e M4 = diagB(M4,z ) M4 dv ⊕ M5 d0c M5 = M5,z M6 d0c ⊕ M7 d0v c; T; O; S | d, let z = op j sk (ym ) in e −→m d0 , e

Figure 4.23: Time-based reduction rules for ILS expression using matrices Given the arrival environment part of an environment vector, d, typically written as dv , a matrix M3,y is used to project out one particular variable, y. Conversely, a matrix M4,y transformed into a diagonal block matrix, diagB(M4,z ), is used to project all but one variable out of a vector representing an arrival environment, dv . A matrix Py,z permutes arrival environment vectors, dv , according to the parameter passing of function calls. If we call a function with formal parameters y with actual parameters z, the matrix Py,z will emulate the parameter passing on environment vectors. A matrix M5,y executes the converse operation of matrix M3,y . Instead of projecting out a variable, M5,y inserts durations into a environment vector at a certain position. The matrices M6 and M7 are used to perform the converse operations of Mc and Mv , respectively. The matrix M6 is used to expand a clock environment vector, dc , into a unified environment vector, d. Accordingly, the matrix M7 is used to expand an arrival environment vector, dv , back into a unified environment vector, d. The actual reduction rules specifying −→m are shown in Figures 4.23, 4.24 and 4.25. In case of executing an operation, (M-S-O P), we first use two matrices, Mc and Mv , to identify the clock part and the argument part of the unified state vector d. The durations vector stating when all arguments needed for the operation are available is expressed by i by summing up the durations of all arguments. The point of times where we begin with the operation on each location is expressed by b by additionally blocking until the clocks are available. The durations after the operation are expressed by e by sequentializing the different operation costs expressed by a diagonal matrix C. The clocks representing the state after the transition step, dc , are gained by selecting only those clocks where the actual operation is placed on by applying the right operation placement matrix, O j,k . The final duration vector d0v results by combining the durations for the resulting variable, z, with the durations for the remaining variables taken from the previous duration vector, dv . The overall state vector d0 is a linear combination of the new clocks d0c and the new argument durations d0v .


173

M-S-I F -T HEN

dc dv i b e d0c d0

= Mc d c = (c j ) j∈[nop ] = Mv d O = (O j,k ) j∈[nop ],k∈[ns ] = M3,y dv = i ⊕ dc = Cb C = diag(c1 ) = O1,k e = M6 d0c ⊕ M7 dv c; T; O; S | d, ifsk y then e1 else e2 −→m d0 , e1

M-S-I F -E LSE

dc dv i b e d0c d0

= Mc d c = (c j ) j∈[nop ] = Mv d O = (O j,k ) j∈[nop ],k∈[ns ] = M3,y dv = i ⊕ dc = Cb C = diag(c1 ) = O1,k e = M6 d0c ⊕ M7 dv c; T; O; S | d, ifsk y then e1 else e2 −→m d0 , e2

Figure 4.24: Time-based reduction rules for ILS expression using matrices The two transition rules (M-S-I F -T HEN) and (M-S-I F -E LSE) are analogous adaptations from the original transition rules for then and else case. In contrast to the operation rule, we now only select the conditional durations with M3,y before adding the operational cost of if. Because there is no resulting value in this case, we also omit the addition of the new clocks as new possible duration for the next arguments. The last transition rule, (M-S-T RANS), is the adaption of (T-S-T RANS), handling the transfer of values between locations. Besides applying selection matrices, we use a matrix, A, that both encodes the transfer of values between locations following the transfer placement and also adds up appropriate transfer duration using T. It composes by submatrices, Si , handling each variable to transfer individually. Accordingly, the reduction relation c; T; O; S | d, d e −→ f d0 , d e0 . expresses a state transition for programs using the new representation. The reduction rules are presented in Figure 4.26. The (M-S-E XP) rule carries over the reductions for expressions to the context of programs. The (M-S-J UMP) rule handles function calls. Besides applying selection matrices, we use a matrix, P, that shuffles around durations of the variable environment according to

174


M-S-T RANS

dc dv

= =

Mc d Mv d

S

=

(Sk,l )k∈[ns ],l ∈[nv ] (

A

=

d0v d0

= =

diagB( S1

...

S nv )

Sl

=

Sk,l • T

I Adv M6 dc ⊕ M7 d0v c; T; O; S | d, transsk x in e −→m d0 , e

if xl ∈ x otherwise

Figure 4.25: Time-based reduction rules for ILS expressions using matrices

M-S-E XP

c; T; O; S | d, e −→m d0 , e0 c; T; O; S | d, d e −→m d0 , d e0 M-S-J UMP

dc dv d0v d0

d i ≡ f i ( y i ) = ei = Mc d = Mv d = Pdv P = Py,z = M6 dc ⊕ M7 d0v c; T; O; S | d, d f is zi −→m d0 , d ei

Figure 4.26: Time-based reduction rules for ILS programs using matrices the passing of arguments of the function call. The following two lemmas state that reducing an expression or a program with contexts using −→ f stays in one-to-one correspondence to reducing their counterparts using vectors and −→m . They are proven by expanding various definitions and using basic dioid properties. Lemma 4.31

L, κ, τ, ξ op , ξ tr | ϑc , ϑv , e −→ f ϑc0 , ϑv0 , e0 iff

(cJκKop j ) j ; TJτK; (OJξ op Kop j sk ) j,k ; (SJξ tr Ksk xl )k,l | dJϑc , ϑv K, e −→m dJϑc0 , ϑv0 K, e0 .


175

Lemma 4.32

L, κ, τ, ξ op , ξ tr | ϑc , ϑv , p −→ f ϑc0 , ϑv0 , p0 iff

(cJκKop j ) j ; TJτK; (OJξ op Kop j sk ) j,k ; (SJξ tr Ksk xl )k,l | dJϑc , ϑv K, p −→m dJϑc0 , ϑv0 K, p0 .

4.3.3

Dynamic Semantics as Linear Transformation

The new representation of program contexts and program state as matrices and vectors over a dioid structure even let us go further. By perform some simple matrix calculations, we are able to reformulate the dynamic semantics again by spelling it out as a linear transformation on environment vectors. D The previous reduction relation, −→m , changes into a labeled transition system, −→l , reading as D c; T; O; S | e −→l e0

and D

c; T; O; S | d e −→l d e0 , respectively. The labeled transition system specifies program state transition from expression e to expression e0 . The state transition itself characterizing the state change is expressed by a transition matrix D. The evaluation context stays unchanged to the previous formulation. The revised reduction rules are shown in Figures 4.27 and 4.28. The following two lemmas capture the facts that reducing an expression or a program with contexts using −→m stays in one-to-one correspondence to making a transition with D

−→l and applying the transition matrix D instead. Lemma 4.33 c; T; O; S | d, e −→m d0 , e0 iff D c; T; O; S | e −→l e0

and

d0 = Dd.

176


L-S-O P

M3 c C O M4 M5 D

= = = = = = =

M3,y1 ⊕ . . . ⊕ M3,ym (c j ) j∈[nop ] diag(c j ) (O j,k ) j∈[nop ],k∈[ns ] diagB(M4,z ) M5,z (M6 ⊕ M7 M5 )O j,k C(M3 Mv ⊕ Mc ) ⊕ M7 M4 Mv D

c; T; O; S | let z = op j sk (ym ) in e −→l e L-S-I F -T HEN

M3 c C O D

= = = = =

M3,y (c j ) j∈[nop ] diag(c1 ) (O j,k ) j∈[nop ],k∈[ns ] M6 O1,k C(M3 Mv ⊕ Mc ) ⊕ M7 Mv D

c; T; O; S | ifsk y then e1 else e2 −→l e1 L-S-I F -E LSE

M3 c C O D

= = = = =

M3,y (c j ) j∈[nop ] diag(c1 ) (O j,k ) j∈[nop ],k∈[ns ] M6 O1,k C(M3 Mv ⊕ Mc ) ⊕ M7 Mv D

c; T; O; S | ifsk y then e1 else e2 −→l e2 L-S-T RANS

S

=

Sl

=

A D

= =

(S ) ( k,l k∈[ns ],l ∈[nv ] Sk,l • T if xl ∈ x I otherwise diagB( S1 . . . Snv ) M6 Mc ⊕ M7 AMv D

c; T; O; S | transsk x in e −→l e Figure 4.27: Time-based reduction rules for ILS expressions as transformations


177

L-S-E XP D c; T; O; S | e −→l e0 D

c; T; O; S | d e −→l d e0 L-S-J UMP

P D

d i ≡ f i ( y i ) = ei = Py,z = M6 Mc ⊕ M7 PMv D

c; T; O; S | d f is zi −→l d ei Figure 4.28: Time-based reduction rules for ILS programs as transformations Proof. We exemplarily show the transformations from (M-S-T RANS) to (T-S-T RANS). The other cases are proven accordingly. dc = Mc d

(4.315)

dv = Mv d

(4.316)

d0v = Adv

(4.317)

0

M6 dc ⊕ M7 d0v

(4.318)

d0 = M6 Mc d ⊕ M7 AMv d

(4.319)

d0 = (M6 Mc ⊕ M7 AMv )d

(4.320)

d = iff

iff

iff D = M6 Mc ⊕ M7 AMv

and

d0 = Dd.

(4.321)

Lemma 4.34 c; T; O; S | d, p −→m d0 , p0 iff D c; T; O; S | p −→l p0

and

d0 = Dd.

178


Program transitions are independent of actual program states. We can generate the set of all possible transition matrices representing all possible transitions by just looking at the finite set of all subexpressions of the program. If we consider a uniquely labeled program, p, we can uniquely identify each transition matrix by the labels found on its source and target expressions. The following lemmas formally state this property. Lemma 4.35 If program p is uniquely labeled, then there exists a family of transition matrices, Di,j , such that i,j

sj

e subexpression of p

iff

and

χ | ϑc , ϑv , s j e −→ f ϑc0 , ϑv0 , si e0

dJϑc0 , ϑv0 K = Di,j Jϑc , ϑv K.

Lemma 4.36 If program p is uniquely labeled, then there exists a family of transition matrices, Di,j , such that i,j

χ | ϑc , ϑv , s j p −→ f ϑc0 , ϑv0 , si p0

iff

dJϑc0 , ϑv0 K = Di,j Jϑc , ϑv K.

A duration matrix for a single transition step, D, tells us the durations for the clocks and each argument values from one function call to the next one—that is, they express the durations for a single computation step. Next, we combine all possible transition matrices possible occurring between all combinations of functions into one big block matrix characterizing the transition relation as a whole. The following result also shows, that it is possible to describe the timing behavior of program p by just one matrix, M. Theorem 4.5 If p is uniquely labeled then there exists a matrix, Mχ,p (or simply M), called transition matrix of p with respect to χ, such that χ | ϑc , ϑv , s j p −→ f ϑc0 , ϑv0 , si p0 iff where

dJϑc0 , ϑv0 K = Bi Mχ,p A j dJϑc , ϑv K. iT

Aj

=

h

Z

...

I

...

Z

Bi

=

h

Z

...

I

...

i Z .

j

i


179

Proof. By Lemma 4.36, there exists a family of matrices, Di,j

i,j

, expressing all possible

transitions as linear transformations. By choosing Mχ,p

=

(Mi,j )

 Di,j

if Di,j ∈ Di,j

where Mi,j

=

Z

=

i,j

Z otherwise   0 ... 0 . .  . . ...   .. 0 . . . 0 (n +1)n ×(n +1)n v v l l

the results follows by calculations in the matrix dioid using the dioid axioms.

4.3.4

Worst-Case Runtime

What we are really interested in is the combined duration of a complete execution of a program—that is, the evaluation of successive, maybe infinite, transition sequences. To this end, we continue with a definition for the notion of n-step worst-case durations of programs. χ,p

Definition 4.17 The duration dn is called n-step worst-case duration of program p with respect to a timed configuration, χ = (L, κ, τ, ξ op , ξ tr ), if χ,p

dn

=

M

{ϑc (`), ϑv ( x )(`) | ∃ϑc , ϑv , p0 s.th. χ | ϑc0 , ϑv0 , p −→nf ϑc , ϑv , p0 }

(4.322)

x,`

where ϑc0 (`) = 1 ϑv0 ( x )(`) = 1

∀` ∈ L

(4.323)

∀ x ∈ Var, ` ∈ L.

(4.324)

The n-step worst-case duration of a program p is defined as the maximal duration that could possibly occur after executing n steps of the program. There is an effective way to calculate the n-step worst-case duration of a program by resorting to the matrix representation of the program as the following lemma states.

180


Lemma 4.37 If program si p is uniquely labeled, then, for the n-step worst-case duration of p, it holds that χ,p

dn

= BMnχ,p Ai .

where

(4.325) T

 Ai

=

  0, . . . , 1, . . . , 1 . . . , 0 | {z }

B

=

[1, . . . , 1] .

i

Proof. By Lemma 4.5, the transition matrix, Mχ,p , expresses all transition steps as linear transformations. The result follows by simple calculations in the matrix dioid using the dioid axioms.

Worst-Case Mean Duration Because combining costs over infinite paths can lead to infinite durations, it does not make much sense to consider the n-step worst-case duration for looping programs. We instead consider mean durations over finite paths with respect to the length of their paths, that is, the duration of paths divided by the length of the paths. Using mean duration as characterization of programs allows us to talk about both terminating and also looping programs. There is also an obvious way to characterize the worst-case behavior of a program using the second characterization: we say, the worst-case behavior of a program is the maximal mean duration considering all paths possibly occurring. Before we actually look into a formal definition of the worst-case mean duration of programs, we first have to consider the matrix representation of the n-step worst-case durations of programs more closely. χ,p

Definition 4.18 A matrix representation BMn A of n-step worst-case duration dn of program p is called trim, if both • ∀i.∃k.(Mk A)i 6= 0, and • ∀ j.∃l.(BMl ) j 6= 0.

If we dealt with a trim matrix representation for the n-step worst-case duration function, we could be certain that each component of the transition matrix contributes to a possible worst-case durations, because all components are both accessible from all


181

starting states and also co-accessible leading to some final state. Transition matrices that are not trim may contain components that need not be taken into account. The canonical transition matrix of a program we obtain following the results of the previous section may not be trim, but a trim counterpart can always be found, as the following lemma states. Lemma 4.38 If program si p is uniquely labeled then, either χ,p

• dn •

= 0, or

χ,p dn

= BTnχ,p A, where BTnχ,p A is a trim matrix representation of the n-step worst-case duration of p.

We call the matrix Tχ,p , or simply T, the trim transition matrix of p.

BMn A,

Proof. By Lemma 4.37, a (possibly non-trim) matrix representation, for the n-step worst-case duration exists. The trim counterpart results by determining the accessible and the co-accessible nodes of the graph interpretation of M.

For the rest of this chapter, we concentrate on a particular dioid structure, the so called “(max, +) algebra” (R ∪ {−∞}, +, max, 0, −∞), to be able to calculate mean durations. We use the conventional division on reals to compute mean values. We write d1/n for the division of a real number d by natural number n to stay consistent with the rest of the dioid notation. The formal definition of the worst-case (or maximum) mean duration of a program then reads as follows. Definition 4.19 We call a duration ρχ,p worst-case mean duration of p with respect to a timed configuration, χ = (L, κ, τ, ξ op , ξ tr ), if ρχ,p = lim sup(dn )1/n χ,p

(4.326)

n

According to the (max,+) spectral theory [BCOQ92] [Gau95, Lemma 1], the following quantities equally describe the maximum cycle mean, ρ(A), of a matrix, A, over (max,+): ×n . The following quantities are equal: Lemma 4.39 Suppose A ∈ Rn(max, +)

(i) lim supk ||Ak ||1/k (ii)

L

1≤k ≤n (trace( A

k ))1/k .

182


Because the maximum cycle mean of a matrix over dioids is computable, we now have means to calculate the worst-case mean duration of a program with a fixed placement. Theorem 4.6 If si p is uniquely labeled, then, for the worst-case mean duration of p, it holds that either • ρχ,p = 0, or • ρχ,p = ρ(Tχ,p ), that is, it is equal to the maximum cycle mean of its trim transition matrix, ρ(Tχ,p ).

Proof. The existence of a trim transition matrix for p follows by Lemma 4.38. By calculations using the dioid axioms, we are able to apply Lemma 4.39.

4.3.5

Optimal Placements

The constraint-based placement analysis of Section 4.2.2 gives us a way to find all valid placements for a certain program. Our goal is to statically determine one particular valid placements that possibly shows a good runtime behavior. Because we do not want to rely on dynamic input data for our judgment, we use the machinery of Section 4.3 to estimate the worst-case run-time behavior of a program with respect to different placements. The following definition makes a connection between results from the constraintbased placement analysis and runtime placements. It tells us which placements are valid. Definition 4.20 (Valid Placements) We define the set of pairs of valid runtime placements, (ξ op , ξ tr ) ∈ V L,κ,τ,p , as follows V L,κ,τ,p =

{

(ξ op , ξ tr )

|

Ξop ; Ξtr ; ∆; Γ; α ` p ! α0 | C , σ |=Υ,Π,Σ,Θ C , and (L, κ, τ, ξ op , ξ tr ), ι |= Π; Σ; Θ; σΞop ; σΞtr

} V L,κ,τ,p ,

The sets of pairs of valid placements, depends on locations, L, calculation costs, κ, transfer costs, τ, and a program, p. A pair of placements, (ξ op , ξ tr ), is valid, if there exist availability assumptions and constraints generated by the constrained-based availability analysis, the constraints are solvable by an availability substitution, and the corresponding timed configuration correctly models the availability assumptions. With the definition of valid runtime placements in place, we are able to define the notion of optimal placements.

4.4. COMPLEXITY CONSIDERATIONS

183

Definition 4.21 (Optimal Placements) A pair of runtime placements (ξ op , ξ tr ), is called an optimal placement for a uniquely labeled program p with respect to locations L, operation costs κ and transfer costs τ if, 0

0

0 0 (ξ op , ξ tr ) ∈ V L,κ,τ,p and ρ(L,κ,τ,ξ op ,ξ tr ),p = min{ρ(L,κ,τ,ξ op ,ξ tr ),p | (ξ op , ξ tr ) ∈ V L,κ,τ,p }.

Optimal placements are such static placements with minimal maximum cycle mean. Fact 4.1 For each uniquely labeled program, p, and given locations, L, operation costs, κ, and transfer costs, τ, the sets of optimal placements of p is computable.

V L,κ,τ,p ,

Proof. The set of valid placements, is computable, because constraint generation for programs using constrained-based placement analysis (using a syntax-directed formulation), constraints solving (using Theorem 4.4), and also the validity test of configurations are all computable. Determining the worst-case mean duration for each program and placement is also computable by using a standard maximum cycle mean algorithm (Theorem 4.6). The computability of the set of minimal placements follows immediately.

4.4

Complexity Considerations

In this section, we briefly investigate the complexity of determining valid placements and determining optimal placements for uniquely labeled programs. We first look at programs that do no include effectful operations at all. The following lemma tells us, that, assuming that there are now effectful operations in our program, it is trivial to find an optimal placement. We just have to pick a placement such that the program does not actually perform any work. Because the program does not contain effectful operations, it is impossible to observe any results. Lemma 4.40 Let p be a uniquely labeled program, L be locations, κ be calculation cost, and τ be transfer costs. 0 , ξ 0 ) is an optimal placement of p, where If op 6∈ p, then (ξ op tr 0 ξ op (op)(s) = ∅,

(4.327)

0 ξ tr (op)(s)

(4.328)

= ∅.

Proof. We have to prove that

184


0 , ξ 0 ) is a valid placement, that is, ( ξ 0 , ξ 0 ) ∈ V L,κ,τ,p . (i) (ξ op tr op tr

Let be ι( A) = ∅, σ(α) = A∅ for one fixed, but arbitrary availability, A∅ ∈ Avail, ( A∅ , A∅ ) ∈ Θ, Σ(op) = A∅ , and Υ = ∅. Choose Π, Ξop , Ξtr arbitrarily. By definition of constraint-based version of the placement analysis, there exists a set of constraints, C ,assumptions ∆, Γ, and α, α0 , such that Ξop ; Ξtr ; ∆; Γ; α ` p ! α0 | C . By looking at the definition of solutions of constraints and of valid configurations, it is obvious that σ |=Υ,Π,Σ,Θ C ,

(4.329)

0 0 (L, κ, τ, ξ op , ξ tr ), ι |= Π; Σ; Θ; σΞop ; σΞtr .

(4.330)

and

0 0 0 0 ,ξ tr ),p 0 , ξ 0 ) is an optimal placement, that is ρ(L,κ,τ,ξ op (ii) (ξ op = min{ρ(L,κ,τ,ξ op ,ξ tr ),p | tr 0 , ξ 0 ) ∈ V L,κ,τ,p }. (ξ op tr 0

0

Simple calculations tell us that ρ(L,κ,τ,ξ op ,ξ tr ),p = 0. Hence, it obviously holds that 0

0

0

0

0 , ξ 0 ) ∈ V L,κ,τ,p }. ρ(L,κ,τ,ξ op ,ξ tr ),p = min{ρ(L,κ,τ,ξ op ,ξ tr ),p | (ξ op tr

As soon as we also allow effectful operations, it is much harder to determine optimal placements. In the remaining section, we show that the even the problem of determining valid placements of arbitrary programs with arbitrary configurations is a NP-complete problem. We first restate a well-known problem that is NP-complete. Definition 4.22 An instance of graph q-colorability consists of a graph G = (V, E), and the question whether vertices of G can be labeled with q colors such that adjacent vertices are assigned different colors. Or, given V = {1. . . . n} and E ⊆ V × V, we seek an assignment φ : V → {1, . . . , q}, such that ∀(u, v) ∈ E, φ(u) 6= φ(v).

Fact 4.2 The problem of graph q-colorability is tractable for q ≤ 2 and NP-complete otherwise.

Proof. see e.g. [GJ90].

Lemma 4.41 Given locations L where |L| > 2, the problem of determining valid placements of programs, p, with respect to L is NP-complete.


185

Proof. We first prove that the problem is NP-hard by giving a polynomial-time Karpreduction [ACG+ 99] from the problem of solving the g-colorability of graphs to the determination of the existence of valid placements for ILS programs. Let G = (V, E) be a graph with vertices V = {v1 , . . . , vn }, edges E ⊆ V × V and g, g > 2, the number of colors allowed to use to color the graph, G. For the given problem instance of g-colorability, we consider a program configuration, L g , κ, τ, p, with • sets of locations, L g = {1, . . . , g}, • operations costs, κ, and transfer costs, τ, and the corresponding canonical mapping ι, such that we correctly model the corresponding availability configuration of single locations without session state specified in Example 4.2, (N , Υ, Π, Σ, Θ), and • a program, p, constructed as follows. For an edge (vi , v j ), we consider the following two expression context Ci,j [·] ≡ let x 0j = opsi,j ( xi ) in 0 transsi,j x 0j in 00

000

ifsi,j x0 then f si,j ( x0 , x1 , . . . , xi , . . . , x 0j , . . . , xn ) else [·] Di,j [·] ≡ Ci,j [Cj,i [·]] For the graph, G = (V, {(vi1 , v j1 ), . . . (vie , v je )}), we construct the following program: p≡ f ( x0 , x1 , . . . , xn ) = Di1 ,j1 [ Di2 ,j2 [. . . [ Die ,je [halt]]]] let s0 = pfuns0 () in let s1 = pfuns1 () in .. . let sn = pfunsn () in f s n +1 ( s 0 , s 1 , . . . , s n ) For a given G, it is obviously possible to construct p in polynomial time. Informally, why does this program considered under the given operation costs and transfer costs do the job? Due to the specific transfer characteristics of Example 4.2, it is now impossible to just select transfer operations as noops. We now have to find a placement that solves the given graph problem.

186


For a placement, (ξ op , ξ tr ), for L g , κ, τ, p, to be valid, the following conditions must hold: Ξop ; Ξtr ; ∆; Γ; α ` p ! α0 | C ,

(4.331)


(4.332)

(L, κ, τ, ξ op , ξ tr ), ι |= Π; Σ; Θ; σΞop ; σΞtr .

(4.333)

By choosing injective availability placements and injective availability assumptions, Ξop , Ξtr , ∆, Γ, with codomains equals to subsets from the set of location set variables LSVar, and, Ξop (op)(si,j ) = αi,j 0 Ξtr (si,j )

=

(4.334)

0 00 (αi,j , αi,j )

(4.335)

α,α0

∆( f ) = αi −−→ 0

(4.336)

the judgments for the constraint-based analysis of Section 4.2.2 tell us, how the generated set of constraints for (4.331) must look like. Hence,

C ≡ C 0 , Ci1 ,j1 , C j1 ,i1 , . . . , Cie ,je , C je ,ie

(4.337)


(4.338)

(L, κ, τ, ξ op , ξ tr ), ι |= Π; Σ; Θ; σΞop ; σΞtr .

(4.339)

C0

where represent constraints generated for the initial expression, and Ci,j represent constraints generated for each program context Ci,j . By inspecting the constraint generation rules, we know that the constraints must look as follows, σ |=Υ,Π,Σ,Θ C 0 , Ci1 ,j1 , C j1 ,i1 , . . . , Cie ,je , C je ,ie

(4.340)

(L, κ, τ, ξ op , ξ tr ), ι |= Π; Σ; Θ; σΞop ; σΞtr ,

(4.341)

0 0 00 00 0 Ci,j ≡ {αi ≤ αi,j , op αi,j , single αi,j , αi,j ≤ αi,j , αi,j ; αi,j , αi,j ≤ α j }, Ci,j

(4.342)

where

C j,i ≡ {α j ≤ α j,i , op α j,i , single α j,i , α j,i ≤

α0j,i , α0j,i

;

α00j,i , α00j,i

≤

0 αi }, C j,i

(4.343)

Because σ is a (Υ; Π, Σ, Θ)-solution for each constraint of C , we further know that for each program context, Di,j [·], it must hold that, Π ` σαi ≤ σαi,j , Π ` Σ(op) ≤ σαi,j , Υ ` σαi,j , Π ` σαi,j ≤

0 σαi,j ,Θ

`

0 σαi,j

00 σαi,j ,Π

(4.344)

≤ σα j ,

(4.345)

Π ` σα j ≤ σα j,i , Π ` Σ(op) ≤ σα j,i , Υ ` σα j,i ,

(4.346)

and

Π ` σα j,i ≤

σα0j,i , Θ

`

σα0j,i

;

;

σα00j,i , Π

`

00 σαi,j

`

σα00j,i

≤ σαi ,

(4.347)


187

and, additionally, 0 , C0 σ |=Υ,Π,Σ,Θ C 0 , Ci,j j,i

(4.348)

0 , C 0 only consist of subtyping constraints. C 0 , Ci,j j,i

(4.349)

By using the definition of the availability configuration of example 4.2 and the definition of the validity of the configuration, we then know, that, for each program context, Di,j [·], it must hold that, ι(σαi ) ⊇ ι(σαi,j ), ι( N{1,...,g} ) ⊇ ι(σαi,j ), |ι(σαi,j )| = 1,

(4.350)

0 ι(σαi,j ) ⊇ ι(σαi,j ), 0 00 1, ι(σαi,j ) 6= ι(σαi,j , 00 ι(σαi,j ) ⊇ ι(σα j ),

(4.351)

ι(σα j ) ⊇ ι(σα j,i ), ι( N{1,...,g} ) ⊇ ι(σα j,i ), |ι(σα j,i )| = 1,

(4.354)

ι(σα j,i ) ⊇ ι(σα0j,i ),

(4.355)

0 00 |ι(σαi,j )| = |ι(σαi,j )| =

(4.352) (4.353)

and

|ι(σα0j,i )|

ι(σα00j,i ,

(4.356)

⊇ ι(σαi ),

(4.357)

0 , C0 σ |=Υ,Π,Σ,Θ C 0 , Ci,j j,i

(4.358)

only consist of subtyping constraints.

(4.359)

=

|ι(σα00j,i )|

=

1, ι(σα0j,i ) ι(σα00j,i )

6=

and, additionally,

C

0

0 , C0 , Ci,j j,i

By simplifying the subset relationships, we see that the existence of a valid placement is equivalent to having, for each program context, Di,j [·], the following subset relationships between sets of locations,

|ι(σαi )| = |ι(σα j )| = 1, ι(σαi ) 6= ι(σα j )

(4.360)

0 , C0 σ |=Υ,Π,Σ,Θ C 0 , Ci,j j,i

(4.361)

0 , C 0 only consist of subtyping constraints. C 0 , Ci,j j,i

(4.362)

and, additionally,

Because a solution, σ, solving (4.361), can always easily be extended to a solution also solving the additional subtyping constraints, we easily see that the existence of a valid placement such that (4.361) holds, corresponds to the existence of a g-coloring of the graph G by interpreting an assignment of αi as a coloring for vi . The problem is trivially in NP. We can solve the problem of determining valid placements of a program p nondeterministically in polynomial time by

188


(i) generating the set of constraints expressing all the solutions using the constraintbased variant of the availability system, and (ii) afterwards running the constraint simplification procedure on the set of constraints nondeterministically guessing the “right” availability assignments on each simplification step. Both steps work in polynomial time, because the generation of constraints works by induction over the syntax of the program, and because the depth of the deduction tree is also polynomially bound.

4.5

Implementation Considerations

In this section, we briefly sketch a first, prototypical implementation of an algorithm that, given calculation costs and transfer costs, determines optimal placements for a program. Our deduction system specifying constraint solving can be considered as formalization of a so-called chronological backtracking solver to determine satisfiability of finite domain constraint satisfaction problems (CSPs) (see for example Chapter 3 of [MS98]). We have implemented a prototype of the placement analysis for ILS . In particular, the solutions of the placement analysis inference are encoded as boolean satisfaction problem. The non-deterministic calculation of valid placements is implemented with a back-tracking algorithm. The evaluation of solutions—that is, valid placements—is performed by using a fast implementation for solving the maximum cycle mean problem—an adaption of Howard’s algorithm to solve Markov decision processes to the maximum cycle mean problem [Das04]. Dasdan’s survey article presents empirical data that suggest that Howard’s algorithm has a quadratic running time with respect to the length of the input program when calculating the maximum cycle mean for one, fixed placement. The evaluation of a single solution is comparatively cheap, but enumerating all solutions of a placement problem potentially takes an exponential amount of time with respect to length of the input program. Our search algorithm tries to avoid unnecessary and duplicate computations. A consistency check at each choice point guarantees that the search is aborted a soon as the constraint set is not solvable anymore. By always using the best solution so far as a search bound and interleaving the search for an optimal placement with the search for the next solution, we only traverse the search tree at most once. For the sample set of small input programs we tested our implementation with, first approximations that are valid but not always optimal are found instantly. The algorithm we implemented is basically a variation of the backtracking integer optimizer of Marriott and Stuckey [MS98, Chapter 3, Figure 3.19].

4.6. RELATED WORK

4.6

189

Related Work

In this section, we discuss related work regarding the two main parts of this chapter, modeling semantics of concurrent systems in a timed manner, and solving a static analyses with constraints. Timed Dynamic Semantics There is a rich set of work extending process algebras and automata with a (real) timed semantics. Domains in such setting are often absolute time values or time intervals (see for example Chen’s thesis about Timed CCS [Che92]). Hybrid system, typically modeled by hybrid automata, also allow to model dynamic behavior, in particular timing, by considering time constraints on transitions [Hen96]. Other approaches are more particular targeted on adding time constraints to automata using real-time valued clocks. Examples are Alur and Dill’s timed automata [AD94] or, similar, Lynch’s MMT timed automata [LV91] [Lyn96, Chapter 23]. We choose to work with a model similar to weighted automata [KS86]. In particular, we use the semirings of dioid structures and (max,+) as time domain, because we are only interested in worst-case running times. The theory of dioids and of the (max,+) algebra are studied extensively in the context of discrete event systems [BCOQ92]. The original theory of discrete event systems considers timed petri nets to model concurrent computations. Gaubert extends non-deterministic finite automata with duration functions over (max, +)—which he calls dater functions—and studies their behavior [Gau95]. Our model is mainly influenced by Gaubert’s work. A notion of weak bisimulation for max/plus automata has been developed recently by Buchholz and Kemper [BK03]. Static Analyses by Constraint Solving Most static analyses can be solved by reducing analysis problems to constraint satisfaction problems. Standard examples are type inference algorithms for simply typed languages typically using unification [BS01], or calculi with subtyping solved using subtyping constraints [SAN+ 02]. Glynn et al. show that binding time analysis can be formulated as boolean constraint problems [GSSS01]. The constraint language of our constraint-based version of location analysis can be considered as a restricted form of set constraints [AW92]. In general, constraint problems are instances of constrain programming [MS98, Apt05]. General methodologies to characterize and to examine the tractability of constraint-satisfaction problems are considered, among others, by Cooper et al. [CCJ94], and Jeavons and Cooper [JC95].

190


Chapter 5

Conclusion This dissertation shows that it is possible to develop multi-tier applications in sequential style. The process of modularizing the program code into components targeted for the specific tiers can be handed over to a (semi-)automatic tool. Using the results of the thesis guarantees that, firstly, such a tool is able to find an optimal placement with respect to the cost model specified in the thesis, and, secondly, that the transformations performed by such a tool are able to generate a distributed system which provably has the same semantics as the original sequential program.

5.1

Review

Chapter 3 lays the theoretical foundations for the transformation scheme of such a tool. There is previous work that formulates similar transformation schemes performing code splitting for programs with additional code annotations, such as program slicing [Tip95] or secure program partitioning [ZZNM02], although none of these come up with a formally defined translation, let alone a proof of correctness of the transformation. The main results from the formal treatment of our transformation scheme are listed in the following. • The starting point of our considerations is a novel intermediate language, ILB , which can be seen as a variation of programs in A-normal form with operations annotated with locations. The semantics of the language is specified by a dynamic and a static semantics. The type system specifying the static semantics features monomorphic types with monomorphic type annotations representing sets of locations. The type system is proven to be correct with respect to the operationally specified dynamic semantics. The annotation part of our type system can be read as a novel form of static program analysis that allows to specify dependencies between values located on different locations. • The target of the first translation step is another calculus, ILC , that is statically 191

192

CHAPTER 5. CONCLUSION typed. This calculus additionally features communication primitives to transfer values between locations. The dynamic semantics is specified similarly to the semantics of the original calculus. The static semantics uses session types to type heterogeneous communication patterns of channels. Besides a calculus specified by Vasconcelos et al. [VRG04], the ILC calculus and its two successors are the only functional programming calculi that allow us to assign static types to programs with heterogeneous communication channels. Analogous to ILB we have proven a type correctness result for ILC . Equational rules for ILC are the basis for the second program transformation step of the whole scheme. The equational rules of ILC preserve the observable I/O behavior of programs which is proven using the proof method of bisimulations. The equational rules are the first formal treatment of a conversion from programs using a message-based communication into programs using a bidirectional stream-based communication in a statically typed setting.

• We have further specified two subsequent calculi, ILD and ILC . The ILD calculus extends the previous calculus, ILC , by explicit ports. The ILE calculus additionally features concurrency and directed communication primitives. For both calculi, the dynamic semantics and the static semantics are specified using operational techniques and a static type system using session types, respectively. A type-based translation states how to translate ILD programs into ILE programs pinning down the actual splitting of sequential programs into distributed counterparts. Chapter 4 introduces the machinery to implement an inference system for the placement analysis which may be used to automatically assign code fragments to locations. Besides the program, such an assignment is assumed as input for the transformation scheme. Our cost model for ILS programs allows to estimate the worst-case behavior of programs with a fixed placement, leading to an efficient method of evaluating valid placements and of determining an optimal choice. In the following, we list the main results from the development of the inference system. • We developed an intermediate language, called ILS , that allows to express the timing behavior of programs running on different locations and communicating via channels. Running times are abstractly modeled by elements of a dioid structure. We specified a placement analysis for ILS analogous to the specification of the placement analysis for ILB and showed that the specification is correct with respect to the timed-based semantics. • We formulated a constraint-based variant of the placement analysis for ILS and showed that the constraint-based version is sound and complete with respect to its logical counterpart. The constraint language we used resembles set constraints, yet the language shows special constraints for transfer possibilities and singleton sets. • We specified a constraint solver for our constraint language, we showed that the solver is sound and complete, and we proved that finding all solutions for arbitrary constraint problems is a NP-complete problem.

5.2. FUTURE WORK

193

• We demonstrated that the dynamic semantics of ILS expressing the timing behavior of programs can be reformulated as linear transformations over dioid vectors. The reformulation opens up a way to effectively compute the worst-case mean duration of a program using a specific placement. By using this approach we introduced a means to determine optimal placements for ILS programs given fixed cost functions.

5.2

Future Work

Some problems have been left open in this thesis; other parts of the thesis suggest new topics for further research. In this section, we will first discuss possible extensions of our source language, ILB , and the accompanying transformation scheme. Subsequently, we will identify possible ways of how to restrict our model to possibly make the computation of optimal placements for a program more tractable. Using a Richer Intermediate Language The starting point of our transformation scheme in chapter 3, the ILB calculus, is an intermediate language with monomorphic types and monomorphic type annotations. Working with a statically typed programming language with monomorphic types makes some programs untypeable, yet they nevertheless do not go wrong. There are two main approaches to compile programming languages with polymorphic types. One way is to “eliminate variable types” at compile time by performing all polymorphic instantiations at compile time [Mor95]. This technique is also known as monomorphisation and has proven to be feasible in a variety of compilers for different languages, such as Mark Jones’s implementation of Gofer [Jon94], a whole-program, optimizing Standard ML compiler, MLTon [Wee06], or various compilers for the C++ programming language. Our intermediate language could be used as a target language for such a compilation scheme. Unfortunately, the elimination approach has some drawbacks that make additionally integrating polymorphic types worth to consider as well. The technique of monomorphisation often leads to unnecessary code duplication, makes it hard to compile modules separately, and disallows the integration of first-class polymorphic definitions. Then again, we do not believe that an extension of ILB with a (restricted form) of type polymorphism would lead to insurmountable obstacles. An interesting research question that could arise in such a setting is whether the operational proof methods we used are applicable in the polymorphic setting as well. Similar results for the polymorphic pi-calculus are already known [SW01]. The placement analysis and its accompanying inference scheme should be transferable to a system with polymorphic types because we considered the deduction, the inference and the evaluations of annotations detached from the type language. Another, orthogonal, way to possibly extend our initial language is to augment the annotation language of our system. Effect polymorphism, besides effect subtyping, is

194

CHAPTER 5. CONCLUSION

known for additionally improving the precision of type system with annotated types, particularly in conjunction with higher-order functions [TB00]. Operational proof techniques and type inference schemes for similar extensions in the realm of region-based memory management exist, respectively [Hel04, TT97]. In our system, the determination of optimal placements works by computing worst-case mean durations for all “ground instances” of the inferred constraint set representing all valid placements. Extending the system to polymorphic effects would amount to adding some sort of quantifier elimination scheme to obtain ground instances, and to later solve and test these. Multi-tier applications often also have to deal with secure information. The flow of secure information is similar in nature to the value dependency between different locations which our calculi feature. Calculi such as Abadi et al.’s DCC exist that capture general notions of dependencies including dependencies between secure information and access control [ABHR99, Aba06]. It would be worthwhile to investigate whether our system could be integrated into DCC as well, resulting in a unified system for multi-tier programming that features locality and security. If such an integration is possible, it will remain to be seen whether our transformation scheme could be carried over to other instances of DCC as well. Our thesis formally proves the correctness of the equational rules on ILC programs specifying the extension of channel scoping stated in Section 3.2.6 using bisimulation. For simplification rules and program transformations specified later in the course of this thesis only partial correctness results such as type preservation are stated. Strictly speaking, we formally do not know whether the other transformation steps are also fully semantic preserving. Yet, we are confident that similar results could be stated for the remaining cases as well, using identical proof methods. Determining Placements The complexity considerations we employed for the determination procedure of valid placements in Section 4.4 showed that finding optimal placements in general is a hard problem. It could be worthwhile to consider special cases of the general problem and investigate whether better decision procedures exist for those. Possible ways to restrict the general case are: • The result in Section 4.4 does not make a claim about finding placements for two locations only. Other solving procedures may exist that tractably find placements for programs annotated with two distinct locations only. • It might be possible to impose further restrictions on the cost function and the transfer function in such a way that an ordering on both, locations and costs, can be set up. Tractable algorithms to solve constraints on ordered domains exist [JC95]. • For some NP-complete problems, efficient approximation algorithms exist that find optimal solutions up to a certain level of approximation [ACG+ 99].

5.3. CLOSING WORDS

195

The evaluation of valid placements considers worst-case mean duration of a program with a fixed placement. By working with dioid structures, the ⊕ operation always takes the maximum running time of two alternative execution paths leading to a worstcase consideration. By employing different probabilities for different alternatives (that is, to add probabilities expressing the likelihood of taking the different branches of conditionals) instead, it would be straightforward to compute the average running time of a program with a fixed placement assuming a Bernoulli distribution of random events. The problem to compute the average running time then amounts to solving a finite Markov chain instead of determining the maximum cycle mean of the transition matrix [Gau95]. Possible probabilities could be obtained by user annotations or sampling data obtained by profiling. Realizing our Approach In general, the mapping to tiers will be a multi-language issue that requires an additional translation step from the target language of the framework to the desired target languages. Alternatively, a heterogeneous framework might be considered if the analysis is directly applies to different languages. Depending on the underlying communication protocol of the target platform, a tunneling scheme might be devised that tunnels the bidirectional channel communication of ILE over another communication protocol. Promising approaches exist in the special area of web applications that map similar communication patterns over HTTP. Examples are web applications using client-based AJAX frameworks1 , the prototypical Links programming language2 , or the HOP programming language [SGL06].

5.3

Closing Words

Our thesis formulates the basic building blocks for a compiler of a multi-tier programming language. Such a language would allow programmers to write multi-tier applications in sequential style avoiding typical bugs that are inherent in the process of manually writing concurrent programs that are divided into different components. In sum, this dissertation solves the problem of how to automatically infer a distribution for a sequentially written multi-tier application to the different tiers. This thesis furthermore shows the original program can be successfully translated into a distributed application that is targeted for multiple tiers.

1 AJAX is a collective term for using JavaScript-based web browser extensions to asynchronously communicate XML data between the client side and the web server using the HTTP inside a web application. 2 http://groups.inf.ed.ac.uk/links/

196

CHAPTER 5. CONCLUSION

Bibliography [Aba06]

Mart´ın Abadi. Access control in a core calculus of dependency. In Julia Lawall, editor, Proceedings International Conference on Functional Programming 2006, pages 263–273, Portland, Oregon, USA, September 2006. ACM Press, New York.

[ABHR99]

Mart´ın Abadi, Anindya Banerjee, Nevin Heintze, and Jon Riecke. A core calculus of dependency. In Alexander Aiken, editor, Proceedings of the 26th ACM SIGPLAN Symposium on Principles of Programming Languages, pages 147–160, San Antonio, Texas, USA, January 1999. ACM Press.

[ACG+ 99]

Giorgio Ausiello, Pierluigi Crescenzi, Giorgio Gambosi, Viggo Kann, Alberto Marchetti-Spaccamela, and Marco Protasi. Complexity and Approximation: Combinatorial Optimization Problems and Their Approximability Properties. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 1999.

[AD94]

Rajeev Alur and David L. Dill. A theory of timed automata. Theoretical Computer Science, 126(2):183–235, 1994.

´ [AEI01]

´ ´ ´ Luca Aceto, Zoltán Esik, and Anna Ingolfsd ottir. Axiomatizing tropical semirings. In Furio Honsell and Marino Miculan, editors, FoSSaCS, number 2030 in Lecture Notes in Computer Science, pages 42–56, Genova, Italy, 2001. Springer-Verlag.

[Apt05]

Krzysztof R. Apt. Explaining constraint programming. In Aart Middeldorp, Vincent van Oostrom, Femke van Raamsdonk, and Roel C. de Vrijer, editors, Processes, Terms and Cycles, volume 3838 of Lecture Notes in Computer Science, pages 55–69. Springer, 2005.

[AW92]

Alexander Aiken and Edward L. Wimmers. Solving systems of set constraints. In Proceedings of the 1992 IEEE Symposium on Logic in Computer Science. IEEE Computer Society Press, June 1992.

[Bar84]

Hendrik P. Barendregt. The Lambda Calculus — Its Syntax and Semantics. North-Holland, 1984. 197

198

BIBLIOGRAPHY

[BB92]

Gérard Berry and Gérard Boudol. The chemical abstract machine. Theoretical Computer Science, 96, 1992.

[BCOQ92]

François Baccelli, Guy Cohen, Geert Jan Olsder, and Jean-Pierre Quadrat. Synchronization and Linearity, An Algebra for Discrete Event Systems. John Wiley and Sons, 1992.

[BFL98]

Michele Boreale, Cédric Fournet, and Cosimo Laneve. Bisimulations in the join calculus. In Proceedings of the IFIP Working Conference on Programming Concepts, Methods and Calculi (PROCOMET). Chapman and Hall, June 1998.

[BK03]

Peter Buchholz and Peter Kemper. Weak bisimulation for (max/+) automata and related models. Journal of Automata, Languages and Combinatorics, 8(2):187–218, 2003.

[BKHB06]

Nick Benton, Andrew Kennedy, Martin Hofmann, and Lennart Beringer. Reading, writing and relations: Towards extensional semantics for effect analyses. In Proceeding of the Fourth Asian Symposium on Programming Languages and Systems (APLAS 2006), volume 4270 of Lecture Notes in Computer Science, pages 114–130. Springer-Verlag, November 2006.

[BS01]

Franz Baader and Wayne Snyder. Unification theory. In Alan Robinson and Andrei Voronkov, editors, Handbook of Automated Reasoning, volume I, chapter 8, pages 445–534. Elsevier Science, 2001.

[CCJ94]

Martin C. Cooper, David A. Cohen, and Peter G. Jeavons. Characterising tractable constraints. Artificial Intelligence, 65(2):347–361, 1994.

[CF58]

Haskell Curry and Robert Feys. Combinatory Logic, volume I. North Holland, 1958.

[CG95]

Roy L. Crole and Andrew D. Gordon. A sound metalogical semantics for input/output effects. In Computer Science Logic, CSL’94, volume 933 of Lecture Notes in Computer Science, pages 339–353, Kazimierz, Poland, 1995. Springer-Verlag.

[CG99]

Roy L. Crole and Andrew D. Gordon. Relating operational and denotational semantics for input/output effects. Mathematical Structures in Computer Science, 9(2):125–158, 1999.

[Che92]

Liang Chen. Timed Processes: Models, Axioms and Decidabilty. PhD thesis, University of Edinburgh, 1992.

[Chu40]

Alonzo Church. A formulation of the simple theory of types. Journal of Symbolic Logic, 5:56–68, 1940.

BIBLIOGRAPHY [Das04]

199

Ali Dasdan. Experimental analysis of the fastest optimum cycle ratio and mean algorithms. ACM Transactions on Design Automation of Electronic Systems, 9(4):385–418, 2004.

[DCMYD06] Mariangiola Dezani-Ciancaglini, Dimitris Mostrous, Nobuko Yoshida, and Sophia Drossopoulou. Session Types for Object-Oriented Languages. In Dave Thomas, editor, ECOOP’06, volume 4067 of LNCS, pages 328–352. Springer-Verlag, 2006. [Den76]

Dorothy Denning. A lattice model of secure information flow. Communications of the ACM, 19(5):236–242, 1976.

[ECM99]

ECMAScript Language Specification. http://www.ecma-international. org/publications/files/ECMA-ST/Ecma-262.pdf, December 1999. ECMA International, ECMA-262, 3rd edition.

[FSDF93]

Cormac Flanagan, Amr Sabry, Bruce F. Duba, and Matthias Felleisen. The essence of compiling with continuations. In Proceedings of the 1993 on Programming Language Design and Implementation, pages 237–247, Albuquerque, New Mexico, June 1993.

[Gau95]

Stéphane Gaubert. Performance evaluation of (max,+) automata. IEEE Transactions On Automatic Control, 40(12), December 1995.

[Gay93]

Simon J. Gay. A sort inference algorithm for the polyadic pi-calculus. In Proceedings of the 1993 ACM SIGPLAN Symposium on Principles of Programming Languages, pages 429–438, Charleston, South Carolina, January 1993. ACM Press.

[GH99]

Simon J. Gay and Malcolm J. Hole. Types and subtypes for client-server interactions. In S. Doaitse Swierstra, editor, Proceedings of the 1999 European Symposium on Programming, number 1576 in Lecture Notes in Computer Science, pages 74–90, Amsterdam, The Netherlands, April 1999. SpringerVerlag.

[Gir72]

Jean-Yves Girard. Interpretation Fonctionnelle et Elimination des Coupures dans l’Arithmetique d’Ordre Superieur. PhD thesis, University of Paris VII, 1972.

[GJ90]

Michael R. Garey and David S. Johnson. Computers and Intractability; A Guide to the Theory of NP-Completeness. W. H. Freeman & Co., New York, NY, USA, 1990.

[GLP02]

Vladimir Gapeyev, Michael Y. Levin, and Benjamin C. Pierce. Recursive subtying revealed. Journal of Functional Programming, 12(6):511–548, November 2002.

200

BIBLIOGRAPHY

[Gor99]

Andrew D. Gordon. Bisimilarity as a theory of functional programming. Theoretical Computer Science, 228(1-2):5–47, October 1999.

[GP98]

Andrew D. Gordon and Andrew Pitts, editors. Higher Order Operational Techniques in Semantics (HOOTS), Publications of the Newton Institute. Cambridge University Press, 1998.

[GP99]

Andrew D. Gordon and Andrew Pitts, editors. Higher Order Operational Techniques in Semantics (HOOTS), volume 26 of Electronic Notes in Theoretical Computer Science, Paris, France, October 1999. Elsevier Science.

[GSSS01]

Kevin Glynn, Peter Stuckey, Martin Sulzmann, and Harald Søndergaard. Boolean constraints for binding-time analysis. In Programs as Data Objects II, number 2053 in Lecture Notes in Computer Science, pages 39–62, Aarhus, Denmark, May 2001. Springer-Verlag.

[GVR03]

´ Simon J. Gay, Vasco Vasconcelos, and Antonio Ravara. Session types for inter-process communication. Technical Report TR-2003-133, Department of Computing Science, University of Glasgow, 2003.

[Har94]

Robert Harper. A simplified account of polymorphic references. Information Processing Letters, 51(4):201–206, August 1994. See also note [Har96].

[Har96]

Robert Harper. A note on: “A Simplified Account of Polymorphic References”. Information Processing Letters, 57(1):15–16, January 1996. See also [Har94].

[Hel04]

Simon Helsen. Bisimilarity for the region calculus. Higher-Order and Symbolic Computation, 17(4):347–394, 2004.

[Hen91]

Fritz Henglein. Efficient type inference for higher-order binding-time analysis. In Hughes [Hug91], pages 448–472.

[Hen96]

Thomas A. Henzinger. The theory of hybrid automata. In Proceedings of the 11th Annual Symposium on Logic in Computer Science, pages 278–292. IEEE Computer Society Press, 1996.

[Hoa85]

C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, Englewood Cliffs, New Jersey, 1985.

[HR98]

Nevin Heintze and Jon G. Riecke. The SLam calculus: Programming with security and integrity. In Luca Cardelli, editor, Proceedings 25th Annual ACM Symposium on Principles of Programming Languages, pages 365–377, San Diego, CA, USA, January 1998. ACM Press.

BIBLIOGRAPHY

201

[Hug91]

John Hughes, editor. Functional Programming Languages and Computer Architecture, number 523 in Lecture Notes in Computer Science, Cambridge, MA, 1991. Springer-Verlag.

[HVK98]

Kohei Honda, Vasco Thudichum Vasconcelos, and Makoto Kubo. Language primitives and type discipline for structured communication-based programming. In Chris Hankin, editor, Proceedings 7th European Symposium on Programming, number 1381 in Lecture Notes in Computer Science, pages 122–138, Lisbon, Portugal, April 1998. Springer-Verlag.

[JC95]

Peter G. Jeavons and Martin C. Cooper. Tractable constraints on ordered domains. Artificial Intelligence, 79(2):327–339, 1995.

[Jef00]

Alan Jeffrey, editor. ACM Workshop on Higher Order Operational Techniques in Semantics (HOOTS), volume 41(3) of Electronic Notes in Theoretical Computer Science, Montreal, Canada, September 2000. Elsevier Science.

[JGS93]

Neil Jones, Carsten Gomard, and Peter Sestoft. Partial Evaluation and Automatic Program Generation. Prentice-Hall, 1993.

[Joh85]

Thomas Johnsson. Lambda lifting: Transforming programs to recursive equations. In Proc. Functional Programming Languages and Computer Architecture 1985, number 201 in Lecture Notes in Computer Science. SpringerVerlag, 1985.

[Jon94]

Mark P. Jones. The implementation of the Gofer functional programming system. Research Report YALEU/DCS/RR-1030, Department of Computer Science, Yale University, New Haven, Connecticut, May 1994.

[KPT96]

Naoki Kobayashi, Benjamin C. Pierce, and David N. Turner. Linearity and the pi-calculus. In POPL ’96: Proceedings of the 23rd ACM SIGPLAN-SIGACT symposium on Principles of programming languages, pages 358–371, New York, NY, USA, 1996. ACM Press.

[Kri03]

Jens Krinke. Context-sensitive slicing of concurrent programs. In Proceedings 9th European Software Engineering Conference, pages 178–187. ACM Press, 2003.

[KS86]

Werner Kuich and Arto Salomaa. Semirings, automata, languages. SpringerVerlag, London, UK, 1986.

[Ler06]

Xavier Leroy. The Objective Caml system release 3.09.3 , Documentation and user’s manual. INRIA, France, September 2006. http://pauillac.inria. fr/caml.

202

BIBLIOGRAPHY

[LV91]

Nancy A. Lynch and Frits W. Vaandrager. Forward and backward simulations for timing-based systems. In Jaco W. de Bakker, Kees Huizing, Willem P. de Roever, and Grzegorz Rozenberg, editors, Proceedings REX Workshop on Real-Time: Theory in Practice, volume 600 of Lecture Notes in Computer Science, pages 397–446, Mook, The Netherlands, June 1991. SpringerVerlag, Berlin, Germany, 1992.

[Lyn96]

Nancy A. Lynch. Distributed Algorithms. Morgan Kaufmann, 1996.

[MC88]

Albert Meyer and Stravos Cosmadakis. Semantical paradigms: notes for an invited lecture. In Proceedings of the 1988 IEEE Symposium on Logic in Computer Science, pages 236–253, Edinburgh, Scotland, 1988.

[Mil78]

Robin Milner. A theory of type polymorphism in programming. Journal of Computer and System Sciences, 17:348–375, 1978.

[Mil89]

Robin Milner. Communication and Concurrency. Prentice Hall, Englewood Cliffs, NJ, 1989.

[Mil90]

Robin Milner. Functions as processes. In Proceedings of the seventeenth international colloquium on Automata, languages and programming, pages 167– 180, New York, NY, USA, 1990. Springer-Verlag New York, Inc.

[Mit96]

John Mitchell. Foundations for Programming Languages. MIT Press, 1996.

[Mog91]

Eugenio Moggi. Notions of computations and monads. Information and Computation, 93:55–92, 1991.

[Mor68]

James Morris. Lambda Calculus Models of Programming Languages. PhD thesis, MIT Press, December 1968.

[Mor95]

Greg Morrisett. Compiling with Types. PhD thesis, Carnegie Mellon University, Pittsburgh, Pennsylvania, December 1995. CMU-CS95-226.

[MPW92]

Robin Milner, Joachim Parrow, and David Walker. A calculus of mobile processes, Part I + II. Information and Control, 100(1):1–77, 1992.

[MS98]

Kim Marriott and Peter J. Stuckey. Programming with constraints: an introduction. MIT Press, 1998.

[NBB+ 60]

Peter Naur, J. W. Backus, F. L. Bauer, J. Green, C. Katz, J. McCarthy, A. J. Perlis, H. Rutishauser, K. Samelson, B. Vauquois, J. H. Wegstein, A. van Wijngaarden, and M. Woodger. Report on the algorithmic language ALGOL 60. Communications of the ACM, 3(5):299–314, 1960.

[Nie93]

Oscar Nierstrasz. Regular types for active objects. In Proceedings OOPSLA ’93, pages 1–15, October 1993.

BIBLIOGRAPHY

203

[NN92]

Hanne Riis Nielson and Flemming Nielson. Semantics with Applications. John Wiley & Sons, 1992.

[NNH99]

Flemming Nielson, Hanne Riis Nielson, and Chris Hankin. Principles of Program Analysis. Springer Verlag, 1999.

[NR00]

Mangala Gowri Nanda and S. Ramesh. Slicing concurrent programs. In Proceedings of the International Symposium on Software Testing and Analysis, pages 180–190. ACM Press, 2000.

[NT04a]

Matthias Neubauer and Peter Thiemann. An implementation of session types. In Bharat Jayaraman, editor, Proc. Practical Aspects of Declarative Languages: 6th International Symposium, PADL 2004, number 3057 in Lecture Notes in Computer Science, pages 56–70, Dallas, Texas, USA, June 2004. Springer-Verlag.

[NT04b]

Matthias Neubauer and Peter Thiemann. Protocol specialization. In WeiNgan Chin, editor, Proc. Programming Languages and Systems, Second Asian Symposium, APLAS 2004, number 3302 in Lecture Notes in Computer Science, Taipei, Taiwan, October 2004. Springer-Verlag.

[NT05]

Matthias Neubauer and Peter Thiemann. From sequential programs to multi-tier applications by program transformation. In Mart´ın Abadi, editor, Proceedings 32nd Annual ACM Symposium on Principles of Programming Languages, pages 221–232, Long Beach, CA, USA, January 2005. ACM Press.

[Pie02]

Benjamin C. Pierce. Types and Programming Languages. MIT Press, 2002.

[Pit97]

Andrew Pitts. Operationally-based theories of program equivalence. In Andrew M. Pitts and Peter Dybjer, editors, Semantics and Logics of Computation, pages 241–298. Cambridge University Press, 1997.

[PL91]

Simon L. Peyton Jones and John Launchbury. Unboxed values as first class citizens in a non-strict functional language. In Hughes [Hug91], pages 636–666.

[Plo75]

Gordon Plotkin. Call-by-name, call-by-value and the λ-calculus. Theoretical Computer Science, 1:125–159, 1975.

[PS93]

Benjamin C. Pierce and Davide Sangiorgi. Typing and subtyping for mobile processes. In Proceedings of the 8th Annual IEEE Symposium on Logic in Computer Science, pages 376–385. IEEE Computer Society Press, 1993.

[Rey72]

John C. Reynolds. Definitional interpreters for higher-order programming languages. In ACM Annual Conference, pages 717–740, July 1972.

204

BIBLIOGRAPHY

[San96]

Davide Sangiorgi. A theory of bisimulation for the pi-calculus. Acta Informatica, 33:69–97, 1996.

[SAN+ 02]

Zhendong Su, Alexander Aiken, Joachim Niehren, Tim Priesnitz, and Ralf Treinen. The first-order theory of subtyping constraints. In John Mitchell, editor, Proceedings 29th Annual ACM Symposium on Principles of Programming Languages, pages 203–216, Portland, OR, USA, January 2002. ACM Press.

[SGL06]

Manuel Serrano, Erick Gallesio, and Florian Loitsch. HOP, a language for programming the Web 2.0. In Proceedings of the First Dynamic Languages Symposium, Portland, OR, USA, October 2006.

[SS01]

Andrei Sabelfeld and David Sands. A per model of secure information flow in sequential programs. Higher-Order and Symbolic Computation, 14(1):59–91, March 2001.

[Ste78]

Guy L. Steele. Rabbit: a compiler for Scheme. Technical Report AI-TR-474, MIT, Cambridge, MA, 1978.

[Ste90]

W. Richard Stevens. UNIX Network Programming. Prentice Hall Software Series, 1990.

[SW01]

Davide Sangiorgi and David Walker. The π-calculus. A Theory of Mobile Processes. Cambridge Universtity Press, 2001.

[TB00]

Mads Tofte and Lars Birkedal. Unification and polymorphism in region inference. In Proof, Language, and Interaction: Essays in Honour of Robin Milner, pages 389–424. MIT Press, 2000.

[THK94]

Kaku Takeuchi, Kohei Honda, and Makoto Kubo. An interaction-based language and its typing system. In C. Halatsis, D. Maritsas, G. Philokyprou, and S. Theodoridis, editors, 6th International PARLE Conference (Athens, Greece, July 1994), volume 817 of LNCS, pages 398–413. Springer, 1994.

[Tip95]

Frank Tip. A survey of program slicing techniques. J. Programming Languages, 3(3):121–189, 1995.

[TJ95]

Yan Mei Tang and Pierre Jouvelot. Effect systems with subtyping. In William Scherlis, editor, Proceedings ACM SIGPLAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation PEPM ’95, pages 45–53, La Jolla, CA, USA, June 1995. ACM Press.

[TT97]

Mads Tofte and Jean-Pierre Talpin. Region-based memory management. Information and Computation, 132(2):109–176, 1997.

BIBLIOGRAPHY

205

[VH93]

Vasco T. Vasconcelos and Kohei Honda. Principal typing schemes in a polyadic pi-calculus. In Eike Best, editor, CONCUR, volume 715 of Lecture Notes in Computer Science, pages 524–538. Springer-Verlag, 1993.

[VRG04]

´ Vasco T. Vasconcelos, Antonio Ravara, and Simon J. Gay. Typechecking a multithreaded functional language with session types. In Proceedings of the International Conference on Concurrency Theory (CONCUR)., number 3170 in Lecture Notes in Computer Science, pages 497–511. Springer-Verlag, 2004.

[VRG06]

´ Vasco T. Vasconcelos, Antonio Ravara, and Simon J. Gay. Type checking a multithreaded functional language with session types. Theoretical Computer Science, 368(1-2):64–87, 2006.

[VS97]

Dennis Volpano and Geoffrey Smith. A type-based approach to program security. In Michel Bidoit and Max Dauchet, editors, TAPSOFT’97: Theory and Practice of Software Development, number 1214 in Lecture Notes in Computer Science, pages 607–621, Lille, France, April 1997. Springer-Verlag.

[Wal05]

David Walker. Substructural type systems. In Benjamin C. Pierce, editor, Advanced Topics in Types and Programming Languages, chapter 1. MIT Press, 2005.

[WCM00]

David Walker, Carl Crary, and Greg Morrisett. Typed memory management via static capabilities. ACM Transactions on Programming Languages and Systems, 22(4):701–771, July 2000.

[Wee06]

Stephen Weeks. Whole-program compilation in MLton. In ML ’06: Proceedings of the 2006 workshop on ML, pages 1–1, New York, NY, USA, 2006. ACM Press.

[WF94]

Andrew Wright and Matthias Felleisen. A syntactic approach to type soundness. Information and Computation, 115(1):38–94, 1994.

[Win93]

Glynn Winskel. The Formal Semantics of Programming Languages: An Introduction. MIT Press, 1993.

[ZCMZ03]

Lantian Zheng, Stephen Chong, Andrew C. Myers, and Steve Zdancewic. Using replication and partitioning to build secure distributed systems. In Proceedings of the 2003 IEEE Symposium on Security and Privacy, page 236. IEEE Computer Society, 2003.

[ZM01]

Steve Zdancewic and Andrew C. Myers. Secure information flow and cps. In David Sands, editor, Proceedings of the 2001 European Symposium on Programming, Lecture Notes in Computer Science, pages 46–61, Genova, Italy, April 2001. Springer-Verlag.

206

BIBLIOGRAPHY

[ZM02]

Steve Zdancewic and Andrew C. Myers. Secure information flow via linear continuations. Higher-Order and Symbolic Computation, 15(2-3):209–234, 2002.

[ZZNM02]

Steve Zdancewic, Lantian Zheng, Nathaniel Nystrom, and Andrew C. Myers. Secure program partitioning. ACM Transactions on Computer Systems, 20(3):283–328, 2002.

Index P , 13 ∪, 13 ], 13 ∩, 13 −, 13 [n], 13 x, 13 R−1 , 13 R; S, 13 I A , 14 Rn , 14 →, 14 ,→, 14 dom, 14 f | X , 14 f \ X, 14 ≡, 16 t[t0/x], 16 e[·], 17 e[e0 ], 17 D , 17 ⊗, 17 ⊕, 17 1, 17 0, 17 M, 18 v, 18 •, 18 M T , 18 diag, 18 diagB, 18 −→, 20, 37, 53, 87, 93 ?i, 21

!i, 21 Ω, 21 dRe, 32, 75 [R], 32, 75 ≈, 32, 76 α −→, 38, 55, 88 ?i A , 38 !i A , 38 locs(α), 38 fv( p), 53 = ˆ , 71 R◦ , 74 >, 76 ≡s , 93 6, 139 99K, 139 , 139 single , 139 σC , 159 Z, 170 I, 170 A-normal form, 19 annotated types, 40, 57 arrival environment, 116 availability, 120 assignment, 126 assumption, 121 containment, 120 environment, 127 function —, 120 function — assumption, 121 operation placement, 120 signature, 120 207

208

INDEX singleton —, 120 substitution, 139 transfer opportunity, 120 transfer placement, 120

Barendregt’s variable convention, 16 base types, 23, 40, 57, 113 bisimulation, 76 c{l }, 52 calculation cost, 115 possibilities, 126 canonical forms lemma for the IL A calculus, 28 for the ILB calculus, 45 for the ILC calculus, 64 chain of sets of locations, 129 channel environments, 55 type environments, 57 channel introduction, 3, 8, 70 channel pooling, 3, 8, 71 client-server architecture, 1 clock environment, 116 locations, 127 close[ A;B] (c), 52 co-induction, 15 complete, 74 complete lattice, 14 completeness of constraint solving, 166 of constraint-based availabilities, 157 connect, 93 constraints, 139 conditional subtyping —, 159 in solved form, 159 contexts, 17 derivation tree, 21 dioids, 17

domain restriction, 14 F-closed, 15 F-dense, 15 first-order function types, 113 fixed point, 15 function environments, 112 functions, 14 extension of a partial —, 14 generating —, 15 monotone —, 14 partial —, 14 graph q-colorability, 184 greatest lower bound, 14 halt observation, 21 halt, 19 head point, 111 induction, 15 inversion lemma for the IL A calculus, 25 for the ILB calculus, 41 for the ILC calculus, 62 iterated substitutions, 74 Knaster-Tarski theorem, 15 least upper bound, 14 listen, 10, 93 location set variable, 120 locations, 115 matrix, 18 block —, 18 diagonal —, 18 transpose of a —, 18 trim –, 180 max-plus algebra, 18 multi-tier applications, 1 n-step worst-case durations, 179 negative domain restriction, 14

INDEX newPort, 9, 87 observations, 38 op A , 36 op, 20 open[ A;B] , 52 open extension, 74 operation placement, 115 operation types, 113 partially ordered set, 14 pfun, 20 placement optimal —, 183 valid —, 182 placement analysis, 119 placement inference, 2, 6 port floating, 3, 9, 91 port introduction, 3, 9, 90 port types, 90 preservation of constraint solving, 162 progress of constraint solving, 164 of the IL A calculus, 30 of the ILB calculus, 49 of the ILC calculus, 68 read, 20, 38 rec, 19 recv, 93 relations antisymmetric —, 14 bisimilarity —, 76 bisimilarity —-, 32 equivalence —, 14 partial order —, 14 preorder —, 14 reflexive —, 14 similarity —, 76 symmetric —, 14 transitive —, 14 rules

209 A-S-D EF, 126 A-S-EO P, 123 A-S-F UN, 124 A-S-H ALT, 125 A-S-I F, 125 A-S-J UMP, 125 A-S-L ET, 125 A-S-P LACE, 123 A-S-PO P, 123 A-S-P ROG, 126 A-S-S INGLE, 121 A-S-T RANS, 125 A-S-T RANSFER -B ASIC, 122 A-S-VAR, 124 C-S-D EF, 144 C-S-EO P, 141 C-S-F UN, 142 C-S-H ALT, 143 C-S-I F, 143 C-S-J UMP, 143 C-S-L ET, 143 C-S-P LACE, 141 C-S-PO P, 141 C-S-P ROG, 144 C-S-T RANS, 143 C-S-T RANSFER, 141 C-S-VAR, 142 C OMP -C-E MPTY, 74 C OMP -C-E XT, 74 CS-S-C OND -1, 161 CS-S-C OND -2, 161 CS-S-E Q, 161 CS-S-O P, 161 CS-S-S INGLE -1, 161 CS-S-S INGLE -2, 161 CS-S-S UB -1, 161 CS-S-S UB -2, 161 CS-S-S UB -3, 161 CS-S-S UB -4, 161 CS-S-T RANS -1, 161 CS-S-T RANS -2, 161 CS-S-T RANS -3, 161

210

INDEX D-A-A PP, 21 D-A-H ALT, 22 D-A-I F -FALSE, 21 D-A-I F -T RUE, 21 D-A-L ET-R EAD, 22 D-A-L ET-VAL, 21 D-A-L ET-W RITE, 22 D-A-PF UN, 21 D-A-S KIP, 22 D-B-A PP, 38 D-B-H ALT, 39 D-B-I F -FALSE, 38 D-B-I F -T RUE, 38 D-B-L ET-R EAD, 39 D-B-L ET-VAL, 38 D-B-L ET-W RITE, 39 D-B-PF UN, 38 D-B-S KIP, 39 D-B-T RANS, 38 D-C-A PP, 54 D-C-C HAN -A PP, 54 D-C-C TX, 54 D-C-C TX -2, 56 D-C-H ALT, 56 D-C-I F -FALSE, 54 D-C-I F -T RUE, 54 D-C-L ET-C LOSE, 54 D-C-L ET-O PEN, 54 D-C-L ET-R EAD, 56 D-C-L ET-T RANS, 54 D-C-L ET-VAL, 54 D-C-L ET-W RITE, 56 D-C-PF UN, 54 D-C-S KIP, 56 D-D-C HAN -A PP, 88 D-D-C TX, 88 D-D-C TX -2, 89 D-D-H ALT, 89 D-D-L ET-C LOSE, 88 D-D-L ET-N EWPORT, 88 D-D-L ET-O PEN, 88 D-D-L ET-R EAD, 89

D-D-L ET-T RANS, 88 D-D-L ET-W RITE, 89 D-D-S KIP, 89 D-E-A PP, 98 D-E-C HAN -A PP, 98 D-E-C TX -1, 98 D-E-C TX -2, 98 D-E-C TX -3, 99 D-E-H ALT, 99 D-E-I F -FALSE, 98 D-E-I F -T RUE, 98 D-E-L ET-C LOSE -C LOSE, 98 D-E-L ET-L ISTEN -C ONNECT, 98 D-E-L ET-R EAD, 99 D-E-L ET-S END -R ECV, 98 D-E-L ET-VAL, 98 D-E-L ET-W RITE, 99 D-E-PAR, 98 D-E-PF UN, 98 D-E-S KIP, 98, 99 D-E-S TRUCT-A SSOC, 97 D-E-S TRUCT-C OMM, 97 D-E-S TRUCT-R EFL, 97 E Q -C-B ETA, 72 E Q -C-C LOSE -O PEN, 72 E Q -C-I F -O PEN, 72 E Q -C-L ET-O PEN, 72 E Q -C-O PEN -C LOSE, 72 E Q -C-O PEN -O PEN, 72 E Q -C-R EFL, 72 E Q -C-S YMM, 72 E Q -C-T RANS, 72 E Q -D-B ETA, 95 E Q -D-L ET-N EW P ORT, 95 E Q -D-N EW P ORT, 95 E Q -D-R EFL, 95 E Q -D-S YMM, 95 E Q -D-T RANS, 95 L-S-E XP, 177 L-S-I F -E LSE, 176 L-S-I F -T HEN, 176 L-S-J UMP, 177

INDEX L-S-O P, 176 L-S-T RANS, 176 M-S-E XP, 174 M-S-I F -E LSE, 173 M-S-I F -T HEN, 173 M-S-J UMP, 174 M-S-O P, 172 M-S-T RANS, 174 S-A-D EF -E XPR, 24 S-A-D EF -O P, 24 S-A-D EF -PF UN, 24 S-A-E XPR -C ONST, 23 S-A-E XPR -R EC, 23 S-A-E XPR -VAR, 23 S-A-P ROG -A PP, 25 S-A-P ROG -H ALT, 25 S-A-P ROG -I F, 25 S-A-P ROG -L ET, 25 S-B-D EF -E XPR, 42 S-B-D EF -O P, 42 S-B-D EF -PF UN, 42 S-B-D EF -T RANS, 42 S-B-E XPR -C ONST, 41 S-B-E XPR -R EC, 41 S-B-E XPR -S UB, 41 S-B-E XPR -VAR, 41 S-B-P ROG -A PP, 43 S-B-P ROG -H ALT, 43 S-B-P ROG -I F, 43 S-B-P ROG -L ET, 43 S-C-D EF -CA PP, 61 S-C-D EF -C LOSE -1, 61 S-C-D EF -C LOSE -2, 61 S-C-D EF -E XPR, 61 S-C-D EF -OP, 61 S-C-D EF -O PEN, 61 S-C-D EF -P FUN, 61 S-C-D EF -T RANS -1, 61 S-C-D EF -T RANS -2, 61 S-C-E XPR -C ONST, 60 S-C-E XPR -R EC, 60 S-C-E XPR -S UB, 60

211 S-C-E XPR -VAR, 60 S-C-P ROG, 62 S-C-P ROG -A PP, 62 S-C-P ROG -C HAN, 62 S-C-P ROG -H ALT, 62 S-C-P ROG -I F, 62 S-C-P ROG -L ET, 62 S-D-D EF -CA PP, 92 S-D-D EF -C LOSE -1, 92 S-D-D EF -C LOSE -2, 92 S-D-D EF -E XPR, 91 S-D-D EF -N EW P ORT, 92 S-D-D EF -OP, 91 S-D-D EF -O PEN, 92 S-D-D EF -P FUN, 91 S-D-D EF -T RANS -1, 92 S-D-D EF -T RANS -2, 92 S-D-P ORT-S UB, 90 S-D-P ORT-VAR, 90 S-D-P ROG, 93 S-D-P ROG -C HAN, 93 S-E-D EF -CA PP, 100 S-E-D EF -C LOSE, 100 S-E-D EF -C ONNECT, 100 S-E-D EF -E XPR, 100 S-E-D EF -L ISTEN, 100 S-E-D EF -OP, 100 S-E-D EF -P FUN, 100 S-E-D EF -R ECV, 100 S-E-D EF -S END, 100 S-E-D EF -S KIP, 100 S-E-P ROG, 101 S-E-P ROG -A LT, 101 S-E-P ROG -A PP, 101 S-E-P ROG -C HAN, 101 S-E-P ROG -H ALT, 101 S-E-P ROG -I F, 101 S-E-P ROG -L ET, 101 S-S-D EF, 114 S-S-F UN, 114 S-S-H ALT, 114 S-S-I F, 114

212

INDEX S-S-J UMP, 114 S-S-L ET, 114 S-S-O P, 114 S-S-P ROG, 114 S-S-T RANS, 114 S-S-VAR, 114 S UB -B-B ASE, 40 S UB -B-F UN, 40 S UB -C-B ASE, 60 S UB -C-C HAN, 59 S UB -C-E MPTY, 59 S UB -C-F UN, 60 S UB -C-G UARD, 59 S UB -C-N U -1, 59 S UB -C-N U -2, 59 S UB -C-S EQ -1, 59 S UB -C-S EQ -2, 59 S UB -D-P ORT, 90 S UB -S-B ASIC, 121 S UB -S-R EFL, 121 S UB -S-T RANS, 121 T-S-E XP, 118 T-S-I F -E LSE, 117 T-S-I F -T HEN, 117 T-S-J UMP, 118 T-S-O P, 117 T-S-T RANS, 117

send, 93 sequential calculus, 2, 4 session types, 55, 57 mirrored —, 57 set of locations, 120 signature, 112 simulation, 76 skip, 93 soundness of constraint solving, 166 of constraint-based availabilities, 148 splitting transformation, 3, 9, 97 substitution lemma for the IL A calculus, 25

for the ILB calculus, 42 for the ILC calculus, 63 substitutions, 16 termination of constraint solving, 166 three-tier architecture, 1 timed configurations, 115 timed environments, 116 trans[ A;B] , 36 trans, 6 transfer costs, 115 placements, 115 possibilities, 126 type environments, 23, 40, 57, 90 type preservation of the IL A calculus, 28 of the ILB calculus, 46 of the ILC calculus, 64 of the ILS calculus, 131 typed relation, 73 typed relations closed —, 74 well-formed —, 73 types, 23 uniquely labeled programs, 168 used port names, 87 validity of timed configurations, 127 of timed environments, 128 value environments, 112 vector, 18 worst-case mean duration, 181 write, 20, 38

Multi-Tier Programming - CiteSeerX

Multi-Tier Programming - CiteSeerX

Suggest Documents

Multitier Wireless Communications - CiteSeerX

Multitier Wireless Communications - CiteSeerX

1 Multitier programming in Hop - ACM Digital Library

VLSI Architectures for Multitier Wireless Systems Joseph ... - CiteSeerX

Design and Evaluation of a Metropolitan Area Multitier ... - CiteSeerX

Multitier biometric template security using ... - Semantic Scholar

Service Differentiation in Multitier Data Centers

programming - CiteSeerX

Analytic Modeling of Multitier Internet Applications - LASS

Tutorial On Strategic Programming Across Programming ... - CiteSeerX

Tutorial On Strategic Programming Across Programming ... - CiteSeerX

Making Programming Synonymous with Programming for ... - CiteSeerX

Tutorial On Strategic Programming Across Programming ... - CiteSeerX

Making Programming Synonymous with Programming for ... - CiteSeerX

Pair Programming in Introductory Programming Labs - CiteSeerX

Co-Logic Programming: Extending Logic Programming ... - CiteSeerX

End User Programming / Informal Programming - CiteSeerX

Multitier Portal Architecture for Thin- and Thick-client Neutron ... - Ogce

Programming Network Architectures - CiteSeerX

Participatory Programming - CiteSeerX

Distributed eXtreme Programming - CiteSeerX

Programming Network Architectures - CiteSeerX

Constraint Programming - CiteSeerX

Programming Shorthands - CiteSeerX