orem
It should be clear that agent configurations are syntactically valid configu- rations. In fact, we will permit agent configurations to be used directly as configurations. Strictly, we should provide an injective function which explic- itly denotes this identification. Instead, we will leave the injection implicit.
CHAPTER 4. DYNAMIC OOMPA
B.4.1 p282
Theorem 4.3.1 For a configuration K,
WF(K)⇒K ≡ Flatten(K)
B.4.4 p288
Lemma 4.3.2 For a configuration K and a renaming ρ,
Flatten(Kρ)≡α Flatten(K)ρ
The Theorems 4.3.3 and 4.3.4 showthat the relationship with the flat- tened form is preserved across ≡α and ≡.
B.4.5 p292
Theorem 4.3.3 Say K1 andK2 are configurations such that K1 ≡α K2 and
Flatten(K1) = g1{Φ∆11
Flatten(K2) = g2{Φ∆22
Then, for some renaming, ρ, such that FN(g2{∆Φ22)Change(ρ) we have
Φ2ρ= Φ1 ∆2ρ= ∆1 g2ρ≡α g1
B.4.6 p296
Theorem 4.3.4 Say K1 and K2 are configurations such that K1
≡K2 and
Flatten(K1) = g1{Φ∆11
Flatten(K2) = g2{Φ∆22
Then, for some renaming, ρ, such that FN(g2{Φ∆)Change(ρ) we have
Φ2ρ= Φ1 ∆2ρ= ∆1 g2ρ
≡α g1
We nowgive the main result of this section. Intuitively, it can be thought to say that the internal transitions of a configuration system are realisable within the operational semantics of the agent-based dynamic system. This is a desirable result. Because the agent-based dynamic system was designed
CHAPTER 4. DYNAMIC OOMPA
to embody our intentions of howwe wish Oompa programs to behave, the result gives us confidence that configuration systems also behave as we would wish.
There are other results we could show that would bring to light different aspects of the relationship between the dynamic systems. We chose this result as the minimum to reassure us of the compatibility of the semantics.
One notable feature of the theorem is that we flatten the scoped config- urations, K1{Φ∅ and K2{Φ∅, rather than just the configurations, K1 and K2.
This is necessary to ensure all the typing information available in Φ gets rolled into the flattened form.
B.4.11 p308
Theorem 4.3.5 Say K1 and K2 are configurations such that
Γ,ΦK1 // K2
and
Flatten(K1{Φ∅) = g1{Φ∆11
Flatten(K2{Φ∅) = g2{Φ∆22
then there is some renaming ρ such that FN(g2{∆Φ22)Change(ρ) and
Γg1{Φ∆11−→g2ρ{Φ∆22ρρ
4.4
Summary
This chapter set out to define Oompa’s two dynamic systems: the agent- based dynamic system and the configuration-based dynamic system. For both of these dynamic system we presented the material in four sections. First we defined their syntax, then some theory of renaming, then their equivalence relations and lastly their semantics. For the configuration-based
CHAPTER 4. DYNAMIC OOMPA
dynamic system, we also defined a semantic equivalence called weak bisimu- lation. The relationship between the two dynamic systems was established by defining an algorithm which converts configurations into structurally equiv- alent agent configurations. We proved a simulation-like result which shows that this relationship is preserved, up to renaming, by internal actions.
Chapter 5
The Type System
Oompa’s operational semantics are defined purely in terms of pattern match- ing. No limitations are put on the behaviour of an agent beyond syntactic conformance to some rule. As a consequence of this, the operational seman- tics permit behaviours we never intended and do not want. Many of these behaviours fall into two groups.
An example of the first kind would be an attempt to perform an invocation on an object which lacks a matching method. No rules of the operational semantics will apply to the agent responsible, so we can think of this be- haviour as “stalling” the agent. This is an example of a “round hole/square peg” error — a square peg will not fit in a round hole.
An example of the second kind would be the assignment of a temperature reading in Fahrenheit to an attribute intended for temperature in centigrade. Some rule of the operational semantic applies to the agent responsible but the transition leads to the propagation of bad data. This belongs to what we might call a “round hole/finger” error — a finger may actually fit in a round hole but it may then get stuck or electrocuted.
CHAPTER 5. THE TYPE SYSTEM
tem [Car96]. Oompa’s types, whose syntax we defined in Chapter 3, provide a way of describing the appropriate values a context can accept and the ap- propriate contexts a value can be used in. The role of Oompa’s type system is to identify and exclude those programs whose behaviour will be inconsistent with their types. We will require a definition set to be syntactically correct, well-formed and type safe.
One important aspect of our type system is that it supports subtyping. The types we give to objects are interface types, which describe the names of the methods the objects must support and the arity of their input and output parameter lists. When we mark a context with an interface type, we require that any object used in the context support the methods described by that type. But an object which supports those methodsand others should also be acceptable. Rather than requiring exact matches between the types of values and contexts, we allow a certain flexibility in the type system. This is formalised by a relation between types called subtyping. For Oompa, we define subtyping relations on both interface types and channel types.
Another important feature of our type system is that it supports recur- sive types. There are two different reasons why we need them. Firstly, without recursive types our channels would be limited to carrying “simpler” values. This severely limits a system’s dynamic behaviour, as the most com- plex channel types in the system would form a static infrastructure — there would be no channels which could be used to transmit their names. Sec- ondly, in an object-oriented system, interface types will often be found to be inter-referential. For example, the following two interfaces have this interde- pendency:
CHAPTER 5. THE TYPE SYSTEM
interface A interface B
{ {
m?()!<d:B> m?()!<d:A>
} }
Consequently, we acknowledge these two kinds of recursion in our type system. The first kind we consider to be explicit recursion and results from the use of therecoperator. For example, the typerect.ChanLong, twhich advertises its recursivity. The second kind we consider to be implicit recur- sion and results from the use of class or interface names in a type position, as in the interface A, above.
Oompa’s type system is based upon [PS93a], which considers a type sys- tem for theπ-calculus, and [AC91], which gives a type system with subtyping and recursive types for the lambda calculus. The work we present in this chapter has been published as a technical report [TB02].
In Section 5.1, we formally define type violations and give the rules of the type safety system. Section 5.2 gives the semantics of types, which are a kind of infinite tree. We define Oompa’s subtyping system in Section 5.3. In Section 5.4, we prove that a type safe program never commits a type violation. We compare our type system with some others in Section 5.5 and Section 5.6 summarises the chapter.
5.1
Typing, Type Violations and Type Safety
In this section, we give the typing system, define the notion of type violation and give the type safety system.
CHAPTER 5. THE TYPE SYSTEM
Table 5.1: Rules of the Typing System TAS-ASS: Γ,Φ∪ {v:T} v:T
TAS-LIT: Γ,ΦP:P
where P is a literal of primitive type P.
TAS-SUB: Γ T1 ≤T2 Γ,Φv:T1 Γ,Φv:T2