A Graph-Based Generic Type System for Object-Oriented Programs

Introduction 71 IntroductionGraph notations are widely used to express class structures and execution states of oo programs.For oo languages, such as Java [1], where object variables are pointers, it is natural to representobject identities by nodes and variables by directed edges, e.g., uml [2] and the trace model ofHe and Hoare [3]. However, traditional semantic definitions and reasoning about properties ofoo programs are based on the plain theory of sets and relations [4, 5], without much utilizationof the properties of graph structures. To close the gap between structural representation andreasoning of oo programs, we define a graph-based type system and operational semantics foroo programs. A significant advantage of this type system is the intuitiveness to study propertiesand relations of complex types and executions of oo programs using graphs and their properties.Concepts and properties of graphs, those of paths, connectivity, homomorphism and isomorphismin particular, articulate the formulation of properties of a program to verify, the idea of reasoningabout the properties, and the design of verification and implementation [6]. Notice that here weemphasize the simplicity of mathematical structure and way of thinking, instead of the actualvisual representation of a program.Overview of contribution. Graph-based representation of type systems with no type operationsis rather straightforward. Types are represented as nodes of a type graph, and relationsof types, including the subtype relation, are represented as edges between them. However,modern oo languages often incorporate generics, i.e., parameterized types, to strengthen thetype-checking with dynamic typing. Their type systems use identified and constrained type variablesin place of a much widened universal superclass to avoid unchecked downcasts [7]. Fora graph-based representation of such type systems, type operations that construct new typesshould be realized by graph transformations that introduce new components into a type graph.How these new components are defined, and how they coexist and get related with the rest ofthe type graph are the main problem of the representation.Recursive generic classes lead to further complication of the problem. That is, a generic class canbe instantiated to a recursive type only for certain type arguments, and such a recursive type isactually an unfolded version of some other type. Consider an example generic class A〈β〉, whereβ is a type variable, and one of its instantiations A〈β ↦→ B〉. Let b of type β be an attribute ofA〈β〉 and a of type A〈β ↦→ B〉 an attribute of class B, the instantiation of the recursive generictype is shown below.baA〈β ↦→ B〉 : B :bbaIn the above figure, the graph on the left is an instantiation graph of A, by substituting thegraph of B (on the right) for β. The white nodes all represent the type A〈β ↦→ B〉, but thegraphs connected to these white nodes are different. We need to relate these graphs using theequi-recursive approach [8] to ensure their consistency.Report No. 448, June 2011UNU-IIST, P.O. Box 3058, Macao