Polimorfismo per Sottotipo verso la programmazione orientata agli ...

Polimorfismo per Sottotipo
verso la programmazione orientata
agli oggetti
Motivazioni
La regola di typing (T-App) per l’applicazione funzionale è molto
restrittiva: per avere un’applicazione ben tipata è necessario che
l’argomento abbia esattamente il tipo richiesto dalla funzione!
Ad es., la funzione λx:{a:Nat}. x.a
non è applicabile ad un record r:{a:Nat, b:T}
Eppure l’applicazione potrebbe essere possibile; si chiede solo che
l’argomento abbia un campo a:Nat da selezionare....
il record r ha questo requisito....
....ha anche altro, che possiamo ignorare!
1
2
1

Idea di base
Intuizione: alcuni tipi sono più informativi di altri, dunque possono essere
utilizzati anche dove si richiede meno informazione !
• S

Subtyping sui tipi record
• (permutazione)
Sottotipo sui tipi record
{l i:T i} è una permutazione di {l k:T k} {l i:T i}

Lambda Calcolo con Subtyping
Se estendiamo il “lambda calcolo con tipi semplici e
record” con il subtyping
La decidibilità del typing?
si mantiene la type safety
Più problematica da dimostrare perchè le regole non sono
guidate dalla sintassi
• transitività del subtyping
• (regole di typing) T-SUB
Subtyping in versione Algoritmica
•Elimino la transitività dalla definizione del subtyping
•La regola di aplicazione funzionale diventa:
Γ|- t:R→S Γ|- s:U U

Verso i linguaggi orientati agli oggetti
• Il sistema di tipi di questi linguaggi è caratterizzato
dal polimorfismo per sottotipo
• Il tipo di un oggetto è l’insieme dei nomi-tipi delle
sue operazioni : interfaccia, tipo = classe dell’oggetto
• classe derivata sottotipo
la relazione di sottipo è implicata dalla derivazione di
classe definita dal programmatore : subtyping nominale
invece che strutturale (la dimostrazione di relazioni di
sottotipo diventa triviale)
Featherweight Java
Un “core-language object oriented”
basato su Java
9
10
5

Cosa c’è in FJ
Scopo: Scopo astrarre i meccanismi fondamentali di Java per definire
typing e semantica e provare type-safety in modo semplice.
Vantaggio: Vantaggio per ogni altra caratteristica aggiuntiva, si studia
l’estensione di FJ con questa caratteristica e si estende la prova di
type-safety in modo ancora...semplice.
Meccanismi fondamentali
Termini: oggetti, creazione di oggetti, invocazioni di metodi e
selezione di campi, cast.
Dichiarazioni: classi, ereditarietà, riscrittura di metodi e
binding dinamico.
Cosa non c’è.....
Sono volontariamente omessi tutti quegli aspetti che renderebbero la prova di
“type-safety” solo più lunga, senza introdurre elementi significativi
(è comunque un frammento computazionalmente completo)
Mancano (rispetto a full Java)
-parte imperativa: assegnamento e referenze
-controllo dell’accesso : tutto è pubblico
-eccezioni
-chiamate al super (tranne che nel costruttore)
-classi astratte (Interface) – inner classi –
-tipi di base (int, bool,...) (anche se li useremo talvolta in esempi)
12
11
6

