A blame calculus with delimited control Taro Sekiyama Atsushi Igarashi Soichiro Ueda Kyoto University Gradual typing Two styles of typing Static typing Dynamic typing C onsistency of programs is checked ID: 428414
Download Presentation The PPT/PDF document "Shifting the Blame" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Shifting the Blame
A blame calculus with delimited control
Taro Sekiyama* Atsushi Igarashi Soichiro UedaKyoto University
Gradual
typingSlide2
Two styles of typing
Static typing
Dynamic typingConsistency of programs is checked before their executionGood: Early bug detection/OptimizationNG: Rejecting programs without no bugsE.g., ML, Haskell, Java, etc.
C
onsistency of programs is checked
during
their execution
Good:
Flexible and rapid development
:
More burdens to detect bugs
E.g., Scheme, Python, Perl, etc. Slide3
Two styles of typing
Dynamic typing
Gradual typing
Static typing
w
here …
static and dynamic typing are integrated
t
yped and
untyped
code coexist
Programs are annotated with types “graduallySlide4
Two styles of typing
Dynamic typing
Gradual typing
Static typing
where
typed and
untyped
code coexist
Programs are annotated with types “gradually”Slide5
Two styles of typing
Dynamic typing
Gradual typing
Static typingSlide6
Gradual typing
[Tobin-Hochstadt&Felleisen’06,Siek&Taha’07]Integration of static and dynamic typingTyped and untyped
code can coexist and interactProgram
typed
untyped
untyped
typed
typedSlide7
Blame calculus
[Tobin-Hochstadt&Felleisen’06,Wadler&Findler’09]A simply typed lambda calculus to model intermediate languages
for gradual typingThe Dynamic type (Dyn for short)The type given to untyped codeCasts (type coercions) t : S TA device to interact typed and untyped code
i
nt
DynSlide8
Blame calculus
[Tobin-Hochstadt&Felleisen’06,Wadler&Findler’09]A typed lambda
calculus to model intermediate languages for gradual typingThe Dynamic type (Dyn for short)The type for untyped codeCasts (type coercions) s : S TA type-directed mechanism to monitor value flows between typed and untyped code
Term
s of type S is coerced to type TSlide9
Blame calculus
[Tobin-Hochstadt&Felleisen’06,Wadler&Findler’09]A typed lambda
calculus to model intermediate languages for gradual typingThe Dynamic type (Dyn for short)The type for untyped codeCasts (type coercions) s : S Tcoerce term s of type S to type Tare used to monitor value flows between typed and untyped codeSlide10
Example
let x =
if … then succ else truelet y : string = if x then “true” else “false”Gradually typed lang.let x : Dyn = if…then
succ
: int→int Dyn
else true :
bool
Dyn
let y : string =
if (x :
Dyn
bool
) then
“true”
else “false”
Blame calculus
Untyped
code is given
Dyn
Injection of typed values into
untyped
code
Run-time test to check that the dynamic value is a BooleanSlide11
Cast semantics
Typed
Untyped1 : int
DynSlide12
Cast semantics
Typed
Untyped
Dyn
:
int
1
intSlide13
Cast semantics
Typed
Untyped
Dyn
:
int
1
bool
Cast fails!
1 is not a BooleanSlide14
This work
Extending gradual typing with delimited-control operators shift/resetAn extension of blame calculus [Tobin-
Hochstadt &Felleisen’06,Wadler&Findler’09] with a new form of castDefining continuation passing style (CPS) transformation for the extended calculusInvestigating three propertiesType soundnessSoundness of the CPS transformationBlame TheoremSlide15
What blame calculus should
guarantee
If something wrong happens, it is detected as cast failureType SoundnessStatically typed terms are never sources of cast failureBlame Theorem
E.g., an integer is
called as
a
functionSlide16
What gradual typing should
guarantee
If something wrong happens, it is detected as cast failureWell typed sides do not cause cast failureE.g., an integer is called as functions
NOT trivial in a blame calculus with control
operatorsSlide17
What gradual typing should
guarantee
If something wrong happens, it is detected as cast failureE.g., an integer is called as functions?
How
should we design
blame calculus to guarantee it?Slide18
Design criterion of blame calculus
All
value flows between typed and untyped parts should be monitored by castsAll uses of dynamic values are completely monitoredSlide19
Problem in introducing
control operators naivelyThe criterion is not satisfied
Terms with control operators can:return a valuecapture a continuationcall a continuationSlide20
T
erms with control operators can:return a value
capture a continuationcall a continuationProblem in introducing control operators naivelymonitored by the early blame calculusThe criterion is not satisfiedSlide21
T
erms with control operators can:return a value
capture a continuationcall a continuationProblem in introducing control operators naivelymonitored by the early blame calculusWe design a system to monitor these actions
The criterion is not satisfiedSlide22
Problem in introducing
control operators naivelyThe criteria is invalidated
Values can be passed via captured continuations not to be monitored by castsSlide23
This work
Extending the blame calculus with delimited-control operators shift/resetA new form of cast to satisfy the criteria
Defining continuation passing style (CPS) transformation for the extended calculusInvestigating three propertiesType soundnessSoundness of the CPS transformationBlame TheoremSlide24
This work
Extends the blame calculus with delimited-control operators shift/resetA new form of cast
to monitor capturing and calling continuationsDefines continuation passing style (CPS) transformation for the extended calculusInvestigates three propertiesType soundnessBlame TheoremSoundness of the CPS transformationcan implement various control effectsSlide25
Challenge for Type Soundness
All
value flows between typed and untyped parts have to be monitored by castsParaphrase of Type SoundnessIt isn’t trivial to satisfy this propertySlide26
Challenge for Type Soundness
Because terms with control operators can take more actionsTo return a valueTo capture a continuation
To call a continuationParaphrase of Type SoundnessIt isn’t trivial to satisfy this propertyAll value flows between typed and
untyped
parts have to be monitored by castsSlide27
Because terms with control operators can take more actions
To return a valueTo capture a continuationTo call a continuation
monitored by the early blame calculusChallenge for Type SoundnessParaphrase of Type Soundness
It isn’t trivial to satisfy
this property
All
value flows between typed and
untyped
parts
have to be monitored by castsSlide28
Because terms with control operators can take more actions
To return a valueTo capture a continuation
To call a continuationmonitored by the early blame calculusChallenge for Type SoundnessParaphrase of Type Soundness
It isn’t trivial to satisfy
this property
All
value flows between typed and
untyped
parts
have to be monitored by casts
We design a system to monitor theseSlide29
Challenge in the presence of control operators
All
value flows between typed and untyped parts should be monitored by castsIt isn’t trivial to satisfy the crucial property:All uses of dynamic values are completely monitoredSlide30
Challenge in the presence of control operators
All
value flows between typed and untyped parts should be monitored by castsIt isn’t trivial to satisfy the crucial property:Because terms with control operators can take more actionsTo return a valueTo capture a continuationTo call a continuation
All uses of dynamic values are completely
monitoredSlide31
Challenge in the presence of control operators
All
value flows between typed and untyped parts should be monitored by castsIt isn’t trivial to satisfy the crucial property:All uses of dynamic values are completely monitoredBecause terms with control operators can take more actions
To return a value
To capture a continuationTo call a continuation
m
onitored by the
early
blame calculusSlide32
Challenge in the presence of control operators
All
value flows between typed and untyped parts should be monitored by castsIt isn’t trivial to satisfy the crucial property:Because terms with control operators can take more actionsTo return a valueTo capture a continuationTo call a continuation
We design a system to monitor these
m
onitored by the
early
blame calculus
All uses of dynamic values are completely
monitoredSlide33
Problem in introducing
control operators naivelyThe criterion is not satisfied
Terms with control operators can:return a valuecapture a continuationcall a continuationSlide34
T
erms with control operators can:return a value
capture a continuationcall a continuationProblem in introducing control operators naivelymonitored by the early blame calculusThe criterion is not satisfiedSlide35
T
erms with control operators can:return a value
capture a continuationcall a continuationProblem in introducing control operators naivelymonitored by the early blame calculusWe design a system to monitor these actions
The criterion is not satisfiedSlide36
This work
Extending the blame calculus with delimited-control operators shift/resetA new form of cast for shift/reset is supportedDefining continuation passing style
(CPS) transformation for the extended calculusInvestigating three propertiesType soundnessSoundness of the CPS transformationBlame TheoremSlide37
Outline
IntroductionBackground: blame calculus
(without shift/reset)Problem with control operatorsOur extension of the blame calculus with shift/resetSlide38
Blame calculus
[Tobin-Hochstadt&Felleisen’06,Wadler&Findler’09]A simply typed lambda calculus to model intermediate languages
for gradually typingThe Dynamic type (Dyn for short)The type given to untyped codeCasts (type coercions) t : S TA device to interact typed and untyped code
i
nt
DynSlide39
Blame calculus [Wadler&Findler’09]
λ with Dyn
and casts Types S, T ::= int | … | S → T | Dyn Terms s, t ::= 1 | + | … | λx.s | s t | s : S T
→
t
he type for
untyped
code
m
onitors that the value of s at S can behave as TSlide40
Cast semantics
1 : int
Dyn 1 : intSlide41
Cast semantics
1 : int
Dyn Slide42
Cast semantics
1
1Slide43
Cast semantics
: Dyn
int 1 : int1
:
Dyn bool
1 :
int
Cast fails!
1 is not a BooleanSlide44
Cast semantics
: Dyn
int 1Slide45
Cast semantics
1
Cast fails!
1 is not a Boolean
:
Dyn
bool
1
1Slide46
Cast semantics
λ
x.sλx. x+1
x
λ
x
.
λ
x.sSlide47
Cast semantics
( )
v : int→int v’
l
et v (v’ <= int Slide48
Cast semantics
v : (int
→int) Dyn λx:Dyn.v (x : Slide49
Cast semantics
v : (int
→int) Dyn λx:Dyn.v (x : Slide50
Example
Sourcelet x = if … then Slide51
Example
let x =
if … then succ else truelet y : string = if x then “true” else “false”Gradually typed lang.let x : Dyn = if…then
succ
: int→int
Dyn
else true :
bool
Dyn
let y : string =
if (x :
Dyn
bool
) then
“true”
else “false”
Blame calculusSlide52
Example
let x =
if … then succ else true
let y : string =
if x then “true” else “false”
Gradually typed lang.
let x
=
Dyn
if…then
succ
:
int→int
Dyn
else true :
bool
Dyn
let y : string =
if (x :
Dyn
bool
) then
“true”
else “false”
Blame calculusSlide53
Example
let x =
if … then
succ else true
let y : string =
if x then
“true”
else “false”
Gradually typed lang.
let x
=
Dyn
if…then
succ
:
int→int
Dyn
else true :
bool
Dyn
let y : string =
if (x :
Dyn
bool
) then
“true”
else “false”
Blame calculusSlide54
Notation
let x :
Dyn = if…then succ : int→int Dyn else true : bool Dynlet y : string = if (x : Dyn
bool
) then “true” else “false”
Blame calculus
t
yped code
untyped
code
castSlide55
Notation
let x
=
Dyn
if…then
succ
:
int→int
Dyn
else true :
bool
Dyn
let y : string =
if (x :
Dyn
bool
) then
“true”
else “false”
Blame calculus
t
yped code
untyped
code
castSlide56
Notation
let x
=
Dyn
if…then
succ
:
int→int
Dyn
else true :
bool
Dyn
let y : string =
if (x :
Dyn
bool
) then
“true”
else “false”
Blame calculus
t
yped code
untyped
code
castSlide57
Notation
let x
=
Dyn
if…then
succ
Dyn
else true
Dyn
let y : string =
if (x) then
Dyn
“true”
else “false”
Blame calculus
t
yped code
untyped
code
castSlide58
Example
let x =
if … then succ else truelet y : string = if x then “true”
else “false”
Gradually typed lang.
let x =
Dyn
if…then
succ
Dyn
else true
Dyn
let y : string =
if x then
Dyn
“true”
else “false”
Blame calculusSlide59
Example
let x =
if … then succ else truelet y : string = if x then “true”
else “false”
Gradually typed lang.
let x =
Dyn
if…then
succ
Dyn
else true
Dyn
let y : string =
if x then
Dyn
“true”
else “false”
Blame calculusSlide60
l
et x =
if … then … elseFirst-order casttyped to untypedtrue
true
: bool
Dyn
Casts from base types
to
Dyn
always succeeds
Result values have the
target value (true) and
its type (
bool
) Slide61
Cast semantics
true : bool
Dyn Casts from base types to
Dyn always
succeedResult values have the target value (true) and its type (bool)
t
rue
boolSlide62
Cast semantics
: Dyn
bool trueCasts from Dyn succeed if the tagged type matches with the target type
t
rue
boolSlide63
Cast semantics
: Dyn
int Casts from Dyn fail if the tagged type doesn’t match with the target typeCast
failure
bool ≠
int
t
rue
boolSlide64
Cast semantics
succ : (
int→int) Dyn
:
Dyn→Dyn
λ
x
.
succ
x
x
:
Dyn
int
(
succ
…)
:
int
Dyn
Casts from function types to
Dyn
generate wrappers of the target function
All value flows between typed and
untyped
parts are monitored by castsSlide65
Cast semantics
succ : (
int→int) Dyn
λ
x
.
succ
x
(
succ
…)
:
int
Dyn
Casts from function types to
Dyn
generate wrappers of the target function
All value flows between typed and
untyped
parts are monitored by casts
x
:
Dyn
int
Dyn→DynSlide66
Cast semantics
succ : (
int→int) Dyn
λ
x
.
succ
x
(
succ
…)
:
int
Dyn
Casts from function types to
Dyn
generate wrappers of the target function
All value flows between typed and
untyped
parts are monitored by casts
x
:
Dyn
int
FuncSlide67
Cast semantics
succ : (
int→int) Dyn
λ
x
.
l
et y =
succ
in
y
x
(
let
…)
:
int
Dyn
Casts from function types to
Dyn
generate wrappers of the target function
All value flows between typed and
untyped
parts are monitored by casts
x
:
Dyn
int
FuncSlide68
Cast semantics
( )
v : int→int v’
l
et v (v’ <= int Slide69
Cast semantics
1
1Slide70
Cast semantics
: Dyn
int 1 : int1
:
Dyn bool
1 :
int
Cast fails!
1 is not a BooleanSlide71
Cast semantics
: Dyn
int 1Slide72
Cast semantics
1
Cast fails!
1 is not a Boolean
:
Dyn
bool
1
1Slide73
Cast semantics
λ
x.sλx. x+1
x
λ
x
.
λ
x.sSlide74
Cast semantics
( )
v : int→int v’
l
et v (v’ <= int Slide75
Cast semantics
v : (int
→int) Dyn λx:Dyn.v (x : Slide76
Cast semantics
v : (int
→int) Dyn λx:Dyn.v (x : Slide77
Example
Sourcelet x = if … then Slide78
Cast semantics
Typed
Untyped
Dyn
1
int
Slide79
Cast semantics
Typed
Untyped
Dyn
:
int
1
intSlide80
Cast semantics
Typed
Untyped
Dyn
:
int
1
bool
Cast fails!
1 is not a BooleanSlide81
Cast semantics
Typed
Untyped
Dyn
:
int
1
λ
:
int
→
boolSlide82
Cast semantics
Typed
Untyped λx. : int → bool
DynSlide83
Problem in the presence of control operators
The standard cast semantics would overlook value flows between typed and untyped codeSTLC: functions interact with callers
STLC with control operators: functions interact not only callers but also contextsSlide84
Outline
IntroductionBackground: blame calculus
(without shift/reset)Problem with control operatorsOur extension of the blame calculus with shift/resetSlide85
Problem with control operators
Cast semantics has to be extended to deal with types of contextsSTLC: functions interact with callersSTLC with control operators: functions interact not only callers but also contexts
Cf. Takikawa et al. [ESOP’13]Slide86
Problem with control operators
All value flows between typed and
untyped code are NOT monitored Values can be passed via captured continuations not to be monitored by castsSlide87
Problem with control operators
NOT
all value flows between typed and untyped code are monitored because the standard cast semantics cannot monitor capturing and calling continuationsSlide88
Shift and reset
CPS-based operators to manipulate “delimited” continuationsReset 〈s〉 delimits continuations in sShift (S k. s) captures continuations up to the closest reset
as k〈E[S k. s]〉 〈s[k:=λx.〈E[x]〉]〉 where E is an evaluation context without reset
used
to impl. exceptions, backtracking, monads, etc.
〈v〉 vSlide89
Shift and reset
CPS-based operators to manipulate “delimited” continuationsReset 〈s〉 delimits continuations in sShift (S k. s) captures continuations up to the closest reset
as k〈E[S k. s]〉 〈s[k:=λx.〈E[x]〉]〉 where E is an evaluation context without reset
used
to impl. exceptions, backtracking, monads, etc.Slide90
Reduction example
〈3 + (S
k. (k 1) == 4)〉= 〈E[S k. (k 1) == 4]〉 where E = 3 + []〈(k 1) == 4〉
λ
x.〈3 + x〉
〈〈3+
1
〉 == 4〉
*
trueSlide91
1) == 4
〉
(λx.〈3 + x〉)kReduction example〈3 + (S k. (k 1) == 4)〉= 〈E[S k. (k 1) == 4]〉
where E
= 3 + []
〈(
captured continuation
〈〈3+
1
〉 == 4〉
*
trueSlide92
1) == 4
〉
kReduction example〈3 + (S k. (k 1) == 4)〉= 〈E[S k. (k 1) == 4]〉 where E = 3 + []
〈(Slide93
1) == 4
〉
(λx.〈3 + x〉)kReduction example〈3 + (S k. (k 1) == 4)〉= 〈E[S k. (k 1) == 4]〉 where E =
3 + []
〈(
captured continuation
〈〈3+
1
〉 == 4〉
*
trueSlide94
Reduction example
〈3 + (S
k. (k 1) == 4)〉= 〈E[S k. (k 1) == 4]〉 where E = 3 + []〈( k 1) == 4〉Slide95
v
=
λx:int. 3 + (S k. (k 1) == x)Problem of the standard cast semantics in the presence of shift/resetv : (int→int) Dyn
λ
y
.
v
y
FuncSlide96
Problem of the standard cast semantics in
the presence of shift/reset
v = λx:int. 3 + (S k. (k 1) == x)
〈f ((
λy.
)
4
)
〉
v
y
〈f ( )
〉
v
4
:
Dyn
int
4
〈f ( )
〉
v
4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
v : (
int
→int
)
Dyn
Typed
function
v
is called under the
untyped
context
(“context” is the body of the reset)Slide97
Problem of the standard cast semantics in
the presence of shift/reset
v = λx:int. 3 + (S k. (k 1) == x)
〈f ((
λy.
)
4
)
〉
v
y
〈f ( )
〉
v
4
:
Dyn
int
4
〈f ( )
〉
v
4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
v : (
int
→int
)
Dyn
Slide98
Problem of the standard cast semantics in the presence of shift/reset
…
〈 1) == 4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
k
(
〉Slide99
Problem of the standard cast semantics in the presence of shift/reset
…
〈 1) == 4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
k
(
〉
captured continuationSlide100
Problem of the standard cast semantics in the presence of shift/reset
…
〈 1) == 4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
k
(
〉
captured continuationSlide101
Problem of the standard cast semantics in the presence of shift/reset
…
〈 ( ) 1
) ==
4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
(
〉
あいう
λ
z
.〈
〉
f
( )
3 + z
captured continuationSlide102
λ
z.〈
〉 Problem of the standard cast semantics in the presence of shift/reset…
〈
1)
== 4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
All value flows between typed and
untyped
parts are
NOT
monitored
k
(
captured continuation
〉
f
( )
3 + zSlide103
λ
z.〈
〉 Problem of the standard cast semantics in the presence of shift/reset…
〈
1)
== 4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
All value flows between typed and
untyped
parts are
NOT
monitored
1) == 4
〉
(
λ
x.〈3 + x〉
)
k
(
captured continuation
〉
f
( )
3 + zSlide104
λ
z.〈 〉
f ( )Problem of the standard cast semantics in the presence of shift/reset…
〈
〉
(k 1) == 4
3 + z
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
All value flows between typed and
untyped
parts are
NOT
monitoredSlide105
Problem of the standard cast semantics in
the presence of shift/reset
v = λx:int. 3 + (S k. (k 1) == x)〈f ((λy.
)
4)〉
l
et z = v in z
y
v : (
int
→int
)
Dyn
Slide106
Problem of the standard cast semantics in
the presence of shift/reset
v = λx:int. 3 + (S k. (k 1) == x)
〈f ((
λy.
)
4
)
〉
v
y
〈f ( )
〉
v
4
:
Dyn
int
4
〈f ( )
〉
v
4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
v : (
int
→int
)
Dyn
Since (let x = e in x)
≈
eSlide107
Problem of the standard cast semantics in
the presence of shift/reset
v = λx:int. 3 + (S k. (k 1) == x)
〈f ( )
〉
v
4
:
Dyn
int
4
〈f ( )
〉
v
4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
〈f
(
4
)
〉
v
〈f ((
λ
y
.
)
4
)
〉
v
ySlide108
Problem of the standard cast semantics in the presence of shift/reset
…
〈(k 1) == 4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
〉Slide109
Problem of the standard cast semantics in the presence of shift/reset
…
〈(k 1) == 4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
〉
captured continuationSlide110
Problem of the standard cast semantics in the presence of shift/reset
…
〈f ( )〉3 + (S
k.
(k 1) == 4)
〈
(
1)
== 4
〉
kSlide111
Problem of the standard cast semantics in the presence of shift/reset
…
〈f ( )〉3 + (S
k.
(k 1) == 4)
〈
(
1)
== 4
〉
k
captured continuationSlide112
Problem of the standard cast semantics in the presence of shift/reset
…
〈( 1) == 4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
〉
(
λ
z
.〈 〉
)
f
( )
3 + z
captured continuationSlide113
Problem of the standard cast semantics in the presence of shift/reset
…
〈( 1) == 4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
〉
(
λ
z
.〈 〉
)
f
( )
3 + z
NOT
a
ll
value flows between typed and
untyped
parts
are monitoredSlide114
Our solution
〈f (v’ 4)〉
In an ideal semantics:
Changing the cast semantics
so that typed
and
untyped
functions are called in typed and
untyped
contexts, resp.
v :
int→int
Dyn
y
〈
let x = v
in
〉Slide115
Outline
IntroductionBackground: blame calculus
(without shift/reset)Problem with control operatorsOur extension of the blame calculus with shift/resetSlide116
How does the problem happen?
…
v = λx:int. 3 + (S k. (k 1) == x)An u
ntyped
continuation is captured and sent to typed code
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
Captured continuations are expected to be typed
The captured continuation
is
untyped
f
( )
3 + zSlide117
Our solution
Changing the cast semantics
so that: Typed code captures only typed continuationsUntyped code captures only untyped continuationsSlide118
Our solution
Changing the cast semantics
so that: Typed code captures only typed continuationsUntyped code captures only untyped continuationsSlide119
Ideal cast semantics
〈f (v’ 4)〉v :
int→int
Dyn
〈
let x = v
in
〉
4
Typed function v should be called in the typed
context
f
x
The cast for the argument type
〈
〉
Untyped
function
f
should be called in the
untyped
context
The cast for the return type
Appropriate casts should be inserted
〜 〈f (v
4
)
〉
(if all casts are ignored)Slide120
Our cast
semantics〈f (v’ 4)〉
v : int→int
Dyn
〈
let x = v
in
〉
4
f
x
〈
〉
The cast for the return type
〈f (v
4
)
〉
(if all casts are ignored)
g
uarantees captured continuations in
untyped
function f are
untyped
Appropriate casts
are
inserted
The result of v is passed to f
g
uarantees captured continuations in typed function v
are
typed
≈
How is type information for additional casts obtained?
By following
Danvy&Filinski’s
type system for shift/resetSlide121
Our cast
semantics 〈let x = v in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
〈f (
v’
4
)
〉
v :
int→int
Dyn
Slide122
Our cast
semantics 〈let x = v in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
〈f (
v’
4
)
〉
v :
int→int
Dyn
Slide123
Our cast
semantics 〈let x = v in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
v
4
〈f (
v’
4
)
〉
v :
int→int
Dyn
The target function v
is called with
the argument to v’Slide124
Our cast
semantics 〈let x = v in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
v
4
〈f (
v’
4
)
〉
v :
int→int
Dyn
The cast for
the argument
typeSlide125
Our cast
semantics 〈let x = v in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
〈
〉
〈f (
v’
4
)
〉
v :
int→int
Dyn
guarantees captured continuations in typed function v are
typedSlide126
Our cast
semantics 〈let x = v in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
f
x
〈f (
v’
4
)
〉
v :
int→int
Dyn
The result x of v is passed to fSlide127
Our cast
semantics 〈let x = v in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
f
x
〈f (
v’
4
)
〉
v :
int→int
Dyn
The cast for
the
return typeSlide128
Our cast
semantics 〈let x = v in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
〈
〉
〈f (
v’
4
)
〉
v :
int→int
Dyn
guarantees captured continuations in
untyped
function f are
untypedSlide129
Our cast
semantics 〈let x = v in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
〈f (
v’
4
)
〉
v :
int→int
Dyn
Additional casts are constructed by using type information given in
Danvy&Filinski’s
type system
Slide130
Our cast
semantics 〈let x = v in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
〈f (
v’
4
)
〉
v :
int→int
Dyn
Slide131
Our cast
semantics〈f (v’ 4)〉
〈
let x = v
in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
v :
int
/
int
→int
/
bool
Dyn
r
equires that the
closest reset’s body
at call
point result in an integer
〈…〉
:
Dyn
int
t
o check the outer reset’s body returns an integerSlide132
Our cast
semantics〈f (v’ 4)〉
〈
let x = v
in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
v :
int
/
int
→int
/
bool
Dyn
g
uarantees that the
closest reset
at call
point returns a Boolean
〈…〉
:
bool
Dyn
t
o inject Boolean values to
untyped
codeSlide133
Our cast
semantics〈f (v’ 4)〉
〈
let x = v
in
〉
4
f
x
〈
〉
〈f (v
4
)
〉
(if all casts are ignored)
≈
v :
int
/
int
→int
/
bool
Dyn
Slide134
Our cast
semantics〈f (v’ 4)〉
v : int→int
Dyn
v
4
The cast for the argument type
Rewritten to (let x = v 4 in x)
( e
≈ (let x = e in x
) ) Slide135
Our cast
semantics〈f (v’ 4)〉
v : int→int
Dyn
〈
let x = v
in
〉
4
f
x
〈
〉
The cast for the return type
〈f (v
4
)
〉
(if all casts are ignored)
g
uarantees captured continuations in
untyped
function f are
untyped
Appropriate casts
are
inserted
w
ith help of
Danvy&Filisnki
’ type system
The result of v is passed to f
g
uarantees captured continuations in typed function v
are
typed
≈Slide136
Challenges to achieve
the ideal cast semanticsHow to manipulate the context where the cast result is used How to obtain type information for the additional
castsBy following Danvy&Filinski’s type system for shift/resetBy manipulating the context captured by shift✔Slide137
Our solution
〈f (v’ 4)〉
In an ideal semantics:
Changing the cast semantics
so that typed
and
untyped
functions are called in typed and
untyped
contexts, resp.
v :
S
Dyn
y
〈
〈f 〉
x
let x = v
in
〉Slide138
OutlineSlide139
Program syntax
Types S, T, α, β ::= int | … | Dyn |
S / α → T / βTerms s, t ::= 1 | + | … | λx.s | s t | s : S T | S k. s | 〈s〉Slide140
Type system
for shift/reset[Danvy&Filinski’89]Γ
; α├ s : T ; βthe type of the closest reset’s bodythe result type of the
closest reset
Example:〈1 + (S k. …) 〉 && false
;
├
S
k. … :
;
int
bool
intSlide141
Type system
for shift/reset[Danvy&Filinski’89]Γ
; α├ s : T ; βthe type of the closest reset’s bodythe result type of the
closest reset
Example:〈1 + (S k. …) 〉 && false
;
├
S
k. … :
;
?
?
?Slide142
Type system
for shift/reset[Danvy&Filinski’89]Γ
; α├ s : T ; βthe type of the closest reset’s bodythe result type of the
closest reset
Example:〈1 + (S k. …) 〉 && false
;
├
S
k. … :
;
?
?
intSlide143
Type system
for shift/reset[Danvy&Filinski’89]Γ
; α├ s : T ; βthe type of the closest reset’s bodythe result type of the
closest reset
Example:〈1 + (S k. …) 〉 && false
;
├
S
k. … :
;
int
int
?Slide144
Type system
for shift/reset[Danvy&Filinski’89]Γ
; α├ s : T ; βthe type of the closest reset’s bodythe result type of the
closest reset
Example:〈1 + (S k. …) 〉 && false
;
├
S
k. … :
;
int
bool
intSlide145
S /
α → T / β
the result type of the closest reset at call pointthe type of the closest reset’s body at call pointType system for shift/reset [Danvy&Filinski’89]Slide146
Issues to achieve
the ideal cast semanticsHow to manipulate the context where the cast result is used How to obtain type information for the additional
castsBy following Danvy&Filinski’s type system for shift/resetBy manipulating the context captured by shift✔✔Slide147
λ
x
.Cast semanticsv : (S/α→T/β) Dyn
〈 〉
k
(v )
x
S
k.
The type of the body of the reset
The return type of the body of the reset
Func
〈…〉
:
β
Dyn
k (…)
:
Dyn
αSlide148
The problematic reduction
is resolved
v = λx:int. 3 + (S k. (k 1) == x)〈f ( 4)〉
*
s〜
〈let x = v in 〉
v
v :
int
/
int→int
/
bool
Dyn
〉
4
〈f 〉
x
〈…〉
:
bool
Dyn
(
c
orresp
. to
β
Dyn
)
〈…〉
:
Dyn
int
(
corresp
. to
Dyn
α
)
corresponds
t
o the continuation captured by the cast resultSlide149
Our cast
semantics〈f (v’ 4)〉
v : int
/int→int/bool
Dyn
〈
let x = v
in
〉
4
f
x
〈
〉
〈…〉
:
Dyn
int
(
corresp
. to
Dyn
α
)
s
ince
α is the type of the reset’s body
〈…〉
:
bool
Dyn
(
corresp
.
t
o
β
Dyn
)
s
ince
β is the result type of the resetSlide150
:
Dyn
/Dyn→Dyn/Dynλx.Cast semanticsv : (S/α
→T/β
)
Dyn
(v )
x
x
:
Dyn
S
(v …)
:
T
DynSlide151
:
Dyn
/Dyn→Dyn/Dynλx.Cast semanticsv : (S/α
→T/β
)
Dyn
(v )
xSlide152
:
Dyn
/Dyn→Dyn/Dynλx.Cast semanticsv : (S/α
→T/β
)
Dyn
〈 〉
k
(v )
x
S
k.Slide153
:
Dyn
/Dyn→Dyn/Dynλx.Cast semanticsv : (S/α
→T/β
)
Dyn
〈 〉
k
(v )
x
S
k.Slide154
:
Dyn
/Dyn→Dyn/Dynλx.Cast semanticsv : (S/α
→T/β
)
Dyn
〈 〉
k
(v )
x
S
k.
k (…)
:
Dyn
αSlide155
:
Dyn
/Dyn→Dyn/Dynλx.Cast semanticsv : (S/α
→T/β
)
Dyn
〈 〉
k
(v )
x
S
k.
k (…)
:
Dyn
α
〈…〉
:
β
DynSlide156
:
Dyn
/Dyn→Dyn/Dynλx. S k.〈 〉
k
Cast semantics
v
: (
S/
α
→T/
β
)
Dyn
x
:
Dyn
int
(
succ
…)
:
int
Dyn
(v )
xSlide157
The problematic reduction
is resolvedv : (
int/int→int/bool) Dyn
λ
y
.
S
k.
v
=
λ
x:int
. 3 + (
S
k.
(k 1) == x)
〈 〉
k
(v )
y
:
Dyn
/
Dyn→Dyn
/
DynSlide158
The problematic reduction
is resolvedv : (
int/int→int/bool) Dyn
λ
y
.
S
k.
v
=
λ
x:int
. 3 + (
S
k.
(k 1) == x)
〈 〉
k
(v )
y
:
Dyn
/
Dyn→Dyn
/
DynSlide159
The problematic reduction
is resolved
v = λx:int. 3 + (S k. (k 1) == x)〈f ((λy.S k. ) 4)〉
〈 〉
k
(v )
y
*
s
〜
〈(k 1) == 4
〉
λ
z
.
〈f 〉
(3 + z)
〈…〉
:
bool
Dyn
(
c
orresp
. to
β
Dyn
)
〈…〉
:
Dyn
int
(
corresp
. to
Dyn
α
)Slide160
The problematic reduction
is resolved
v = λx:int. 3 + (S k. (k 1) == x)〈f ((λy.S k. ) 4)〉
〈 〉
k
(v )
y
*
〈f ((
λ
y
.
)
4
)
〉
v
y
λ
z.〈 〉
f
( )
〈
〉
(k 1) == 4
3 + zSlide161
The problematic reduction
is resolved
v = λx:int. 3 + (S k. (k 1) == x)〈f ((λy.S k.
) 4)〉
λz
.〈f z
〉
v
4
〈f ( )
〉
v
4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4)
〈 〉
k
(v )
y
〈f (
S
k. )〉
〈 〉
k
(v )
4
〈
〉
〈 〉
k
(v )
4Slide162
Problem of the standard cast semantics in the presence of shift/reset
…
All value flows between typed and untyped parts are NOT monitored〈 〉
〈 〉
k
(v )
4
λz
.〈f z
〉
v
=
λ
x:int
. 3 + (
S
k.
(k 1) == x)Slide163
The problematic reduction
is resolved
v = λx:int. 3 + (S k. (k 1) == x)〈f ((λy.
)
4)〉
v
y
〈f ( )
〉
v
4
〈f ( )
〉
v
4
〈f
(
)〉
3 + (
S
k.
(k 1) ==
4) Slide164
Our calculus
Program syntax: Types S, T, α, β ::= int
| … | Dyn | S/α → T/β Terms s, t ::= 1 | + | … | λx.s | s t | s : S T | S k. s | 〈s〉Type system: Semantics:
shift/
reset + our cast semantics
Γ
;
α
├ s : T
;
βSlide165
Type soundness
If 〈s〉 is a well typed, closed term, then:
〈s〉 diverges;〈s〉 v for some v; orsome cast in 〈s〉 fails*via Progress and Preservation
If something wrong happens,
it is detected as cast failureSlide166
Outline
IntroductionBackground: blame calculus
(without shift/reset)Problem with control operatorsOur extension of the blame calculus with shift/resetPropertiesSoundness of CPS transformationBlame TheoremSlide167
In the paper…
A formal system including run-time termsSupport for “blame”Blame TheoremStatically typed terms are never responsible for cast failure
CPS transformationSounenss of the CPS transformationPreservation of TypePreservation of Equalityresponsibility for cast failure Slide168
CPS transformation
A technique to implement control operatorsPrograms with control operators are transformed to ones without themCPS transformation for shift/reset is well studiedSlide169
Our CPS transformation
[[・]][[・]] transforms terms/types in our calculus to ones in the simply typed blame calculus
The definition is standard except for casts[[s : S T]] := λk. [[s]] (λx. x : [[S]] [[T]]) [[Dyn]] := Dyn[[S/α→T/β]] := [[S]]→([[T]]→[[α]])→[[β]] Slide170
Soundness of
the CPS transformation
If s t, then [[s]] 〜 [[t]]where 〜 is an equational system with usual call-by-value axioms and a few additional axiomasIf
Γ
;α├ s : T ; β, then [[
Γ
]]├ [[s]] : ([[T]]→[[
α]])→[[β]]
Preservation of Equality
Preservation of TypeSlide171
Blame Theorem
(Cf. [Tobin-Hochstadt&Felleisen’06,Wadler&Findler’09]
Cast failure is always triggered by untyped code That is, in a fully typed program, cast failure never happensSlide172
In the paper…
A formal system including run-time terms and typing rulesCPS transformation for run-time termsSupport for “blame”Blame TheoremMore precisely typed sides are never blamed
responsibility of cast failure Slide173
Related work
Constraining delimited control with contracts [Takikawa et al., ESOP’13]s
tudies “macro” gradual typing with:Control operators not based on CPS powerful enough to express shift/resetContract systemallows refined type information to be represented Modules are fully typed or fully untypedSlide174
Conclusion
An extension of blame calculus with shift/resetCast semantic to monitor capturing and calling continuations Three properties investigatedType soundnessBlame Theorem
Soundness of the CPS transformation