Types for object-oriented and functional programming languages

parentpitaΛογισμικό & κατασκευή λογ/κού

18 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

548 εμφανίσεις

Universita degli Studi di Torino
Dipartimento di Informatica
C.so Svizzera,185 - 10149 Torino,Italia
PhD thesis
Types for object-oriented and
functional programming languages
Silvia Likavec
Prof.Viviana Bono
Prof.Pierre Lescanne
Prof.Pietro Torasso
2001 - 2004
Abstract vii
Acknowledgements ix
Summary xi
Riassunto xvii
R´esum´e xxiii
I Introduction 1
1 Introduction 3
1.1 Type systems for programming languages.............3
1.1.1 Introduction.........................3
1.1.2 Formalizing a typed programming language........5
1.2 Object-oriented programming...................7
1.2.1 Basic concepts.......................7
1.2.2 Typing object-oriented languages.............8
1.2.3 Class-based vs.object-based languages..........9
1.3 Basic domain theory........................10
1.4 Basic category theory........................11
1.5 Overview of the thesis.......................13
II Core calculus of classes and mixins and extensions 15
2 Mixins in programming languages 19
2.1 Introduction.............................19
2.1.1 What is a mixin?......................19
2.1.2 Examples..........................20
2.2 Literature on mixins.........................22
3 Core calculus of classes and mixins 27
3.1 Overview..............................27
3.2 Motivating the design........................28
3.3 Core calculus in more details....................29
3.4 Extending the core calculus.....................31
4 Adding higher-order mixins 33
4.1 Introduction.............................33
4.2 Syntax of the calculus........................34
4.3 Operational semantics........................38
4.3.1 Reduction rules for standard and heap expressions....39
4.3.2 Reduction rules for class and mixin related forms.....40
4.3.3 Reduction rule for mixin composition...........43
4.4 Type system.............................46
4.4.1 Types............................46
4.4.2 Subtyping rules.......................48
4.4.3 Typing rules for standard and heap expressions......49
4.4.4 Typing rules for class and mixin related forms.......49
4.4.5 Typing rule for mixin composition.............52
4.5 Properties of the system.......................53
4.5.1 Preliminary properties...................54
4.5.2 Subject reduction......................60
4.5.3 Soundness.........................73
4.6 An example of mixin inheritance..................80
5 Adding incomplete objects 85
5.1 Introduction.............................85
5.2 Syntax of the calculus........................87
5.3 Operational semantics........................90
5.3.1 Reduction rules for object-oriented forms.........91
5.3.2 Reduction rules for incomplete objects...........95
5.4 Type system.............................97
5.4.1 Types............................97
5.4.2 Typing rules for class related forms............98
5.4.3 Typing rules for mixin related forms............99
5.4.4 Typing rules for incomplete objects............101
5.5 Allowing method invocation on incomplete objects........103
5.6 Properties of the system.......................104
5.6.1 Preliminary properties...................104
5.6.2 Subject reduction......................105
5.6.3 Soundness.........................119
5.7 Examples..............................122
5.7.1 Object completion via method addition..........123
5.7.2 Object completion by object composition.........125
6 Width subtyping for incomplete objects 129
6.1 Introduction.............................129
6.2 Syntax and operational semantics..................131
6.2.1 An example of reduction..................132
6.3 Type system.............................134
6.4 A more exible solution......................136
6.4.1 Remarks..........................138
6.5 Properties of the system.......................139
6.5.1 Subject reduction......................139
7 Final remarks 145
7.1 Conclusions.............................145
7.1.1 Mixin calculus supporting higher-order mixins......145
7.1.2 Mixin calculus with incomplete objects..........145
7.1.3 Incomplete objects with width subtyping.........146
7.2 Related work - comparison.....................146
7.2.1 Mixin calculi........................146
7.2.2 Calculi with incomplete objects..............149
7.3 Future research directions......................149
III Understanding
λµ￿µ calculus and Gemini 151
8 Introduction to
λµ￿µ calculus and Gemini 155
8.1 Intuition and syntax.........................155
8.2 Reduction rules...........................157
8.3 Two conuent subcalculi......................158
8.4 Type assignment systemfor
8.5 Related systems...........................160
8.5.1 λµ calculus.........................160
8.5.2 λC calculus.........................161
9 Conuence of Gemini 163
9.1 Introduction.............................163
9.2 Parallel reduction for Gemini
9.3 Conuence of Gemini
9.4 Parallel reduction and conuence for Gemini
10 Semantics of Gemini 175
10.1 Continuation semantics.......................175
10.1.1 Introduction.........................175
10.1.2 Category of continuations.................176
10.1.3 Category of negated domains................177
10.1.4 Fromordinary models to continuation models.......179
10.2 Semantics of Gemini
10.3 Kleisli category and continuation semantics............189
10.3.1 Kleisli category.......................189
10.3.2 Kleisli triple of continuations...............190
10.4 Semantics of Gemini
10.5 Improving the semantics of Gemini
11 Final remarks 203
11.1 Conclusions.............................203
11.2 Future research directions......................203
IV Using intersection types to characterise the behaviour of
lambda terms 205
12 Behavioural inverse limit λ-models 207
12.1 Introduction.............................207
12.2 Inverse limit λ-models and intersection types...........209
12.2.1 Stone duality........................209
12.2.2 Inverse limit λ-models...................210
12.2.3 Step functions.......................211
12.3 The models.............................212
12.3.1 Reminder on λ-calculus..................212
12.3.2 Normalisation,persistent normalisation,and closable prop-
12.3.3 Relationships between sets of terms............214
12.3.4 Functional behaviour of terms...............216
12.3.5 Denition of models....................217
12.3.6 Main theorem,version I..................218
12.4 Types and lter models.......................219
12.4.1 Pretypes and types.....................219
12.4.2 Filter models........................222
12.5 The type assignment systems....................225
12.5.1 The type assignment systems and examples of derivations 225
12.5.2 Main theorem,version II..................229
12.6 Persistently normalising terms...................231
12.6.1 Safe and unsafe subterms..................231
12.6.2 Characterisation of PN..................232
12.7 Reducibility method.........................234
12.7.1 Reducibility method....................234
12.7.2 Soundness.........................236
12.8 Conclusion.............................238
This thesis consists of three parts.
The rst part presents three extensions of the core calculus of classes and mix-
ins.The rst extension is a proposal for a programming langu age equipped with
higher-order mixins,which enable the construction of sophisticated class hierar-
chies.In the second extension mixins are seen as incomplete classes,and accord-
ingly,their instances are seen as incomplete objects that could be completed in
an object-based fashion via method addition and object composition.In the third
extension,width subtyping on (complete) object types is added to the calculus of
mixins and incomplete objects.
The second part studies the untyped
λµ￿µ calculus called Gemini.The con-
uence of Gemini
and Gemini
,two well-behaved subcalculi of Gemini,closed
under call-by-name and call-by-value reduction respectively,is proved.Moreover,
the interpretation of Gemini
in the category of negated domains,and the interpre-
tation of Gemini
in the Kleisli category is given.To the best of our knowledge,
this is the rst interpretation of untyped
λµ￿µ calculus.
In the third part,two inverse limit λ-models are constructed,which completely
characterise the sets of terms with similar computational behaviours:the sets
of normalising,head normalising,weak head normalising λ-terms,those corre-
sponding to the persistent versions of these notions,and the sets of closable,clos-
able normalising,and closable head normalising λ-terms.
Many people believed that I would be writing these lines after all.I warmly thank:
✁✄ My supervisors Viviana Bono and Pierre Lescanne for sharing their knowl-
edge with me and for dedicating their time and patience to the development
of this thesis.Without their help and encouragement it would be much
harder to come to the end of this path.
￿ Mariangiola Dezani for her valuable support and advice during these three
years of my PhD.
♦ Silvia Ghilezan for suggesting Torino as a place for doing my PhD,and for
providing constant encouragement and constructive criticismduring all this
￿ Lorenzo Bettini for being a dynamic and practically oriented co-author.
￿ Ugo de'Liguoro for numerous discussions we had on metaphys ics.
￿ The whole λ group at Dipartimento di Informatica in Torino for being a
stimulating working environment.
￿ Michele Bugliesi,Dan Dougherty,Susan Eisenbach,and Hugo Herbelin
for accepting to be the referees for my thesis.Steffen van Bakel,Pierre-
Louis Curien,Ren´e David,Sophia Drossopoulou,Paola Gannini,and Ugo
de'Liguoro for giving their availability to substitute some of the referees in
case of necessity.
￿ My mum,dad,and Danka for their love and support,and for boldly believ-
ing in me for more than 30 years.
♥ Chris for successfully fooling the kilometres with me,always being an end-
less source of love,comfort,and motivation.
♣ Ale,Andris,Bobo,Cri,Elaine,Fabri,Gigi,Iva,Loca,and Vivi for their
friendship and presence that made my days in Torino colorful and unforget-
table.Bobo and Fabri for infecting me with tango.Marcello for taking me
to the rst party in Torino.
♠ Daniela,Duda,Gaga,Goca,Ivana,Jovana,Livija,Natasa,Tanja,and Zoran
for their constant friendship that I would never stop counting on and for
sharing many joyful and critical moments with me.Ivana and Tanja for
their help in resolving all the bits and pieces that were in the way.
￿ Antonietta Pontieri for her patience in helping me to ght th e bureaucracy.
￿ Daniel,Dragisa,Etienne,Myriam,Pushpinder,and Tom for making my
staying in Lyon much more enjoyable.Tomfor the help with French transla-
tions.Sonia for being my companion in many schools,meetings and work-
Treba mi svet
Otvoren za poglede
Otvoren za trcanje
I treba mi soba
Da primi pet hiljada ljudi
Sa dignutimcasama
Sa dignutimcasama
This thesis was developed as a joint work between Dipartimento di Informat-
ica,Universita di Torino,Italy,and Laboratoire de l'Informatique du Par all´elisme
Ecole Normale Sup´erieure de Lyon,France.
The thesis is divided into three parts.The rst part,superv ised by Prof.Vi-
viana Bono,is a proposal for the design of a mixin-based calculus that accommo-
dates incomplete objects and higher-order mixins.The second part is developed
under the supervision of Prof.Pierre Lescanne,and it investigates some properties
of two subcalculi of untyped
λµ￿µ calculus of Curien and Herbelin [CH00].The
third part,written in collaboration with Prof.Mariangiola Dezani and Prof.Silvia
Ghilezan,presents two inverse limit models for the lambda calculus with intersec-
tion types.
Mixin calculus
In object-oriented world,there are two predominant programming paradigms:
class-based and object-based.Class-based object-oriented languages promote
disciplined programming by enabling construction of solid class hierarchies,while
object-based languages provide a convenient environment for experimenting with
prototypes,where parts of their implementation might still be missing.
The aim of this work was to give the basis for designing a calculus that com-
bines class-based features with object-based ones,that is,to try to t into one
setting the best of both worlds,discipline and exibilit y rst of all.We propose
two extensions of the Core Calculus of Classes and Mixins of [BP S99],one
with higher-order (composable) mixins,the second one with incomplete objects.
Our approach
Mixins [BC90] are (sub)class denitions parameterized over a superclass and
were introduced as an alternative to some forms of multiple inheritance.A mixin
can be seen as a function that,given one class as an argument,produces a (sub)class,
by adding and/or overriding certain sets of methods.
Mixins in our calculi have the following form:
method m
= v
redefine m
= v
expect m
constructor v
Methods m
= v
are newly introduced by the mixin,m
= v
are redening
methods,that will redene the methods with the same names fr omthe superclass,
and m
are expected method (names),that must be provided by the superclass.All
the methods are functions of the private
,and of
,which will be bound to
the newly created object at instantiation time.In addition,redening methods can
refer to their corresponding superclass implementation via a special keyword
A mixin type takes into account the types of the methods already present in the
mixin and the expected types of the components not yet present.New subclasses
are created by applying a mixin to a class via a mixin application operation ￿.The
type systemdetermines when a mixin application is possible.
The rst proposed calculus extends the core calculus of clas ses and mixins of
[BPS99] with higher-order mixins.In this extension a mixin can:(i) be applied to
a class to create a fully-edged subclass;( ii) be composed with another mixin to
obtain yet another mixin with more functionalities.In what we believe being quite
a general framework,we give directions for designing a programming language
equipped with higher-order mixins,although our study is not based on any already
existing object-oriented language.
In the second proposed calculus we extend the core calculus of classes and
mixins of [BPS99] with incomplete objects.Since mixins have a exible nature of
incomplete classes prone to be completed according to the programmer's needs,
we decided that the promising starting point for our calculus could be the com-
bination of mixin-based inheritance with constructs for manipulating incomplete
objects.In addition to standard class instantiation,it is also possible to instanti-
ate mixins thus obtaining incomplete objects.Therefore,an incomplete object is
incomplete in two different respects:( i) it may need some expected methods;
(ii) its redening methods cannot be invoked until methods with the functionality
of their
are added.Incomplete objects can be completed in two ways:(i)
via method addition,that adds one of the expected methods or one of the miss-
s;(ii) via object composition,that composes an incomplete object with
a complete one that contains all the required methods.When a method is added,
it becomes an effective component of the host object,meaning that the methods
of the host object may invoke it,but also the new added method can use any of
its sibling methods.The type systemensures that all method additions and object
compositions are type safe and that only complete methods are invoked on ob-
jects.This way the type information at the mixin level is fully exploited,obtaining
a tamed and safe object-based calculus.
In addition to functional,record,and reference types,our type systemhas class
types,mixin types,and object types (both for complete and incomplete objects in
the second extension).
The metatheory of both extensions is studied.In particular,the soundness
property is proved,to guarantee the absence of run-time me ssage-not-understood
Gemini calculus
λµ￿µ calculus was introduced by Curien and Herbelin in [CH00],to provide a
Curry-Howard correspondence for classical logic.The terms of
λµ￿µ represent
derivations in a sequent calculus proof system and reduction reects the process
of cut-elimination.
The untyped version of the calculus can be seen as the foundations of a func-
tional programming language with an explicit notion of control.The new termi-
nology for the basic syntactic constructs was given in [GL04],which will also be
used in this work.We call this untyped language Gemini.
The basic syntactic entities are given by the following:
v::= x | λx.v | µα.c e::= α | v • e | ￿µx.c c::= ￿v ￿ e￿
where v ranges over the set Caller of callers,e ranges over the set Callee of
callees and c ranges over the set Capsule of capsules.The variables denoted with
Latin letters represent input and the variables denoted with Greek letters denote
continuations.We refer to the terms of Gemini as G-terms.
There are three rules that characterise the reduction in the calculus:
(λ) ￿λx.r ￿ r
• e￿ → ￿r[x ←r
] ￿ e￿
(µ) ￿µα.c ￿ e￿ → c[α ←e]
(˜µ) ￿r ￿ ˜µx.c￿ → c[x ←r]
The calculus has a critical pair ￿µα.c
￿ ￿µx.c
￿ where both,(µ) and (￿µ) rule can be
applied ambiguously,producing two different results.Hence,the calculus is not
conuent.But if the priority is given to one of the rules,we ob tain two conuent
,that are closed under call-by-name and call-by-value
This work investigates some properties of two subcalculi of untyped
λµ￿µ cal-
culus of Curien and Herbelin [CH00],called Gemini
and Gemini
It proves the conuence and then gives domain theoretic mode ls for both versions.
In order to prove the conuence for each of them,we adopt the t echnique
of parallel reductions given by Takahashi in [Tak95].This approach consists of
simultaneously reducing all the redexes existing in a term.First,we dene the
notion of parallel reduction ⇒
for Gemini
.Then,we show that →→
is a reex-
ive and transitive closure of ⇒
.Therefore,in order to prove the conuence of
,it is enough to prove the diamond property for ⇒
,which follows from the
stronger Star property for ⇒
that we prove.The proof for Gemini
is obtained
by a straightforward modication of the proof for Gemini
When interpreting the calculi that embody a notion of control,it is convenient
to start from continuation semantics,that enables to explicitly refer to continua-
tions,which are the semantic constructs that represent evaluation contexts.
Continuation semantics of Gemini
is given by the interpretation in the cate-
gory of negated domains of [SR98a],whereas Gemini
is interpreted in Moggi's
Kleisli category over predomains for the continuation monad [Mog91].Using
computational monads,we also give an improved interpretation for Gemini
troducing the new syntactic entity,called co-value.In all the cases the reduction
preserves the denotations.The main point about these domain-theoretic models
is that they cope with untypedness of the calculus by solving a recursive domain
Using intersection types to characterise the behaviour
of lambda terms
In the simply typed lambda calculus λ

