ECOOP 2009 – Object-Oriented Programming potx

Lagorioinductively defined on top of the constant [ ] and all constants representing class, method and field names declared in prog , and on top of the binary function Method add can be e

Lecture Notes in Computer Science 5653

Commenced Publication in 1973

Founding and Former Series Editors:

Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Sophia Drossopoulou (Ed.)

ECOOP 2009 – Object-Oriented Programming

23rd European Conference

Genoa, Italy, July 6-10, 2009

Proceedings

1 3

ISBN-10 3-642-03012-2 Springer Berlin Heidelberg New York

ISBN-13 978-3-642-03012-3 Springer Berlin Heidelberg New York

This work is subject to copyright All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks Duplication of this publication

or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965,

in its current version, and permission for use must always be obtained from Springer Violations are liable

to prosecution under the German Copyright Law.

Welcome to the proceedings of ECOOP 2009! Thanks to the local organizers forworking hard on arranging the conference — with the hard work they put in,

it was a great success Thanks to Sophia Drossopoulou for her dedicated work

as PC Chair in assembling a fine scientific program including forward-lookingkeynotes, and for her efforts to reduce the environmental impact of the PCmeeting by replacing a physical meeting with a virtual meeting I would alsolike to thank James Noble for taking the time and effort to write up last year’sbanquet speech so that it could be included in this year’s proceedings

One of the strong features of ECOOP is the two days of workshops precedingthe main conference that allows intense interaction between participants Thanks

to all workshop organizers

Last year’s successful summer school tutorials were followed up this year withseven interesting tutorials Thanks to the organizers and speakers

This year’s Dahl-Nygaard award honored yet another pioneer in the field,

namely, David Ungar for his contributions including Self I appreciate his efforts

in providing us with an excellent award talk

The world is changing and so is ECOOP Please contemplate my short note

on the following pages entitled On Future Trends for ECOOP.

On Future Trends for ECOOP

The world is changing and so is the European Conference on Object-OrientedProgramming (ECOOP) series ECOOP 1998 had more than 700 attendees, ma-

ny workshops, a large tutorial program, and many exhibitors Since then manythings have changed starting with the com bust, which meant a reduction inparticipation from industry and consequently also a reduction in tutorial atten-dance and exhibits The past decade has also seen a number of more specializedconferences in the OO area focusing on specific topics, e.g., Java, so it is per-haps natural that some move on from ECOOP to such conferences on subtopicswithin OO, while ECOOP still covers new, and less established OO ideas of thefuture

These trends have changed ECOOP from a mix of industry and academia tomostly academia, resulting in lower attendance, significantly reduced exhibits,and a change in tutorials from fully paid introductory tutorials to an academicprogram of summer school tutorials

Since the turn of the century, there has also been a slow drop in the ber of workshops, which, besides the strong papers in the main conference, hasbeen one of the hallmarks of ECOOP A strong workshop program is important

num-in attractnum-ing strong academics who are not only trendsetters, but also activeparticipants willing to have lively discussions on their views

The changing conditions for ECOOP can and should lead to changes in theconference: I encourage those of you interested in developing ECOOP to look

to the future: which parts of ECOOP should be strengthened? Which should

be changed? The introduction of summer school tutorials is an example of asuccessful change — one that has been appreciated by attendees Perhaps thechange from a larger conference to a smaller, more academic conference with in-tense workshops and lively summer school tutorials provides for a more intimateconference with ample oppertunity for academic interchange

Naturally, the AITO members continually assess the focus and direction ofeach ECOOP The AITO General Assembly meeting, which traditionally is heldthe evening before the main conference opens, includes a discussion on the up-coming ECOOP conferences We appreciate all input from ECOOP attendees,

so I will conclude by encouraging you to pass on your thoughts to any AITOmember

It is both an honor and a pleasure to be presenting the proceedings of the23rd European Conference on Object-Oriented Programming (ECOOP 2009).This year’s ECOOP was held in Genoa, Italy; it had a technical program of 25research papers on a broad range of topics, accompanied by 14 workshops andseven summer school tutorials

Each of the 117 submissions received at least four (and as many as seven)reviews For PC papers five reviews were required, and higher standards applied

As in the previous two years, the authors were given the opportunity to writeshort responses after reading the preliminary reviews

After that, instead of the traditional physical meeting which would have sulted in around 37 tonnes of CO2, the PC had two weeks of intensive deliberati-ons over CyberChairPRO and email, during which further reviews were written,and papers were hotly debated and deeply scrutinized Our virtual meeting wascomplemented by four long conference calls

re-Many PC members had mixed feelings about this mode of deliberarion, and

I am particularly grateful to those who joined the PC despite their skepticism,and to those who had to be awake at 3:00 in the morning to participate in thecalls Although the fun of a physical meeting cannot be matched by conferencecalls, I firmly believe that ECOOP’s high quality of selection was maintained.Consequently, I hope that future chairs will adopt and improve virtual meetings.The PC selected 25 papers, presented in this volume, and awarded two bestpaper prizes: one to Davide Ancona and Giovanni Lagorio, for “CoinductiveType Systems for Object-Oriented Languages,” and the other to Einar Høst andBjarte Østvold for “Debugging Method Names.”

David Ungar was this year’s recipient of the Dahl-Nygaard award, and liam Cook gave the banquet speech The volume also includes summaries of thetwo ECOOP invited talks, namely “Classes, Jim, but not as we know them - Ty-

Wil-pe Classes in Haskell: what, why, and whither,” given by Simon Peyton Jones,and “Java on 1000 Cores: Tales of Hardware/Software Co-design” given by CliffClick The volume concludes with “The Myths of Object-Orientation,” last year’sbanquet speech by James Noble, prefaced by Jan Vitek, last year’s PC chair

I thank the authors of all submitted papers, and the external referees whoprovided excellent reviews I am grateful to AITO and in particular to Eric Jul fortheir trust and their advice when needed, to Richard van de Stadt for helping withand customizing CyberChairPRO to the special needs of this PC, and to the localorganizers – especially Elena Zucca and Davide Ancona – for valuable input to allissues related to the program I am particularly obliged to the PC members fortheir hard work, their enthusiastic debates, their support throughout the process,and their commitment to make a success of ECOOP 2009

ECOOP 2009 was organized by the University of Genoa and the University ofMilan, Italy, under the auspices of AITO (Association Internationale pour lesTechnologies Objets), and in cooperation with ACM SIGPLAN and SIGSOFT

Executive Committee

Conference Chairs

Giovanna Guerrini University of Genoa, Italy)

Program Chair

Sophia Drossopoulou Imperial College, London, UK

Organizing Committee

Organizing Chair

Walter Cazzola University of Milan, Italy

Workshop Chairs

Ferruccio Damiani University of Turin, Italy

Mario S¨udhold Ecole des Mines de Nantes, France

Summer School Committee

Antonio Cisternino University of Pisa, Italy

Paola Giannini University of Piemonte Orientale, Italy

New Zealand

Publicity Chair

XII Organization

Poster and Demo Chairs

Lorenzo Bettini University of Turin Italy

Giovanni Lagorio University of Genoa, Italy

Vittoria Gianuzzi University of Genoa, Italy

Doctoral Symposium Chair

Stephen Nelson Victoria University of Wellington,

Organization XIII

Program Committee

Elisa Baniassad The Chinese University of Hong Kong, ChinaFran¸coise Baude University of Nice Sophia Antipolis, France

Bernhard Beckert University of Koblenz, Germany

Lodewijk Bergmans University of Twente, The Netherlands

John Tang Boyland University of Wisconsin-Milwaukee, USA

Siobhan Clarke Trinity College Dublin, Ireland

Sophia Drossopoulou Imperical College, London, UK

Cormac Flanagan University of California at Santa Cruz, USA

Kathryn E Gray University of Cambridge, UK

Atsushi Igarashi Kyoto University, Japan

Viktor Kuncak Ecole Polytechnique F´ed´erale de Lausanne,

Switzerland

Gary T Leavens University of Central Florida, USA

Oscar Nierstrasz University of Bern, Switzerland

Diomidis Spinellis Athens University of Economics and Business,

Greece

Richard BubelRobert BunyanNicholas CameronWalter CazzolaSelim CiraciCurtis CliftonRoberta CoelhoTal Cohen

David KitchinVladimir KlebanovKenneth KnowlesKrzysztof KuchcinskiAdrian Kuhn

