'

&

$

%

CIS500

SoftwareFoundations

Fall2004

1December

CIS500,1December1

'

&

$

%

Announcements

�Myofficehoursthisweek,Friday1:30-3:00PM

�Lasthomeworkouttoday,dueDec8th.

�RegradesformidtermIIinbyDec8th.

CIS500,1December2

'

&

$

%

ObjectEncodings

Lasttime,wetalkedaboutencodingobjectsinthetypedlambdacalculuswith

records,recursion,referencesandsubtyping.

Wehavealittemoretotalkaboutthistopic,butlet’sworkthroughan

exampletoseewhereweare.

CIS500,1December3

'

&

$

%

\heading{Examplefromlasttime}

classSetCounter{

protectedintx=1;

intget(){returnx;}

voidset(inti){x=i;return;}

voidinc(){this.set(this.get()+1);return;}

}

classInstrCounterextendsSetCounter{

protectedinta=0;

voidset(inti){a++;super.set(i);return;}

intaccesses(){returna;}

}

CIS500,1December4

'

&

$

%

SetCounter={get:Unit→Nat,set:Nat→Unit,inc:Unit→Unit};

CounterRep={x:RefNat};

setCounterClass=

λr:CounterRep.

λself:SetCounter.

{get=λ_:Unit.!(r.x),

set=λi:Nat.r.x:=i,

inc=λ_:Unit.self.set(succ(self.getunit))};

newSetCounter=

λ_:Unit.letr={x=ref1}in

fix(setCounterClassr);

CIS500,1December5

'

&

$

%

InstrCounter={get:Unit→Nat,set:Nat→Unit,

inc:Unit→Unit,accesses:Unit→Nat};

InstrCounterRep={x:RefNat,a:RefNat};

instrCounterClass=

λr:InstrCounterRep.

λself:InstrCounter.

letsuper=setCounterClassrselfin

{get=super.get,

set=λi:Nat.(r.a:=succ(!(r.a));super.seti),

inc=super.inc,

accesses=λ_:Unit.!(r.a)};

newInstrCounter=

λ_:Unit.letr={x=ref1,a=ref0}in

fix(instrCounterClassr);

CIS500,1December6

'

&

$

%

Onemorerefinement...

CIS500,1December7

'

&

$

%

Asmallflyintheointment

Theimplementationwehavegivenforinstrumentedcountersisnotveryuseful

becausecallingtheobjectcreationfunction

newInstrCounter=

λ_:Unit.letr={x=ref1,a=ref0}in

fix(instrCounterClassr);

willcausetheevaluatortodiverge!

Intuitively(seeTAPLfordetails),theproblemisthe“unprotected”useof

selfinthecalltosetCounterClassininstrCounterClass:

instrCounterClass=

λr:InstrCounterRep.

λself:InstrCounter.

letsuper=setCounterClassrselfin

...

CIS500,1December8

'

&

$

%

Toseewhythisdiverges,considerasimplerexample:

ff=λf:Nat→Nat.

letf′=fin

λn:Nat.0

=⇒ff:(Nat→Nat)→(Nat→Nat)

Now:

fixff−→ff(fixff)

−→letf′=(fixff)inλn:Nat.0

−→letf′=ff(fixff)inλn:Nat.0

−→uhoh...

CIS500,1December9

'

&

$

%

Onepossiblesolution

Idea:“delay”selfbyputtingadummyabstractioninfrontofit...

setCounterClass=

λr:CounterRep.

λself:Unit→SetCounter.

λ_:Unit.

{get=λ_:Unit.!(r.x),

set=λi:Nat.r.x:=i,

inc=λ_:Unit.(selfunit).set(succ((selfunit).getunit))};

=⇒

setCounterClass:CounterRep→(Unit→SetCounter)→(Unit→SetCounter)

newSetCounter=

λ_:Unit.letr={x=ref1}in

fix(setCounterClassr)unit;

CIS500,1December10

