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 .

Embed :

Presentation Download Link

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

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

L/O: To revise the causes of the Cold War in order to write a balanced essay.. THE USA. THE USSR. BOTH SIDES. NO ONE IT WAS INEVITABLE. https://www.youtube.com/watch?v=HpYCplyBknI. . EVENT. WHAT HAPPENED?.

and accountability . Denise Chaffer . Director of Safety and Learning . NHSLA. Is It Blame or Is It Accountability?. by. . Rick Brenner. . http://www.chacocanyon.com/pointlookout/051221.shtml. Blame is to be accountable in a way deserving of censure, discipline, .

. cultivation:. . Activity. . data. . &. . Emission. . Factors. . for. . an. . integrated,. . scalable. . system. Moving. . on. . From. . Experimental. . Approaches. . to. . Advancing.

DKQ57347VSHQW57347D OLIHWLPH57347PDNLQJ57347QXFOHDU57347ZDU57347SDODWDEOH 2Q573477KHUPRQXFOHDU57347DU 7KLQNLQJ57347ERXW57347WKH573478QWKLQNDEOH 573565735957347DQG57347WKLV VWUDQJHORYLDQ57347SKRQH57347JRW57347YHU57347JRRG57347SUHVV5736157347a Q57347DQ

DATE: September 29, 2017 PRESENTED BY: Peter Graven, PhD. What is Cost Shifting?. Time. Price/unit. (as percentage of Medicare). Charges (300%). Private (150%). Medicare (. 100%. ). Uninsured (120%).

Mohit Gupta and Shree K. Nayar. Computer Science. Columbia University. Supported by. : . NSF. . and ONR. Structured Light 3D Scanning. Defect Inspection. Wafer defect. Gaming. Archiving Heritage. Biometrics.

Only 29% of Millennials Cite Ad Skipping as Their Primary Reason . Top Reasons For Time-shifting TV Shows. Source: . HUB Entertainment research; Survey of 1210 . tV. consumers 16-74 who watch at least 5 hours of .

Top Reasons For Time-shifting TV Shows. Source: HUB Entertainment research 3/15; Survey of 1210 . tV. consumers 16-74 who watch at least 5 hours of . tv. /week and have broadband home access; What do you consider to be the biggest benefits of watching episodes of a current show at a later time?.

to learn more about active listening, then join aConversation with Colleagues call to practice your listening skills Conversations with Colleagues click attachments to add to calendarThese conversati

We charac terise where positive and negative blame can arise by decomposing the usual notion of subtype into positive and negative subtyping and show that these recombine to yield naive subtyping Naive typ ing has previously appeared in type systems

© 2021 docslides.com Inc.

All rights reserved.