Ivan KurtevGiovanni LagorioRustan LeinoKeren LenzBrian LewisOndrej LhotakAdrian LienhardPeter M¨ullerElton MathiasSean McDirmidFadi MeawadTodd MillsteinDimitris MitropoulosClayton Goodrich MyersMayur Naik

Shin NakajimaSrinivas NedunuriAnders Bach NielsenEmma Nilsson-NymanLennart OhlssonJohan OstlundMatthew ParkinsonDavid J PearceThomas PedersonFabrizio PerinFrances PerryLeaf PetersenBenjamin PierceMarco PistoiaFilip PizloAlex PotaninDaniel P¨ahlerXin Qi

David R¨othlisbergerPritam Roy

Mohan RajagopalanHridesh RajanLukas RenggliJorge RessiaWilliam RetertGregor RichardsRobby

Sven G RobertzArjan de RooChieri SaitoAlberto SardinhaJan Sch¨aferMarco ServettoJeremy SingerSriram SrinivasanRok StrniˇsaKonstantinos StroggylosPhilippe Suter

Daniel TangOlivier TardieuRan TavoryEwan TemperoTachio TerauchiCheng ThaoIgor TsvetkovShmuel TyszberowiczNaoyasu UbayashiGiora UngerPeter Van RoyMichalis VazirgiannisMandana VaziriToon VerwaestMirko ViroliEran WernerNathan WestonBen WiedermannVictor WinterTobias WrigstadLei ZhaoTian ZhaoLukasz ZiarekSteffen Zschaler

Table of Contents

Keynote 1

Classes, Jim, But Not as We Know Them – Type Classes in Haskell:

What, Why, and Whither 1

Simon Peyton Jones

Types, Frameworks and Modelling

Coinductive Type Systems for Object-Oriented Languages 2

Davide Ancona and Giovanni Lagorio

Checking Framework Interactions with Relationships 27

Ciera Jaspan and Jonathan Aldrich

COPE - Automating Coupled Evolution of Metamodels and Models 52

Markus Herrmannsdoerfer, Sebastian Benz, and Elmar Juergens

Aliasing and Transactions

Making Sense of Large Heaps 77

Nick Mitchell, Edith Schonberg, and Gary Sevitsky

Scaling CFL-Reachability-Based Points-To Analysis Using

Context-Sensitive Must-Not-Alias Analysis 98

Guoqing Xu, Atanas Rountev, and Manu Sridharan

NePaLTM: Design and Implementation of Nested Parallelism for

Transactional Memory Systems 123

Haris Volos, Adam Welc, Ali-Reza Adl-Tabatabai,

Tatiana Shpeisman, Xinmin Tian, and Ravi Narayanaswamy

Access Control and Verification

Implicit Dynamic Frames: Combining Dynamic Frames and Separation

Logic 148

Jan Smans, Bart Jacobs, and Frank Piessens

Fine-Grained Access Control with Object-Sensitive Roles 173

Jeffrey Fischer, Daniel Marino, Rupak Majumdar, and

Todd Millstein

Practical API Protocol Checking with Access Permissions 195

Kevin Bierhoff, Nels E Beckman, and Jonathan Aldrich

XVI Table of Contents

Modularity

Adding State and Visibility Control to Traits Using Lexical Nesting 220

Tom Van Cutsem, Alexandre Bergel, St´ ephane Ducasse, and

Wolfgang De Meuter

Featherweight Jigsaw: A Minimal Core Calculus for Modular

Composition of Classes 244

Giovanni Lagorio, Marco Servetto, and Elena Zucca

Modular Visitor Components: A Practical Solution to the Expression

Families Problem 269

Bruno C.d.S Oliveira

Mining and Extracting

Debugging Method Names 294

Einar W Høst and Bjarte M Østvold

MAPO: Mining and Recommending API Usage Patterns 318

Hao Zhong, Tao Xie, Lu Zhang, Jian Pei, and Hong Mei

Supporting Framework Use via Automatically Extracted

Concept-Implementation Templates 344

Abbas Heydarnoori, Krzysztof Czarnecki, and

Thiago Tonelli Bartolomei

Refactoring

Stepping Stones over the Refactoring Rubicon: Lightweight Language

Extensions to Easily Realise Refactorings 369

Max Sch¨ afer, Mathieu Verbaere, Torbj¨ orn Ekman, and Oege de Moor

Program Metamorphosis 394

Christoph Reichenbach, Devin Coughlin, and Amer Diwan

From Public to Private to Absent: Refactoring Java Programs under

Concurrency, Exceptions and Initialization

Loci: Simple Thread-Locality for Java 445

Tobias Wrigstad, Filip Pizlo, Fadi Meawad, Lei Zhao, and Jan Vitek

Table of Contents XVII

Failboxes: Provably Safe Exception Handling 470

Bart Jacobs and Frank Piessens

Are We Ready for a Safer Construction Environment? 495

Joseph (Yossi) Gil and Tali Shragai

Type-Based Object Immutability with Flexible Initialization 520

Christian Haack and Erik Poll

Concurrency and Distribution

Security Monitor Inlining for Multithreaded Java 546

Mads Dam, Bart Jacobs, Andreas Lundblad, and Frank Piessens

EventJava: An Extension of Java for Event Correlation 570

Patrick Eugster and K.R Jayaram

Remote Batch Invocation for Compositional Object Services 595

Ali Ibrahim, Yang Jiao, Eli Tilevich, and William R Cook

ECOOP 2008 Banquet Speech

Introduction to: The Myths of Object-Orientation 618

Jan Vitek

The Myths of Object-Orientation 619

James Noble

Author Index 631

Classes, Jim, But Not as We Know Them — Type Classes in Haskell: What, Why, and

Whither

Simon Peyton Jones

Microsoft Research

Haskell is now quite widely used, but its most important contributions are the

ideas that it embodies In this talk I will focus on one of these ideas, namely type

classes, with a few anecdotes and reflections along the way about the process ofdeveloping the language

Type classes are probably Haskell’s most distinctive feature The original idea

is very neat and, better still, it led to a long series of subsequent tions and innovations Indeed, although the language is now nineteen years old,Haskell’s type system is still in a state of furious development For example, I

generalisa-am involved in adding type-level functions to Haskell, as I will briefly describe

I will explain what type classes are, how they differ from the classes of stream object oriented languages, why I think they are so cool, and what thehot topics are I’ll give plenty of examples, so you don’t need to already knowHaskell

main-S Drossopoulou (Ed.): ECOOP 2009, LNCS 5653, p 1, 2009.

c

Springer-Verlag Berlin Heidelberg 2009

Coinductive Type Systems for Object-Oriented

Davide Ancona and Giovanni Lagorio

DISI, Univ of Genova, Italy

{davide,lagorio}@disi.unige.it

Abstract We propose a novel approach based on coinductive logic to

specify type systems of programming languages

The approach consists in encoding programs in Horn formulas whichare interpreted w.r.t their coinductive Herbrand model

We illustrate the approach by first specifying a standard type systemfor a small object-oriented language similar to Featherweight Java Then

we define an idealized type system for a variant of the language wheretype annotations can be omitted The type system involves infinite termsand proof trees not representable in a finite way, thus providing a the-oretical limit to type inference of object-oriented programs, since onlysound approximations of the system can be implemented

Approximation is naturally captured by the notions of subtyping andsubsumption; indeed, rather than increasing the expressive power of thesystem, as it usually happens, here subtyping is needed for approximatinginfinite non regular types and proof trees with regular ones

1 Introduction

In the context of object-oriented programming, many solutions have been posed to the problem of type inference [17,16,1,21,6,20,12], but the increasinginterest in dynamic object-oriented languages is asking for ever more precise andefficient type inference algorithms [3,12]

pro-Two important features which should be supported by type inference are metric and data polymorphism [1]; the former allows invocation of a method on

para-arguments of unrelated types, the latter allows assignment of values of unrelatedtypes to a field While most proposed solutions support parametric polymor-phism well, only few inference algorithms are able to deal properly with datapolymorphism; such algorithms, however, turn out to be quite complex and can-not be easily specified in terms of a type system

In this paper we propose a novel approach based on coinductive logic to ify type systems of programming languages The approach consists in encodingprograms in Horn formulas which are interpreted w.r.t their coinductive Her-brand model This is made possible by the notion of type constraint defined in

spec-
This work has been partially supported by MIUR EOS DUE - Extensible Object

Systems for Dynamic and Unpredictable Environments

S Drossopoulou (Ed.): ECOOP 2009, LNCS 5653, pp 2–26, 2009.

c