,the basic type forming operator is the
arrow →.Among many known extensions of this type assignment system,the
one which characterizes larger class of terms is the extension with intersection
types.The intersection type assignment systemwas introduced in [BCDC83] and
[CDCV80],and is denoted by λ

.In this system,the new type-forming operator
is introduced,namely the intersection ∩.Consequently,it is possible to assign
two types σ and τ to a certain lambda termat the same time.Another outstanding
feature of this systemis the universal type ω which can be assigned to all lambda
We construct two inverse limit λ-models which completely characterise sets of
terms with similar computational behaviours:the sets of normalising,head nor-
malising,weak head normalising λ-terms,those corresponding to the persistent
versions of these notions,and the sets of closable,closable normalising,and clos-
able head normalising λ-terms.More precisely,for each of these sets of terms
there is a corresponding element in at least one of the two models,such that a
term belongs to the set if and only if its interpretation (in a suitable environment)
is greater than or equal to that element.We use the nitary lo gical description of
the models,obtained by dening suitable intersection type assignment systems,to
prove this.
Questa tesi e stata sviluppata in co-tutela tra il Dipartimento di Informatica,Uni-

a di Torino,Italia,e il Laboratoire de l'Informatique du Pa rall
elisme (LIP),
Ecole Normale Sup´erieure de Lyon,Francia.
La tesi e divisa in tre parti.La prima parte,sviluppata sotto la supervisione
della Prof.ssa Viviana Bono,e una proposta per il design di un calcolo basato sul
costrutto di mixin,nel quale vengono modellati una forma di oggetti incom-
pleti ed introdotti mixin di ordine superiore.La second a parte e stata sviluppata
sotto la supervisione del Prof.Pierre Lescanne e presenta alcune propriet

