Multiple-Dispatching Based on Automata

Transcription

1 Published in: Journal of Theory and Practice of Object Systems, 1(1), Multiple-Dispatching ased on Automata Weimin Chen GMD-IPSI Integrated Publication and Information Systems Institute Dolivostr Darmstadt, Germany Volker Turau 1 Fachhochschule Giessen-Friedberg Fachbereich MND Wilhelm-Leuschner-Str Friedberg, Germany turau@courbet.fh-friedberg.de Abstract. We present a novel technique for multiple-dispatching. In object-oriented programming languages, multiple-dispatching provides increased expressive power over single-dispatching by guiding method lookup using the values of all arguments instead of the receiver only. However, the efficient implementation for multiple-dispatching is still critical with regard to its success as a standard. There have been several time-efficient dispatching techniques proposed, but they are very space consuming. In this paper, we transform multiple-dispatching into a lookup automaton problem. Analysis and experiments show that our approach is space-efficient while providing the same time-efficiency as the previous known techniques. Moreover, we present a technique to further minimize the space-complexity of lookup automata. Key Words. Multi-methods, Multiple-dispatching, Lookup, Type hierarchy, Automata. 1 Introduction Today most programming languages are based on the notion of types. A data type consists of a representation and a set of operations which can be applied to instances of the types. In many object-oriented languages, types are organized in a hierarchy and a subtype relation is defined over them. One important feature of this subtype relation is subtype polymorphism [9]: if A is a subtype of, then every instance of A is also an instance of. Operations on the instances of types are defined by generic functions, where a generic function corresponds to a set of methods and the methods 1. This work was done during a visit at the International Computer Science Institute, erkeley, California. 1

2 define the type-specific behavior of the generic function. In the presence of subtype polymorphism, method selection must occur at run time. In many object-oriented languages, a message (function invocation) is sent to a distinguished receiver object, and the run time type of the receiver determines the method that is actually invoked by the message. The arguments of the message are passed on to the invoked method but do not participate in the method dispatching. For example, in C++ we can define a virtual function of the form area(shape) 2 which is dynamically dispatched based on the actual type of shape supplied with the function invocation. However, one cannot write a virtual function of the form display- On(shape,device) which is dynamically dispatched based on actual types of both shape and device. To surmount these limitations, some object-oriented languages include a more powerful form of function invocation in which all arguments of a method can participate in the method dispatching (method lookup), i.e. a method is dynamically dispatched based on the types of all arguments. These methods are called multi-methods. The dispatching for multi-methods is called multiple-dispatching [10]. Perhaps the most-known languages that support multi-methods are CLOS [8] and one of its predecessors CommonLoops [7]. One fundamental issue for multi-methods is the efficient mechanism for method lookup. Efficient implementation of multi-methods is critical with regard to its success as a standard. There have been several time-efficient lookup mechanisms proposed [13, 15, 18]. However, by far the largest problem is that all these structures for dynamic lookup may lead to combinatorial explosion, which leads to a space problem. In this paper we present a new dispatching technique. Dispatching is simulated by lookup automata. If n is the arity of the function invocation, then the time-complexity of the method lookup is O(n). The main contribution of our approach compared to the other lookup mechanisms is that it is space-efficient while providing the same time-efficiency as [13, 15, 18]. Moreover, we present a technique to further minimize the space-complexity of the lookup automata. The results presented are intended to provide an optimized dispatching technique for totally ordered multi-methods, supported by e.g. CLOS [8] and CommonLoops [7]. The organization of this paper is as follows. We state the basic concepts concerning the type hierarchy and multi-methods in section 2. Section 3 describes the overall approach in order to have an intuitive idea of our approach. The formal statement of the problem is presented in section 4. Next, sections 5 and 6 discuss algorithms to construct and simulate the lookup automata respectively. In section 7, we discuss a technique to further optimize the lookup automata. Experiments and space evaluation are discussed in section 8. We discuss the related work in section 9. Finally section 10 summarizes the results of our work. 2. The first argument can be understood as the method receiver. 2

3 2 asic Concepts 2.1 Type Hierarchy and Type Ordering In the discussion that follows, we represent the subtype relation by in a finite type hierarchy. Also we denote A if A and A, in this case we say that A is subtype of, or is supertype of A. Particularly, we use A to denote that A is the direct subtype of. Since relation defines a partial order, such a system of types forms a directed acyclic graph (DAG). There is a path from A to if and only if A. In the rest of this paper, a type A in is denoted by A, and S, a subset of types in, is denoted by S. Now we consider the following type ordering in : A local type ordering for a type C is a total order C over C and its supertypes such that if C A, then C C A. Furthermore, if C, and D E then D C E. This rule is recursively applied. The only constraint of local type ordering is that there should not exist two types A and which have a common subtype such that D A E and E D hold for some types D and E. If this restriction is satisfied, is called consistent. In this paper, we always assume that is consistent; A global type ordering is a partial order, such that if A, then A, and if there is a type C such that C D and C E, then either D E or E D. CLOS [8] is an example of a language that uses local type ordering to determine the type precedence. In this paper, we discuss the general lookup techniques for languages which use the local type ordering to determine the type precedence, while noticing possible simplified cases if is a directed tree (single inheritance), or if is a global type ordering. 2.2 Method Applicability, Confusability, and Specificity The main concepts concerning multi-methods which we use in this paper are presented in [2]: method applicability given a generic function invocation, m(t 1,..., T n ), we say that a method m k (T k 1,..., T k n) is applicable for that invocation if and only if T i T k i for 1 i n; method confusability if two methods are both applicable for a function invocation, we say that they are confusable. Formally, methods m 1 (T 1 1,..., T 1 n) and m 2 (T 2 1,..., T 2 n) 3 are confusable if for any i, 1 i n, there exists a type T i, such that T i T 1 i and T i T 2 i ; otherwise they are non-confusable. The equivalence classes of the transitive extension of the relation confusable are called confusable sets. If is a confusable set of methods and m i and m j are in then there are k ( 0) methods m 1, m 2,..., m k in such that m i is confusable with m 1, m 1 is confusable with m 2,..., and m k is confusable with m j. We say that a generic function invocation m(t 1,..., T n ) is covered by a confusable set if there exists a method m such that m is applicable for m; 3. For the sake of easy description, the method names are subscripted. In real system, however, the confusable methods names are identical. 3