Springer-Verlag Berlin Heidelberg 2009

Coinductive Type Systems for Object-Oriented Languages 3

previous work on principal typing of Java-like languages [7,4] and is a tion of the algorithm presented in [6] In contrast with other approaches based

generaliza-on a unique kind of subtyping cgeneraliza-onstraint, the encoding of a program into a Hornformula is allowed by constraints which are atoms (that is, atomic formulas)

of different forms, each one corresponding to a kind of compound expression ofthe language Coinduction arises naturally at two different levels: at the level ofterms, since recursive types are infinite terms, and at the level of proofs, sincerecursive methods and the use of infinite types require proofs to be infinite aswell

The paper is structured as follows: In Section 2 we provide a first example byformalizing a type system for a fully annotated language similar to FeatherweightJava (FJ) [14]; the example is intended as a way for gently introducing the mainconcepts of the approach and to prepare the reader to the idealized type systempresented in Section 3 and formalized in Section 4 In Section 5 the idealized typesystem is extended with subtyping and subsumption, and soundness is claimed(some proofs are sketched in Appendix B) Finally, conclusion and comments onfurther work can be found in Section 6

2.1 Syntax and Operational Semantics

The syntax of the languages is defined in Figure 1 Syntactic assumptions listed inthe figure have to be verified before transforming a program into a Horn formula

We use bars for denoting sequences: for instance, e m denotes e

1, , e m , τ x n denotes τ1 x1, , τ n x n, and so on.

We assume countably infinite sets of class names c, method names m, field names f , and parameter names x A program consists of a sequence of class

declarations and a main expression from which the computation starts A classdeclaration consists of the name of the declared class and of its direct superclass(hence, only single inheritance is supported), a sequence of field declarations, aconstructor declaration, and a sequence of method declarations We assume a

predefined class Object , which is the root of the inheritance tree and contains

no fields, no methods and a constructor with no parameters A field tion consists of a type annotation and a field name A constructor declarationconsists of the name of the class where the constructor is declared, a sequence

declara-of parameters with their type annotations, and the body, which consists declara-of aninvocation of the superclass constructor and a sequence of field initializations,

4 D Ancona and G Lagorio

v ::= new c(v n)| false | true

Assumptions: n, m, k ≥ 0, inheritance is acyclic, names of declared classes in a program,

methods and fields in a class, and parameters in a method are distinct

Fig 1 Syntax of OO programs

one for each field declared in the class.1 A method declaration consists of a turn type annotation, a method name, a sequence of parameters with their typeannotations, and an expression (the method body)

re-Expressions are standard; even though the conditional expression, and theconstants true and false could be encoded in the language, we have introducedthem for making clearer the connection with union types in Section 3.2 Formaking the examples easier to read, we will also use the primitive type of integers,but leave it out in the formal treatment, which would be straightforward As in

FJ, the expression this is considered as a special implicit parameter.

A type annotation can be either the primitive type bool or a class name

Finally, the definition of values v is instrumental to the (standard) small steps

operational semantics of the language, indexed over the class declarations defined

by the program, given in Figure 2

(field-1)cbody(cds, c) = (x n , {super( .); f = e
;k }) f = f i 1≤ i ≤ k

This is a generalization of constructors of FJ, which makes the encoding

composi-tional: a constructor declaration contained in a class c can be encoded if just the name c and the fields declared in c are known.

Coinductive Type Systems for Object-Oriented Languages 5

For reasons of space, the rule for contextual closure and the standard definition

of contexts have been omitted (to be as general as possible, no evaluation strategy

is fixed); furthermore side conditions have been placed together with premises

Auxiliary functions cbody and mbody are defined in Appendix A.

Rule (field-1) corresponds to the case where the field f is declared in the same

class of the constructor, otherwise rule (field-2) applies and the field is searched

in the direct superclass The notation e[e n /x n] denotes parallel substitution of

x i by e i (for i = 1 n) in expression e.

In rule (invk), the parameters and the body of the method to be invoked are

retrieved by the auxiliary function mbody, which performs the standard method

look-up If the method is found, then the invocation reduces to the body of themethod where the parameters are substituted by the corresponding arguments,

and this by the receiver object (the object on which the method is invoked).

The remaining rules are trivial

The one step reduction relation on programs is defined by: (cds e) → (cds e )

iff e → cds e  Finally, → ∗ and→ ∗

cds denote the reflexive and transitive closures

of→ and → cds, respectively

2.2 Encoding of Programs into Horn Formulas

Since Prolog is the most direct way to implement a prototype interpreter forcoinductive logic programming (see the conclusion), we follow the standard Pro-

log syntax notation We assume two countably infinite sets of predicate and function symbols each associated with an arity n ≥ 0, and ranged over by p and f respectively, and a countably infinite set of logical variables ranged over

by X Functions with arity 0 are called constants We write p/n, f /n to mean that predicate p, function f have arity n, respectively For symbols we follow the

usual convention: function and predicate symbols always begin with a lowercaseletter, whereas variables always begin with an uppercase letter

A Horn formula Hf is a finite conjunction (or, more abstractly, a finite set)

of clauses (ranged over by Cl ) of the form A ← B, where A is the head and B

is the body.

The head is an atom, while the body is a finite and possibly empty conjunction

of atoms; the empty conjunction is denoted by true A clause with an empty body (denoted by A ← true) is called a fact An atom has the form2 p(t n) where thepredicate p has arity n and t n are terms.