Un primo sguardo informale
Un programma FJ è formato da
Parte Dichiarativa
termine (main)
ESEMPIO: Parte Dichiarativa D
class A extends Object { A() { super(); } }
class B extends Object { B() { super(); } }
class Pair extends Object {
Object fst; Object snd;
Pair(Object fst, Object snd)
{ super(); this.fst=fst; this.snd=snd; }
Pair setfst(Object newfst)
{ return new Pair(newfst, this.snd); }
13
14
7

D
ESEMPIO: D + Main
Lucido precedente
new Pair (new A( ), new B( ) ).setfst (new B( ) )
Semantica
Come risultato finale ci attendiamo :
new Pair (new B( ), new B( ) )
Espressione da valutare nel
contesto delle dichiarazioni
FJ Sintassi : Termini e Valori
t ::= termini
x variabile
t.f selezione campo
t.m(t ) invocazione metodo
new C(t ) creazione oggetto
(C) t cast di tipo
v ::= valori
new C(v) creazione oggetto
Dove t sta per t 1 ,..., t n , etc.
15
16
8

FJ Sintassi : Dichiarazioni
• K ::= dichiarazione costruttore
C(C f) {super(f); this.f=f;}
• M ::= dichiarazione metodo
C m(C x) {return t;}
• CL ::= dichiarazione classe
• class C extends C {C f; K M}
dove C f sta per C 1f 1...C nf n, M sta per M 1...M n, e
simili.
Notare!
• Si esplicita sempre la superclasse di una classe
(eventualmente OBJECT che è assunta essere una classe
vuota): i campi dichiarati dalla sottoclasse sono aggiunti a
quelli della superclasse (e delle sue superclassi) e devono
avere nomi distinti!
• L’oggetto è un new esplicito con il costruttore (e eventuali
parametri), non ha un’identità (non ci sono referenze)
• È sempre esplicito l’oggetto su cui si invoca il metodo,
anche nel caso del this
• Il costruttore ha una struttura prefissata: super(...) e
inizializzazione dei nuovi campi con i (rimanenti)
parametri (in ordine).
17
18
9

Classe = Tipo
• Quando dichiaro una classe A , sto
introducendo la definizione di un nuovo
tipo di nome A
• La rappresentazione interna di questo tipo A
è un tipo record
>
• Le istanze/oggetti di tipo A avranno una
rappresentazione a record corrispondente
SUBTYPING Nominale
• Come in Java, il sottotipo è dichiarato (sottoclasse)
• Assumiamo una class table CT : funzione che associa
ad ogni nome di classe una dichiarazione
• CT(C) = class C extends D {...}
• C

Subtyping nominale vs. Strutturale
♦Nominale: i nomi sono significativi! Da essi dipende
l’insieme delle relazioni di sottotipo valide: il compilatore, al
momento della dichiarazione di sottoclasse, deve solo
controllare che la relazione di sottotipo sia rispettata (ad es.
non ci sono nomi di campi uguali fra quelli ereditati e quelli
definiti). Il confronto fra le rappresentazioni dei tipi avviene
solo una volta sola.
♣Strutturale: le relazioni di sottotipo valide dipendono dalla
rappresentazione dei tipi (il subtyping è definito sui tipi in
base alla loro struttura); ogni volta che in una derivazione di
tipo devo provare una relazione di sottotipo, devo confrontare
i tipi-record che li rappresentano
Nominale vs.Strutturale: Vantaggi
♦ Nominale:
nomi/tipi sono utili anche a run-time (tag degli oggetti)
danno gratis i tipi ricorsivi e mutuamente ricorsivi (un tipo A può
riferirsi ad A nella sua definizione, oppure A si riferisce a B che si riferisce
ad A senza che abbia alcun senso domandarsi quale, fra A e B, è definito
per primo)
la relazione di sottotipo è decidibile in senso triviale
♣ Strutturale
sono molto più eleganti ed adatti a studi teorici, in quanto ogni
espressione di tipo ha in sè tutte le informazioni per ragionare sulle sue
proprietà
21
22
11

Nominale vs.Strutturale:Svantaggi
♦Nominale:
1) Una convenzione sui nomi ( la loro rappresentazione, le relazioni di
sottotipo dichiarate, etc..) è preliminare alla stessa operazione di controllo
che la definizione del tipo è corretta (es., che i metodi siano correttamente
tipati)
Per esempio, una tabella delle classi del programma è costruita come passo
preliminare, quindi è parametro del typing: il controllo della correttezza sia
delle dichiarazioni che del main -correttezza rispetto ai tipi- usa le
informazioni di questa tabella
2) Una convenzione sui nomi riguarda un “ambiente” : es., ambienti come
reti etc. sono più refrattarie a tali convenzioni globali.
FJ : la tabella CT delle classi
Una tabella di classi CT è una funzione da nomi di classi
C a dichiarazioni di classi CL.
Un programma è una coppia (CT, p) dove p=D t :
in ciò che segue assumiamo di riferirci sempre a una fissata CT
(se esaminiamo il programma p, è quella costruita dalle
dichiarazioni di p)
Si assume che CT soddisfi delle condizioni di consistenza (sanity
conditions):
i) per ogni C che compare in CT, C appartiene al dominio di CT
(tranne che per OBJECT)
ii) non ci sono cicli nella relazione

Definizioni Ausiliarie:
lookup campi
• fields(Object) = Ø (Ø sequenza vuota)
• CT(C) = class C extends D {C f; K M}
fields(D) = D g
fields(C) = D g; C f
fields( C ): restituisce la lista dei campi di C, ereditati e nuovi
Definizioni Ausiliarie:
lookup tipi metodi
• CT(C) = class C extends D {C f; K M}
B m (B x) {return t;} ∈ M
mtype(m; C) = B→B
• CT(C) = class C extends D {C f; K M}
m is not defined in M
mtype(m; C) = mtype(m; D)
25
26
13