'

&

$

%

Similarly:

instrCounterClass=

λr:InstrCounterRep.

λself:Unit→InstrCounter.

λ_:Unit.

letsuper=setCounterClassrselfunitin

{get=super.get,

set=λi:Nat.(r.a:=succ(!(r.a));super.seti),

inc=super.inc,

accesses=λ_:Unit.!(r.a)};

newInstrCounter=

λ_:Unit.letr={x=ref1,a=ref0}in

fix(instrCounterClassr)unit;

CIS500,1December11

'

&

$

%

Success

(?)

Thisworks,inthesensethatwecannowinstantiateinstrCounterClass

(withoutdiverging!),anditsinstancesbehaveinthewayweintended.

However,allthe“delaying”weaddedhasanunfortunatesideeffect:insteadof

computingthe“methodtable”justonce,whenanobjectiscreated,wewill

nowre-computeiteverytimeweinvokeamethod!

Section18.12inTAPLshowshowthiscanberepairedbyusingreferences

insteadoffixto“tietheknot”inthemethodtable.

CIS500,1December12

'

&

$

%

Success(?)

Thisworks,inthesensethatwecannowinstantiateinstrCounterClass

(withoutdiverging!),anditsinstancesbehaveinthewayweintended.

However,allthe“delaying”weaddedhasanunfortunatesideeffect:insteadof

computingthe“methodtable”justonce,whenanobjectiscreated,wewill

nowre-computeiteverytimeweinvokeamethod!

Section18.12inTAPLshowshowthiscanberepairedbyusingreferences

insteadoffixto“tietheknot”inthemethodtable.

CIS500,1December12-a

'

&

$

%

Recap

CIS500,1December13

'

&

$

%

Multiplerepresentations

AlltheobjectswehavebuiltinthisseriesofexampleshavetypeCounter.

Buttheirinternalrepresentationsvarywidely.

CIS500,1December14

'

&

$

%

Encapsulation

Anobjectisarecordoffunctions,whichmaintaincommoninternalstateviaa

sharedreferencetoarecordofmutableinstancevariables.

Thisstateisinaccessibleoutsideoftheobjectbecausethereisnowaytoname

it.(Instancevariablescanonlybenamedfrominsidethemethods.)

CIS500,1December15

'

&

$

%

Subtyping

Subtypingbetweenobjecttypesisjustordinarysubtypingbetweentypesof

recordsoffunctions.

Functionslikeinc3thatexpectCounterobjectsasparameterscan(safely)be

calledwithobjectsbelongingtoanysubtypeofCounter.

CIS500,1December16

'

&

$

%

Inheritance

Classesaredatastructuresthatcanbebothextendedandinstantiated.

Wemodeledinheritancebycopyingimplementationsofmethodsfrom

superclassestosubclasses.

Eachclass

�waitstobetoldarecordrofinstancevariablesandanobjectself(which

shouldhavethesameinterfaceandbebasedonthesamerecordof

instancevariables)

�usesrandselftoinstantiateitssuperclass

�constructsarecordofmethodimplementations,copyingsomedirectly

fromsuperandimplementingothersintermsofselfandsuper.

Theselfparameteris“resolved”atobjectcreationtimeusingfix.

CIS500,1December17

'

&

$

%

Whereweare...

CIS500,1December18

'

&

$

%

The(an)essenceofobjects

�Multiplerepresentations

�Encapsulationofstatewithbehavior

�Subtyping

�Inheritance(incrementaldefinitionofbehaviors)

�“Openrecursion”throughself

CIS500,1December19

'

&

$

%

What’smissing

Thepeculiarstatusofclasses(whicharebothrun-timeandcompile-time

things)

Namedtypeswithdeclaredsubtyping

Recursivetypes

Run-timetypeanalysis(casting,etc.)

(...lotsofotherstuff)

CIS500,1December20

'

&

$

%

ModelingJava

CIS500,1December21

'

&

$

%