For list terms we use the standard notation [ ] for the empty list and [| ] for the list constructor, and adopt the syntax abbreviation [t n ] for [t

1|[ [t n |[ ]]].

A formula/clause/atom/term is ground if it contains no logical variables.

In the following simple examples terms are built in the usual inductive3 wayfrom functions symbols and logical variables In particular, the Herbrand uni-

verse of a Horn formula, obtained from a program prog , is the set of all terms

6 D Ancona and G Lagorio

inductively defined on top of the constant [ ] and all constants representing class,

method and field names declared in prog , and on top of the binary function

Method add can be encoded in the following clause:

has meth(nelist , add, [E ], nelist) ←

type comp(E, object), new (nelist, [E, nelist], nelist), override (list, add, [object], nelist).

The clause states that for all types E , class NEList5 has a method named add

taking one argument6 of type E and returning a value of type NEList (atom has meth(nelist, add, [E], nelist)), if the following constraints are satisfied:

– E is type compatible with Object (atom type comp(E, object)),

– the constructor of class NEList takes two arguments, the former of type E

and the latter of type NEList , and returns7an object of type NEList (atom new (nelist, [E, nelist], nelist)),

– in case of overriding, the signature of the method is compatible with method

add of the direct superclass List (atom override (list, add, [object], nelist)).

Note that if some of the constraints above cannot be satisfied, then the methodadd (hence, the whole program) is not well-typed (the conjunction of atoms

B cd n defined in Figure 4 explicitly requires that all declared methods must bewell-typed)

Each constraint corresponds to an atom which is directly generated from the

method declaration: type comp(E, object) is derived from the type annotation of the parameter of add , new (nelist, [E, nelist], nelist) is generated from the body

of add , and override (list, add, [object], nelist) depends from the direct superclass

of NEList , and the signature and return type of add

Sec-Coinductive Type Systems for Object-Oriented Languages 7

To encode a method body into a conjunction of constraints (that is, atoms) wefollow the consolidated constraint-based approach to compositional typecheckingand type inference of Java-like languages [5,7,4,15,6]: each kind of compoundexpression is associated with a specific predicate:

– new (c, [t n ], t) corresponds to object creation, c is the class of the invoked constructor, t n the types of the arguments, and t the type of the newly

created object (recall footnote 7)

– field acc(t1, f , t2) corresponds to field access, t1 is the type of the accessed

object, f the field name, and t2the resulting type of the whole expression;

– invoke(t0, m, [t n ], t) corresponds to method invocation, t0is the type of the

receiver, m the method name, t n the types of the arguments, and t the

type of the returned value This predicate is completely redundant here (its

definition is identical to has meth), but not in the type system defined in

Section 3.2;

– cond (t1, t2, t3, t) corresponds to conditional expression, t1 is the type of the

condition, t2and t3the types of the “then” and “else” branches, respectively,

and t the resulting type of the whole expression.

Besides those predicates needed to encode an expression, others are instrumental

to the encoding, as type comp and override above.

The encoding of a program is defined in Figure 3, whereas Figure 4 contains

the set of clauses Hf defaultwhich are shared by all programs, and the conjunction

of atoms B cd n which imposes the requirement that each method declaration

in cd n

must be well-typed Note that not all formulas in Figure 4 are Horn

clauses; indeed, for brevity we have used the negation of predicates dec field and dec meth However, since the set of all field and method names declared in a program is finite, the predicates not dec field , not dec meth could be trivially

defined by conjunctions of facts, therefore all formulas could be turned into Hornclauses

For the encoding we assume bijections to translate class, field and methodnames to constants, and parameter names to logical variables (translations aredenoted by
c,
f,
m, and
x, respectively) Furthermore, we assume that  this = This

The rules define a judgment for each syntactic category of the OO language:

requiring that each method declared in cd n

is well-typed (see Figure 4),

whereas B m is the conjunction of atoms generated from the main expression

e of the program;

– fd in c
Cl, md in c
Hf : the encoding of a field/method declaration

depends on the class c where the declaration is contained;

– cn in fds
Cl: the encoding of a constructor declaration depends on the

declaration of the fields contained in the class of the constructor: the

encod-ing is defined only if all fields in fds are initialized by the constructor in the

8 D Ancona and G Lagorio

new (
c, A,
c) ← type comp(A, [
τ n]), B m , extends(
c, P ),

new ( P, [t m], P ), B
k , type comp([t
k], [
τ
k]).

τ0 m( τ x n){e} in c

dec meth (
c,
m , [
τ n

],
τ 0)← true.

has meth (
c,
m , A,
τ 0)← type comp(A, [
τ n]), extends(
c, P ),

override (P,
m, [
τ n],
τ0), B, type comp(t,
τ0).

true inV
(bool | true) (false)false inV
(bool | true)

Fig 3 Encoding of programs

same order8as they appear in fds (that is, as they have been declared in the

class of the constructor);

– e in V
(t | B): an expression is encoded in a pair (t|B), where t is

the term encoding the type of the expression, and B the conjunction of

atoms generated from the expression The encoding depends on the type

8

This last restriction is just for simplicity

Coinductive Type Systems for Object-Oriented Languages 9

class(object ) ← true.

subclass(X , X ) ← class(X ).

subclass(X , object) ← class(X ).

subclass(X , Y ) ← extends(X , Z ), subclass(Z , Y ).

type comp(bool , bool) ← true.

type comp(C1 , C2 ) ← subclass(C1 , C2 ).

type comp([ ] , [ ]) ← true.

type comp([T1 |L1 ], [T2 |L2 ]) ← type comp(T1 , T2 ), type comp(L1 , L2 ).

field acc(C , F , T ) ← has field(C , F , T ).

invoke(C , M , A, R) ← has meth(C , M , A, R).

new (object, [ ], object) ← true.

has field (C , F , T ) ← dec field(C , F , T ).

type comp(T1 , bool), type comp(T2 , T4 ), type comp(T3 , T4 ).

B cd n is the conjunction of atoms generated from cd nas follows:

has meth (
c,
m, [
τ1, ,
τ k],
τ0) is in B cd n iff class c is declared in cd n and contains

and adds to them the two new facts stating respectively that class c1 has been

declared and that its direct superclass is c2

A constructor declaration generates a single clause whose head has the form

new (
c, A,
c), where c is the class of the constructor, A is the logical variable corresponding to the list of arguments passed to the constructor, and c is the

type of the object9created by the constructor The first atom in the body checks

that the list of arguments A is type compatible w.r.t the of parameter type notations, that is, that A is a list of exactly n types which are subtypes of the

an-corresponding type annotations (see the 3rd and 4th clause defining predicate

type comp in Figure 4) However, all occurrences of the parameters are directly

encoded by the corresponding types as specified by the environment{x:τ n } (see

9

We have already pointed out that the third argument of new is completely redundant

here, but this is not true for the type system defined in Section 3.2

10 D Ancona and G Lagorio

rule (var) below) The atoms B m

, extends(
c, P ), new (P, [t m ], P ) encode the vocation of the constructor of the direct superclass, where B m

in-and t m are the

atoms and types generated from the arguments (see the first premise) Finally,

the remaining atoms check that the field f k

declared in the class are initialized

correctly; B k

and t k are the atoms and types generated from the initializing

expressions (see the second premise) Finally, note that the clause is correctlygenerated only if: (1) the free variables of the expressions contained in the con-structor body are contained in the set {x n } of the parameters (therefore, this

cannot be used); (2) all fields declared in the class are initialized exactly onceand in the same order as they are declared

Rule (meth-dec) generates two clauses, one for the predicate dec meth and the other for the predicate has meth Predicate dec meth specifies just the sig- natures and return types of all methods declared in c, and is used for defining predicates override and has meth (see Figure 4); predicate has meth specifies

names, and argument and return types of all methods (either declared or herited) of a class The clauses generated by this rule correspond to the casewhen the method is found in the class, whereas there is a unique shared clause(defined in Figure 4) to deal with method look-up in the direct superclass

in-Atoms extends(
c, P ), override(P,
m, [
τ n ],
τ0) ensure that the method overrides

correctly the method (if any) inherited from the direct superclass P Atoms

B , type comp(t,
τ0) check that the body is correct and that the type of the

re-turned value is compatible with the declared type Note that the variable this can be accessed in the body of the method and that it has type c, as specified

in the environment{This:c, x:τ n }.

Rule (var) can be instantiated only if x is defined in the environment V ; the associated type t is returned together with the empty conjunction of atoms.

The other rules for expressions (except for the trivial ones on booleanconstants) are very similar: premises generate types and atoms for all subex-pressions, then the conclusion collects all generated atoms, adds a new atomcorresponding to the whole expression, and generates a fresh variable (to avoidclashes) for the type of the whole expression

Clauses defined in Figure 4 are quite straightforward For instance, they state

that Object is a predefined class which is the root of the inheritance relation and which has a default constructor with no parameters Since Object cannot be

redefined, it turns out that the class declares no fields and no methods

The definition of field acc is identical to dec field , but this is no longer true

for the type system defined in the next section (see Section 3.2)

The predicate override checks that methods are overridden correctly (we use

the most restrictive formulation asking types of arguments and of the returned

value to be all invariant); the first clause specifies that all methods of class Object are overridden correctly (since, in fact, object has no methods), the second states

that a method declared in a class is overridden correctly only by a method havingthe same name and types of parameters and returned value, while the last clausesays that a method is overridden correctly if it is not declared in the class and

if it is overridden correctly in the direct superclass

Coinductive Type Systems for Object-Oriented Languages 11

Finally, the clause defining cond states that a conditional expression is correct

if the type of the condition is bool (we use type comp for uniformity with the

definitions given in Section 4); the corresponding type is any common super type

of the expressions of the two branches

Coinductive Herbrand Models Well-typed programs are defined in terms

of coinductive Herbrand models, that is, greatest instead of least fixed-pointsare considered

As we will see in Section 3.4, coinduction arises naturally at two differentlevels: at the level of terms, since recursive types are infinite10 terms, and atthe level of proofs, since recursive methods and the use of infinite types requireproofs to be infinite as well

The Herbrand base of a Horn formula obtained from a program prog is the set

of all ground atoms built from the predicates in the formula and the (ground)terms of the Herbrand universe of the formula

A substitution θ is defined in the standard way as a total function from logical

variables to terms, different from the identity only for a finite set of variables.Composition of substitutions and application of a substitution to a term are

defined in the usual way A ground instance of a clause A ← A 1 A n is a

ground clause Cl s.t Cl = Aθ ← A 1 θ, , A n θ for a certain substitution θ Given a Horn formula Hf , the immediate consequence operator T Hf is an

endofunction defined on the parts of the Herbrand base of Hf as follows:

T Hf (S) = {A | A ← B is a ground instance of a clause of Hf , B ∈ S}.

A Herbrand model of a logic program Hf is a subset of the Herbrand base of

Hf which is a fixed-point of the immediate consequence operator T Hf Since

T Hf is monotonic for any prog, by the Knaster-Tarski theorem there always exists the greatest Herbrand model of Hf , which is also the greatest set S s.t.

S ⊆ T Hf (S) The greatest Herbrand model of Hf is denoted by M co (Hf ) and called the coinductive Herbrand model of Hf

A conjunction of atoms B is satisfiable in Hf iff there exists a substitution θ s.t B θ ⊆ M co (Hf ).

A program cd n

e is well-typed iff cd n

e
(Hf |B) and B is satisfiable in Hf

Finally, we only informally state the claim and do not prove it (since it is out

of the scope of this section) that the notion of well-typed program is equivalent

to that given by a conventional type system (like that of FJ)

Claim (informal equivalence) A program cd n

e is well-typed w.r.t to a standard type system iff cd n

e
(Hf |B) and B is satisfiable in Hf

3 An Idealized Type System: An Outline

In this section we present a more advanced type system supporting methodand data polymorphism The type system is idealized since it involves infinite10

However, in the simple type system defined here infinite terms are not needed

12 D Ancona and G Lagorio

terms and proof trees not representable in a finite way, therefore only soundapproximations of the system can be implemented Under this perspective, thesystem could be considered as an abstract specification for a large class of typeinference algorithms for object-oriented programs which can only be sound butnot complete w.r.t the given system, and, thus, an attempt at pushing to theextreme the theoretical limits of static type analysis

3.1 Extension of the Syntax

At the syntax level the only needed extension to the language defined in Section 2concerns type annotations which now can be empty, that is, users can omit(partially or totally) field and method type annotations:

τ ::= N | 

N ::= c | bool

This extension does not affect the operational semantics given in Figure 2

A type annotation τ can be either a nominal type N (the primitive type bool

or a class name c), or empty Consider for instance the following example:

in-Type annotations are intended as explicit constraints imposed by the user, but

do not make type analysis less precise For instance, if the declaration of field

el is annotated with type Item, then only instances of Item or of a subclass ofItem can be correctly added to a list However, if we add to a list an instance ofExtItem which is a subclass of Item, then the type system is able to assign tothe first element of the list the type ExtItem

3.2 Structured Types

To have a more expressive type system, we introduce structured types encoded

by the following terms:

Coinductive Type Systems for Object-Oriented Languages 13

– X , which represents a type variable;

– bool , which represents the type of boolean values;

– obj (
c, t), which represents the instances of class c, where t is a record

[
f1:t1, ,
f n :t n ] which associates with each field f i of the object a

corre-sponding type term t i; as in the type system of Section 2, the methods of aclass are encoded as clauses, whereas the types of fields need to be associatedwith each single instance, to be able to support data polymorphism;

– t1∨ t2, which represents a union type [8,13]: an expression has type t1∨ t2if

– The difference between predicates type comp and subclass is now evident:

type comp/2 (see Figure 6) defines the relation of type compatibility between

structured and nominal types For instance, the atom

type comp(obj ( c
1, t1)∨ obj (
c2, t2),
c)

is expected to hold, whenever both c1 and c2are subclasses of c.

– The first and third argument of predicate new are now clearly different: the

former is the class name of the invoked constructor, whereas the latter is thestructured type of the created object The following invariant is expected to

hold: if new (
c, [t n

], t) holds, then type comp(t,
c) holds as well.

– Predicates invoke and has meth are now clearly distinct: the first argument

of invoke is the structured type of the receiver, whereas the first argument

of has meth is the class from which method look-up is started.

3.3 Typing Methods

As already mentioned, type annotations are intended as explicit constraints posed by the user, but do not make type analysis less precise For instance, if

im-we assume that a program declares11classes H and P, with H subclass of P, and

we annotate the parameter of method add of class EList as follows

a d d ( P e ){new N E L i s t (e , t h i s )}

then new EList().add(e) is not well-typed if e=new Object(), while it has

type obj (
NEList , [
el :obj (
H , [ ]),  next:obj (
EList , [ ])]) if e=new H() (hence, the

type associated with field el corresponds to an instance of H rather than P) Thismeans that, during type analysis, parameters are associated with a structuraltype (even when they are annotated) which depends on the specific methodinvocation

11

Note that here H and P denotes concrete names and are not meta-variables

14 D Ancona and G Lagorio

Similarly, the type of this cannot be fixed (we cannot simply associate with

it the class name where the method is declared, as done in Section 2), therefore

this is treated as an implicit parameter which is always the first of the list The only implicit constraint on this requires its associated type to be type compatible

with the class where the method is declared Consider for instance the followingclass declaration:

c l a s s C { val ; C ( v ){ super (); val = v ;} get (){ t h i s val } }

Method get generates the following clause:

has meth(
C ,  get, [This], X ) ← type comp(This,
C ), field acc(This,  val , X ).

The head of the clause requires method get of class C to have just the implicit

parameter this (indeed, no explicit parameters are declared), whereas the body requires this to be an instance of either C or a subclass of C, and to have a field val of type X Hence, if e has type obj (
C , [  val :t ]), then the expression e.get() has type t

A quite standard consequence of type inference [16,17,1,21] is that no rule

is imposed on method overriding Consider for instance the following two classdeclarations:

c l a s s P { P (){ super ();} m (){new A ()} }

c l a s s H extends P { H (){ super ();} m (){new B ()} }

In this very simple example method m of class P always returns an instance of

A, but is overridden by the method of H which always returns an instance of B,where A and B are two unrelated classes The definition of method m of class Hwould not be considered type safe in Java, if we assume to annotate methods

m in P and in H with the return type A and B, respectively Indeed, in Java thetype of an instance of class H is a subtype of the type of an instance of class P

In the type system defined here the structural type obj (
H , [ ]) is not a subtype

of obj (
P , [ ]); indeed, an object type obj (
c1, t1) is a subtype of obj ( c
2, t2) if

and only if c1 = c2 and t1 is a record type which is a subtype of the record

type t2 (w.r.t the usual width and depth subtyping relation, see Section 5.3for the formal definition) In this way the two method declarations above are

perfectly legal, and the method invocation e.m() has type obj (
A, [ ]) if e has type obj (
P , [ ]), obj (
B , [ ]) if e has type obj (
H , [ ]), and obj (
A, [ ]) ∨ obj (
B , [ ])

if e has type obj (
P , [ ]) ∨ obj (
H , [ ]).

3.4 Regular Types

Whereas in Section 2 types are just constants, here we take a coinductive proach by allowing types (and, hence, terms) to be infinite This is essential toencode recursive types Consider for instance the following class declarations:

ap-Coinductive Type Systems for Object-Oriented Languages 15

c l a s s List extends Object {

The expression new List().altlist(i,new A()) returns an empty list (an

in-stance of EList) if i ≤ 0, or, if i > 0, a non empty list (an inin-stance of NEList) whose length is i and whose elements are alternating instances of class A and

B (starting from an A instance) Similarly,new List().altlist(i,new B())turns an alternating list starting with a B instance

re-The following two mutually recursive types t A and t B precisely describe

new List().altlist(i,new A())andnew List().altlist(i,new B()), tively:

respec-t A = obj (
EList , [ ]) ∨ obj (
NEList , [
el :obj (
A , [ ]),  next :t B])

t B = obj (
EList , [ ]) ∨ obj (
NEList , [
el :obj (
B , [ ]),  next :t A])

In fact, t A and t B correspond to regular infinite trees (see in the following).However, coinductive terms include also non regular trees12[19] (see Section 5.1)

4 An Idealized Type System: A Full Formalization

In Section 2 types are just constants, whereas here types can be infinite terms,therefore the coinductive version of the Herbrand universe and base needs to beconsidered In the rest of the paper we will identify terms with trees

The definition of tree which follows is quite standard [11,2] A path p is a finite

and possibly empty sequence of natural numbers The empty path is denoted by

, p1· p2denotes the concatenation of p1 and p2, and|p| denotes the length of p.

We first give a general definition of tree, parametric in the set S of nodes, and

then instantiate it in the case of terms and idealized proof trees

A tree t defined over a set S is a partial function from paths to S s.t its domain (denoted by dom(t )) is prefix-closed, not empty, and verifies the following closure property: for all m, n and p, if p · n ∈ dom(t) and m ≤ n then p · m ∈ dom(t).

12

That is, infinite trees which cannot be finitely represented

16 D Ancona and G Lagorio

If p ∈ dom(t), then the subtree of t rooted at p is the tree t  defined bydom(t ) ={p  | p · p  ∈ dom(t)}, t  (p  ) = t (p · p  ); t  is said a proper subtree of

Note that, by definition, if t (p) = X , then p · n  ∈ dom(t) for all n; the same

consideration applies for constants (hence, logical variables and constants canonly be leaves)

Regular terms can be finitely represented by means of term unification problems

[19], that is, systems of a finite number of equations [11,2] of the form X = t (where t

is a finite term which is not a variable) Note that Horn formulas are built over finiteterms; infinite terms are only needed for defining coinductive Herbrand models.The definition of coinductive Herbrand universe and base of a Horn formula

Hf is a straightforward extension of the conventional definition of inductive

Herbrand universe and base, where terms are defined as above

A useful characterization of coinductive Herbrand models is based on the

notion of idealized proof tree [19,18].

An idealized proof tree T (proof for short) for a Horn formula Hf is a tree defined over the coinductive Herbrand base of Hf , satisfying the following ad- ditional property: for all paths p in dom(T ), if T (p) = A, m = min{n | p · n  ∈ dom(T )}, and for all n < m T (p · n) = A n , then A ← A 0 , , A m−1 is a ground

instance of a clause of Hf

A proof T for a Horn formula Hf is a proof of the atom A iff T () = A It can

be proved [19,18] that{A | A ground, ∃ proof T for Hf of A } is the coinductive Herbrand model of Hf

4.1 Encoding of Programs into Horn Formulas

The encoding of programs for the idealized type system is defined in Figure 5,

whereas Figure 6 contains the set of clauses Hf defaultwhich are shared by all grams For completeness, all rules and clauses have been included, even thoughsome of them are the same as those defined in Figure 3 and Figure 4 Rules andclauses which are different are highlighted

pro-Soundness of the encoding is claimed in Section 5, where the system is tended with subtyping and subsumption

ex-For simplicity, as already done in Figure 4, in Figure 6 we have used someconvenient abbreviation; besides¬dec field and ¬dec meth, inequality has been

introduced for field names; however, since the set of all field names declared in aprogram is finite,= could be trivially defined by conjunctions of facts, thereforeall formulas could be turned into Horn clauses

Before explaining some details, it is interesting pointing out the main ences with the encoding defined in Section 2

differ-Coinductive Type Systems for Object-Oriented Languages 17

new (
c, [
x n

], obj (
c, [
f:t
k |R])) ← type comp([
x n], [
τ n]), B m ,

extends (
c, P ), new (P, [t m], obj (P, R)), B
k , type comp([t
k], [
τ
k]).

(meth-dec) e in {This,
x n }
(t | B)

τ0m( τ x n){e} in c

dec meth(
c,
m) ← true.

has meth (
c,
m , [This,
x n], t) ← type comp(This,
c),

true inV
(bool | true) (false)

false inV
(bool | true)

Fig 5 Encoding of programs for the idealized type system (rules with underlined name

in bold are those different w.r.t Figure 3)

18 D Ancona and G Lagorio

Here only those methods which might be invoked during the execution of themain expression are required to be type safe, and no overriding rule is imposed.These differences stem from the fact that the encoding of Section 2 corre-sponds to the specification of a typechecking algorithm (since programs are fullyannotated with types), whereas here we are specifying a type inference algorithmwhich has to work with programs which may have no type annotations at all.Earlier error detection is sacrificed in favor of a more precise type analysis Thisapproach is not new, indeed it is followed by most of the proposed solutions tothe problem of type inference of object-oriented programs [17,16,1,12]

More in details, these two main differences are reflected by the fact that in rule

(prog) only the atoms B m generated from the main expression are considered,

and that in Figure 6 no override predicate is defined Note that the type system could be easily made more restrictive, by adding to B m in rule (prog) the atoms

B cd n generated from cd n

as follows: all atoms contain distinct logical variables,

and has meth(
c,
m, A, R) is in B cd n iff class c is declared in cd n

and declares a

method m Then it would be possible to accept only programs s.t the formula

B m , B cd n is satisfiable (for types different from the bottom) In this way, thetype system would reject programs containing methods which are inherentlytype unsafe, even though unused On the other hand, a method m which is notinherently type unsafe as m(x){x.foo()} would not be well-typed in a programwhere no class declares a method foo

We only comments rules and clauses which are new or significantly differentw.r.t those given in Section 2

The clause generated from rule (constr-dec) is very similar to that in Figure 3,

except for the following two differences: (1) the type returned by new is the structured type obj (
c, [
f:t  k |R]) where the types t k of the fields f k declared inthe class are determined by the initializing expressions e k , whereas R is the

record assigning types to the inherited fields, which is derived from the type

obj (P, R) returned by the invocation of the constructor of the direct superclass; (2) n logical variables x n need to be explicitly introduced since such variablesare used for passing the actual types each time the constructor is invoked This

difference is reflected in the environment V used in the judgments for expressions

which simply contains the parameters, but no associated types (see also the rule(var)) Finally, since type annotations can be empty, we have to define
; because type comp(t ,
) must be always true (no additional constraint is imposed), for

simplicity we adopt the convention that
 always generates a fresh variable.

In rule (meth-dec) the main differences w.r.t Figure 3 (except for those

al-ready mentioned for (constr-dec)) are that this has to be dealt as an implicit

parameter (the first of the list) of the method, and that no rule on ing13is imposed Predicate dec meth has only two arguments since the types of

overrid-arguments and of the returned value are no longer needed.14

Coinductive Type Systems for Object-Oriented Languages 19

class(object ) ← true.

subclass(X , X ) ← class(X ).

subclass(X , object) ← class(X ).

subclass(X , Y ) ← extends(X , Z ), subclass(Z , Y ).

type comp(bool , bool) ← true.

type comp([ ], [ ]) ← true.

type comp([T1 |L1 ], [T2 |L2 ]) ← type comp(T1 , T2 ), type comp(L1 , L2 ).

∗type comp(obj (C1 , X ), C2 ) ← subclass(C1 , C2 ).

∗type comp(T1 ∨ T2 , C ) ← type comp(T1 , C ), type comp(T2 , C ).

∗field acc(obj (C , R), F , T ) ← has field(C , F , TA), field(R, F , T ), type comp(T , TA).

∗field acc(T1 ∨ T2 , F , FT1 ∨ FT2 ) ← field acc(T1 , F , FT1 ), field acc(T1 , F , FT1 ).

∗field([F :T |R], F , T ) ← true.

∗field([F1 :T1 |R], F2 , T ) ← field(R, F2 , T ), F1
= F2

∗invoke(obj (C , S), M , A, R) ← has meth(C , M , [obj (C , S)|A], R).

∗invoke(T1 ∨ T2 , M , A, R1 ∨ R2 ) ← invoke(T1 , M , A, R1 ), invoke(T2 , M , A, R2 ).

∗new(object, [ ], obj (object, [ ])) ← true.

has field (C , F , T ) ← dec field(C , F , T ).

has field (C , F , T1 ) ← extends(C , P), has field(P, F , T1 ), ¬dec field(C , F , T2 ).

∗has meth(C , M , A, R) ← extends(C , P), has meth(P, M , A, R), ¬dec meth(C , M ).

∗cond(T1 , T2 , T3 , T2 ∨ T3 ) ← type comp(T1 , bool).

Fig 6 Definition of Hf default for the idealized type system (clauses marked with anasterisk are those different w.r.t Figure 4)

For what concerns Figure 6, new clauses have been introduced to deal with

union types: invoking a method M with arguments of type A on an object of type T1∨ T2 is correct if the same method with the same argument type can

be invoked on type T1 and on type T2, and the resulting type is the union

of the two obtained types R1 and R2 Note that conditional expressions can

be typed in a more precise way with the union of the types of the twobranches

In the first clause of predicate field acc, after retrieving the type of the field from the record part of the type of the object (a new predicate field has been

introduced), it is checked that such a type is compatible with the type annotationassociated with the field declaration This check can be useful for analyzing openexpressions (for closed expressions the check is redundant since is already done

at creation time)

5 Extending the System with Subtyping

In this section we extend the idealized type system presented in Section 3 andSection 4 with subtyping and subsumption; rather than increasing the expressivepower of the system, subtyping and subsumption allow sound (but not complete)implementation of the system, by supporting approximation of infinite non reg-ular types and proof trees with regular ones

20 D Ancona and G Lagorio

5.1 Non Regular Types

Non regular (hence infinite) types may be inferred for quite simple expressions.For instance, assume to add to class List the following method declaration:

b a l L i s t ( i ){

i f (i <=0) new EList ()

e l s e new NEList (new A () ,

t h i s balList (i -1) addLast (new B ()))

}

where the obvious declarations of methods addLast in classes EList and NEList

have been omitted Method balList generates all linked lists of the form a i b i (where i ≥ 0, and a and b denote the instances of class A and B, respectively) It

is well known that the language{a i b i | i ≥ 0} is not regular; indeed, the most

precise type of new List().balList(i) is the non regular term t0 defined bythe following system containing a countably infinite number of equations:

n])