a di due
sottocalcoli del
λµ￿µ calcolo non tipato di Curien e Herbelin [CH00].La terza
parte,scritta in collaborazione con la Prof.ssa Mariangiola Dezani e la Prof.ssa
Silvia Ghilezan,presenta due modelli per il lambda calcolo tipato con i tipi inter-
Mixin calcolo
Nel mondo dei linguaggi orientati agli oggetti,ci sono due paradigmi di program-
mazione predominanti:i linguaggi basati sulle classi e i linguaggi basati sugli
oggetti.I linguaggi basati sulle classi promuovono una programmazione disci-
plinata,permettendo la costruzione di solide gerarchie di classi,mentre i linguaggi
basati sugli oggetti forniscono un ambiente conveniente per sperimentare con pro-
totipi,ovvero codice in cui parti dell'implementazione potrebbero essere assenti.
Lo scopo della prima parte di questo lavoro e di fornire le basi per un cal-
colo che unisca alcune delle caratteristiche di entrambi i paradigmi,e produca un
linguaggio con la disciplina delle classi e la essibilit a dei prototipi.Abbiamo
proposto due estensioni del Core Calculus of Classes and Mixin s di [BPS99],
una con i mixin di ordine superiore ed un'altra con gli oggett i incompleti.
Il nostro approccio
I mixin [BC90] sono denizioni di (sotto)classi parametrizza te rispetto a una so-
praclasse,e sono stati introdotti come alternativa a certe forme di ereditarieta
multipla.Un mixin puo essere visto come funzione che,data una classe come
argomento,produce una nuova (sotto)classe,aggiungendo e/o ridenendo certi
insiemi di metodi.
Nei nostri calcoli,i mixin hanno la forma seguente:
method m
= v
redefine m
= v
expect m
constructor v
I metodi m
= v
sono i metodi nuovi introdotti dal mixin,gli m
= v
sono i metodi rideniti che sovrascriveranno i metodi con gli stessi nomi della
sopraclasse,e gli m
sono i (nomi dei) metodi previsti,che devono essere for-
niti della sopraclasse.Tutti i metodi sono funzioni di un
privato,e di
che sara legato all'oggetto stesso nel momento della sua creazione.In piu,i
metodi rideniti possono chiamare la loro corrispondente i mplementazione nella
sopraclasse,usando la parola-chiave
.Il tipo del mixin contiene i tipi dei
metodi gia presenti nel mixin ed i tipi previsti per le componenti non ancora pre-
senti.Le nuove sottoclassi sono generate applicando un mixin ad una classe,
attraverso un'operazione di applicazione ￿.Il sistema di tipi determina quando
un'applicazione mixin-classe e possibile.
Il primo calcolo proposto estende il Core Calculus of Classes a nd Mixins di
[BPS99] con i mixin di ordine superiore.In questa estensione un mixin pu

