The CoreLaCasa1 Language
Philipp Haller1 and Alexandre Loiko2
1
KTH Royal Institute of Technology, Sweden
[email protected]
2
Stockholm University, Sweden
[email protected]
Todo list
Possibly add All to set of types(?) Otherwise have to di↵erentiate between syntax types
and type-checking types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
This a↵ects the conclusion and proof of last case of Theorem 1. As the theorem and
proof is currently stated, box-typed names can contain null. . . . . . . . . . . . . .
refer to ECOOP’10, which refers to FJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maybe change the syntax to have the types coincide and not have more ⌃, -types than
method and field types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I think it makes sense for the meta-variables C, D to allow value Object. It is unclear
whether they do. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
citation! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to better formulate this? A definition by equivalence seemed better than a definition
by axioms because of the negation. . . . . . . . . . . . . . . . . . . . . . . . . . . .
There are probably about 5-6 di↵erent kinds judgements A ` B with di↵erent types of
A and B. Is this how things are usually done? Is it possible to introduce di↵erent
notation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Potential problem: box types do not have labels. Thus ` t : ⌧ in T-Open means that t
cannot be a box type. This it is a unnecessary restriction. . . . . . . . . . . . . . .
insert citation! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Well-formed class definitions: similar to ECOOP’10, TODO: present in conventional rule
& axiom notation! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overriding is messy. See ECOOP’10. Add rules. Write this in a better way. . . . . . . .
I am still not sure how to ensure that new C, Box[C], x.f etc will never fail due to
unknown C. Must (at least in mechanization) restrict set of types to be only
those in cd. How is it simplest to formulate that H, F S will only contain subterms
and sub-expressions of a well-formed program? . . . . . . . . . . . . . . . . . . . . .
Problems with the current rules: `x F S requires ` hL, ti,
(x) = . But by the
current evaluation rules it may happen that x 62 L. An example is let x1 =
obj.meth(par) in x1 . Evaluating this one step from L = {obj 7! . . . , meth 7! . . .}
x
gives H, h{this 7! . . . , p 7! . . .}, bodyi 1 hL = {obj 7! . . . , meth 7! . . .}, x1 i ✏ if
mbody(C, m) = (p, body). Importantly, x1 62 L. But if this is to be well-formed, the
second frame must typecheck under some ,
(x) = . By T-Frame1, we must
have dom( ) ✓ dom(L), which is impossible as x1 62 L.
An alternative is to “initialize” return value bindings with null. That is, change
E-invoke to add a binding L[x1 7! null]. But methods can return boxes, and
boxes cannot (probably) be null.
So it remains to rewrite the rules for `x . That can be done by adding T-Frame1’:
2
6
6
6
6
6
6
6
7
8
8
8
8
9
1
A formal account of LaCasa
Haller et al.
p ::= cd f d t
program
cd ::= class C extends D {f d md} class declaration
f d ::= var f : C
field declaration
md ::= def m(x : ) : ⌧ = t
method declaration
, ⌧ ::=
type
C, D
class type
| Box[C]
box type
Figure 1: Core language syntax. C, D range over class names, f , m, x range over term names.
t ::=
x
| let x = e in t
terms
variable
let binding
e ::=
expressions
null
null reference
|x
variable
| x.f
selection
| x.f = y
assignment
| x.m(y)
invocation
| new C
instance creation
| box[C]
box creation
| x.open {y ) t}
open box
Figure 2: Terms and expressions.
Object
I replaced (x) <: by (x) = , because otherwise `x =) `x
. Maybe that is not
a problem (?) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
formatting is ugly, I can’t make things idented. Can infrule make things left-adjusted
instead of centered? Also, this must be split into 3, it is impossible to read! . . .
Completely unreadable. Splitting this into several rules is possible. . . . . . . . . . . .
Change log: changed dom(H) ✓ dom(⌃) to dom(H) = dom(⌃). Couldn’t prove progress
for let x = y.f in t otherwise. Nothing said that L(y) = o =) o 2 dom(H). . .
not yet written! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
not yet written! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
todo rewrite! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rewrite after defining well-formedness. Check the type thing! . . . . . . . . . . . . . . .
Coq syntax probably a little fishy! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mutual recursion in Coq! Is it a problem? . . . . . . . . . . . . . . . . . . . . . . . . . .
1
.
9
. 9
. 10
.
.
.
.
.
.
.
10
12
13
13
13
14
15
Syntax
Possibly add All to set of types(?) Otherwise have to di↵erentiate between syntax types
and type-checking types
Figure 1 shows the syntax of our core language. A program consists of a sequence of class
definitions, cd, as well as the body of a “main” method, t (a term). A class C has (a possibly
2
A formal account of LaCasa
Haller et al.
H(o) = hC, F M i
heap
dom(F M ) = f ields(C)
domain of field mapping
F M (f ) 2 dom(H) ] {null}
range of field mapping
a1
a2
F S = hL1 , t1 i
hL2 , t2 i
. . . ; stack frames
L(x) 2 dom(H) ] {null}
environment
Figure 3: Core language reduction context. C is a class name, f, x — term names, o — a
reference.
empty) sequence of fields, f d, and methods, md. Methods have exactly one parameter, in order
to simplify the presentation.
2
Operational semantics
We formalize the semantics with small-step reduction rules. Reductions are defined in a context
consisting of a heap H, list F S of stack frames hL, tix .
2.1
Execution context
The heap H is a mapping from a set of references o 2 dom(H) to run-time objects. A runtime object is a tuple hC, F M i, where C is a class name (corresponding to the type of the
object) and F M is a mapping from term names (the fields names of the class) to references in
dom(H) ] {null}. F S is an ordered sequence of annotated stack frames. Each stack frame is
a pair hL, ti of an environment L and a term t. In the stack, frames can be annotated with a
term name x that is the name of the return value of this frame in the next frame. Frames that
do not return a value to the next frame are annotated with ✏. We use a meta-variable a = x|✏
to range over annotations. We use the notation hL, ti[x 7! r] for hL[x 7! r], ti. Here r can be a
reference, a box reference or null. This notation is defined identically for both annotated and
unannotated frames.
The environment is a mapping from term names x 2 dom(L) to references in dom(H) ]
{null}. See figure 3.
(
H(s) if s 6= r
We write H 0 = H[r 7! x] for the updated mapping H 0 (s) =
. Similarly we
x
if s = r
define L[x 7! r]. We use the notation F M = hL1 , t1 ia F M 0 to indicate that the stack F M
starts with stack frame hL1 , t1 i that is followed by F M 0 . When f is a term name and C is a
class name, mbody(f, C) stands for the tuple (x, t) where x is the name of the parameter and t
is the method body of f . By f ields(C), we mean the list of field names of class C in order of
definition.
2.2
Semantics
We give a recursive definition of two computation relations, H, hC, ti ! H 0 , hC 0 , t0 i and
H, F S ⇣ H 0 , F S 0 . We call the relations !, ⇣ single frame step and multiple frame step
respectively.
3
A formal account of LaCasa
Haller et al.
Multiple frame rules
H, hL, ti ! H,0 hL0 , t0 i
a
a
H, hL, ti F S ⇣ H,0 hL0 , t0 i F S
(E-StackFrame)
If there is a single frame step, there is a multiple frame step.
H, hL, xi
y
x 2 dom(L)
F S ⇣ H, F [y 7! L(x)] F S
F
H, hL, xi
✏
F
F S ⇣ H, F
FS
(E-return1)
(E-return2)
A frame with a single variable can return to the next frame.
Whenever a method is invoked, the body of that method is executed in a new environment.
This environment contains the global variables, the parameter and this pointer. We say that
L0 = globals(p) is the environment of global variables. For var x : 2 f d, globals(p)(x) =
ox 6= null is a reference.
L(y) = o
H(o) = hC, F Si
mbody(m, C) = (p, t1 )
L0 = globals(p)
(E-invoke)
a
HhL, let x1 = y.m(z) in t2 i F S ⇣
x1
a
HhL0 [p 7! L(z), this 7! L(y)], t1 i
hL, t2 i F S
Invoking methods creates a new frame, in which the term is the method body.
L(x2 ) = b(o)
o 2 dom(H)
a
HhL, let x1 = x2 .open{y ) t1 } in t2 i F S ⇣
✏
a
Hh{y 7! o}, t1 i hL[x1 7! b(o)], t2 i F S
(E-Open)
Evaluating an open expression creates a new frame. In the new frame, the body t1 of the
open expression is evaluated in the context where only a reference y to the unboxed value
o, b(o) = L(x2 ), is visible. The result of this evaluation is discarded, and x1 is bound to the
box b(o).
2.2.1 Single frame rules
Frame transition rules, see below:
H, hL, let x = null in ti
! H, hL[x 7! null], ti
y 2 dom(L)
H, hL, let x = y in ti ! H, hL[x 7! L(y)], ti
H(L(y)) = hC, F M i
f 2 dom(F M )
H, hL, let x = y.f in ti ! H, hL[x 7! F M (f )], ti
(E-Null)
(E-Var)
(E-Field)
L(y) = o
H(o) = hC, F M i
H 0 = H[o 7! hC, F M [f 7! L(z)]i]
(E-Assign)
H, hL, let x = y.f = z in ti ! H 0 , hL, let x = z in ti
4
A formal account of LaCasa
3
Haller et al.
o2
/ dom(H)
f ields(C) = f
H 0 = H[o 7! hC, f 7! nulli]
H, hL, let x = new C in ti ! H 0 , hL[x 7! o], ti
(E-New)
o f resh 2
/ dom(H)
f ields(C) = f
H 0 = H[o 7! hC, f 7! nulli]
H, hL, let x = box[C] in ti ! H 0 , hL[x 7! b(o)], ti
(E-Box)
Typing rules
The language CoreLaCasa1 is typed. Types almost correspond to class definitions, in a
way that will be explained shortly. Types have a subtyping relation that corresponds to class
inheritance.
3.1
Well-formed types
In a program p = cd f d t, only certain types are valid. We write p ` ValidType( ) to capture
this. The program p defines a list of class names and inheritance relationships between class
names. The inheritance relation defines a subtyping relation <:. Valid types are class types
corresponding to class definitions in p, but also box types and a new type All.
p = cd f d t
class C . . . 2 cd
p ` ValidType(C)
(WF-Class-type)
Class types are valid types.
p ` ValidType(C)
p ` ValidType(Box[C])
(WF-Box-type)
Box types constructed from class types are valid types.
p ` ValidType(All)
p ` ValidType(Object)
p = cd f d t
class C extends D . . . 2 cd
p ` C <: D
(WF-All-type)
(WF-Object-type)
(<:-Inheritance)
p ` C <: D
p ` C <: E
p ` C <: E
(<:-Transitivity)
p ` ValidType(C)
p ` C <: C
(<:-Reflexivity)
p ` ValidType(C)
p ` All <: C
(<:-All)
5
on!
A formal account of LaCasa
Haller et al.
p ` C <: D
p ` Box[C] <: Box[D]
(<:-Box)
The class type Object is the root of any inheritance chain in a well-formed program. Wellformedness is defined in 4 below. By the properties of subtyping and inheritance, C <: Object
for any class type C.
Note that <:-All only holds for class types C, so All 6<: Box[C].
This a↵ects the conclusion and proof of last case of Theorem 1. As the theorem and proof
is currently stated, box-typed names can contain null.
The motivation for introducing All is to typecheck expressions with value null.
refer to ECOOP’10, which refers to FJ
maybe change the syntax to have the types coincide and not have more ⌃, -types than
method and field types
I think it makes sense for the meta-variables C, D to allow value Object. It is unclear
whether they do.
3.2
Operational capability security
A class is operational-capability-secure if none of its methods access global variables. In section 3.3, we will use predicates Ocap(C), ¬Ocap(C) to define a type system for CoreLaCasa1 ,
which is why we will not use a full type system to define operational capability security. Instead,
we will define Ocap in terms of free variables:
Definition 1. In a program p = cd f d t, for a class class C extends D {f d md} 2 cd, we
define Ocap(C) to be
8 (def m(x : ) : ⌧ = t) 2 md .
f vars(t) ✓ {this, x}
where f vars(t) is the free variables that appear in t.
How to better formulate this? A definition by equivalence seemed better than a definition
by axioms because of the negation.
3.3
Type assignment
There are probably about 5-6 di↵erent kinds judgements A ` B with di↵erent types of A
and B. Is this how things are usually done? Is it possible to introduce di↵erent notation?
Terms and expressions are type-checked in a typing context . A typing context is a mapping
of names to either tuples ( , l) of a type and a label. Meta-variables l, m range over labels. Metavariables 4, ⇤, 3 = , l range over pairs of types and labels. The labels have a similar role to
capabilities in ECOOP’10. We define a partial order relation  on labels. We also define 4  ⇤
in terms of <: and :
4 = ,l
6
⇤ = ⌧, m
4⇤
<: ⌧
lm
(-def)
A formal account of LaCasa
Haller et al.
There is one special label in the set of labels: shared.
We give rules for the typing judgements
` t : 4,
` e : 4. The types in all typing
judgements are required to be well-formed in the sense of section 3.1. By this we mean that
every typing rule has an implicit context p, under which all types and all subtyping relations
<: ⌧ that appear in the prerequisite part of the rule satisfy p ` ValidType( ) and p ` <: ⌧ .
We drop the notation p ` ValidType( ), because the class definitions and the set of valid
types do not change during program execution.
` null : All, all
(T-null)
x 2 dom( )
` x : (x)
(T-var)
We use an auxillary function f typep (C, f ) that gives the type of field f of class C when
f 2 f ields(C) in program p. We drop the prefix p, for the same reason as above.
` x : C, l
f 2 f ields(C)
` x.f : f type(C, f ), l
` y : C, l
` x : C, l
(T-field)
` x.f : D, m
(C, l) <: (D, m)
` x.f = y : C, l
mtype(m, C) = 4 ! ⇤
` x.m(y) : ⇤
`y:3
(T-assign)
34
(T-invoke)
Ocap(C)
` new C : C, all
(T-new1)
¬Ocap(C)
` new C : C, shared
(T-new2)
Ocap(C)
` Box[C] : Box[C], all
` x : Box[C], m
l fresh label
{y 7! C, l} ` t : 4
` hL, x.open{y ) t}i : Box[C], m
(T-box)
(T-Open)
Potential problem: box types do not have labels. Thus ` t : ⌧ in T-Open means that t
cannot be a box type. This it is a unnecessary restriction.
We also need to be able to type-check terms. Therefore, we add a rule for let-expressions:
`e:4
[x 7! 4] ` t : ⇤
` let x = e in t : ⇤
(T-let)
7
A formal account of LaCasa
4
Haller et al.
Well-formedness
insert citation!
We follow ?? and are inspired by FJ and ECOOP’10 and prove safety by a combination
of progress and preservation. The recipe consists of first constructing an invariant called wellformedness of a configuration H, F S. Then one shows that a well-formed configuration for
which no reduction rules ⇣ applies must satisfy certain termination properties (i.e., show that
no ⇣ rule is applicable only when some of a short list of possible conditions is true ). This is
called progress. Finally, show that a configuration satisfying the invariant can be reduced by
⇣ to another well-formed configuration (preservation).
Progress and preservation together is a general proof method to show claims about program
termination and program invariants.
4.1
Well-formed class definitions
Well-formed class definitions: similar to ECOOP’10, TODO: present in conventional rule &
axiom notation!
We define what it means for a program p = cd f d t to be well-formed. We want wellformedness to have the following properties:
1. Every class definition cd 2 cd is well-formed. Well-formedness of class definitions is defined
below.
2. The inheritance chain of every class cd 2 cd only contains distinct classes in cd and ends
with Object.
3. A class definition cd = class C extends D {f d md} is well-formed if every field declaration f d 2 f d and every method declaration md 2 md is well-formed, and if the field
names and method are all distinct.
4. A field declaration f d = var f : E in class C extends D {f d md} is well-formed if
p ` ValidType(E) and f 2
6 f ieldsp (D). (Fields cannot be overridden).
5. A method declaration md = def m(x : ) : ⌧ = t in class C is well-formed if , = D or
= Box[D] for a class in cd, similar for ⌧ and = {this 7! C, x 7! } ` t <: ⌧
Overriding is messy. See ECOOP’10. Add rules. Write this in a better way.
I am still not sure how to ensure that new C, Box[C], x.f etc will never fail due to unknown
C. Must (at least in mechanization) restrict set of types to be only those in cd. How is it
simplest to formulate that H, F S will only contain subterms and sub-expressions of a wellformed program?
4.2
Stack frame typing
First, we define typing of single stack frames:
`t:4
8
dom( ) ✓ dom(L)
` hL, ti : 4
(T-Frame1)
A formal account of LaCasa
Haller et al.
`F :4
` Fa : 4
(T-Frame2)
A frame, annotated or not, F = hL, ti has type 4 under , if, in addition to ` t : 4, it
also holds, that every variable assigned a type by , is present in the environment L.
Problems with the current rules: `x F S requires
` hL, ti,
(x) = . But by
the current evaluation rules it may happen that x 62 L. An example is let x1 =
obj.meth(par) in x1 . Evaluating this one step from L = {obj 7! . . . , meth 7! . . .}
x
gives H, h{this 7! . . . , p 7! . . .}, bodyi 1 hL = {obj 7! . . . , meth 7! . . .}, x1 i ✏ if
mbody(C, m) = (p, body). Importantly, x1 62 L. But if this is to be well-formed, the
second frame must typecheck under some ,
(x) = . By T-Frame1, we must have
dom( ) ✓ dom(L), which is impossible as x1 62 L.
An alternative is to “initialize” return value bindings with null. That is, change E-invoke
to add a binding L[x1 7! null]. But methods can return boxes, and boxes cannot (probably) be null.
So it remains to rewrite the rules for `x . That can be done by adding T-Frame1’:
`t:⇤
4.3
(x) = 4
dom( ) \ {x} ✓ dom(L)
4
`x hL, ti : ⇤
(T-Frame1’)
Stack well-formedness under heap typing
We let ⌃ be a partial mapping of references to types. We define a judgement ⌃ ` , L where
, L are contexts and environments. This is meant to encompass “ and L are compatible with
the heap typing: for every (x, ) 2 , L(x) has the correct type in ⌃. ”
I replaced (x) <:
problem (?)
by (x) = , because otherwise `x =) `Object
. Maybe that is not a
x
8x 2 dom( ) \ dom(L) .
L(x) = o ^ ⇥(x) = C, l =) ⌃(o) <: C ^
L(x) = null =) ⇤
[9 ⇥C, l . (x) = C, l] ^
L(x) = b(o) =)
⇤
[9 C, l . (x) = Box[C], l ^ ⌃(o) <: C]
⌃ ` ,L
(WF-heap-type-env)
formatting is ugly, I can’t make things idented. Can infrule make things left-adjusted
instead of centered? Also, this must be split into 3, it is impossible to read!
We use the judgement ⌃ ` , L to define judgements ⌃ ` F S meaning “There are compatible
typing contexts { i }i under which every frame in F S is well-typed such that ⌃ ` i , Li ”. We
define ⌃ ` F S with auxillary judgement ⌃ `4
x F S and mutual recursion. As in section ??,
this gives 3 pairs of rules, for empty stacks, non-empty stacks with annotated first frames and
non-empty stacks with un-annotated first frames.
⌃`✏
(WF-heap-FS-✏)
⌃ `4
x ✏
(WF-heap-FS-✏0 )
9
A formal account of LaCasa
Haller et al.
Empty stacks are well-formed.
⌃ ` FS
`4
x F :⇤
`F :4
⌃ ` , L(F )
⌃ ` F✏ FS
(WF-heap-frame-✏)
⌃ ` FS
⌃ ` , L(F )
✏
⌃ `4
F
F
S
x
(WF-heap-frame-✏0 )
Well-formed non-empty stack with an ✏-annotated first frame. The first frame must type
check to some type-label pair 4, and the remaining stack must be well-formed.
`F :4
`4
y F :⇤
⌃ `4
⌃ ` , L(F )
x FS
x
⌃`F
FS
⌃ `⇤
x FS
x
⌃ `4
FS
y F
⌃ ` , L(F )
(WF-heap-frame-x)
(WF-heap-frame-x0 )
Well-formed non-empty stack frames with a x-annotated first frame. The first frame must
type check to ⇤, and the remaining stack must be well-formed if the return value has type ⇤.
4.4
Well-formed heaps
For a heap H, the typing judgement ⌃ ` H is meant to capture that “every reference in H points
to a run-time object hC, F M i, and the field references in f 2 F M are either F M (f ) = null,
or point at run-time objects of correct, type ⌃(F M (f )) <: f type(f, C)”.
dom(H) = dom(⌃)
8o, hC, F M i 2 H.
C <: ⌃(o)
dom(F M ) =
⇥ f ields(C) ^
8f 2 dom(F M ). F M (f ) 6= null =)
⇤
F M (f ) 2 dom(H) ^ ⌃(F M (f )) <: f type(C, f )
⌃`H
(WF-heap)
Completely unreadable. Splitting this into several rules is possible.
Change log: changed dom(H) ✓ dom(⌃) to dom(H) = dom(⌃). Couldn’t prove progress
for let x = y.f in t otherwise. Nothing said that L(y) = o =) o 2 dom(H).
4.5
Well-formedness
A configuration H, F S is well-formed under heap typing ⌃ when ⌃ ` H, ⌃ ` F S. We write this
as ⌃ ` H, F S.
Separation! Define paths and separation similarly to ECOOP’10.
10
A formal account of LaCasa
5
Haller et al.
Progress
Theorem 1 (Progress: termination or null dereference). When a well-formed configuration
⌃ ` H, F S is stuck under ⇣, one of these six cases applies:
• F S consists of a single frame hL, xi where x is a variable
• the topmost frame of F S is of the form hL, let x = y.m(z) in ti with L(y) = null
• the topmost frame of F S is of the form hL, let x = y.f in ti with L(y) = null
• the topmost frame of F S is of the form hL, let x = y.f = z in ti with L(y) = null
• the frame stack is empty ✏
Proof. Case analysis of F S:
If F S = ✏, the sixth case applies, and the proof is done. Otherwise, let F S = F a F S 0 , F =
hL, ti be the topmost frame.
Since ⌃ ` H, F S, by definition we must have ⌃ ` H, ⌃ ` F S
Case analysis of ⇣ rules: There are 3 rules E-StackFrame, E-return1, E-return2
for ⇣, if E-StackFrame does not apply, its premise does not apply: 6 9F 0 , H 0 . H, F
!
H 0 , F 0 . Then (H, F ) is stuck under , ! , .
Case analysis of a:
If a = ✏, WF-heap-frame-✏ applies and 9 , 4. ` F : 4 ^ ⌃ ` , L
If a = x, WF-heap-frame-x applies and 9 , 4. ` F : 4 ^ ⌃ ` , L.
Thus 9 , 4. ` F : 4 ^ ⌃ ` , L. Let , 4 be such that the above holds.
Then there is only one rule T-Frame1 with conclusion ` F : 4. Its premise is ` t :
4 ^ dom( ) ✓ dom(L).
Structure analysis of t: There are 10 cases to consider from figure 1.
t = x Since
` t : 4 we have
` x : 4.
Enumerating rules with this conclusion gives only T-var and x 2 dom( ), (x) = 4.
By dom( ) ✓ dom(L) we know x 2 dom(L).
Case analysis of F S 0 :
If F S 0 = ✏, we are done as this is the first case of the theorem conclusion.
If F S 00 = F 0 F S 00 we show that the premise for E-return1 or E-return2 is satisfied.
Case analysis of a:
If a = ✏, then rule E-return2 applies with H = H, L = L, x = x, F = F 0 , F S = F S 00 .
If a = y, then since x 2 dom(L), rule E-return1 applies with H = H, L = L, x = x, y =
y, F = F 0 , F S = F S 00 .
But then H, F S cannot be stuck, under , ⇣ , .
t = let x = null in t0 : Rule E-Null applies with H = H, L = L, x = x, t = t0 . Then H, F
cannot be stuck under , ! , , which is a contradiction.
t = let x = y in t0 : Since
` t : 4, we have
` let x = y in t0 : 4.
There is a single rule T-let with a matching conclusion, therefore
⇤] ` t0 : 4
` y : ⇤,
[x 7!
11
A formal account of LaCasa
Haller et al.
` y : ⇤, T-var must apply and y 2 dom( ), (y) = ⇤.
By induction on
Since dom( ) ✓ dom(L), we have y 2 dom(L).
The rule E-Var applies to H, F since y 2 dom(L) with H = H, L = L, x = x, y = y, t = t0 .
t = let x = y.f in t0 : Since
` t : 4, we have
` let x = y.f in t0 : 4.
Induction on typing derivation of the last gives T-let,
Induction on
f type(C, f ), l.
Induction on
` y.f : ⇤ gives T-field and
` y.f : ⇤,
` y : C, l
` y : C, l gives T-var and y 2 dom( ),
[x 7! ⇤] ` t0 : 4.
f 2 f ields(C)
⇤ =
(y) = C, l.
Since dom( ) ✓ dom(L), we have y 2 dom(L).
By induction ⌃ ` , L, WF-heap-type-env applies. y 2 dom( ) \ dom(L), so the
premise of WF-heap-type-env can be applied to y.
Case analysis of L(y):
If L(y) = null, the third case of the theorem conclusion holds with L = L, x = x, y =
y, f = f, t = t0 .
If L(y) = o, the premise of WF-heap-type-env gives ⌃(o) <: C.
By induction on ⌃ ` H, rule WF-heap applies. By the premise dom(H) = dom(⌃).
Then o 2 dom(H), H(o) = hD, F M i.
Apply the second premise of WF-heap on o, hD, F M i.
It gives D <: ⌃(o).
By <:-Transitivity, D <: ⌃(o)
⌃(o) <: C, it follows D <: C.
By overriding rules , D <: C =) f ields(C) ✓ f ields(C).
et written!
Since f 2 f ields(C) ✓ f ields(D), it holds f 2 f ields(D).
Then rule E-field with H = H, L = L, y = y, C = D, F M = F M, t = t0 applies to H, F :
L(y) = o and o 2 dom(H) and H(o) = hD, F M i imply H(L(y)) = hD, F M i.
This contradicts that H, F is stuck under ,
!,.
When L(y) = b(o), the premise of WF-heap-type-env gives (y) = Box[D], l0 for some
D.
But we know (y) = C, l, which contradicts (y) = Box[D], l0 .
let x = y.f = z in t0 : Since
` t : 4, we have
` let x = y.f = z in t0 : 4.
Induction on typing derivation of the last gives T-let,
4.
Induction on ` y.f = z : ⇤ gives T-assign and
(D, m)
⇤ = (C, l)
12
[x 7! ⇤] ` t0 :
` z : C, l
` y.f : D, m
` y : E, m
f 2 f ields(E)
Induction on
f type(E, f ).
` y.f : D, m gives T-field and
Induction on
` y : E, m gives T-var and y 2 dom( )
Since dom( ) ✓ dom(L), we have y 2 dom(L).
` y.f = z : ⇤,
(y) = E, m.
(C, l) 
D=
A formal account of LaCasa
Haller et al.
By induction ⌃ ` , L, WF-heap-type-env applies. y 2 dom( ) \ dom(L), so the
premise of WF-heap-type-env can be applied to y.
Case analysis of L(y):
If L(y) = null, the fourth case of the theorem conclusion holds with L = L, x = x, y =
y, f = f, z = z, t = t0 .
If L(y) = b(o), the premise of WF-heap-type-env gives (y) = Box[D0 ], l0 for some D0 .
But we know (y) = E, m, which contradicts (y) = Box[D0 ], l0 .
If L(y) = o, the premise of WF-heap-type-env gives ⌃(o) <: E.
By induction on ⌃ ` H, rule WF-heap applies. By the premise dom(H) = dom(⌃).
Then o 2 dom(H), H(o) = hE 0 , F M i.
Apply the second premise of WF-heap on o, hE 0 , F M i.
It gives E 0 <: ⌃(o).
By <:-Transitivity, E 0 <: ⌃(o)
⌃(o) <: E, it follows E 0 <: E.
By overriding rules , E 0 <: E =) f ields(E 0 ) ✓ f ields(E).
0
not yet written!
0
Since f 2 f ields(E) ✓ f ields(E ), it holds f 2 f ields(E ).
Induction on z : C, l gives T-var. and z 2 dom( ).
Since dom( ) ✓ dom(L), we have z 2 dom(L).
Then rule E-Assign with L = L, o = o, H = H, y = y, C = E 0 , f = f, F M = F M, z =
z, t = t0 applies to H, F .
This contradicts that H, F is stuck under ,
let x = y.m(z) in t:
!,.
todo rewrite!
If L(y) = null, we are done. Otherwise, well-formedness gives L(y) 2 dom(H), H(L(y)) =
hC, F M i and C <: type(y), and mbody(m, C) is defined. But then E-Invoke applies.
let x = new C in t: Rule E-New with o = fresh reference , C = C, f = f ields(C), H 0 =
H[o 7! hC, f 7! nulli], L = L, x = x, t = t0 applies.
let x = box[C] in t: Rule E-Box with o = fresh reference , C = C, f = f ields(C), H 0 =
H[o 7! hC, f 7! nulli], L = L, x = x, t = t0 applies.
let x = y.open{z ) t1 } in t2 : Since
4.
` t : 4, we have
Induction on typing derivation of the last gives T-let,
⇤] ` t0 : 4.
Induction on
` y.open{z ) t1 } in : ⇤,
[x 7!
` y.open{z ) t1 } in : ⇤ gives rule T-Open.
Premise of T-Open give
Induction on
` let x = y.open{z ) t1 } in t2 :
` y : Box[C], m.
` y : Box[C], m gives T-var and y 2 dom( ), (x) = Box[C], m.
Since dom( ) ✓ dom(L), we must have y 2 dom(L).
Case analysis on L(y):
If L(y) = null, by induction of ⌃ ` , L, WF-heap-type-env applies.
13
rewrite after defin
well-formedness. C
the type thing!
yntax probably a
fishy!
A formal account of LaCasa
Haller et al.
We apply the premise to y 2 dom(G) \ dom(L). We get (y) = D, m for some D, m. This
is a contradiction with (y) = Box[C], l.
If L(y) = o, the premise of WF-heap-type-env applies and (y) = D, m for some D, m.
This is a contradiction with (y) = Box[C], l.
If L(y) = b(o), the premise of WF-heap-type-env applies and ⌃(o) is defined. By the
premise of WF-heap, dom(H) = dom(⌃), so H(o) is defined. The premise of E-Open
applies.
6
Mechanization
We need extra details:
Infinite sets
Sets S with decidable equality with
fresh (l: list S) -> {x : S | Forall l (fun s => s <> x)}.
That is, for any list of elements in S, there exists an element x that such that for every s 2 l,
x is not equal to s. These are needed to create fresh references.
Partial functions with finite support
Functions f: S -> Option T with finite domain. Finiteness of domain can be defined like this:
Definition finite_support (f: S -> Option T) :=
{l: list S | all_member_or_None f l}
Definition member_or_None (f: S -> Option T) (l: list S) :=
forall s, f s <> None -> member l s.
Updating of partial functions with finite support
To define H[o 7! hC, F M i], we need an update operation:
Definition update (f: S -> Option T) (x: S) (t: T) : S -> Option T.
Updating can be done with both elements of the domain of the partial function and new
elements. Updating a function with finite domain yields a function with finite domain:
Theorem update_finite_support (f: S -> Option T) (p: partial_finite_support f) (x: S) (t: T) :
partial_finite_support (update f x t).
14
A formal account of LaCasa
6.1
Haller et al.
The mechanization
All sets need have decidable equality. We have a set Names of term names, infinite set Reference
of references, partial functions (made up notation) L: Names -> References | Box References | null,
H: Refercences -> Objects. Objects are pairs (ClassType, FieldMap). FieldMap is a
total map from fields(ClassType) to References | Box References | null. ClassType
is either Object or a tuple BaseClassType, list Field, list Method. A Field is a tuple
Name, ClassType. A Method is a tuple Name, param_type: ClassType, return_type: ClassType, Term.
Terms and expressions straight-forward.
Is there mutual recursion? There is one between Term and Expression. . There is another Mutual recursion
between ClassType and Method, and between ClassType and Field.
Coq! Is it a proble
Names, References, Objects seem OK.
References
15