Definizioni Ausiliarie:
lookup definizioni metodi
• CT(C) = class C extends D {C f; K M}
B m (B x) {return t;} ∈ M
mbody(m; C) = (x; t)
• CT(C) = class C extends D {C f; K M}
m is not defined in M
mbody(m; C) = mbody(m; D)
Definizioni Ausiliarie:
riscrittura-metodi legale
mtype(m; D) = D→D 0 implica
C = D and C 0 = D 0
override(m, D, C →C 0)
Il predicato override(m, D, C →C 0 ) restituisce vero se il metodo m: C →C 0
può essere definito in una sottoclasse di D (la riscrittura del metodo è legale
solo se mantiene la setssa signatura!)
27
28
14

Semantica Operazionale
• Regole di transizione per ridurre termini
a valori
• Semantica call-by-value : l’invocazione di un
metodo è valutata solo dopo aver ridotto a valore
sia il termine che rappresenta l’oggetto
d’invocazione sia i parametri attuali (i valori a cui
i termini si riducono sono termini di creazioneoggetti
della forma new A(v 1...v n) )
• Semantica di computazione/small step
Regole di valutazione
Nota. A) this è una variabile (esattamente come i parametri formali), rimpiazzata
dall’oggetto di invocazione nel body del metodo; B)come in Java, un cast run-time
non modifica l’oggetto, semplicemente ha successo o fallisce;
C) il parametro attuale è un valore
29
30
15

Regole di Congruenza
ESEMPI: Valutazione...
• Selezione campo
new Pair(new A(), new B()).snd
• Cast
→ new B()
(Pair)new Pair(new A(), new B())
→ new Pair(new A(), new B())
31
32
16

ESEMPI: Valutazione
• Invocazione metodo
ESEMPI: Valutazione
• Selezione campi + cast
Definizione. La riduzione →* è definibile come al solito: è la
chiusura transitiva di quella a un passo.
33
34
17

Nota sul binding dinamico
• Sistemi con tipi nominali (es. Java): ogni oggetto run-time
ha un tag con il (concretamente, un puntatore al) suo tipo
attuale (nome della classe con il cui costruttore l’oggetto è
stato creato mediante “new”), che contiene un puntatore
alla superclasse, etc...
• Il suddetto tipo attuale , con cui l’oggetto è etichettato,
viene utilizzato per informazioni sul tipo dinamico, RTTI,
per la ricerca dinamica dei body dei metodi associati
all’oggetto (binding dinamico), etc.
• In FJ non ci sono le referenze agli oggetti, l’oggetto è
direttamente un new di una classe; perciò il tag run-time
coincide con il tipo che è argomeno della new.
Esercizio
Scrivere un programma con override di un metodo e descriverne
la valutazione, evidenziando il binding dinamico per la chiamata
del metodo riscritto.
35
36
18

Sistema di Tipi
Insieme di regole, guidate dalla sintassi, per
dimostrare asserzioni della forma
• Γ ⏐⎯ t : C t ha tipo C in Γ
• .... m ... OK in C m è ben tipato in C
• class C......... OK
la definizione della classe C è ben tipata
dove Γ è un insieme di assunzioni della forma x:C.
Si assume già data la tabella CT, su cui lavorano le funzioni ausiliarie.
Typing dei termini
(variabili e new)
37
38
19

Typing dei termini
(selezione campi/invocazione metodi)
Typing dei termini (cast)
Domanda Perchè 2 regole di tipo per il cast? Perchè così è in Java.....
Domanda: perchè c’è, invece, una sola regola di valutazione, quella
per Up-cast, nella semantica operazionale ?
39
40
20

Nota sui cast
• Typing: ci sono 3 forme possibili di cast:
i) in 2 di esse, il soggetto è sottoclasse o sopraclasse del
target, quindi il tipo statico (assunto dal type checker) è
quello del target
ii) nella terza forma, il target ed il tipo del soggetto non
hanno alcuna relazione di sottotipo: in tal caso vogliamo
che il typechecker rifiuti come mal-tipata l’espressione,
infatti così è in Java............................
Ancora sui cast
Valutazione: quando riduco un cast, se il tipo
run-time dell’oggetto è sottotipo del target,
si elimina semplicemente il Cast (dunque,
basta una sola regola di valutazione):
Negli altri casi mi arresto su un termine che
non è un valore!
41
42
21

Typing dei Metodi
Nota: la definizione di override è un’implicazione; dunque, se
m non occorre in D , l’antecedente override(...) è trivialmente
vero!
Typing delle Classi
La definizione della classe C è ben tipata sse il costruttore ha la forma richiesta
(chiama il super per inizializzare i campi della sopraclasse, poi inizializza i campi
aggiuntivi di C, rispettando le concordanze di tipo dei parametri) ed ogni metodo è
ben tipato in C.
43
44
22