Of course, type t0 can be inferred with a non regular proof (see Section 5.2),while a type inference algorithm would only be able to infer a regular type,15

like the following:

t = obj (
EList , [ ]) ∨ obj (
NEList , [
el :obj (
A, [ ]) ∨ obj (
B , [ ]),  next:t ])

To infer t subtyping and subsumption have to be introduced in the type system; indeed, as explained in Section 5.3, t0 is a subtype of t

5.2 Non Regular Proofs

Consider the following method declaration added to class List:

d u p l i c a t e ( i ,e , l ) {

i f (i <=0) l e l s e t h i s duplicate (i -1 , e ,new NEList (e , l )) }

Method duplicate adds n (with n = max(0,i)) duplicates of the element e at

the beginning of the list l

Let us consider the expression new List().duplicate(i,e,l), where i, e

and l are expressions of type int, t e , and t l, respectively In our system it is

possible to prove that the expression has the type t0 defined by the following

infinite set of equations (where n ranges over the natural numbers):

t n = t n  ∨ t n+1 t 

0= t l t n+1  = obj (
NEList , [
el :t e ,  next:t 

n])

15

Indeed, it can be shown that there exist infinitely many regular types which can

approximate t with an arbitrary precision

Coinductive Type Systems for Object-Oriented Languages 21