4 method specificity given two methods m i and m j that are both applicable to a function call, we assume that an ordering mechanism is provided that uniquely determines the precedence between those methods. If one method has precedence over another for a given invocation, we say that it is more specific than the other. One mechanism is called inheritance order precedence: suppose m i (T i 1,..., T i n) and m j (T j 1,..., Tj n) are two applicable methods for a generic function invocation m(t 1,..., T n ), we consider their formal arguments in a prespecified order (such as left-to-right 4 ), and find the first argument position in which the formal argument types of m i and m j differ, say k. If T i k Tk T j k, then m i is more specific than m j, and vice versa. The inheritance order precedence is sufficient to determine method specificity in a multiple inheritance language with multi-methods [2]. CLOS is an example of a language that uses inheritance order precedence to determine method specificity. 2.3 An Important Fact An important result presented in [2] for static type checking of multi-methods is, that a generic function invocation m(t 1,..., T n ) is covered by at most one confusable set. Unfortunately, in general it is impossible to detect the confusable set that covers the given function invocation at compile time. To resolve this problem, we introduce a concept called broad confusable set of methods, the set of all methods with the same name as well as the same arity. Clearly, each confusable set must be a subset of one broad confusable set. Furthermore, it is easy to see the following fact: A generic function invocation m(t 1,..., T n ) is covered by at most one broad confusable set, which can be detected at compile time. ased upon this result, the task of dynamic dispatching is to find the most specific method (in the broad confusable set) for the given generic function invocation. Although in this paper we discuss the dispatching approach in the context of statically typed languages, yet it is still valid for dynamically typed languages. 3 Overview of Our Dispatching Approach In order to have an intuitive idea of our approach, in this section we view the overall approach of multiple-dispatching by presenting examples. We introduce a lookup automaton (LUA) to simulate the dynamic dispatching in a given broad confusable set. A LUA is a deterministic finite automaton [3] and is defined as a 5-tuple = (Q,,, q 0, F), where Q is a finite set of states; is a finite set of input symbols; is a state transition function, which is a mapping Q Q; q 0 Q is the initial state of the finite state control; and F Q is the set of final states. In the discussion of this paragraph, we use upper case letters to denote types and the corresponding lower case letters to denote their instances. For example, we write a to denote an instance of type A. 4. Any prespecified order can be transformed into left-to-right by exchanging the argument location during compile time. Hence, without loss of generality, we can assume that the prespecified order is left-to-right during dispatching. 4

5 Type hierarchy : broad confusable set : A C D E F C F D D E C E m 1 (A,,, ) m 2 (C, C,, ) m 3 (C, D, A, F) G H Lookup Tree: A C C D A F m 1 m 2 m 3 Fig. 1 An example of a type hierarchy, a confusable set, and the corresponding lookup tree To understand the underlying ideas of the LUA, we start with a simple construction. Fig. 1 shows an example of a type hierarchy and a broad confusable set of methods. A simple approach to perform dispatching of multi-methods can be based on the following tree structure, where all edges are labelled by type names and each leaf is labelled by a method name. In this tree, the labels of the edges of each path from the root to a leaf correspond to the signature of the method of the leaf s label, and vice versa. Fig. 1 depicts this tree for the set. How can this tree be utilized for dispatching? For a given method invocation the method to be dispatched is found by traversing this tree starting at the root. The types of the actual parameters decide which edge will be followed: the edge labelled by the most specific supertype is selected. Once a leaf is reached the corresponding method is dispatched. For example, function invocation m(c, d, a, h) will lead to a path with edge labels C, D, A, F and method m 3 is dispatched. This structure has a low space requirement, but it has a big disadvantage. To see this, consider function invocation m(e, h, c, f). In the first step, the edge with label C is selected, because in the available labels A and C the type C is the most specific supertype of E. Note that in order to decide this, the knowledge of the relation E is needed. In the second step, the edge with label C is selected because of relation H. ut already in the next step it becomes apparent that this path was wrong. This is because the only possible edge in this step has label, but is not a supertype of C. Hence we have to backtrack and to undo the last selection. As long as there are alternatives we can proceed. Finally we reach a leaf and a method can be dispatched or there is no applicable method. In the example the path with labels C, D, A, F will be 5

6 q 0 A C q 1 {m 1, m 2, m 3 } {m 1 } q 2 C D {m 2, m 3 }{m 1 } {m 2 } E F q 3 {m 1 } {m 1 } q 4 q 5 {m 3 } q 6 {m 3 }{m 2 }{m 1 } q 7 A A q 8 q 9 {m 2 } q 10 {m 3 } q 11 q 12 {m 2 }{m 3 } {m 2 }{m 3 } F F q 13 q 14 q 15 {m 3 }{m 2 }{m 1 } q 15 A q 10 F q 14 q 14 q 15 {m 1 } {m 2 } {m 3 } {m 2 }{m 1 } {m 3 } {m 2 } {m 3 } Fig. 2 The lookup automaton (LUA) based on the example shown in Fig. 1 selected and method m 3 will be dispatched. Hence, the main disadvantages of this approach are that firstly backtracking may be needed and secondly the complete knowledge of the local type ordering is needed at runtime. Consequently, this lookup procedure may require exponential time. The LUA we introduce avoids backtracking and for dispatching only the knowledge of the subtype relation is needed. This could also be achieved by introducing a complete tree indicating all possible combinations of types. ut this obviously leads to exponentially growing space requirements. Our goal is to find a structure with low space requirements supporting dispatching in linear time with respect to the arity of the function invocation. Fig. 2 shows the LUA based on the example shown in Fig. 1, where final states are characterized by double circles. In order to avoid drawing cross arrows, the states without circles refer to the corresponding circled states. In Fig. 2, we indicate the method precedence order at each state by a list of sets of methods. Suppose that at state q the list is a 1 a 2... a l (where a i ), and method m 1 a i and m 2 a j. If i < j, then method m 1 at state q will have higher priority to be selected than m 2 ; if i = j, then m 1 and m 2 at state q will have the same priority to be selected. For example, consider the list {m 2, m 3 }{m 1 } at state q 2 : methods m 2 and m 3 have higher priority to be selected than the other method m 1, while m 2 and m 3 have the same priority to be selected. The basic idea to construct the LUA is the following: in order to reduce the size of the LUA, the number of states introduced should be as small as possible. Informally, if states have the same precedence order, they will be merged together. In order to easily catch the idea, we firstly state how to simulate this LUA. Afterwards, we describe the overall approach of how to construct it. Consider a generic function invocation m(e, h, c, f). Initially we are at start state q 0. There are two types A and C following state q 0. We select transition (q 0, C) = q 2 because, in the set {A, C}, C is the most specific supertype of the first argument type E. At state q 2, five types, C, D, E, and F follow. We select transition (q 2, F) = q 7 because, in the set {, C, D, E, F}, F is the most specific supertype of the second argument type H. Similarly, the next state transitions are (q 7, A) = q 10 and (q 10, F) = q 15. At the final state q 15, method m 3 is the most specific method for the given invoca- 6