ModelsinGeneral

Nosuchthingasa“perfectmodel”—Thenatureofamodelistoabstract

awayfromdetails!

Somodelsareneverjust“good”:theyarealways“goodforsomespecificsetof

purposes.”

CIS500,1December22

'

&

$

%

ModelsofJava

Lotsofdifferentpurposes−→lotsofdifferentkindsofmodels

�Source-levelvs.bytecodelevel

�Large(inclusive)vs.small(simple)models

�Modelsoftypesystemvs.modelsofrun-timefeatures(notentirely

separateissues)

�Modelsofspecificfeatures(exceptions,concurrency,reflection,class

loading,...)

�Modelsdesignedforextension

CIS500,1December23

'

&

$

%

FeatherweightJava

Purpose:modelthe“coreOOfeatures”andtheirtypesandnothingelse.

History:

�OriginallyproposedbyaPennPhDstudent(AtsushiIgarashi)asatool

foranalyzingGJ(“Javaplusgenerics”)

�SinceusedbymanyothersforstudyingawidevarietyofJavafeaturesand

proposedextensions

CIS500,1December24

'

&

$

%

Thingsleftout

�Reflection,concurrency,classloading,innerclasses,...

�Exceptions,loops,...

�Interfaces,overloading,...

�Assignment(!!)

CIS500,1December25

'

&

$

%

Thingsleftout

�Reflection,concurrency,classloading,innerclasses,...

�Exceptions,loops,...

�Interfaces,overloading,...

�Assignment(!!)

CIS500,1December25-a

'

&

$

%

Thingsleftout

�Reflection,concurrency,classloading,innerclasses,...

�Exceptions,loops,...

�Interfaces,overloading,...

�Assignment(!!)

CIS500,1December25-b

'

&

$

%

Thingsleftout

�Reflection,concurrency,classloading,innerclasses,...

�Exceptions,loops,...

�Interfaces,overloading,...

�Assignment(!!)

CIS500,1December25-c

'

&

$

%

Thingsleftin

�Classesandobjects

�Methodsandmethodinvocation

�Fieldsandfieldaccess

�Inheritance(includingopenrecursionthroughthis)

�Casting

CIS500,1December26

'

&

$

%

Example

classAextendsObject{A(){super();}}

classBextendsObject{B(){super();}}

classPairextendsObject{

Objectfst;

Objectsnd;

Pair(Objectfst,Objectsnd){

super();this.fst=fst;this.snd=snd;}

Pairsetfst(Objectnewfst){

returnnewPair(newfst,this.snd);}

}

CIS500,1December27

'

&

$

%

Conventions

Forsyntacticregularity...

�Alwaysincludesuperclass(evenwhenitisObject)

�Alwayswriteoutconstructor(evenwhentrivial)

�Alwayscallsuperfromconstructor(evenwhennoargumentsarepassed)

�Alwaysexplicitlynamereceiverobjectinmethodinvocationorfieldaccess

(evenwhenitisthis)

�Methodsalwaysconsistofasinglereturnexpression

�Constructorsalways

�Takesamenumber(andtypes)ofparametersasfieldsoftheclass

�Assignconstructorparametersto“localfields”

�Callsuperconstructortoassignremainingfields

�Donothingelse

CIS500,1December28

'

&

$

%

FormalizingFJ

CIS500,1December29

'

&

$

%

Nominaltypesystems

Bigdichotomyintheworldofprogramminglanguages:

�Structuraltypesystems:

�Whatmattersaboutatype(fortyping,subtyping,etc.)isjustits

structure.

�Namesarejustconvenient(butinessential)abbreviations.

�Nominaltypesystems:

�Typesarealwaysnamed.

�Typecheckermostlymanipulatesnames,notstructures.

�Subtypingisdeclaredexplicitlybyprogrammer(andcheckedfor

consistencybycompiler).

CIS500,1December30

'

&

$

%

AdvantagesofStructuralSystems