Riassunto del Typing
• Il typing è in forma algoritmica (la
subsumtpion è implicita dove serve)
• Usando i tipi dei termini si può decidere se i
metodi sono ben tipati o non (typechecking)
• Se i metodi sono ben tipati, si può decidere
se la classe è ben tipata (ossia tutti i metodi
sono ben tipati, i campi e il costruttore
rispettano la forma richiesta) (typechecking)
Un problema sui cast (continua)
Per dimostrare la type preservation con una small-step semantics è
necessario (solo formalmente), introdurre gli stupid-cast
Ad esempio, siano A e B sottoclassi di OBJECT, ma non correlate fra
loro: si consideri il seguente termine
(A) (Object) new B( )
che è ben tipato per il compilatore.
Ma run-time può succedere che ...??????????????
(A)(Object) new B( ) → (A) new B( ) ...............
chiaramente (A) new B( ) non è tipabile con nessuna delle
2 regole descritte sopra
45
46
23

Regola per stupid-cast
Per trattare formalmente il teorema di Type-Preservation
(senza passare alla big-step semantics) , estendiamo le
regole di Typing con la seguente regola (T-SCast)
Γ⏐⎯ t : D not(C

Type Preservation
Typechecking: Un termine con un sottotipo
può essere usato in ogni contesto in cui è
richiesto un tipo più grande (polimorfismo)
I termini (programmi) ben tipati si
mantengono ben tipati durante la
valutazione.
Nota sui Cast
Un termine FJ ben tipato che non contiene down-cast
si riduce sempre a termini che non contengono nè
down-cast nè stupid cast.
49
50
25

Proprietà: Progress
• GOAL (Progress)
Un termine ben tipato, che non contiene
down-cast, o è un valore o si può ridurre
con una regola di valutazione
(ossia, un termine che ha un tipo e contiene
solo up-cast non può produrre fallimento, o
è gia un valore o si riduce per valutazione )
Progress (prova formale)1
Lemma (assenza di “campo inesistente” o di
“messaggio non compreso” in programmi ben
tipati)
Sia t un termine ben tipato:
• Se t=new C(t 1,..t n).f allora
f appartiene ai fields(C)
• Se t=new C(t 1,..t n).m(s 1,..s k) allora
mbody(m,C) = ((x 1,..x k), t0)
Prova. Triviale, per induzione sulle regole di Typing
51
52
26

Progress (prova formale)2
Si deve formalizzare il concetto di “contesto di valutazione”
per esprimere “il prossimo termine da ridurre”.
Un contesto di valutazione E è un buco [ ] oppure E.f,
E.m(t), v.m(v,E,t), new C(v,E,t), C(E).
Scriviamo E[t] per indicare il termine ottenuto rimpiazzando
il buco in E con t.
Così, se t->t’, possiamo scrivere
t come E[r] e t’ come E[r’] , per un unico E,
dove r->r’ con un passo di valutazione
Progress (prova formale)3
Formulazione formale del Teorema di Progress:
Sia t un termine chiuso che non può essere ridotto
(forma normale); allora o t è un valore oppure è
uguale a un contesto di valutazione E riempito
con (C)newD(v), dove D non è sottotipo di C
ossia
t = E[(C)newD(v)] con D non sottotipo di C.
Prova. Per banale induzione sulle regole di typing.
53
54
27

Type Safety : tiriamo le fila
Cucendo insieme i risultati ottenuti:
1. Se un termine FJ è ben tipato ed eseguiamo un passo
di valutazione, otteniamo un termine ben tipato
(Preservation)
2. Se un termine è ben tipato, allora ogni selezione di
campo ed invocazione di metodo è corretta (non può
produrre uno stuck) ( Lemma )
3. Se arriviamo ad un termine stuck (non si può ridurre
e non è un valore) allora ci siamo fermati su un Cast
in cui il tipo effettivo dell’oggetto non è un sottotipo
del target del Cast (Progress formale)
Come volevasi dimostrare : Type Safety
TYPE SAFETY
Un programma corretto rispetto ai tipi
senza down-cast non può fallire run-time
Prova. Preservation + Progress .
Ovviamente in Java sono ammessi down-cast,
in questo caso l’eventuale fallimento è
rappresentato dal sollevamento di
opportune eccezioni run-time.
55
56
28

Esempio
Siano A e B due classi in cui il metodo m è riscritto, es.:
class A extends Object { A() { super(); }
Bool m() { return true; } }
class B extends A { B() { super(); }
Bool m() { return false; }}
Si consideri il termine ((A) new B()).m
(1) Typing: ⏐⎯(A) new B():A ossia
⏐⎯((A) new B()).m :Bool
(2) Valutazione: (A)new B() → new B() perciò
((A)new B()).m → new B().m
che restituisce false (binding dinamico)
(3) Type Preservation : (A)new B() → new B()
⏐⎯(A) new B():A , ⏐⎯new B():B dove B