7 tion. Note that, during the LUA simulation, only the knowledge of subtype relation is needed. The number of state transitions is equal to the function arity 4. The LUA in Fig. 2 is constructed as follows. At first, the initial state q 0 is created, where three methods m 1, m 2, and m 3 may be applicable with the same priority, i.e. at q 0 the method precedence order is {m 1, m 2, m 3 }. At the next level, the set of the first argument types of the methods m 1, m 2, and m 3 is {A, C}. Consider the state transitions (q 0, A) and (q 0, C). At the state (q 0, A), only method m 1 may be applicable, so that we create a new state q 1 = (q 0, A) with precedence order {m 1 }; at state (q 0, C), three methods m 1, m 2, and m 3 may be applicable but m 2 and m 3 have higher priority to be selected than m 1, i.e. the precedence order is {m 2, m 3 }{m 1 }. At this level, so far there is still no state with precedence order {m 2, m 3 }{m 1 }. Thus, a new state q 2 = (q 0, C) with precedence order {m 2, m 3 }{m 1 } is created. Now consider the situation at the next level. At state q 1, only m 1 may be applicable, so that only state transition (q 1, ) is considered ( is the second argument type of m 1 ). We create a new state q 3 = (q 1, ) with precedence order {m 1 }. At state q 2, the possible applicable methods are m 1, m 2, and m 3, so the state transitions (q 2, ), (q 2, C), and (q 2, D) must be considered. Since the state (q 2, ) is with precedence order {m 1 }, which is the same as the precedence order at state q 3, we define (q 2, ) = q 3. Similar to the situation of state transition (q 0, C), the new states q 4 = (q 2, C) and q 5 = (q 2, D) are created. Now, at q 2 we have introduced the transitions (q 2, ), (q 2, C), and (q 2, D). In order to simulate all possible cases, however, it is still necessary to introduce additional transitions (q 2, E) and (q 2, F). We will explain this in the next paragraph. Continuing with this procedure, the construction of the LUA is completed, where the most specific methods at final states are underscored. We turn back to discuss why at state q 2 it is necessary to introduce the additional transitions (q 2, E) and (q 2, F). Consider the case that these additional transitions are not introduced. Recall that m 3 is the most specific method for the above invocation m(e, h, c, f). For this function invocation we consider the LUA simulation again. At first, for the first argument type E, we select transition (q 0, C) = q 2. Consider the second argument type H. As types E and F are not introduced at q 2, in the set of the remaining types {, C, D}, finding the most specific supertype of H requires the knowledge of the relation H rather than the relation. y the relationship C H D (since C F D holds and is consistent), we know that, in the set {, C, D}, C is the most specific supertype of H with respect to H. Thus, at state q2 the state transition (q2, C) = q4 is selected. Clearly the simulation is not correct since eventually the most specific method m3 is not in the path following q4. Therefore, backtracking is required to re-select the state transition as (q 2, D) instead of (q 2, C). Hence, if the types E and F are not introduced at state q 2, there will be two consequences during the simulation: the knowledge of local type ordering instead of subtype relation is needed, and backtracking is required. Given a broad confusable set and a type hierarchy, there is another possibility to construct the LUA. At first, one can simply enumerate all possible dispatching cases and then represent that by a finite automaton, such as the complete tree described as above. Afterwards, standard techniques to minimize this automaton can be employed [4]. This seems to be a natural way for constructing the LUA. However, there are 7

8 some problems with this approach when used for larger systems. The main weakness is that, before minimizing the automaton, a large memory overhead may take place because representing all possible dispatching cases may lead the automaton to be combinatorial explosive. Consequently, the procedure to minimize the automaton can become very expensive. In an approach presented in this paper we overcome this weakness by addressing the construction and minimization of the LUA simultaneously: the procedure to reduce the size of the LUA is performed at the time of constructing the LUA. Consequently, with our approach the large memory overhead is prevented because unnecessary states of the LUA are never created. 4 Formal Statement of the Problem In this section, we present the terminology and notation which we will employ throughout the paper. Moreover, we present the several associated results. 4.1 The Operator and the Function M (k) In the following we always assume that is a broad confusable set of methods with arity n. Let denote the set { a 1 a 2...a p p >0, ai 2, ai aj =, for i j}. The list a 1 a 2...a p is represented by p i 1 a i and each ai (i = 1,..., p) is called a factor of p a i. Note that the order among the factors is important, e.g. a 1 a 2 a 2 a 1 unless a 1 or i 1 a 2 is empty. Now we introduce an operator : by means of A = p q i 1 j 1 ai b j, for A = p i 1 a i and = q j 1 b j. Clearly, A. In this paper, we always assume that all factors of elements in are not empty. Therefore, if a factor in A is empty we omit it. For A,, we say A = if and only if they have the same factor list after omitting all empty factors. For example, suppose = {m 1, m 2, m 3, m 4, m 5 } and let A = a 1 a 2 = {m 1, m 2 }{m 3, m 4 } and = b 1 b 2 b 3 b 4 = {m 1 }{m 2, m 3 }{m 4 }{m 5 }. It is easy to check that A and. Thus, A = 2 4 i 1 j 1 ai b j = (a 1 b 1 )(a 1 b 2 )(a 1 b 3 )(a 1 b 4 ) (a 2 b 1 )(a 2 b 2 )(a 2 b 3 )(a 2 b 4 ) = {m 1 } {m 2 } {m 3 } {m 4 } = {m 1 }{m 2 }{m 3 }{m 4 }. In the following we define function domain: 2 by means of domain(a) = p i 1 a i, for A = p a i. i 1 8