Indeed, a non regular proof can be built containing the following atoms:

invoke(obj (  List , [ ]),
duplicate, [int, t e , t0 ], t0)

invoke(obj (  List , [ ]),
duplicate, [int, t e , t1 ], t1)

invoke(obj (  List , [ ]),
duplicate, [int, t e , t n  ], t n)

.

Intuitively, each atom corresponds to a recursive call of the infinite sequence

(starting from the top) which is generated when the value of i tends to +∞ However, type t0 is provably equivalent (see Section 5.3) to the followingregular type:

t = t l ∨ obj (
NEList , [
el :t e ,  next:t ]) But type t can be inferred with a regular proof only with subsumption To see

that, we first prove that the atom

(1) invoke (obj (  List , [ ]),
duplicate, [int, t e , t], t) holds This derives from the fact that t and t ∨ t are equivalent and that (2) invoke (obj (  List , [ ]),
duplicate , [int, t e , obj (
NEList , [
el :t e ,  next:t ])], t) holds But obj (
NEList , [
el :t e ,  next:t ]) is a subtype (see Section 5.3) of t , hence, by

subsumption16, (2) holds if (1) holds, and we conclude by coinductive hypothesis

Finally, from (1) we have that invoke(obj (  List , [ ]),
duplicate , [int, t e , t l ], t) holds