essere applicato ad una classe per generare una sottoclasse funzionante;(ii) essere
composto con un altro mixin per ottenere un altro mixin con piu funzionalita.Il
nostro scopo e di offrire alcune direzioni,secondo noi generali,per il design di un
linguaggio di programmazione con i mixin di ordine superiore,benche il nostro
calcolo non sia basato su alcun linguaggio esistente in particolare.
Nel secondo calcolo proposto estendiamo il Core Calculus of Cl asses and
Mixins di [BPS99] con una forma di oggetti incompleti.Poiche i mixin pos-
sono essere visti come classi incomplete che possono essere completate secondo
le richieste del programmatore,abbiamo deciso che un buon punto di partenza
per il nostro calcolo potesse essere l'ereditariet a basata sui mixin,combinata
con operazioni per la manipolazione degli oggetti incompleti.Nella nostra pro-
posta,quindi,oltre che instanziare le classi,´e possibile instanziare i mixin per
ottenere cos degli oggetti incompleti.Un oggetto incompleto puo essere in-
completo in due modi:( i) gli possono mancare alcuni metodi previsti;(ii) i
suoi metodi rideniti non possono essere invocati nch e i metodi con la funzion-
alita del loro
non sono stati aggiunti.Gli oggetti incompleti possono essere
completati in due modi:(i) con method addition,che aggiunge uno dei metodi
previsti o uno dei
mancanti;(ii) con object composition,che compone un
oggetto incompleto con un oggetto completo contenente tutti i metodi richiesti
dall'incompleto.Quando un metodo viene aggiunto (via addition o via com-
position),diventa una componente effettiva dell'oggetto ospite,quindi i metodi
dell'oggetto ospite possono invocarlo,ma anche il nuovo me todo aggiunto puo
usare i metodi dell'oggetto ospite.Il sistema di tipi assic ura che tutte le aggiunte
di metodo e composizioni degli oggetti siano ben tipate e che soltanto i metodi
completi possano essere invocati sugli oggetti.Con quest o approccio,le infor-
mazioni di tipo al livello dei mixin sono sfruttate completamente,ottenendo un
calcolo basato sugli oggetti safe.
Partendo dai tipi funzionali,tipi puntatore,e tipi reco rd,il nostro sistema di
tipi comprende anche i tipi delle classi,i tipi dei mixin ed i tipi degli oggetti (degli
oggetti completi,e anche degli oggetti incompleti nella seconda estensione).
La metateoria di entrambe le estensioni e stata studiata estensivamente.In par-
ticolare,entrambi i calcoli sono stati dimostrati sound,una proprieta che garan-
tisce l'assenza degli errori detti messagge-not-underst ood durante l'esecuzione.
Gemini calcolo
λµ￿µ calcolo e stato introdotto da Curien ed Herbelin in [CH00],per fornire una
corrispondenza Curry-Howard alla logica classica.I termini di
λµ￿µ rappresentano
le derivazioni in un sistema di prove basato sui sequenti e la riduzione riette il
processo dell'eliminazione del cut.
La versione non tipata del calcolo puo essere vista come la fondazione di un
linguaggio di programmazione funzionale con una nozione esplicita di controllo.
Una nuova terminologia per le costruzioni sintattiche di base e stata introdotta
in [GL04],ed e stata usata anche in questo lavoro.Chiameremo questo nostro
linguaggio non tipato Gemini.
Le entita sintattiche di base sono cos´ denite:
v::= x | λx.v | µα.c e::= α | v • e | ￿µx.c c::= ￿v ￿ e￿
dove i v appartengono all'insieme Caller dei caller,gli e appartengono all'insieme
Callee dei callee e i c appartengono all'insieme Capsule delle capsule.Le vari-
abili denotate con le lettere latine rappresentano l'input mentre le variabili deno-
tate con le lettere greche rappresentano le continuazioni.I termini di Gemini si
chiamano G-termini.
Ci sono tre regole che caratterizzano la riduzione nel calcolo:
(λ) ￿λx.r ￿ r
• e￿ → ￿r[x ←r
] ￿ e￿
(µ) ￿µα.c ￿ e￿ → c[α ←e]
(˜µ) ￿r ￿ ˜µx.c￿ → c[x ←r]
Il calcolo ha una coppia critica ￿µα.c
￿ ￿µx.c
￿,dove le due regole (µ) e (￿µ)
possono essere applicate ambiguamente,producendo due risultati diversi.Quindi
il calcolo non e conuente.Ma se si d a a una delle regole la priorita,si ottengono
due sottocalcoli conuenti
,che sono chiusi per call-by-name e call-
by-value riduzioni,rispettivamente.
Il presente lavoro studia alcune proprieta di questi due sottocalcoli chiamati
e Gemini
,rispettivamente.Viene provata la conuenza per tutte le d ue
versioni,e vengono presentati dei loro modelli categoriali.
Per dimostrare la conuenza per le due versioni,abbiamo ado ttato la tecnica
delle riduzioni parallele,introdotta da Takahashi in [Tak95].Questa tecnica con-
siste nella riduzione simultanea di tutti i residui che esistono in un termine.Come
primo passo,abbiamo denito la nozione di riduzione parall ela ⇒
per Gemini
Dopodiche,abbiamo dimostrato che →→
e una chiusura riessiva e transitiva
di ⇒
.Di conseguenza,per dimostrare la conuenza di →→
,e stato sufcente
provare la propriet a del diamante per ⇒
,che seque dalla piu forte propriet a
di stella per ⇒
(anch'essa dimostrata).Le prove delle propriet a per Gemini
sono state ottenute modicando direttamente le prove per Gemini
Quando si interpretano dei calcoli che comprendono nozioni di controllo,con-
viene utilizzare la semantica delle continuazioni,che permette di riferirsi esplici-
tamente alle continuazioni,ovvero alle costruzioni semantiche che rappresentano
i contesti di valutazione.
La semantica delle continuazioni per Gemini
e stata ottenuta interpretando
il calcolo nella categoria dei domini negati di [SR98a],mentre Gemini
e stato
interpretato nella categoria di Kleisli basata sui predomini per le monadi delle
continuazioni,introdotte da Moggi in [Mog91].Usando le monadi delle com-
putazioni,otteniamo inoltre un'interpretazione miglior ata per Gemini
ducendo una nuova categoria sintatica che abbiamo chiamato co-value.In tutti
i casi,la riduzione preserva le denotazioni.
Uso dei tipi intersezione per caratterizzare il compor-
tamento dei lambda termini
Nel lambda calcolo con tipi semplici λ

,l'operatore principale per construire i
tipi e la freccia →.Fra le molte estensioni di questo sistema di tipi,quella
che caratterizza la classe piu grande di termini e l'estensione con i tipi inter-
sezione.Il sistema di tipi con i tipi intersezione e stato introdotto in [BCDC83]
ed in [CDCV80],ed e di solito denotato da λ

.Il nuovo operatore ∩ per la for-
mazione di tipi e introdotto in questo sistema.La caratteristica principale di tale
operatore e che rende possibile assegnare due tipi σ e τ ad un certo lambda ter-
mine allo stesso tempo.Un'altra caratteristica important e di questo sistema e il
tipo universale ω che puo essere assegnato a tutti i lambda termini.
In questo lavoro,sono stati costruiti due modelli per il lambda calcolo basati
sui limiti inversi.Essi caratterizzano completamente gli insiemi di termini con
comportamenti computazionali simili:gli insiemi dei termini normalising,head-
normalising,weak head-normalizing,gli insiemi dei termini che corrispondono
alle versioni persistenti di queste nozioni,e gli insiemi dei termini closable,clos-
able normalising,e closable head normalising.Pi´u precisamente,per ciascuno
di questi insiemi di termini,esiste un elemento corrispondente almeno in uno
dei due modelli,tale che il termine appartiene all'insieme se e solo se la sua in-
terpretazione (in ambiente adatto) e superiore o uguale a quell'elemento.Per di-
mostrare questo,abbiamo usato la descrizione logica nita ria dei modelli,ottenuta
denendo i sistemi di tipi con i tipi intersezione adatti.
Cette these s'est droul ´ee en collaboration avec deux laboratoires scientiques:l e
Dipartimento di Informatica de l'universit ´e du Turin,en Italie,et le Laboratoire
de l'Informatique du Parall ´elisme (LIP),l'
Ecole Normale Sup´erieure de Lyon,en
La these est divis´ee en deux parties.La premiere partie,dirig´ee par Viviana
Bono (professeur),propose un calcul fond´e sur la notion de mixin,qui permet
de repr´esenter a la fois des objets incomplets et des mixins d'ordre sup ´erieur.
La seconde partie,dirig´ee par Pierre Lescanne (professeur),´etudie les propri´et´es
de deux sous-calculs du
λµ￿µ calcul non typ´e de Curien et Herbelin [CH00].
La troisieme partie,´ecrite en collaboration avec Mariangiola Dezani et Silvia
Ghilezan,pr´esente deux modeles de limite inverse pour le lambda calcul avec
types intersections.
Mixin calculus
Dans le monde orient´e objet,on trouve deux paradigmes de programmation pr´edo-
minants:les langages fond´es sur les classes et ceux fond´es sur les objets.Les
langages fond
es sur les classes renforcent la discipline de programmation en per-
mettant la construction de hi´erarchies de classes rigides,alors que les langages
fond´es sur les objets offrent un environnement confortable pour l'exp ´erimentation
de prototypes,dont certaines parties manquent encore.
Le but de ce travail ´etait de concevoir un calcul qui combine les deux paradigmes,
c'est- a-dire d'essayer de fournir en un seul langage la discipline des classes et la
exibilit ´e des prototypes.Nous proposons deux extensions du Core Calc ulus of
Classes and Mixins [BPS99],l'une avec mixins d'ordre sup ´erieur (composite),
l'autre avec objets incomplets.
Notre approche
Les mixins [BC90] sont des d´enitions de (sous) classes param ´etr´ees par une
super-classe.Ils ont
e introduit comme une alternative

a certaines formes d'h
multiple.Un mixin peut etre vu comme une fonction qui,´etant donn´ee une classe
en argument,produit une (sous) classe,en ajoutant et/ou red´enissant certains
ensembles de m´ethodes.
Dans notre calcul,les mixins ont la forme suivante:
method m
= v
redefine m
= v
expect m
constructor v
Les m´ethodes m
= v
sont introduites par le mixin,les m
= v
sont des
ethodes red
enies,qui vont red
enir les m
ethodes de m

eme nom provenant de
la super-classe,et les m
sont des (noms de) m´ethodes attendues,qui doivent etre
fournis par la super-classe.Toutes les m´ethodes sont fonctions du champ priv´e
et de
,qui seront li´es a l'instanciation a l'objet en cours de cr ´eation.En
outre,les m´ethodes red´enies peuvent faire r ´ef´erence a leur impl´ementation dans
la super-classe grace au mot-clef sp´ecial
.Un type de mixin prend en compte
les types des m´ethodes d´eja pr´esentes dans le mixin,ainsi que les types attendus
pour les composants manquant.On cr´ee de nouvelles sous-classes en appliquant
un mixin a une classe via un op´erateur d´edi´e ￿.Le systeme de types v´erie que
l'application de mixin est possible.
Le premier calcul propos´e par la these ´etend le Core Calculus of Classes and
Mixins [BPS99] avec des mixins d'ordre sup´erieur.Dans cette extension,un
mixin peut (i) etre appliqu´e a une classe pour cr´eer une sous-classe complete,ou
(ii) tre compos´e avec un autre mixin,ce qui donne un nouveau mixin avec plus
de fonctionnalit´es.Dans ce que nous croyons etre un cadre sufsamment g ´en´eral,
nous donnons des ´el´ements pour concevoir un langage de programmation ´equip´e
de mixins d'ordre sup ´erieur,bien que notre ´etude ne soit pas bas´e sur un langage
orient´e-objet existant.
Dans le second calcul propos´e par la these,nous ´etendons le Core Calculus of
Classes and Mixins [BPS99] avec des objets incomplets.Les mixins pouvant etre
vus comme des classes incompl

etes,susceptibles d'

etre compl
ees suivant les be-
soins du programmeur,nous avons choisi comme point de d´epart de notre calcul la
combinaison du style d'h
eritage fourni par les mixins avec les constructions pour
la manipulation d'objets incomplets.Par cons ´equent,en plus de l'instantiation de
classe habituelle,le calcul fournit aussi un m´ecanisme d'instanciation de mixin,
qui g´enere des objets incomplets.Ainsi,un objet incomplet est incomplet en deux
sens distincts:(i) il peut avoir besoin de m´ethodes attendues et (ii) les m´ethodes
qu'il red ´enit ne peuvent pas etre invoqu´ees tant que leurs
s ne sont pas
fournies.Les objets incomplets peuvent etre compl´et´es de deux fac¸ons:(i) par
ajout de m´ethode,qui ajoute l'une des m´ethodes attendues ou l'un des
s man-
quant,ou bien (i) par composition d'objets,qui compose un objet complet avec
un objet complet contenant toutes les m
ethodes requises.Lorsqu'une m
ethode est
ajout´ee,elle devient un composant effectif de l'objet h ote,de telle sorte que les
m´ethodes de cet objet peuvent y faire r´ef´erence.De meme,la m´ethode ajout´ee
peut utiliser les autres m´ethodes de l'objet h ote.Le systeme de types v´erie que
tous les ajouts de m´ethode et les compositions d'objets sont s ures et que seules
des m´ethodes compl etes sont invoqu ´ees.Ainsi,l'information de types sur les
mixins est exploit´ee au maximum,ce qui donne un calcul d'objets s ur et exible.
En plus des types de fonctions,d'enregistrements et de r ´ef´erences mutables,
nos systemes de types comprennent des types de classes,de mixins et d'objets
(complets et incomplets pour la seconde extension).
Nous ´etudions la m´etath´eorie des deux extensions.En particulier,nous prou-
vons la propri´et´e de suret´e,pour garantir l'absence d'erreur Message not under-
stood a l'ex ´ecution.
Le Gemini calcul
λµ￿µ calcul a ´et´e introduit par Curien et Herbelin [CH00],dans le but d'´etablir
une correspondance de Curry-Howard pour la logique classique.Les termes de
λµ￿µ repr´esentent des d´erivations dans une pr´esentation de la logique classique re-
posant sur un calcul de s´equents,et la r´eduction re ete le processus d'´elimination
des coupures.
La version non typ´ee du calcul peut etre vue comme le fondement d'un lan-
gage de programmation fonctionnel avec une notion explicite de controle.Une
nouvelle terminologie a ´et´e donn´ee dans [GL04],que nous utilisons ici.Nous
appelons ce langage non typ´e Gemini.
Les constructions de base sont d´enies comme suit:
v::= x | λx.v | µα.c e::= α | v • e | ￿µx.c c::= ￿v ￿ e￿
ou v d´esigne un ´el´ement de l'ensemble Caller des callers,e d´esigne un ´el´ement
de l'ensemble Callee des callees,et c d
esigne un
ement de l'ensemble Cap-
sule des capsules.Les variables en lettres latines repr ´esentent les entr´ees et
les variables en lettres grecques repr´esentent les continuations.Nous appelons les
terms de Gemini des G-termes.
La r´eduction dans ce calcul est caract´eris´ee par trois regles principales:
(λ) ￿λx.r ￿ r
• e￿ → ￿r[x ←r
] ￿ e￿
(µ) ￿µα.c ￿ e￿ → c[α ←e]
(˜µ) ￿r ￿ ˜µx.c￿ → c[x ←r]
Le calcul pr´esente une paire critique ￿µα.c
￿ ￿µx.c
￿ ou les regles (µ) et (￿µ)
s'appliquent toutes les deux et donnent deux r ´esultats diff´erents.Le calcul est
donc non-conuent.N ´eanmoins,si la priorit´e est donn´ee a l'une des r egles,on
obtient deux sous-calculs conuents
,qui sont clos par r´eduction
en appel par nomet en appel par valeur,respectivement.
Ce travail ´etudie les propri´et´es de deux sous-calculs du
λµ￿µ calcul de Curien
et Herbelin [CH00],appel´es respectivement Gemini
et Gemini
.On prouve leur
conuence et on en donne des mod eles dans la th´eorie des domaines.
Pour prouver la conuence de ces calculs,nous adoptons la te chnique des
r´eductions paralleles propos´ee par Takahashi [Tak95].Cette approche consiste a
r´eduire simultan´ement tous les redexes d'un terme.D'abord,on d ´enit la notion
de r
eduction parall

ele ⇒
pour Gemini
.Ensuite,nous montrons que →→
est une
fermeture r´eexive et transitive de ⇒
.Ainsi,pour prouver la conuence de →→
il suft de prouver la propri ´et´e du diamant pour ⇒
,qui d´ecoule de la propri´et´e
plus forte de l'´etoile,que nous prouvons.La preuve pour Gemini
est obtenue
en modiant l ´egerement la preuve pour Gemini
Pour interpr´eter les calculs dot´es d'une notion de contr ole,il est int´eressant
de partir de la s´emantique des continuations,qui permet de faire explicitement
r´ef´erence a des continuations,qui sont les structures s´emantiques utilis´ees pour
repr´esenter les contextes d'´evaluation.
La s´emantique des continuations de Gemini
est donn´ee par l'interpr ´etation
dans la cat´egorie des domaines ni ´es [SR98a],alors que Gemini
est interpr´et´e
dans la cat´egorie de Kleisli sur les pr´edomaines pour la monade des continua-
tions,propos´ee par Moggi [Mog91].En utilisant les monades calculatoires,nous
donons aussi une meilleure interpr´etation pour Gemini
,qui introduit une nou-
velle entit´e syntaxique appel´ee co-valeur.Dans tous les cas,la r´eduction pr´eserve
la d´enotation.L'avantage principal de ces mod eles est qu'ils s'accomodent du
caractere non typ´e du calcul en r´esolvant une ´equation de domaine r´ecursif.
Utilisation de types intersections pour caract´eriser le
comportement de lambda termes
Dans le lambda calcul simplement typ´e λ

,l'op ´erateur basique de construction
de type est la  eche →.Parmi les nombreuses extensions connues de ce systeme
de types,celle qui caract´erise la plus grande classe de termes est l'extension avec
types intersections.Le systme de types avec intersection [BCDC83,CDCV80]
est not
e λ

.Dans ce syst

eme,un nouvel op
erateur de construction de type est
introduit,l'intersection ∩.Grace a cet op´erateur,il est possible d'assigner deux
types σ et τ simultan´ement a un certain lambda terme.Une caract´eristique de ce
systeme est le type universel ω,qui peut etre assign´e a tous les lambda termes.
Nous construisons deux λmodeles avec limite inverse qui caract´erisent comple-
tement des ensembles de termes dot´es de comportements calculatoires semblables:
les termes normalisants,ceux qui admettent une forme normale de tete,ceux qui
admettent une forme normale de tete faible,les ensembles de termes correspon-
dant aux versions persistentes de ces notions,ainsi que les ensembles de terms qui
admettent la fermeture,la fermeture normalisant et la fermeture normalisant de
tete.Plus pr´ecis´ement,pour chacun de ces ensembles de termes,il y a un ´el´ement
correspondant dans au moins l'un des deux mod eles,de sorte qu'un terme appar-
tient a l'ensemble consid ´er´e si et seulement si son interpr´etation est sup´erieur ou
´egale a l'´el´ement correspondant.Pour prouver ce r´esultat,nous utilisons une de-
scription logique nie des mod eles,obtenue en d´enissant des syst emes de types
avec intersection ad´equat.
Part I
Chapter 1
1.1 Type systems for programming languages
1.1.1 Introduction
In a struggle for designing more exible and expressive prog ramming languages,
type systems certainly play a very important role.They were introduced in order
to check the occurrence of some execution errors during run-time,and ensure the
semantical good behaviour of programs.
A type is a syntactic construct assigned to a term to provide a description of
some properties of the term.It is a set of values together with the operations and
relations applicable to them.A type assigned to a term can be compared with a
dimension of a physical entity.More accurately,terms and their types can be seen
as programs and their specications,respectively.
Typed languages are the ones where variables can be assigned nontrivial
types,i.e.,each part of the program can be assigned a type that describes its be-
havior,and can be deduced from the types of its sub-fragments.The types of
operands are checked to prevent nonsensical operations.On the other hand,un-
typed languages either have no types at all,or have a single universal type for all
It is exactly the concept of  type for functional languages that is the connect-
ing link among the various parts of this thesis.
We distinguish dynamically typed languages,where type checking is done
just before the operations are executed,from statically typed languages,where
types are assigned to terms at compile time.Static typing enables earlier detection
of errors,and provides information to compilers,as well as documentation of
the program.The algorithm that performs the type checking process is called
typechecker,and the program that passes the typechecking process is said to
be well-typed.In the case of dynamic typing,only values are assigned types,
which brings more exibility,but at the cost of execution sp eed and space.Java
[AGH00],ML [MTHM97],Haskell [JHA
99],and Pascal [JW71] are examples
of statically typed languages.LISP [Ste90] and Python [vRD03] are some of the
dynamically typed languages.In this thesis we are dealing with static typing only.
Using type systems enables static analysis of the programs,thus establishing
the properties about their execution.The key property of absence of some runtime
errors is ensured by proving formally a property of type safety.For instance,
for object-oriented languages this guarantees avoiding message-not-understood
Base types in programming languages include types like Character,String,
Integer,Real,Boolean etc.By applying certain operators to base types,it is also
possible to build new types,like record or function types.
Record type is a list of label-type pairs,where all the labels are pairwise
distinct.They give types to records,which means that they assign a type to each
value corresponding to a label in a record.Record type is of the form

Function type types functions.It needs to take into account the types of its
arguments and the types of the returned results.It has the form
σ →τ
which means that the argument is of type σ and the result is of type τ.
Intersection type makes it possible to assign two types σ and τ to a certain
lambda termat the same time.It has the form
σ ∩τ.
We distinguish explicitly typed languages where programs are typed manu-
ally,i.e.,types are part of the syntax and the programmer gives the annotations to
the program's source code,so that the compiler has only to check the validity of
provided types,from implicitly typed ones where programs are typed automati-
cally,i.e.,types are inferred by a type inference algorithm.
1.1.2 Formalizing a typed programming language
In this thesis we focus on the languages based on the functional programming
paradigm.Functional programming is a programming style in which compu-
tation is performed by applying functions to arguments.The central concept is
evaluation of expressions,rather than execution of commands.A functional lan-
guage is the language that supports functional programming style.Functional
programs have a more abstract nature,making formal reasoning about them eas-
When formalizing a typed functional programming language,the following is
usually described:
• syntax of its terms and types.Terms are the programs and types express
static information about the terms;
• scoping rules dened by the set of free variables of the program.A notion
of substitution of types or terms for free variables is also given;
• operational semantics via reduction rules that compute results (values) start-
ing fromterms;
• type system that consists of the set of formal rules used compositionally to
assign types to well-typed programs.
Judgements of the type systemspecify the has type relations of the form
Γ ￿ t:τ,
where Γ is a context,t is a term and τ is a type.Contexts are used to record the
types of the free variables.A context Γ has the form
Γ = x


where for all i = 1...n,x
are term variables,and σ
are types.All the variables
in the context are pairwise distinct,and none of themoccurs twice.
Starting from some typing judgements of the language,type rules assert the
validity of other judgements.They are given by one or more premisses,followed
by a conclusion judgement.
The consistency of a type systemwith respect to operational semantics is pro-
vided by type soundness,which ensures that the well typed programs are well-
behaved,i.e.,they cannot go wrong.
Simply typed lambda calculus
As an example,we present here the syntax,operational semantics and typing rules
of the simply typed lambda calculus.For comprehensive account of the subject
we refer the reader to [Bar84].
The syntax of the lambda calculus is given by
t::= x | λx.t | tt
where x is a variable,λx.t is a lambda abstraction (which represents a mapping
x ￿→t),and tt is the application (which represents application of a function to its
The main reduction rule of the lambda calculus is the β-rule,which we give
for the call-by-name variant:
This means that the actual parameter t
is substituted for the formal parameter x
in the function body t
The typing systemfor simply typed lambda calculus has the following axioms
and rules.
(x:α) ∈ Γ
Γ ￿ x:α
Γ,x:α ￿ t:β
Γ ￿ λx.t:α →β
Γ ￿ t
:α →β Γ ￿ t

Γ ￿ t

In some languages,subtyping relation of the form
Γ ￿ σ <:τ
between types is given.It means that an expression of type σ can be used when-
ever an expression of type τ is expected.In the type system,subtyping is usually
included by the subsumption principle which says that if an expression e has type
σ and σ is a subtype of τ (σ <:τ),then e is also of type τ.
For the record types the subtyping relation is given by


iff J ⊆ I and ∀j ∈ J,σ
This means that a subtype of a record type may have more elds ( subtyping in
width) and types of corresponding labels may be subtypes of the ones in the su-
pertype (subtyping in depth).
In the case of function types,the argument has a contravariant position,whereas
the result is covariant.This can be expressed as
iff σ
and τ
If we add imperative side effects to a functional language,reference types
have to be taken into account.A reference variable of type σ denotes a location
in which a value of type σ is stored.Hence,for reference types there are no
non-trivial subtypes,i.e.,
ref σ <:ref τ iff σ ￿ τ.
In the sequel,we consider type systems for object-oriented languages and in
these systems,subtyping relation plays a very important role.
1.2 Object-oriented programming
1.2.1 Basic concepts
Object-oriented programming languages are not loosing their strength and inu-
ence over the last two decades.
The basic computational entities are objects which are data structures with
a state (represented by instance variables or elds ) and some operations,called
methods,used to access and manipulate the object's state.
A program can act on objects'states by invoking methods on them.Objects
are instances of classes.A class stores implementation information about its ob-
jects,like initial values of the instance variables,and names and bodies of the
One of the main features of object-oriented languages is inheritance which
is the ability to generate subclasses from existing classes.The subclass inherits
all the components from its superclass and it has the possibility to add/replace
the instance variables and methods from the superclass.Using inheritance as an
implementation technique when designing class hierarchies,avoids code duplica-
tion,enhances code reuse,and enables consistent changes in the class hierarchy.
Encapsulation is a concept that enables modular programming,since objects
in a system can be seen as black boxes that hide the implemen tation details
of their components while only revealing their usable interface.There are usually
three levels of visibility for instance variables and methods:public,when they can
be seen and accessed fromall the components of the system,protected,if they can
be only inherited,and private,when they are owned by a class and accessible only
frominside the class itself.
Dynamic binding enables choosing the appropriate method to be executed
based on the run-time type of the receiving object.The same message can be
sent to different objects that have the method with the given name and appropriate
type but different implementations.When the code selection depends only on
the receiving object,it is called single dispatch,whereas in the case of multiple
dispatch,the selected code depends also on method arguments.
is a language construct that is used to refer to the object that executes the
method.The term
is used in languages like Object Pascal and Smalltalk,this
is used in C++ and Java,and Current is used in Eiffel.
Finally,another basic concept of this thesis is the concept of mixin.Mixins
[BC90,FKF98] are (sub)class denitions parameterized over a superclass and
were introduced as an alternative to some forms of multiple inheritance [BLS94,
Bra92,LM96].It can be seen as a function that,given one class as an argument,
produces another class,by adding and/or overriding certain sets of methods.
1.2.2 Typing object-oriented languages
In object-oriented programming languages,types ensure that certain methods can
be safely invoked on certain objects,preventing the occurrence of the so called
message-not-understood errors.In the literature,invo king a method is often
regarded to as sending a message to an object.The object that is sent a message,
must have a method with the same name,where types of formal parameters and
return types are compatible with the ones in the message.
Object types give names and types of methods that the objects of that type
support,but usually do not restrict the implementation of the methods.Types can
be seen as a usable interface which species the legal operat ions on the objects of
that type.As pointed out in [FM96],there is also another formof object type:the
type that also imposes some implementation constraints.In this work,only the
rst formwill be used.
,which denotes the object that receives the message and executes
the method,may introduce complexity in typing systems,when it is given a poly-
morphic type,usually called
specializes as the methods are inherited and can be considered as a special form
of a recursive type.
Subtyping is an important concept that enables uniform treatment of expres-
sions of various types.Object subtyping is based on record subtyping and we
distinguish subtyping in width,where the subtype can have more components,
and subtyping in depth,with componentwise subtyping on the components.This
form of object subtyping is called structural because it depends only on the pub-
lic interfaces of the objects,not on their implementations.Especially,objects in
subtyping relation do not necessary need to be instances of the classes that are in a
subclass relation.Hence,objects with the same interface,but different implemen-
tations can be used interchangeably in a program.There is another formof object
subtyping,called nominal subtyping,where subtyping hierarchy depends strictly
on the class hierarchy (as it is for instance in Java [AGH00]).
In the presence of subtyping,there is some added exibility in constructing
language expressions,although at the price of further complications in typing is-
sues,since the actual parameters of the methods can differ from the formal ones.
Subtyping in the presence of
is more complicated because of the well-
known issues concerning subtyping and recursive types.
1.2.3 Class-based vs.object-based languages
In object-oriented world,there are two predominant programming paradigms:
class-based and object-based.
In class-based languages,objects are created as instances of classes (that can
be seen as templates) and as such are computational entities of a software system.
But they are passive with respect to their structure,which is xed by a class
hierarchy.In object-based languages,new objects are produced starting from
the existing ones,through operations like method addition and method override.
Class-based object-oriented languages (like Java [AGH00] and C++ [Str97]) pro-
mote disciplined programming by enabling construction of class hierarchies,espe-
cially needed in a programming-in-the-large setting.The object-based paradigm
is gaining a renewed interest in the context of script languages (see for example
[BDG02,DG03]) like Java-Script [Fla02],and delegation-based languages (see
for example [AD02,ABDCD03]),since it provides a convenient environment for
experimenting with prototypes,where parts of their implementation might still be
missing.For some insightful discussions about the differences between the two
paradigms observed from different angles,some of the good references are the
books of Abadi-Cardelli [AC96] and of Bruce [Bru02].
1.3 Basic domain theory
The theory of domains was established in order to have appro priate spaces on
which to dene semantic functions for the denotational appr oach to programming
language semantics. [GS90]
This section summarises some basic terminology on domain theory.
A partially ordered set or poset (X,￿
) is a set X with a binary relation
which is reexive,anti-symmetric and transitive.If no con fusion can arise,
we will often omit the underlying relation and write just X for a poset (X,￿
Let X be a poset and let A ⊆ X.Then:
• x ∈ X is an upper bound for A if ∀a ∈ A.a ￿ x;
• x ∈ X is a greatest element of A if x ∈ A and x is an upper bound for A;
• a ∈ A is maximal if ∀a
∈ A,if a ￿ a
,then a
= a;
• the notions of a lower bound,least and minimal element are dened analo-
• a join or supremum of A (if it exists) is a least upper bound for A.It is
denoted by ￿A.A meet or inmum of A (if it exists) is a greatest lower
bound for A.It is denoted by ￿A.
Let X be a poset.Then:
• A ⊆ X is called directed,A ⊆
X,if A ￿= ∅ and ∀x,y ∈ A,∃z ∈ A.x ￿
z and y ￿ z;
• X is complete or cpo if it has a least element ⊥ and every A ⊆
X has a
• X is a lattice if it has nite meets and joins.If it has only nite meets (joi ns)
it is called a meet (join)-semilattice.A poset with arbitrary meets and joins
is called a complete lattice;
• x ∈ X is compact or nite if ∀A ⊆
X.x ￿ ￿A ⇒∃a ∈ A.x ￿ a.The
set of all compact elements of X is denoted by K(X).
Let X be a cpo.Then:
• its lifting is X ∪ {⊥} = X

,where ⊥ ￿∈ X and x ￿

y iff (x =
⊥or x ￿
• X is algebraic if for all x ∈ X,the set M = {x
∈ K(X) | x
￿ x} is
directed and x = ￿M;
• X is bounded complete if every bounded subset of X has a join;
• X is Scott domain if it is algebraic and bounded complete.
A function f between two cpo's (X,￿
) and (Y,￿
) is:
• monotone if ∀x,y ∈ X.x ￿
y ⇒f(x) ￿
• continuous if it is monotone and ∀A ⊆
X.f(￿A) = ￿f(A);
• strict if f(⊥) = ⊥.
If X is a cpo and f:X →X is continuous then a xed point of f is an ele-
ment x ∈ X such that x = f(x).The minimal xed point is given by ￿
For two domains X and Y,the function space X ￿→Y contains the continu-
ous functions fromX to Y ordered pointwise,which means that
f ￿ g iff ∀x ∈ X.f(x) ￿ g(x).
Two posets X and Y are isomorphic if there are monotone functions f:X →
Y and g:Y →X such that g ◦ f = id
,and f ◦ g = id
A pair of continuous functions (f,g),where f:X → Y and g:Y → X is
called embedding-projection pair if g ◦ f = id
,and f ◦ g ￿ id
1.4 Basic category theory
Category theory arose in mathematics to enable abstract description of different
mathematical structures and relationships between them.
A category C is specied by the following:
• A collection Obj(C) of objects,often denoted by A,B,C,....
• A collection Mor(C) of morphisms,often denoted by f,g,h,....
• Two operations assigning to each morphism f its source src(f) and target
tar(f),both objects of C.If A = src(f) and B = tar(g),we write
f:A →B or f ∈ C(A,B).
• Morphisms f and g are composable if tar(f) = src(g).Composition of
two composable morphisms f and g is a morphism denoted by g ◦ f such
that src(g ◦ f) = src(f) and tar(g ◦ f) = tar(g).
• For each object A of C there exists an identity morphism id
:A →A.
• For every f:A →B,g:B →C and h:C →D the following holds:
◦ f = f,f ◦ id
= f
h ◦ (g ◦ f) = (h ◦ g) ◦ f
The opposite category C
is the category with the same collection of ob-
jects as the category C and morphisms given by the following:f:A → B is a
morphismin C
if and only if f:B →A is a morphismin C.
The category is small if Obj(C) is a set.It is locally small if far all A,B ∈
Obj(C),C(A,B) is a set.
A functor F:C → D between two categories C and D,maps objects of C
into objects of D and morphisms of C into morphisms of D,preserving identities
and composition,i.e.,
• For every A ∈ Obj(C),FA ∈ D;
• For every f:A →B in C,Ff:FA →FB in D;
• For every f:A →B,g:B →C,F(id
) = id
and F(g◦f) = Fg◦Ff.
In a category C,a binary product of objects A and B is a triple

where A × B is an object in C,and π
:A × B → A,π
:A × B → B are
morphisms in C,such that for any C ∈ C and any two morphisms f:C →A and
g:C → B,there is a unique morphism h:C → A ×B for which π
◦ h = f
and π
◦ h = g.h is usually denoted by ￿f,g￿.
Given morphisms f:X → X
and g:Y → Y
,morphism f ×g is dened
f ×g = ￿f ◦ π
,g ◦ π
￿:X ×Y →X
Finally,cartesian closed category (CCC) is a category which has nite prod-
ucts and for any A,B ∈ Obj(C),exponent B
∈ Obj(C) and a morphism
× A → B exist,such that for any f:A × B → C there is a unique
morphismλ(f):A →C
for which f = ev ◦ (λ(f) ×id
Some examples of categories are:
1.Set (Part),the category of sets and total (partial) functions;
2.Any preorder (X,≤) can be seen as a category,where objects are the ele-
ments of X,and morphisms are instances of the order relation;
3.Cat,the category of small categories and functors;
4.SDom,the category of Scott domains and continuous functions.
For further reading on category theory,some of the good textbooks are [Lan71,
1.5 Overview of the thesis
This thesis was developed as a joint work between Dipartimento di Informatica,
Universita di Torino,Italy,and
Ecole Normale Sup´erieure de Lyon,France,under
supervision of Prof.Viviana Bono (Torino) and Prof.Pierre Lescanne (Lyon).
The thesis is divided into three parts.The rst part,superv ised by Prof.Vi-
viana Bono,is described in Part II.It is a proposal for the design of a mixin-based
calculus that combines and puts to the test some fairly innovative features with
more classical ones.It is organised as follows:
• Chapter 2 is an introduction to mixin calculi.It also gives a simple example
of the mixin usage and gives an account on the existing work on the subject.
• Chapter 3 is a short overview of Core calculus of mixins and classes
of [BPS99] that was the starting point for the rst part of the t hesis.
• Chapter 4 presents the extension of the Core calculus of mixins and cla sses
of [BPS99] with higher-order mixins,which enable the construction of more
exible class hierarchies.
• In Chapter 5 the Core calculus of mixins and classes of [BPS99] is en-
riched with incomplete objects,thus yielding a language suited for rapid
prototyping.It is an attempt to integrate good features of class-based and
object-based languages.
• In Chapter 6,width subtyping on complete objects is added to the variant of
the calculus with mixins and incomplete objects fromChapter 5.A general
technique for composing objects in the presence of subtyping is given.
• Finally,Chapter 7 concludes comparing our work with the related work on
the subject,and giving some directions for possible future development.
The work on the mixin-based calculi is published in [BBL04a,BBL04b,BBL04c,
The second part was developed under the supervision of Prof.Pierre Lescanne
and is described in Part III.It investigates some properties of the untyped
calculus and is organised as follows:
• Chapter 8 recalls the syntax and the reduction rules of
λµ￿µ calculus,and
its two well-behaved subcalculi
.It also presents the type
system based on simple types,and gives a short account of the related sys-
• Chapter 9 presents an elegant proof of the conuence for the
variants of the calculus.
• Chapter 10 deals with the denotational semantics of untyped
λµ￿µ calcu-
lus.It gives an account of negated categories where the
calculus is
interpreted.Next,the basic notions of Kleisli triple and Kleisli category
are presented and interpretation of the
calculus is given.Finally,the
improved interpretation of
calculus is provided.
• Chapter 11 concludes,indicating some possible future research directions.
The work fromthis part can be also found in [LL04].
The third part was written in collaboration with Prof.Mariangiola Dezani and
Prof.Silvia Ghilezan It is presented in Part IV and is organised as follows:
• Section 12.2 discusses the duality between intersection types and inverse
limit domains.
• In Section 12.3 the models D

and E

are built.
• In Section 12.4 we dene intersection types and build sets F
and F
lters in order to prove the isomorphismbetween the inverse limit λ-models
and the lter models.The corresponding intersection type a ssignment sys-
tems are dened in Section 12.5.
• The main result is a complete characterisation of computational behaviours
of terms by their typeability in the corresponding type systems.This is
stated in Section 12.5 and one direction of the equivalence is proved there
for all cases but for persistently normalising terms.Section 12.6 deals with
the case of persistently normalising terms,which needs the notions of re-
placeable and non-replaceable variables.
• In Section 12.7 we prove the other direction of the equivalence using stan-
dard techniques of the reducibility method adapted for these type systems.
The results fromthis part are published in [DCGL04].
Part II
Core calculus of classes and mixins
and extensions
Chapter 2
Mixins in programming languages
2.1 Introduction
2.1.1 What is a mixin?
Recently,the concept of a mixin is undergoing a renaissanc e,due to its exible
nature of incomplete entity that can be completed accordi ng to the program-
mer's needs.There are two uses of the term mixin in the litera ture:it can be
seen as a mixin class (parameterized (sub)class denition,see [ALZ00,DT01,
BBV02,BBV03]),and as a mixin module (module supporting deferred compo-
nents,see [ALZ02,FF98,SB98,HL02]).In this work the term mixin refers to
mixin classes.
Mixins [BC90,FKF98] are (sub)class denitions parameterize d over a super-
class and were introduced as an alternative to some forms of multiple inheritance
[BLS94,Bra92,LM96].Amixin could be seen as a function that,given one class
as an argument,produces another class,by adding and/or overriding certain sets
of methods.The same mixin can be used to produce a variety of classes with
the same functionality and behavior,since they all have the same sets of methods
added and/or redened.This uniformextension and modicat ion of classes is ab-
sent from the classical class-based languages,where a new subclass needs to be
written whenever a class has to be extended with a certain set of components.
The superclass denition is not needed at the time of writing the mixin def-
inition.This minimizes the dependencies between superclass and its subclasses,
thus improving modularity and code reuse.
Mixins actually specify how a particular subclass differs from an arbitrary
superclass.Therefore,separate mixins can be used to specify each of these varia-
tions and more complex structures can be obtained by combining the basic mixins.
This approach is fundamentally different fromthe inheritance mechanismin pure
class-based languages.
As mentioned before,the notion of mixin is not strictly connected to object-
oriented programming.A mixin module is generally regarded as a construct with
some missing components,expected to be provided by some other module.Mix-
ins were rst introduced in the Flavors system [Moo86] and CLO S [Kee89],al-
though not as a formal language construct but as a programming idiom.
2.1.2 Examples
In this section,we present the examples that should illustrate some of the uses of
In standard class-based languages,(sub)classes are produced by extending
the (super)class,giving denitions of new methods and/or r edening the exist-
ing methods fromthe superclass.
Let us assume that we have two classes FileStream and Socket that both
have methods read and write with different implementations.Moreover,class
Socket may have some additional methods,for example,IPaddress.
To create encrypted streamclass EncryptedFileStream which redenes
these two methods,we have to extend the class FileStream providing rede-
nitions for these two methods.
class FileStream
method write =...
method read =...
class EncryptedFileStream extends FileStream
redefine write =...
redefine read =...
If we also want to create class EncryptedSocket,which encrypts data
communicated over a network connection,then read and write methods must
be redened with the same body as in the previous case.Theref ore,we have to
extend the class Socket providing again the same redenitions for these two
class Socket
method write =...
method read =...
class EncryptedSocket extends Socket
redefine write =...
redefine read =...
In some other situation we might want to use the stream as a logging de-
vice which provides a doLog method.Then we have to create the subclass
LogFileStream that extends the class FileStream with the denition of
doLog method.The same would happen if we wanted to use a socket as a log-
ging device,i.e.,we would again be in the situation to create a new subclass
LogSocket with the same additional method denition.
class LogFileStreamextends FileStream
method doLog =...
class LogSocket extends Socket
method doLog =...
We can see that the extensions in all the cases duplicate the code,thus making
the code less understandable and more difcult to maintain.It would be much
better if we could reuse the method redenitions that we used when extending the
FileStream class to also extend the Socket class.Furthermore,it should be
possible to use the denition of doLog method whenever we need to add logging
functionality to some class.
Mixins are a simple solution to these problems.We can group the encrypting
redenitions into Encrypted mixin and then apply this mixin to all the classes
that need to be encrypted.
mixin Encrypt
redefine write =...
redefine read =...
class EncryptedFileStream= Encrypted ￿ FileStream
class EncryptedSocket = Encrypted ￿ Socket
In the same manner,we can create the mixin Logger and apply it to any class
that is supposed to provide logging.
mixin Logger
method doLog =...
class LogFileStream= Logger ￿ FileStream
class LogSocket = Logger ￿ Socket
Mixins are also useful to simulate some cases of (linearized) multiple inher-
itance.For example,we can construct class LogEncryptedFileStream by
applying mixins Logger and Encrypted to FileStream,i.e.,
class LogEncryptedFileStream= Logger ￿ Encrypted ￿ FileStream
With the mixin constructs we achieved a signicant reductio n in code size,
and we provided for a better understanding of the program,since the connected
(re)denitions are grouped together and can be uniformly ap plied to many differ-
ent classes.
In the following chapters (see Sections 4.6 and 5.7) we will see how this ma-
chinery works in our proposal and what are its benets and res trictions.
2.2 Literature on mixins
In the literature,there are many proposals that deal with mixins.We mention here
some of them,the most interesting with respect to our proposal.Direct compari-
son with our work will be given in Section 7.2.
• Bracha and Cook extend Modula-3 with mixins in [BC90] (this is one of
the seminal papers on mixins).Mixins are taken as the basic compositional
constructs in the language and inheritance is simulated by mixin composi-
tion.The novelty is seeing object types as mixins,which either explicitly
state the modications to the superclass,or are obtained as a result of mixin
composition.The left-hand mixin has a priority and the co mposition is
not explicitly written in order to ensure upward compatibility with the ex-
isting language.
• JIGSAW is a module manipulation language introduced by Bracha and
Lindstrom [Bra92,BL92].The basic notion is that of a module and oper-
ators can be seen as module-to-module functions.JIGSAW's operator suite
supports mixins,encapsulation,multiple inheritance,and strong typing.
Amodule is a language construct that binds names to values through deni-
tions.Names are not bound to types.Module can also contain declarations
which assign types to the attributes,without providing values for them,and
are used for dening abstract classes.Modules do not have fr ee variables.
They can be nested.
While JIGSAW is a typed language,its operators are dened in untyped
lambda calculus and typing constraints are deduced for module operations.
They do not need access to modules'denitions.Since module s are seen as
generators,operators are modelled as functions that operate on generators
and produce generators as results.
There is a number of operators that can be used to modify modules.Mixin
composition is modelled by merge and override operations.In the rst case,
name conicts result in static error,while in the second one,left-hand mod-
ule is modied by the right-hand one,where the type of the res ult is taken
from the overriding module and it has to be the subtype of the type in the
module being overridden.It is also possible to:eliminate the conicting
attributes by rename operator,eliminate the attribute denition (but retain
its declaration) by restrict in order to achieve sharing,statically bind at-
tribute references by freeze,control visibility by hide and show,and access
overridden denitions by copy-as operator.
Typing in JIGSAWis structural.Modules have interfaces associated to them
which provide types for all visible attributes of the module.The subtyping
relation on interfaces is interface equivalence.
Object are produced instantiating modules,which is done by taking the
xed-point of the module generator.
• Flatt et al.[FKF99] extend a subset of sequential Java called CLASSIC-
JAVA with mixins and call it MIXEDJAVA.Only mixins and interfaces can
be declared,whereas classes can be seen as special cases of mixins where all
the components are dened.As opposed to C LASSICJAVA,where classes
are organized into class hierarchy,and new classes are produced by extend-
ing the existing classes,in MIXEDJAVA the basis for inheritance is a mixin
hierarchy and new classes are produced by applying mixins to classes.
They distinguish two types of mixins,atomic and composite ones.Atomic
mixin denes a set of elds and methods that extend or/and red ene elds
and methods fromunspecied superclass.Mixin is not statically connected
to the superclass,but uses its inheritance interface to specify howthe inher-
ited methods are extended and/or overridden.Mixin also implements one
or more interfaces.
A composite mixin does not have any new eld and method denit ions,
but combines two existing mixins in order to produce a new mixin with
different functionality.The left-hand mixin has a preced ence over the
right-hand one which means that the method redenitions are taken from
the left-hand mixin according the left-hand mixin's inheri tance interface,
whereas the new denitions are taken from both mixins.Compos ition is
well-dened only if the right-hand mixin implements the lef t-hand mixin
inheritance interface (i.e.,the right-hand mixin is required to provide all the
methods expected by the left-hand one).A new mixin extends the right-
hand mixin inheritance interface and implements all the inheritance inter-
faces implemented by the composing mixins.
The duplication of method names during run-time is resolved with the run-
time context information provided by the current view of the object (repre-
sented as a chain of mixins).
It is possible to instantiate mixins with the new operator if they have all
the methods implemented,i.e.,they do not inherit any methods from the
• Boudol [Bou01] extends Reference ML [WF94] with records and let rec
operator.Degrees (which are boolean information) are introduced into the
type system,distinguishing certainly safe frompossibly unsafe variables for
recursion from the typing context.Degrees apply also to functions select-
ing out the functions that are protective towards their arguments and thus
safe for the recursion (since in the recursive record semantics of objects the
usage of let rec expression is unsafe).This enriched ML leads to a theoret-
ically solid treatment of mixins,which are seen as class transformers and
are protective functions of their argument
• Ancona and Zucca [AZ98,AZ02] give a formal mathematical model for
mixin modules.A mixin is a function from input to output components,
i.e.,fromdeferred and virtual components to the components dened in the
module.They give an axiomatic/denotational characterisation of the oper-
ators for composing mixins in order to obtain higher-order mixins.These
operations are:merge,restrict,override,hide,and functional composition.
It is showed that all these operations can be expressed using three primitive
operations (sum,reduct,freeze) which are characterized by the small set of
axioms.They also present a variety of method renaming forms,to deal with
different typologies of name collisions.
• In [LZ03] Ancona et al.present JAM,where the notion of mixin is inte-
grated with Java,respecting Java design principles and type system con-
In JAM,mixin declaration has two parts:components dened by the m ixin
and components expected from the superclass,labelled with inherited
modier.The latter methods must have the same return and arg ument type
and equivalent throws clause as the corresponding methods in the parent
class.Unexpected and ambiguous overriding,as well as hiding,are all for-
bidden in JAM.Mixin instantiation on classes can be explained by a copy
principle,i.e.,the newly obtained subclass behaves as if obtained by usual
inheritance,copying all the components from the superclass.Mixins can
implement interfaces,in the same way classes do.
Classes obtained by applying the same mixin to different classes are sub-
classes of the corresponding mixin.This enables using common interface
to manipulate objects of any mixin instance.
JAM to Java translator ensures that JAM code can be executed on every Java
Virtual Machine.
One of the drawbacks of the approach in this work is that this cannot be
used as argument in method and constructor invocations inside a mixin.
Therefore,it is not possible to refer to the generic parent class or to the
generic heir class.Moreover,there is no support for mixin composition.
• Traits have been recently proposed by Sch¨arli et al.[SDNB03] as an al-
ternative to class and mixin inheritance in order to enhance code reuse in
object-oriented programs.A trait is a collection of methods that can be
used as building blocks for assembling classes.It is a lan guage construct
that implements pure behaviour providing only a set of methods.It can also
expect some other methods that serve as parameters.A trait neither denes
nor directly accesses state variables.
Newclasses can be created by subclassing existing classes,possibly adding
a set of traits or composting a number of traits.Additionally,special glu-
ing methods that connect the traits and state variables nee d to be provided.
When traits are composed (using symmetric sum,override,exclusion,and
aliasing operators) the conicting methods are resolved explicitly.Thus
traits can be used to extract reusable building blocks from classes,thereby
identifying different aspects of their behaviour.
The original calculus of traits,since intended as an extension of Smalltalk,
is untyped.A typed calculus of traits is proposed by Fisher and Reppy in
[FR04] as an attempt to integrate traits into a statically-typed object-oriented
Chapter 3
Core calculus of classes and mixins
3.1 Overview
The rst part of this thesis extends The Core Calculus of Classes and Mixins of
[BPS99].When designing the calculus,the main goal was to nd a balanced
solution that has enough expressive power and a relatively simple type system.
Starting fromthe basic constructs like records and references,the components
that model classes and mixins were added,thus producing a calculus that supports
mixin inheritance,data encapsulation,structural subtyping,and modular object
creation.The main constructs introduced in the calculus are:
- class value classval,
- mixin expression mixin,
- mixin application ￿,
- instantiation expression new.
Mixins govern the inheritance mechanism which is achieved via mixin appli-
cation.The class values are the products of mixin inheritance.The new construct
creates new objects fromthe existing classes.
The class value consists of a class generator,and two sets of method names,
public and protected.The generator function produces a function from
a record of methods.To this function,the xed-point operat or can be applied at
instantiation time (when new constructor is applied) to bind
in method bodies
and produce an object.
A mixin expression consists of declarations of new and rede ned methods,as
well as the mixin constructor,described later.It also contains names of protected
methods,not modelled in the extensions presented in this work.
Inheritance in the calculus is simulated by applying a mixin to a class value.
When creating a new (sub)class,mixin dictates the changes to the (super)class.
First,the superclass generator builds the record of its methods.Then the generator
of the new class is built by integrating the modications spe cied by the mixin
(method additions and/or replacements).
Instantiation is possible only on fully-edged classes,wh ile mixins serve only
as inheritance mechanism.
Objects are represented by recursive records of methods.Methods are func-
tions that depend on two arguments,
.A special parameter
bound in all method bodies to enable themto reference the host object.Recursive
reference to
is given only after resolving the inheritance,which permits the
xed-point operator to be applied only once.Redening metho ds have three ar-
guments:additional special keyword
is used to enable themto access the old
method body inherited fromthe superclass.
Constrained parameterization ensures static type checking.Each mixin dec-
laration species to which class the mixin may be applied.Th e mixin declara-
tion and mixin application are typed separately.The calculus supports structural
subtyping,hence the types of objects do not depend on the classes they were
instantiated from,which removes the dependency of object users on class imple-