9 Furthermore, let A = p i 1 a i, m 1, m 2 domain(a) such that m 1 a i and m 2 a j. If i < j, we say that m 1 precedes m 2 with respect to A, shortly denoted by m 1 A m 2. The function T (k) : is defined to map a method to its k th argument type, i.e. T (k) (m(t 1,..., t n )) = t k, for m(t 1,..., t n ). An inverse function T 1 (k) T 1 (k) (t) = {m T (k) (m) = t }. : 2 can be defined by means of For the sake of convenience, sometimes we extend the argument domain of T (k) from into 2 by means of T (k) ( ) = {T (k) (m) m }, for 2. For t and S, the type precedence list ( t 1,..., t l ) over S for t is the linearization of the set {t S t t } such that t i t t i 1, for 1 i < l. Now we define a function M (k) : 2 by means of M (k) (t, S) = l i 1 T 1 (k) (t i ), where ( t 1,..., t l ) is a type precedence list over S for t. Proposition 1 For all A,, and C, the following holds: (a) (associativity) (A ) C = A ( C); (b) (conditional commutativity) A = A, if A or consists of only one factor; (c) (identity element) A = A = A, if we regard ; (d) domain(a ) = domain(a) domain(); (e) For all t, M (k) (t, T (k) ( )) represents a precedence order for the methods (in ) whose k th argument types are the supertypes of t; (f) For all t and S, A M (k) (t, S) = A M (k) t, S T(k) (domain(a)). Proof. (a), (b), (c), (d), and (e) can be directly derived from the corresponding definitions. (f) s S T (k) (domain(a)), we have domain(a) T 1 (k) (s) =. y definition, M (k) (t, S) = l T 1 (k) (t i ), where ( t 1,..., t l ) is a type precedence list over S for t. Now assume that i 1 { t 1,..., t l } T (k) (domain(a)) = {t i1,..., t i }, and q A = p a i. i 1 Thus, t { t 1,..., t l } {t i1,..., t i }, we have domain(a) T 1 q (k) (t ) =. Therefore, 9

10 A M (k) (t, S) = p l i 1 j 1 ai T 1 (k) (t j ) = p q i 1 j 1 a i T 1 (k) (t ij ) = A M (k) t, S T(k) (domain(a)). The operator and the functions domain and T (k) are easy to implement. However, the implementation of M (k) (t, S) will rely on the algorithm of how to determine the type precedence list ( t 1,..., t l ) over S for t. Ducournau, et al. [12] discussed this supertype linearization problem in general. In the context of CLOS, however, obrow, et al. [8] proposed a concrete algorithm to determine the type list. For every c, define R c = {(c, c 1 ), (c 1, c 2 ),..., (c k 1, c k )}, where c 1,..., c k are the direct supertypes of c, and c i c c i 1 for 1 i < k. Let T c be the set of type c and its supertypes. Let R = R c. To compute the precedence list for t, c T t topological sorting proceeds by finding a type c in T t such that no other type precedes that element according to the elements in R. The type c is placed first in the result. Remove c from T t, and remove all pairs of the form (c, c ), c T t, from R. Repeat the process, appending types with no predecessors to the tail of the result. Stop when no element can be found that has no predecessor. Using this approach, we compute the type precedence list ( t 1,..., t l ) over T t for t. Therefore, in order to compute M (k) (t, S), we can extract all t i S from the list ( t 1,..., t l ). If is a directed tree, the algorithm will be much simpler. 4.2 The Functions GL, closure, and LU Given two types s, t, we define the set of greatest lower bounds for s and t by GL(s, t) = {u u s, u t, and u such that u u s and u u t }. 5 For a subset of types S, we say that S is closed if for any s, t S, GL(s, t) S. The closure of a subset S, denoted by closure(s), is defined as the intersection of all closed subsets T such that S T. Clearly closure(s) is also closed. On the other hand, for any t and S, we define set of least upper bounds for t with respect to S by LU (t, S) = {s S t s, s S such that t s s }. 6 For example, in the type hierarchy shown in Fig. 1, GL(C, D) = {E, F}, closure({c, D}) = {C, D, E, F}, and LU (G, {A, C, D}) = {C, D}. The following propositions are the direct results of the definitions of GL and LU. 5. In order to keep things simple, we borrow the notation GL which is originally defined in lattice structures, where GL is a unique element. However, in a DAG, we define GL to be a set. 6. In order to distinguish our notion from the well-known standard notion LU defined in lattice structure, we use the notation LU. 10