by subsumption, since t l is a subtype of t

5.3 Formal Definitions

Subtyping is coinductively defined by the following rules, where, for simplicity,

we assume that field names in object types are distinct:

(bool)

bool ≤ bool (obj)

∀ i = 1 m f π(i) = f i t π(i) ≤ t 

i obj (c, [f :t n])≤ obj (c, [f  :t m]) π:{1 m}→{1 n}

(distr)obj (c, [f :t n , f :t f , f  :t m])≤ t obj (c, [f :t n , f :t f  , f  :t m])≤ t

obj (c, [f :t n , f :t f ∨ t 

f , f  :t m])≤ t

16

We are applying the counter-variant rule which says that if a method invocation has

a type, then it has the same type for any invocation where an argument of type t a has been replaced with a new argument of a subtype of t a

22 D Ancona and G Lagorio

Rule (obj) uses standard width and depth record subtyping, but is invariantw.r.t the class of the object Since all field names are assumed to be distinct, in

rule (obj) π must necessarily be injective and, therefore, n ≥ m.

Rule (∨R1), (∨R2) and (∨L) are standard Rule (distr) ensures that object

types “distributes over” union; by (distr), (∨R1), (∨R2) and (obj) we prove that obj (c, [f :t1∨ t2])≤ obj (c, [f :t1])∨ obj (c, [f :t2]), whereas by (∨L), (∨R1), (∨R2) and (obj) we prove that obj (c, [f :t1])∨ obj (c, [f :t2])≤ obj (c, [f :t1∨ t2])

To avoid unsound subtyping we require some contractiveness conditions [9,10]

A particular care must be taken when proving subtyping between non tractive types; for instance, by coinductively applying rule (∨R1) or (∨R2) we can obtain t ≤ ⊥ for every t, which is clearly unsound A similar issue arises

con-with rule (distr) Instead of the more drastic solution of prohibiting the tiation of rules (∨R1), (∨R2) and (distr) with non contractive types, we prefer

instan-to require meta-proofs instan-to be contractive

A meta-proof for t1≤ t2is contractive if it does not contain an infinite subtree

which is obtained by instantiating only rules (∨R1), (∨R2) and (distr).

Finally, we say that t1 ≤ t2 holds if there exists a (coinductive) contractive

meta-proof for t1≤ t2built with the subtyping rules defined above

We define on top of subtyping a notion of subsumption between atoms To do this, we first need to annotate each predicate of arity n with a string α of length

n (where α(i) denotes the annotation of the i-th argument), specifying whether

arguments are covariant (≤), contravariant (≥) or invariant (=) For instance,

we write p/ ≤≥= to mean that predicate p has 3 arguments, and that the first is

covariant, the second contravariant and the last invariant

If p/α, then the ground atom p(t n ) subsumes the ground atom p(t n) iff forall i = 1 n the relation t i α(i) t i  holds, where t ≥ t  holds iff t  ≤ t holds, and

t = t  holds iff t and t  are syntactically equal.

Let us consider the invoke predicate Clearly it must be contravariant w.r.t.

the arguments corresponding to the receiver and the arguments passed to themethod, covariant w.r.t the type of the returned value, and invariant w.r.t the

name of the method, therefore invoke/ ≥=≥≤

For instance, invoke(obj (c1, [ ]), m,[obj (c3, [f1:t1, f3:t3])], obj (c4, [ ])) is subsumed

by invoke (obj (c1, [ ]) ∨ obj (c2, [ ]), m, [obj (c3, [f1:t1])], obj (c4, [f2:t2]))

The annotations for the other predicates encoding expressions are the

follow-ing: new /=≥≤ , field acc/ ≥=≤ , cond / ≥≥≥≤ All the remaining predicates can beinvariant in all arguments

Coinductive Type Systems for Object-Oriented Languages 23

The immediate consequence operator T Hf as defined in Section 2 can be nowrefined with the notion of subsumption:

T Hf (S) = {A  | A ← B is a ground instance of a clause of Hf

A subsumes A  and B ∈ S}.

The definition of idealized proof tree can be easily refined in a similar way

5.4 Soundness of the System

Soundness follows by progress and subject reduction theorems below; the formerstates that a well-typed program cannot get stuck, the latter states that if a well-typed program reduces, then it reduces to a well-typed program The proofs ofthese two theorems come directly from the main lemmas in Appendix B

Theorem 1 (Progress) If cds e
(Hf , B) and B is satisfiable in Hf , then either e is a value or e → cds e  for some e  .

Theorem 2 (Subject reduction) If cds e
(Hf , B), B is satisfiable in Hf , and e → cds e  , then cds e 
(Hf , B  ), and B  is satisfiable in Hf

We say that cds e is a normal form iff there exists no e  s.t (cds e) → (cds e ).

Soundness ensures that reduction of well-typed programs never gets stuck

Theorem 3 (Soundness) If cds e
(Hf , B), B is satisfiable in Hf , (cds e) → ∗ (cds e  ), and cds e  is a normal form, then e  is a value.

Proof By induction on the number n of reduction steps The claim for n = 0 holds by progress If n > 0, then there exists e  s.t (cds e) → (cds e ), and(cds e )→ ∗ (cds e  ) in n − 1 steps By subject reduction we have that cds e 

(Hf , B  ) and B  is satisfiable in Hf , therefore we can conclude by inductive

6 Conclusion and Further Developments

We have shown how type systems can be specified by encoding programs intoHorn formulas and by considering their coinductive Herbrand models [19,18].The encoding was made possible thanks to the notion of type constraint forprincipal typing of Java-like languages [7,4]

Coinduction arises naturally at two different levels: at the level of terms,since recursive types are infinite terms, and at the level of proofs, since recursivemethods and the use of infinite types require proofs to be infinite as well.The approach has been used for fully formalizing two quite different type sys-tems, for the same language (the only syntactical difference being the possibility

of omitting type annotations) The definitions of the two type systems are sonably compact, and modular: despite the two systems are quite different, only

rea-24 D Ancona and G Lagorio