Somewhatsimpler,cleaner,andmoreelegant(noneedtoalwaysworkwrt.a

setof“namedefinitions”)

Easiertoextend(e.g.withparametricpolymorphism)

Caveat:whenrecursivetypesareconsidered,someofthissimplicityand

eleganceslipsaway...

CIS500,1December31

'

&

$

%

AdvantagesofNominalSystems

Recursivetypesfallouteasily

Usingnameseverywheremakestypechecking(andsubtyping,etc.)easyand

efficient

Typenamesarealsousefulatrun-time(forcasting,typetesting,reflection,...).

Java(likemostothermainstreamlanguages)isanominalsystem.

CIS500,1December32

'

&

$

%

Representingobjects

Ourdecisiontoomitassignmenthasanicesideeffect...

Theonlywaysinwhichtwoobjectscandifferare(1)theirclassesand(2)the

parameterspassedtotheirconstructorwhentheywerecreated.

Allthisinformationisavailableinthenewexpressionthatcreatesanobject.

Sowecanidentifythecreatedobjectwiththenewexpression.

Formally:objectvalueshavetheformnewC(v)

CIS500,1December33

'

&

$

%

FJSyntax

CIS500,1December34

'

&

$

%

Syntax(termsandvalues)

t::=terms

xvariable

t.ffieldaccess

t.m(t)methodinvocation

newC(t)objectcreation

(C)tcast

v::=values

newC(v)objectcreation

CIS500,1December35

'

&

$

%

Syntax(methodsandclasses)

K::=constructordeclarations

C(Cf){super(f);this.f=f;}

M::=methoddeclarations

Cm(Cx){returnt;}

CL::=classdeclarations

classCextendsC{Cf;KM}

CIS500,1December36

'

&

$

%

Subtyping

CIS500,1December37

'

&

$

%

Subtyping

AsinJava,subtypinginFJisdeclared.

Assumewehavea(global,fixed)classtableCTmappingclassnamesto

definitions.

CT(C)=classCextendsD{...}

C<:D

C<:C

C<:DD<:E

C<:E

CIS500,1December38

'

&

$

%

Moreauxiliarydefinitions

Fromtheclasstable,wecanreadoffanumberofotherusefulpropertiesofthe

definitions(whichwewillneedlaterfortypecheckingandoperational

semantics)...

CIS500,1December39

'

&

$

%

Fieldslookup

fields(Object)=∅

CT(C)=classCextendsD{Cf;KM}

fields(D)=Dg

fields(C)=Dg,Cf

CIS500,1December40

'

&

$

%

Methodtypelookup

CT(C)=classCextendsD{Cf;KM}

Bm(Bx){returnt;}∈M

mtype(m,C)=B→B

CT(C)=classCextendsD{Cf;KM}

misnotdefinedinM

mtype(m,C)=mtype(m,D)

CIS500,1December41

'

&

$

%

Methodbodylookup

CT(C)=classCextendsD{Cf;KM}

Bm(Bx){returnt;}∈M

mbody(m,C)=(x,t)

CT(C)=classCextendsD{Cf;KM}

misnotdefinedinM

mbody(m,C)=mbody(m,D)

CIS500,1December42

'

&

$

%

Validmethodoverriding

mtype(m,D)=D→D0impliesC=DandC0=D0

override(m,D,C→C0)

CIS500,1December43

'

&

$

%

Evaluation

CIS500,1December44

'

&

$

%

Theexampleagain

classAextendsObject{A(){super();}}

classBextendsObject{B(){super();}}

classPairextendsObject{

Objectfst;

Objectsnd;

Pair(Objectfst,Objectsnd){

super();this.fst=fst;this.snd=snd;}

Pairsetfst(Objectnewfst){

returnnewPair(newfst,this.snd);}

}

CIS500,1December45

'

&

$

%

Evaluation

Projection:

newPair(newA(),newB()).snd−→newB()

CIS500,1December46