11 Proposition 2 Let s, t 1, t 2 such that s t 1 and s t 2. Then there exists s GL(t 1, t 2 ) such that s s. Proposition 3 Let t, S, and s S. If t s, then there exists s LU (t, S) such that t s s. Theorem 4 Let S. Then S is closed if and only if for all t, LU (t, S) contains at most one element. Proof. if: Let s 1, s 2 S. It suffices to prove that GL(s 1, s 2 ) S. Let s GL(s 1, s 2 ). y proposition 3, s 1, s 2 LU (s, S) such that s s i s i for i = 1, 2. y assumption, LU (s, S) contains at most one element. Hence, s 1 = s 2. Now s GL(s 1, s 2 ) implies that s = s 1 LU (s, S) S. only if: Let S be closed and t. Furthermore, let s 1, s 2 LU (t, S). Clearly if t S then s 1 = s 2 = t. Thus, we assume that t S. This induces t GL(s 1, s 2 ), as S is closed. Furthermore, we have t s 1 and t s 2. Therefore, by proposition 2, s GL(s 1, s 2 ) such that t s. Hence, by the definition of LU, s 1 = s 2. This implies that LU (t, S) 1. In the following the algorithms for closure and for the function LU are presented. Initially, a topological sorting is performed on the types of with respect to the relation. Let be the number of types of and let T[1], T[2],..., and T[ ] be the types of such that T[i] T[j] holds only if i < j. In the function closure, a variable of type array[1.. ] of {not_in_closure, in_closure} is needed. Initially, [i] = not_in_closure, for 1 i. function closure(s) returns 2 1 { for i = downto 1 do 2 if T[i] S then [i] in_closure 3 else 4 { {j T[i] T[j] and [j] = in_closure} 5 if then 6 { j min min 7 if j, j min < j such that not(t[j min ] T[j]) then 8 [i] in_closure 9 else /* j {j min }, T[j min ] T[j]. So T[i] closure(s). is updated in the following. */ 10 foreach T[i ] such that T[i ] T[i] do 11 delete the edge from T[i ] to T[i] and add the edge from T[i ] to T[j min ] 12 } 13 } 14 return {T[j] [j] = in_closure, 1 j } 15 } The function uses a for-loop (lines 1-13) to scan all types of, where may be updated (c.f. lines 10-11). For convenience, when the loop variable i is equal to k, we term the for-loop as the k-loop. Let k (1 k ) be the updated when the k-loop terminates. In k we denote the relations,, and by k, k, and k. There- 11

12 fore, in the function closure the relations and (used at lines 4, 7, and 10) must be understood as i 1 and i 1 in the corresponding i 1. Now we define the following set when the k-loop terminates: k = {T[i] k i < k or [i] = in_closure}. The following lemma is necessary for proving the correctness of the function closure: Lemma 5 Given k, 1 k, let a, b k. (a) If a k b, then with respect to k there is a path from a to b such that all nodes of the path are in k ; (b) a k b if and only if a b. Theorem 6 The function closure returns the correct result. The proofs of lemma 5 and theorem 6 are stated in the appendix. Remarks: (a) If is a directed tree (single inheritance), then every subset S is always closed, i.e. closure(s) = S holds; (b) As we have mentioned, at line 7 the relation must be understood as i 1 in i 1. y the definition of (c.f. line 4), we have T[j] i 1, for j. According to lemma 5(b), at line 7 the relation i 1 can be treated as the relation in. In order to make subtype relationships tests fast, Agrawal, et al. [1] proposed a structure to maintain a compressed transitive closure of the subtype relation. An index and a set of ranges are associated with each type. If the index of one type falls into a range of another type, then the first type is a subtype of the second. Using this technique, we can test subtype relationships in constant time if the type hierarchy is a directed tree (single inheritance). If the type hierarchy is a DAG (multiple inheritance), experimental results show that subtype relations can be tested in essentially constant time [1], and, in the worst case, in O(log( )) time, where is the number of types in the type hierarchy; (c) As the type hierarchy may be updated, it is necessary to make a copy at the beginning. Furthermore, at line 10, it is necessary to find all direct subtypes for a given type. Therefore, the data structure for the copy of the type hierarchy must efficiently support this operation; (d) A topological sort of the types of is performed only once. This sorting will be used in later stages; (e) The time-complexity of the function closure is O( + ), where is the number of edges in. In later sections, we will see that the function LU (s, S) is invoked at run time, only in the case that S is closed. The following is the algorithm of LU (s, S) under the condition that S is closed. function LU (s, S) returns 2 1 { Suppose S = {T[i 1 ], T[i 2 ],..., T[i k ]}, where 1 i 1 < i 2 <... < i k and s = T[l] 12

13 Remarks: 2 for j = 1 to k do 3 if i j l and s T[i j ] then return {T[i j ]} 4 return 5 } (a) The correctness of the function LU is a direct result of theorem 4, i.e. the result of LU (s, S) contains at most one element; (b) The worst time-complexity of the function LU is O( S ). 4.3 The Central Result Having introduced the basic concepts, we can now state the central result. Theorem 7 Given the types t 1,..., t k, let R k = R( t 1,..., t k ) = k i 1 (a) Let a be a factor of R k and m a. Then M (i) ti, T (i) ( ). (1) a = {m m and m have the same first k argument types}; (b) R( t 1,..., t k ) represents the precedence order of the methods (in ) whose first k argument types are the supertypes of t 1,..., t k, respectively. Proof. (a) Let m 1 (t 1 1,..., t k 1,...) and m 2 (t 1 2,..., t k 2,...). Suppose that i, 1 i k such that t i 1 t i 2. Hence, methods m 1 and m 2 are not together in a factor of M (i) ti, T (i) ( ) nor in a factor of R k. On the other hand, it is clear that if m and m have the same first k argument types, then they are both together in one factor; (b) The proof is by induction on k. When k = 1, then R(t 1 ) = M (1) t1, T (1) ( ) and the result follows from proposition 1(e). y definition, we have R( t 1,..., t k ) = R(t 1,..., t k 1 ) M (k) tk, T (k) ( ). Suppose R k 1 = R(t 1,..., t k 1 ) defines the precedence order of the methods (in ) whose first k 1 argument types are the supertypes of t 1,..., t k 1, respectively. y proposition 1(e), M (k) tk, T (k) ( ) presents the precedence order of the methods (in ) whose k th argument types are the supertypes of t k. Let X k be the precedence order of the methods (in ) whose first k argument types are the supertypes of t 1,..., t k, respectively. Note that X k satisfies the following properties: domain(x k ) = domain(r k 1 ) domain( M (k) tk, T (k) ( ) ); let m 1, m 2 domain(r k 1 ) domain( M (k) tk, T (k) ( ) ). If m1 and m 2 are in different factors of R k 1, then m 1 and m 2 will be in different factors of X k and the order between them must be kept. On the other hand, if m 1 and m 2 are in a same factor of R k 1, then m 1 and m 2 have the same first k 1 argument types. Therefore, the order between them presented in X k will be determined by their order presented in M (k) tk, T (k) ( ). 13