3 rules out of 12 have to be changed, while almost half of the clauses shared byall programs could be reused

The idealized type system provides theoretical limit to type inference ofobject-oriented programs, since only sound approximations of the system can

be implemented From the soundness of the type system can be directly derivedthe type safety of any type inference algorithm which is proved to be sound w.r.t.the system

The idealized type system has also shown how simple type annotations can

be used without compromising the precision of type analysis, thus integratingsmoothly the two different notions of nominal and structural type

Finally, the followed approach allows quite naturally typing of open

expres-sions and general queries on the program, as has meth(C, m, [int ], T ) asking for all classes C and return type T of method m with exactly one argument of type int However, because of the limitations of the logic, very simple properties can

be proved independently of any program

One of the most interesting and challenging issue left open in this paper cerns the implementation of reasonable approximations of the idealized typesystem We have just started investigating possible solutions to this problem,

con-by exploiting recent results on the operational semantics of coinductive logicprogramming [19,18] We have developed a prototype18supporting a partial im-plementation of the idealized type system, based on a Prolog meta-interpreterfor coinductive logic programs, which still needs to be integrated with the no-tions of subtyping and subsumption Since regular types are fully supported assolutions to term unification problems interesting examples can be typed (as theone shown in Section 3.4), even without subsumption

Recon-4 Ancona, D., Damiani, F., Drossopoulou, S., Zucca, E.: Polymorphic bytecode: positional compilation for Java-like languages In: ACM Symp on Principles ofProgramming Languages 2005 ACM Press, New York (2005)

Com-5 Ancona, D., Lagorio, G., Zucca, E.: True separate compilation of Java classes In:PPDP 2002 - Principles and Practice of Declarative Programming ACM Press,New York (2002)

6 Ancona, D., Lagorio, G., Zucca, E.: Type inference for polymorphic methods inJava-like languages In: Italiano, G.F., Moggi, E., Laura, L (eds.) ICTCS 2007

- 10th Italian Conf on Theoretical Computer Science 2003, eProceedings WorldScientific, Singapore (2007)

18

Available at http://www.disi.unige.it/person/LagorioG/J2P

Coinductive Type Systems for Object-Oriented Languages 25

7 Ancona, D., Zucca, E.: Principal typings for Java-like languages In: ACM Symp

on Principles of Programming Languages 2004 ACM Press, New York (2004)

8 Barbanera, F., Dezani-Cincaglini, M., de’Liguoro, U.: Intersection and union types:Syntax and semantics Information and Computation 119(2) (1995)

9 Brandt, M., Henglein, F.: Coinductive axiomatization of recursive type equality andsubtyping In: de Groote, P., Hindley, J.R (eds.) TLCA 1997 LNCS, vol 1210.Springer, Heidelberg (1997)

10 Brandt, M., Henglein, F.: Coinductive axiomatization of recursive type equalityand subtyping Fundam Inform 33(4) (1998)

11 Courcelle, B.: Fundamental properties of infinite trees Theoretical Computer ence 25 (1983)

Sci-12 Furr, M., An, J., Foster, J.S., Hicks, M.: Static type inference for Ruby In: SAC

2009 - 24th ACM Symp on Applied Computing (2009)

13 Igarashi, A., Nagira, H.: Union types for object-oriented programming Journ ofObject Technology 6(2) (2007)

14 Igarashi, A., Pierce, B.C., Wadler, P.: Featherweight Java: a minimal core calculusfor Java and GJ ACM Transactions on Programming Languages and Systems 23(3)(2001)

15 Lagorio, G., Zucca, E.: Just: safe unknown types in java-like languages Journ ofObject Technology, 6(2) (February 2007); Special issue: OOPS track at SAC (2006)

16 Oxhøj, N., Palsberg, J., Schwartzbach, M.I.: Making type inference practical In:Lehrmann Madsen, O (ed.) ECOOP 1992 LNCS, vol 615, pp 329–349 Springer,Heidelberg (1992)

17 Palsberg, J., Schwartzbach, M.I.: Object-oriented type inference In: ACM Symp

on Object-Oriented Programming: Systems, Languages and Applications 1991(1991)

18 Simon, L., Bansal, A., Mallya, A., Gupta, G.: Co-logic programming: Extendinglogic programming with coinduction In: Arge, L., Cachin, C., Jurdzi´nski, T., Tar-lecki, A (eds.) ICALP 2007 LNCS, vol 4596, pp 472–483 Springer, Heidelberg(2007)

19 Simon, L., Mallya, A., Bansal, A., Gupta, G.: Coinductive logic programming.In: Etalle, S., Truszczy´nski, M (eds.) ICLP 2006 LNCS, vol 4079, pp 330–345.Springer, Heidelberg (2006)

20 Wang, T., Smith, S.: Polymorphic constraint-based type inference for objects nical report, The Johns Hopkins University (2008) (submitted for publication)

Tech-21 Wang, T., Smith, S.F.: Precise constraint-based type inference for java In: sen, J.L (ed.) ECOOP 2001 LNCS, vol 2072, p 99 Springer, Heidelberg (2001)

Knud-26 D Ancona and G Lagorio

Fig 7 Auxiliary functions

B Lemmas and Main Theorems of Section 5 (Some Proofs Are Sketched)

Progress To prove progress we need the following lemmas.

Lemma 1 If C[e] in V
(t | B), then e in V
(t  | B  ), with B  ⊆ B Proof By case analysis on the contexts and by induction on their structure. 

Lemma 2 If cds
Hf , and invoke(
c,
m, [t1, , t n ], t) is satisfiable in Hf , then mbody(cds , c, m) = (x n , e) for some variables x n and expression e.

Proof By induction on the height of the inheritance tree Note that by

Theorem 1 [Progress] If cds e
(Hf , B) and B is satisfiable in Hf , then either e is a value or e → cds e  for some e .

Subject reduction The following lemma strongly relies on the notion of

sub-typing and subsumption as defined in Section 5

Lemma 3 If cds
Hf , e in V
(t | B), Bθ ⊆ M co (Hf ), and e → cds e  , then there exist t  , B  and θ  s.t e  in V
(t  | B  ), B  θ  ⊆ M co (Hf ), and t  θ  ≤ tθ.

Theorem 2 [Subject reduction] If cds e
(Hf , B), B is satisfiable in Hf , and e → cds e  , then cds e 
(Hf , B  ), and B  is satisfiable in Hf

Checking Framework Interactions with Relationships

Ciera Jaspan and Jonathan AldrichInstitute for Software Research,Carnegie Mellon University,Pittsburgh PA 15213, USAciera@cmu.edu, jonathan.aldrich@cs.cmu.edu

Abstract Software frameworks impose constraints on how plugins may interact

with them Many of these constraints involve multiple objects, are temporal, anddepend on runtime values Additionally, they are difficult to specify because theyare often extrinsic and may break behavioral subtyping This work introduces

relationships as an abstraction for specifying framework constraints in FUSION

(Framework Usage SpecificatIONs), and it presents a formal description and plementation of a static analysis to find constraint violations in plugin code Wedefine three variants of this analysis: one is sound, one is complete, and a prag-matic variant that balances these tradeoffs We prove soundness and complete-ness for the appropriate variants, and we show that the pragmatic variant caneffectively check constraints from real-world programs

Object-oriented frameworks have brought many benefits to software development, cluding reusable codebases, extensible systems, and encapsulation of quality attributes.However, frameworks are used at a high cost; they are complex and difficult to learn[1] This is partially due to the complexity of the semantic constraints they place on the

in-plugins that utilize them.

As an example, consider a constraint in the ASP.NET web application framework.The ASP.NET framework allows developers to create web pages with user interfacecontrols on them These controls can be manipulated programatically through callbacksprovided by the framework A developer can write code that responds to control events,adds and removes controls, and changes the state of controls

One task that a developer might want to perform is to programmatically change theselection of a drop down list The ASP.NET framework provides the relevant pieces,

as shown in Fig 11 Notice that if the developer wants to change the selection of aDropDownList(or any other derivedListControl), she has to access the indi-vidualListItems through the ListItemCollectionand change the selectionusingsetSelected Based on this information, she might na¨ıvely change the selec-tion as shown in List 1 Her expectation is that the framework will see that she hasselected a new item and will change the selection accordingly

1

As the implementation of FUSION runs on Java, we translated the examples to Java syntax

S Drossopoulou (Ed.): ECOOP 2009, LNCS 5653, pp 27–51, 2009.

c

Springer-Verlag Berlin Heidelberg 2009