'

&

$

%

Evaluation

Casting:

(Pair)newPair(newA(),newB())−→newPair(newA(),newB())

CIS500,1December47

'

&

$

%

Evaluation

Methodinvocation:

newPair(newA(),newB()).setfst(newB())

−→

��

newfst7→newB(),

this7→newPair(newA(),newB())

��

newPair(newfst,this.snd)

i.e.,newPair(newB(),newPair(newA(),newB()).snd)

CIS500,1December48

'

&

$

%

((Pair)(newPair(newPair(newA(),newB()),newA())

.fst).snd

−→((Pair)newPair(newA(),newB())).snd

−→newPair(newA(),newB()).snd

−→newB()

CIS500,1December49

'

&

$

%

Evaluationrules

fields(C)=Cf

(newC(v)).fi−→vi

(E-ProjNew)

mbody(m,C)=(x,t0)

(newC(v)).m(u)

−→[x7→u,this7→newC(v)]t0

(E-InvkNew)

C<:D

(D)(newC(v))−→newC(v)(E-CastNew)

plussomecongruencerules...

CIS500,1December50

'

&

$

%

t0−→t′

0

t0.f−→t′

0.f(E-Field)

t0−→t′

0

t0.m(t)−→t′

0.m(t)(E-Invk-Recv)

ti−→t′

i

v0.m(v,ti,t)−→v0.m(v,t′

i,t)(E-Invk-Arg)

ti−→t′

i

newC(v,ti,t)−→newC(v,t′

i,t)(E-New-Arg)

t0−→t′

0

(C)t0−→(C)t′

0

(E-Cast)

CIS500,1December51

'

&

$

%

Typing

CIS500,1December52

'

&

$

%

Notes

FJhasnoruleofsubsumption(becausewewanttofollowJava).Thetyping

rulesarealgorithmic.

(Wherewouldthismakeadifference?...)

CIS500,1December53

'

&

$

%

Typingrules

x:C∈Γ

Γ`x:C(T-Var)

CIS500,1December54

'

&

$

%

Typingrules

Γ`t0:C0fields(C0)=Cf

Γ`t0.fi:Ci

(T-Field)

CIS500,1December55

'

&

$

%

Typingrules

Γ`t0:DD<:C

Γ`(C)t0:C(T-UCast)

Γ`t0:DC<:DC6=D

Γ`(C)t0:C(T-DCast)

Whytwocastrules?

Becausethat’showJavadoesit!

CIS500,1December56

'

&

$

%

Typingrules

Γ`t0:DD<:C

Γ`(C)t0:C(T-UCast)

Γ`t0:DC<:DC6=D

Γ`(C)t0:C(T-DCast)

Whytwocastrules?Becausethat’showJavadoesit!

CIS500,1December56-a

'

&

$

%

Typingrules

Γ`t0:C0

mtype(m,C0)=D→C

Γ`t:CC<:D

Γ`t0.m(t):C(T-Invk)

Notethatthisrule“hassubsumptionbuiltin”—i.e.,thetypingrelationinFJ

iswritteninthealgorithmicstyleofTAPLchapter16,notthedeclarative

styleofchapter15.

Why?BecauseJavadoesitthisway!

ButwhydoesJavadoitthisway??

CIS500,1December57

'

&

$

%

Typingrules

Γ`t0:C0

mtype(m,C0)=D→C

Γ`t:CC<:D

Γ`t0.m(t):C(T-Invk)

Notethatthisrule“hassubsumptionbuiltin”—i.e.,thetypingrelationinFJ

iswritteninthealgorithmicstyleofTAPLchapter16,notthedeclarative

styleofchapter15.

Why?BecauseJavadoesitthisway!

ButwhydoesJavadoitthisway??

CIS500,1December57-a

'

&

$

%

Typingrules

Γ`t0:C0

mtype(m,C0)=D→C

Γ`t:CC<:D

Γ`t0.m(t):C(T-Invk)

Notethatthisrule“hassubsumptionbuiltin”—i.e.,thetypingrelationinFJ

iswritteninthealgorithmicstyleofTAPLchapter16,notthedeclarative

styleofchapter15.

Why?BecauseJavadoesitthisway!

ButwhydoesJavadoitthisway??

CIS500,1December57-b

'

&

$

%

Javatypingisalgorithmic

TheJavatypingrelationisdefinedinthealgorithmicstyle,for(atleast)two

reasons:

1.Inordertoperformstaticoverloadingresolution,weneedtobeableto

speakof“thetype”ofanexpression

2.Wewouldotherwiserunintotroublewithtypingofconditionalexpressions

Let’slookatthesecondinmoredetail...

CIS500,1December58

'

&

$

%

Javatypingmustbealgorithmic

Wehaven’tincludedtheminFJ,butfullJavahasbothinterfacesand

conditionalexpressions.

Thetwotogetheractuallymakethedeclarativestyleoftypingrules

unworkable!

CIS500,1December59

'

&

$

%

Javaconditionals

t1∈boolt2∈T2t3∈T3

t1?t2:t3∈?

ActualJavarule(algorithmic):

t1∈boolt2∈T2t3∈T3

t1?t2:t3∈min(T2,T3)

CIS500,1December60

'

&

$

%

Javaconditionals

t1∈boolt2∈T2t3∈T3

t1?t2:t3∈?

ActualJavarule(algorithmic):

t1∈boolt2∈T2t3∈T3

t1?t2:t3∈min(T2,T3)

CIS500,1December60-a

'

&

$

%

Morestandard(declarative)rule:

t1∈boolt2∈Tt3∈T

t1?t2:t3∈T

Algorithmicversion:

t1∈boolt2∈T2t3∈T3

t1?t2:t3∈T2∨T3

Requiresjoins!

CIS500,1December61

'

&

$

%

Morestandard(declarative)rule:

t1∈boolt2∈Tt3∈T

t1?t2:t3∈T

Algorithmicversion:

t1∈boolt2∈T2t3∈T3

t1?t2:t3∈T2∨T3

Requiresjoins!

CIS500,1December61-a

'

&

$

%

Javahasnojoins

But,infullJava(withinterfaces),therearetypesthathavenojoin!

E.g.:

interfaceI{...}

interfaceJ{...}

interfaceKextendsI,J{...}

interfaceLextendsI,J{...}

KandLhavenojoin(leastupperbound)—bothIandJarecommonupper

bounds,butneitheroftheseislessthantheother.

So:algorithmictypingrulesarereallyouronlyoption.

CIS500,1December62

'

&

$

%

FJTypingrules

fields(C)=Df

Γ`t:CC<:D

Γ`newC(t):C(T-New)

CIS500,1December63

'

&

$

%

Typingrules(methods,classes)

x:C,this:C`t0:E0E0<:C0

CT(C)=classCextendsD{...}

override(m,D,C→C0)

C0m(Cx){returnt0;}OKinC

K=C(Dg,Cf){super(g);this.f=f;}

fields(D)=DgMOKinC

classCextendsD{Cf;KM}OK

CIS500,1December64

'

&

$

%

Properties

CIS500,1December65

'

&

$

%

Preservation

Theorem[Preservation]:IfΓ`t:Candt−→t′,thenΓ`t

′:C

′forsome

C′<:C.

Proof:Straightforwardinduction.

???

CIS500,1December66

'

&

$

%

Preservation

Theorem[Preservation]:IfΓ`t:Candt−→t′,thenΓ`t

′:C

′forsome

C′<:C.

Proof:Straightforwardinduction.???

CIS500,1December66-a

'

&

$

%

Preservation?

Surprise:well-typedprogramscansteptoill-typedones!

(How?)

(A)(Object)newB()−→(A)newB()

CIS500,1December67

'

&

$

%

Preservation?

Surprise:well-typedprogramscansteptoill-typedones!

(How?)

(A)(Object)newB()−→(A)newB()

CIS500,1December67-a

'

&

$

%

Preservation?

Surprise:well-typedprogramscansteptoill-typedones!

(How?)

(A)(Object)newB()−→(A)newB()

CIS500,1December67-b

'

&

$

%

Solution:“StupidCast”typingrule

Addanothertypingrule,marked“stupid”to

Γ`t0:DC6<:DD6<:C

stupidwarning

Γ`(C)t0:C(T-SCast)

Thisisanexampleofamodelingtechnicality;notveryinterestingordeep,but

wehavetogetitrightifwe’regoingtoclaimthatthemodelisanaccurate

representationof(thisfragmentof)Java.

CIS500,1December68

'

&

$

%

Solution:“StupidCast”typingrule

Addanothertypingrule,marked“stupid”to

Γ`t0:DC6<:DD6<:C

stupidwarning

Γ`(C)t0:C(T-SCast)

Thisisanexampleofamodelingtechnicality;notveryinterestingordeep,but

wehavetogetitrightifwe’regoingtoclaimthatthemodelisanaccurate

representationof(thisfragmentof)Java.

CIS500,1December68-a

'

&

$

%

CorrespondencewithJava

Let’strytostatepreciselywhatwemeanby“FJcorrespondstoJava”:

Claim:

1.Everysyntacticallywell-formedFJprogramisalsoasyntactically

well-formedJavaprogram.

2.Asyntacticallywell-formedFJprogramistypableinFJ(withoutusing

theT-SCastrule.)iffitistypableinJava.

3.Awell-typedFJprogrambehavesthesameinFJasinJava.(E.g.,

evaluatingitinFJdivergesiffcompilingandrunningitinJavadiverges.)

Ofcourse,withoutaformalizationoffullJava,wecannotprovethisclaim.

Butit’sstillveryusefultosaypreciselywhatwearetryingtoaccomplish—in

particular,itprovidesarigorouswayofjudgingcounterexamples.

(Cf.“conservativeextension”betweenlogics.)

CIS500,1December69

'

&

$

%

Alternativeapproachestocasting

�Loosenpreservationtheorem

�Usebig-stepsemantics

CIS500,1December70

'

&

$

%

Progress

Problem:well-typedprogramscangetstuck.

How?

Castfailure:

(A)newObject()

CIS500,1December71

'

&

$

%

Progress

Problem:well-typedprogramscangetstuck.

How?

Castfailure:

(A)newObject()

CIS500,1December71-a

'

&

$

%

Progress

Problem:well-typedprogramscangetstuck.

How?

Castfailure:

(A)newObject()

CIS500,1December71-b

'

&

$

%

FormalizingProgress

Solution:Weakenthestatementoftheprogresstheoremto

Awell-typedFJtermiseitheravalueorcanreduceonesteporis

stuckatafailingcast.

Formalizingthistakesalittlemorework...

CIS500,1December72

'

&

$

%

EvaluationContexts

E::=evaluationcontexts

[]hole

E.ffieldaccess

E.m(t)methodinvocation(receiver)

v.m(v,E,t)methodinvocation(arg)

newC(v,E,t)objectcreation(arg)

(C)Ecast

Evaluationcontextscapturethenotionofthe“nextsubtermtobereduced,”in

thesensethat,ift−→t′,thenwecanexpresstandt

′ast=E[r]and

t′

=E[r′]forauniqueE,r,andr

′,withr−→r

′byoneofthecomputation

rulesE-ProjNew,E-InvkNew,orE-CastNew.

CIS500,1December73

'

&

$

%

Progress

Theorem[Progress]:Supposetisaclosed,well-typednormalform.Then

either(1)tisavalue,or(2)t−→t′forsomet

′,or(3)forsomeevaluation

contextE,wecanexpresstast=E[(C)(newD(v))],withD6<:C.

CIS500,1December74