14 Hence, by means of the operator, we get X k = R k 1 M (k) tk, T (k) ( ) = R( t 1,..., t k ). Corollary 8 Let the function invocation m( t 1,..., t n ) be covered by. R(t 1,..., t n ) represents the precedence order of all applicable methods (in ) for that invocation. If R(t 1,..., t n ), then each factor of R(t 1,..., t n ) includes only one method. We can calculate R(t 1,..., t k ) recursively by referring to (1) and proposition 1(f) as follows: R k = R k 1 M (k) tk, T (k) ( ) = R k 1 M (k) tk, T (k) ( ) T (k) (domain(r k 1 )) = R k 1 M (k) tk, T (k) (domain(r k 1 )) (2) where k > 0, and R 0 =. Now we can discuss mechanisms for constructing and simulating the LUA based on the above results. 5 LUA Construction In this section, we present an algorithm to construct the LUA = (Q,,, q 0, F), which depends on the type hierarchy and the broad confusable set. The following routine construct constructs the LUA through calculating the value of R(t 1,..., t k ) using formula (2). In the following, for each state q Q the attribute q.pord holds the precedence order at state q. routine construct() 1 { create a start state q 0 2 q 0.pord 3 Q Q 0 {q 0 } 4 5 for k = 1 to n do 6 { Q 1 7 foreach q Q 0 do build_next_states(k, q, Q 1 ) 8 Q Q Q 1 9 Q 0 Q 1 10 } 11 F Q 0 12 } In the above routine construct, Q 0 represents the set of all states built at level k. The subroutine build_next_states(k, q, Q 1 ) attempts to construct all possible state transitions (q, t) (t ) at level k, where the argument Q 1 represents the set of all states built so far at level k+1. After subroutine build_next_states(k, q, Q 1 ) has been executed, Q 1 may be expanded and then represents the new set of all states built so far at level k+1. 7 The following proposition is necessary for the subroutine build_next_states. Proposition 9 Let m * with m *. For all t closure T(k) m * and 1 k < n, m * domain M(k) t, T(k) m * holds. 14

15 Proof. Clearlyclosure T(k) m *. t closure T(k) m *, t T(k) m * such that t t, i.e. m( t 1,..., t n ) m * such that t k = t. y the definitions of domain and M (k), we have m( t 1,..., t n ) domain( T 1 (k) (t )) domain M(k) t, T(k) m *, i.e. m( t 1,..., t n ) m * domain M(k) t, T(k) m *. Remarks: subroutine build_next_states(k, q, Q 1 ) 1 { T T (k) (domain(q.pord)) 2 T closure(t) 3 T 4 foreach t T do 5 { pord q.pord M (k) (t, T) 6 if k = n then pord the first factor of pord 7 if q Q 1 such that is_equal(q.pord, pord) then 8 (q, t) q 9 else 10 { create a new state q new and add it to Q 1 11 q new.pord pord 12 (q, t) q new 13 } 14 } 15 } function is_equal(pord 1, pord 2 ) returns boolean 1 { Suppose that pord 1 = a 1 a 2...a p and pord 2 = b 1 b 2...b q, where a i, b j 2 if p q then return false 3 for i = 1 to p do 4 if the smallest elements (with respect to a fixed order of 8 ) in a i and b i are unequal then 5 return false 6 return true 7 } (a) In subroutine build_next_states, lines 4-14 define a loop, in which a temporal variable, pord, is introduced to calculate the attribute (q, t).pord and to decide whether (q, t) is a new state. However, the fact pord is important so that the first factor of pord exists, as stated in line 6. This can be proved as follows: we have pord = q.pord M (k) t, T(k) (domain(q.pord)), where t closure T(k) (domain(q.pord)) and 1 k < n. Assume q.pord, and let m * = domain(q.pord). Then m *. y proposition 9, for all t 7. Hence, subroutine build_next_states(k, q, Q 1 ) side-effects the argument Q Suppose that we pre-sort all methods in, so that in each subset of the smallest element with respect to this order can be found. 15

16 closure T(k) m *, m* domain M(k) t, T(k) m *. y proposition 1(d), we can derive domain(pord), i.e. pord. Therefore, the above fact can be easily proved by induction on k. As a direct result, for all q Q, q.pord. This result will be used later in the stage of LUA simulation; (b) In line 7 of subroutine build_next_states, we need to compare the equality between q.pord and pord. y theorem 7, there exist two type-lists t 1,..., t k, and t 1,..., t k such that q.pord = R(t 1,..., t k) and pord = R( t 1,..., t k ). Let a i be the i th factor of q.pord, and b i the i th factor of pord. y theorem 7(a), either a i = b i or a i b i = holds. 9 This fact is useful to simplify the implementation of the equality test between q.pord and pord in function is_equal: in order to compare the equality between two sets a i and b i, we can just compare the smallest elements in a i and b i. Let s explain the above algorithms in the context of the example shown in Fig. 2. Suppose that we have already constructed all states and transitions at level 2, where Q 0 = {q 3, q 4, q 5, q 6, q 7 }. Now we are going to construct states and transitions at level 3. Firstly, the subroutine build_next_states(3, q 3, Q 1 ) is invoked, where Q 1 = ; q 3.pord = {m 1 }, so T = T (3) (domain(q 3.pord)) = T (3) ({m 1 }) = {}, and T = closure(t) = {}; In the loop body (lines 5-14), pord = q 3.pord M (3) (t, T) = {m 1 } {m 1, m 2 } = {m 1 }, when t =. Therefore, a new state q 8 with precedence order {m 1 } must be created and then (q 3, ) = q 8. Now Q 1 = {q 8 }. Afterwards, two other subroutine invocations build_next_states(3, q 4, Q 1 ) with Q 1 = {q 8 } and build_next_states(3, q 5, Q 1 ) with Q 1 = {q 8, q 9 } are executed. Now Q 1 becomes as {q 8, q 9, q 10 }. Consider the next subroutine invocation build_next_states(3, q 6, Q 1 ), where Q 1 = {q 8, q 9, q 10 }; q 6.pord = {m 3 }{m 2 }{m 1 }, so T = T (3) (domain(q 6.pord)) = T (3) ({m 1, m 2, m 3 }) = {A, }, and T = closure(t) = {A, }; In the loop body (lines 5-14), pord = q 6.pord M (3) (t, T) = ({m 3 }{m 2 }{m 1 }) {m 3 } = {m 3 }, if t = A; ({m 3 }{m 2 }{m 1 }) ({m 1, m 2 }{m 3 }) = {m 3 }{m 2 }{m 1 }, if t =. Therefore, when t = A, the equality pord = {m 3 } = q 10.pord yields (q 6, t) = q 10 (as q 10 Q 1 ); when t =, a new state q 11 with precedence order {m 3 }{m 2 }{m 1 } is created and then (q 6, t) = q 11. Now Q 1 = {q 8, q 9, q 10, q 11 }. 9. Assume m a i b i. y theorem 7(a), a i = {m m and m have the same first k argument types} = b i. 16

17 Likewise, the last subroutine invocation at level 3 is build_next_states(3, q 7, Q 1 ) with Q 1 = {q 8, q 9, q 10, q 11 }, in which a new state q 12 is created. Consequently, Q 1 = {q 8, q 9, q 10, q 11, q 12 } is the set of all states constructed at level 3. 6 LUA Simulation We have described the approach to construct the LUA for each broad confusable set. Clearly, a function invocation m(t 1,..., t n ) is covered by at most one broad confusable set, so that only one LUA should be simulated for that invocation. Furthermore, we know which LUA has to be simulated (we say that this LUA covers the function invocation m(t 1,..., t n )). In order to reduce the space-complexity, the LUA does not identify all possible dispatching cases. Generally, given a function invocation m(t 1,..., t n ) and a LUA that covers m(t 1,..., t n ), it is not possible to directly employ the standard automaton simulation technique. Rather, a special algorithm to simulate the LUA is necessary where the knowledge of the relation is used. In this section, we present the algorithm to simulate the LUA. 6.1 Approach In the following, let level(q) denote the length of the path from state q 0 to state q (i.e. the number of transitions from the start state to q). From the routine construct, we can see that level(q) is independent of the selected path. For example, in Fig. 2, level(q 3 ) is 2 and there are three different paths from q 0 to q 3. Moreover, we introduce a notion D (q, ) = {t (q, t) is defined}. y the subroutine build_next_states, for any q Q F, we have D (q, ) = closure T(level(q) 1) (domain(q.pord)). Hence D (q, ) is closed, for q Q F. Theorem 10 Let S, t. For all k, 1 k n, the following holds: M (k) (t, S) =, if LU (t, closure(s)) = ; M (k) (t, S), if LU (t, closure(s)), and t is the unique element in LU (t, closure(s)). Proof. If LU (t, closure(s)) =, then {s S t s} = and hence M (k) (t, S) =. Now let LU (t, closure(s)). y theorem 4 we have LU (t, closure(s)) = {t }. y definition, M (k) (t, S) = l i 1 T 1 (k) (t i ), where { t 1,..., t l } = {s S t s}, and t i t t i 1 for 1 i < l. On the other hand, by proposition 3 we have {s S t s} = {s S t s}. Meanwhile by the restriction on the relation, the relation t i t t i 1 still holds for 1 i < p. Therefore, M (k) (t, S) = l T 1 (k) (t i ), i.e. M (k) (t, S) = M (k) (t, S) holds. i 1 17

18 Let m(t 1,..., t n ) be a function invocation covered by. y theorem 10 and formula (2), we can recursively calculate R k = R(t 1,..., t k ) (with R 0 = ) as follows: R k = R k 1 M (k) (t k, T (k) (domain(r k 1 ))), if LU (t k, closure(t (k) (domain(r k 1 )))) ; = R k 1 M (k) (t, T (k) (domain(r k 1 ))), if (unique) t LU (t k, closure(t (k) (domain(r k 1 )))). (3) The task of the LUA simulation is to find a final state q such that q.pord is equal to the first factor of R n. We can accomplish this by tracing a list of states q i1,..., q i n with q ik.pord = R k (or the first factor of R k, if k = n). According to the formula (3) and the definition of D (q, ), we have the relation q ik 1 = ( q ik, t), where t LU (t k, D ( q ik, )). Formally, the LUA simulation is based on the following proposition. Proposition 11 Let the LUA = (Q,,, q 0, F) cover the function invocation m(t 1,..., t n ). Let q Q F be a state with q.pord = R k, where k = level(q). If LU (t k+1, D (q, )), then (q, t).pord = R k+1 (or its first factor, if k+1 = n), for the unique t LU (t k+1, D (q, )). Proof. Since D (q, ) = closure T(k 1) (domain(q.r)) is closed for q Q F, by theorem 4, t D (q, ) is unique. If k + 1 < n, we have (q, t).pord = q.pord M (k 1) t, T(k 1) (domain(q.pord)) = R k M (k 1) t, T(k 1) (domain(q.pord)) = R k+1. (by formula (3)) Likewise, if k + 1 = n, (q, t).pord = the first factor of R n. The following function simulate reads the type-list t 1,..., t n, and then returns either the most specific method (if any exists) in or the predefined error-handling function if there is no applicable method in. Let f 0 be a predefined error-handling function, and let {f 0 } be denoted by +. Remarks: function simulate(t 1,..., t n ) returns + 1 { q q 0 2 for k = 1 to n do 3 { T LU (t k, D (q, )) 4 if T then q (q, t), where t T 5 else return f 0 6 } 7 return the (unique) method in the (unique) factor of q.pord 8 } 18

19 (a) In line 3 the function LU (t k, D (q, )) is invoked, where D (q, ) is closed. Under this condition, the implementation of LU has been stated in section 4.2; (b) In the run time environment, the function simulate just uses the knowledge of the relation, the knowledge of the relation T, for T, is not needed any more; (c) Line 7 refers to the attribute q.pord, which consists of one factor only that includes only one method at the final states (c.f. subroutine build_next_states). In fact this is the only place referring to the attribute q.pord in the time of simulation. From the view of implementation, it is not necessary to store the attribute q.pord, for q Q F, to the run time environment, e.g. in Fig. 2 only the underscored methods at states q 13, q 14, and q 15 need to be saved; (d) According to proposition 11, it is easy to prove the correctness of the function simulate by induction. 6.2 Improvement The time-complexity of function simulate depends on the implementation of the function LU. As stated in Section 4, the worst time-complexity of the function call LU (s, S) is O( S ) when S is closed. Consequently, the total time-complexity of function simulate will rely on the size of D (q, ) in line 3 of simulate. In the following we consider an improvement for the time-efficiency of function simulate. Let c 0 be a predefined constant independent of any concrete type hierarchy and LUA. At compile time, for any q, if D (q, ) > c, we can extend the state transitions (q, t) with respect to the domain of t from D (q, ) into in the following way: (q, t) (q, t ), if LU (t, D (q, )), so unique t LU (t, D (q, ))); q 1, if LU (t, D (q, )) =, where q 1 is the predefined failure state. Note that the extended LUA does not create any new state except for the predefined failure state q 1. As an example, when c = 3, an extended LUA based on the example shown in Fig. 2 is given in Fig. 3. To simulate the extended LUA, an attribute (1-bit) will be attached to each state q Q F to indicate whether the corresponding D (q, ) is extended or not. The following is the improved version of the function simulate, after the LUA is extended as above. function simulate(t 1,..., t n ) returns + /* improved version */ 1 { q q 0 2 for k = 1 to n do 3 { if D (q, ) is extended then 4 { q (q, t k ) 5 if q = q 1 then return f 0 6 } 19

20 q 0 A C q 1 {m 1, m 2, m 3 } {m 1 } q 2 C D {m 2, m 3 }{m 1 } {m 2 } E, F, q 3 {m 1 } {m 1 } q 4 q 5 {m 3 } q 6 {m 3 }{m 2 }{m 1 } q 7 A q 8 q 9 {m 2 } q 10 {m 3 } q 11 q 12 {m 2 }{m 3 } {m 2 }{m 3 } A q 1 A F {m 3 }{m 2 }{m 1 } A q 10 F F q 13 q 14 q 15 q 14 q 15 {m 1 } {m 2 } {m 3 } {m 2 }{m 1 } {m 3 } q 14 {m 2 } q 15 {m 3 } Fig. 3 The extended LUA (c = 3) based on the example shown in Fig. 2, in which only D (q 2, ) with cardinality 5 should be extended to. In this figure, the symbols with bold-font are newly appended. Remarks: 7 else /* D (q, ) is not extended */ 8 { T LU t k, D (q, ) 9 if T then q (q, t), where t T 10 else return f 0 11 } 12 } 13 return the (unique) method in the (unique) factor of q.pord 14 } (a) In section 4.2, we performed the topological sorting on, so = {T[1], T[2],..., T[ ]}. For the representation of the LUA, for any non-final state q Q F, the function (q, t) with respect to the argument t can be converted into a function fq(i) = (q, T[i]) with respect to the number argument i. On the one hand, if D (q, ) = (i.e. D (q, ) is extended), the argument domain of fq is [1, ]. In this case, fq can be represented by a linear table so that the time-complexity with respect to fq is O(1); on the other hand, if D (q, ) (i.e. D (q, ) is not extended and D (q, ) c), the argument domain of fq is a subset of [1, ], with size D (q, ) c. In this case, fq can be represented by a hash table or a binary tree. Since c is the predefined constant, the time-complexity with respect to fq is O(1) also. A related question is, how to get for t a corresponding number i with t = T[i] at run time? As the topological sorting on is performed at compile time, each type t can be identified by the number i, which can be attributed to t. Therefore, for any t, getting the number i such that t = T[i] can be preformed with time-complexity O(1) at run time. Conclusively, the time-complexity of the improved function simulate is O(n), where n is the method arity; 20

21 (b) If the predefined constant c = 0, all transitions (q, t) will be extended for all q Q. In this case, even the knowledge of relation is not needed in the run time environment, since lines 8-11 are never executed; (c) The value of the predefined constant c influences the number of transitions in the LUA and the efficiency of the simulation: a higher value of c would save space but would make the algorithm run slower; conversely, a lower value of c would cause the opposite effects. More experience is necessary to find a good value. 7 Optimization We have shown the mechanisms for the LUA construction and simulation. The essence of the routine construct is to calculate the precedence order at each level, while creating as few as possible states in the LUA. However, the question remains, whether the number of states in the LUA is minimal. In a LUA, two states s1 and s2 at same level are called distinguished, if there exists an input type-list which leads to different final states starting from s1 and s2 respectively. If states s1 and s2 are not distinguished, they are called undistinguished. An obvious procedure to minimize the size of the LUA is to merge all undistinguished states into one common state. The brute force method for finding undistinguished states is to try all possible input type-lists, and to examine whether the results differ. To avoid this costly procedure we proceed in two steps filtering unreachable methods and merging undistinguished states. In the routine construct, we create a new state provided a new precedence order is obtained. Given a number k, 1 k n, and a type-list t 1, t 2,... t k, by theorem 7, R( t 1,..., t k ) represents the precedence order of for the first k argument-types, which are the supertypes of t 1,..., t k respectively. While constructing the value of R( t 1,..., t k ), however, we do not consider the remaining types t k 1,..., t n. It is still possible that in R( t 1,..., t k ) there is a number of methods which can never be chosen after all. For example, in Fig. 2 the method m 1 at state q 6 is in this case. In this section, we describe how to filter out those methods which can never be chosen, and then show how to merge undistinguished states. At last, we discuss how to construct a LUA with the minimal number of states. 7.1 Filtering Unreachable Methods Given a type-list t 1,..., t k (k n), we have R( t 1,..., t k ). Now consider a method m R( t 1,..., t k ). If there is a type-list t k 1,..., t n such that m is in the first factor of R( t 1,..., t n ), then m is called k-reachable in R( t 1,..., t k ), else k-unreachable in R( t 1,..., t k ). For example, in Fig. 2 the precedence order at state q 6 is {m 3 }{m 2 }{m 1 }, in which m 1 is 2-unreachable because m 1 can never be chosen at any final state following q 6 ; on the other hand, it is easy to check that m 2 and m 3 are 2-reachable in {m 3 }{m 2 }{m 1 }. Let s reconsider the construction procedure. At level k, we can calculate precedence order R( t 1,..., t k ) in which all k-unreachable methods are filtered. efore describing this procedure, we shall introduce several notations and associated results. 21