nestedreﬁnement...

Nested Refinement Types for JavaScript

Ravi Chugh

Disserta/on Defense − September 3, 2013

Types for JavaScript

“Dynamic” or Untyped Features Enable Rapid Prototyping

http://stackoverflow.com/tags02-‐03-‐13

Count Tag

411,345 C#

361,080 Java

337,896 PHP

321,757 JavaScript

175,765 C++

160,768 Python

83,486 C

64,345 Ruby

9,827 Haskell

1,347 OCaml

1. Development Tools 2. Reliability & Security

3. Performance

1. Development Tools

op>onal “type systems” unsound but provide some IDE support

2. Reliability & Security

lightweight sta>c checkers

run-‐>me invariant checkers

secure language subsets

3. Performance

fast language subset to facilitate op/miza/ons

Just-‐In-‐Time (JIT) engines perform sta/c/dynamic analysis to predict types

Why So Hard?

implicit global object

scope manipula/on

JavaScript

var li]ing

‘,,,’ == new Array(4)

“The Good Parts”

objects

reflec/on

arrays

eval()*

lambdas

JavaScript

implicit global object

scope manipula/on

var li]ing

‘,,,’ == new Array(4)

objects

reflec/on

arrays

eval()*

lambdas

JavaScript

12 Expressiveness

Usability Idioms of Dynamic Languages

Verifica>on Hoare Logics

Model Checking Abstract Interpreta/on

Theorem Proving …

+ Logic

Thesis Statement:

“Refinement types can reason about

dynamic languages to verify the absence of run-‐/me errors …

13 Expressiveness

Theorem Proving …

+ Logic

Thesis Statement:

… without resor/ng to undecidable

logics”

14 Expressiveness

Theorem Proving …

+ Logic Dependent

JavaScript (DJS) [POPL 2012, OOPSLA 2012]

Outline

Mo/va/on and Thesis

Challenges of Dynamic Languages

Tour of Dependent JavaScript

Technical Contribu/ons

Evalua/on

Looking Ahead

objects

reflec/on

arrays

eval()*

lambdas

JavaScript

Core Technical Challenges

reflec/on

objects

Java JavaScript

JavaScript function negate(x) { if (typeof x == “number”) { return 0 - x; } else { return !x;} }

run-‐/me type-‐test

but boolean on else-‐branch

x should be numeric on then-‐branch…

Java interface NumOrBool { NumOrBool negate(); }class Bool implements NumOrBool { boolean data; Bool(boolean b) { this.data = b; } Bool negate() { return new Bool(!this.data); } }class Num implements NumOrBool { … }

declared union type

JavaScript function negate(x) { if (typeof x == “number”) { … } else { …} }

Java interface NumOrBool { NumOrBool negate(); }class Bool implements NumOrBool { boolean data; Bool(boolean b) { this.data = b; } Bool negate() { return new Bool(!this.data); } }class Num implements NumOrBool { … }

ad-‐hoc union type

declared union type

JavaScript

ML, Haskell a

function negate(x) { if (typeof x == “number”) { … } else { …} }

datatype NumOrBool = | Num (n:number) | Bool (b:boolean)let negate x = match x with | Num n → Num (0 – n) | Bool b → Bool (!b)

declared union type

JavaScript function negate(x) { if (typeof x == “number”) { … } else { …} }

Lightweight Reflec>on

Java class Person { String first; String last;

Person (String s1, String s2) { this.first = s1; this.last = s2; } void greeting(…) { … } }var john = new Person(“John”, “McCarthy”);var s = john.first + “…”;

var john = { “first” : “John”, “last” : “McCarthy”, “greeting” : … };

var s = john.first + “…”;

JavaScript

field names are declared

keys are arbitrary computed strings

var s = john.first + “…”;

JavaScript

john[“first”]

obj.f means obj[“f”]Objects are Dic>onaries

var john = {};

john.first = “John”; john.last = “McCarthy”; john.greeting = …;

JavaScript

incrementally extend object

“sealed” a]er ini/aliza/on

var john = {};

john.first = “John”; john.last = “McCarthy”; john.greeting = …;

// much later in the code john.anotherKey = …;

addMoreKeys(john);

if (…) { addEvenMoreKeys(john); }

JavaScript

Objects are Extensible29

class Person { String first; String last;

Person (String s1, String s2) { this.first = s1; this.last = s2; } void greeting(…) { … } }var john = new Person(“John”, “McCarthy”);var s = john.first + “…”;class TuringWinner extends Person {

int year; TuringWinner (…) { … } }var twJohn = new TuringWinner(…);twJohn.greeting();

inherit from superclass

class Person { String first; String name;

Person (String s1, String s2) { this.first = s1; this.last = s2; } void greeting(…) { … } }var john = new Person(“John”, “McCarthy”);...... s = john.first + “…”;class TuringWinner extends Person {

int year; TuringWinner (…) { … } }var twJohn = new TuringWinner(…);twJohn.greeting();

inheritance chain declared

JavaScript

var twJohn = { “year” : 1971, “__proto__” : john };

twJohn.greeting();

inheritance chain computed

Objects Inherit from Prototypes

var twJohn = { “year” : 1971, “__proto__” : john };

twJohn.greeting();

JavaScript

Objects Inherit from Prototypes

Objects are Extensible

Objects are Dic>onaries

Lightweight Reflec>on

Refinement Types

Dependent JavaScript (DJS) [POPL ’12, OOPSLA ’12]

✓ ✓ ✓ ✓

✓ * ✓

Haskell

lightweight reflec/on

objects are dic/onaries

objects are extensible

prototype inheritance

Outline

Mo/va/on and Thesis

Evalua/on

Looking Ahead

typeof true // “boolean”

typeof 0.1 // “number” typeof 0 // “number”

typeof {} // “object” typeof [] // “object” typeof null // “object”

typeof returns run-‐/me “tags”

Tags are very coarse-‐grained types

“undefined”

“boolean”

“string”

“number”

“object”

“function”

Refinement Types

{ x | p }“set of values x s.t. formula p is true”

{ n | tag(n) = “number” }Num ≡

{ v | tag(v) = “number” ∨ tag(v) = “boolean” }NumOrBool ≡

{ i | tag(i) = “number” ∧ integer(i) }Int ≡

{ x | true }Any ≡

{ n | tag(n) = “number” }Num ≡

{ i | tag(i) = “number” ∧ integer(i) }Int ≡

{ x | true }Any ≡

Syntac/c Sugar for Common Types

Refinement Types

3 ::{ n | n = 3 } { n | n > 0 } 3 ::{ n | tag(n) = “number” ∧ integer(n) } 3 ::{ n | tag(n) = “number” } 3 ::

Refinement Types

{ n | n = 3 } { n | n > 0 } { n | tag(n) = “number” ∧ integer(n) } { n | tag(n) = “number” }

<:⊆. ⊆. ⊆.

Subtyping is Implica/on

Refinement Types

{ n | n = 3 } { n | n > 0 } { n | tag(n) = “number” ∧ integer(n) } { n | tag(n) = “number” }

⇒⇒⇒⇒

Refinement Types

SMT Solver or Theorem

Prover

Refinement Type

Checker

p ⇒ q ?

Yes / No

Mutable Objects Dic/onary Objects Tag-‐Tests Prototypes

function negate(x) { if (typeof x == “number”) { return 0 - x; } else { return !x;} }

Type Annota>on in Comments

//: negate :: (x:NumOrBool) → NumOrBool

{ v | tag(v) = “number” ∨ tag(v) = “boolean” }

NumOrBool ≡

Syntac>c Sugar for Common Types

{ x | tag(x) = “number” }

“expected args”

⊆ { x | tag(x) = “number” }

⇒{ x | tag(x) = “number” } { x | tag(x) = “number” }✓

“expected args”

⊆ { x | tag(x) = “boolean” }

✓ { x | not(tag(x) = “number”) { x | ∧ (tag(x) = “number” ∨{ x | tag(x) = “boolean”) }

//: negate :: (x:NumOrBool) → NumOrBool✓

Refinement Types Enable Path Sensi/vity

Output type depends on input

//: negate :: (x:NumOrBool) → { y|tag(y) = tag(x) }

if (“quack” in duck) return “Duck says ” + duck.quack();else return “This duck can’t quack!”;

What is “Duck Typing”?

Mutable Objects Tag-‐Tests Dic/onary Objects Prototypes

(+) :: (Num,Num) → Num(+) :: (Str,Str) → Str

Can dynamically test the presence of a method

but not its type

{ d | tag(d) = “object” ∧ { v | has(d,“quack”) ⇒{ v | sel(d,“quack”) :: () → Str }

Operators from McCarthy theory of arrays

{ d | tag(d) = “object” ∧ { v | has(d,“quack”) ⇒{ v | sel(d,“quack”) :: () → Str }

Call produces Str, so concat well-‐typed

var x = {};x.f = 7;x.f + 2;

x0:Empty

x1:{d|d = upd(x0,“f”,7)}

DJS is Flow Sensi/ve

McCarthy operator DJS verifies that x.f is definitely a number

Dic/onary Objects Tag-‐Tests Mutable Objects Prototypes

var x = {};x.f = 7;x.f + 2;

x0:Empty

x1:{d|d = upd(x0,“f”,7)}

DJS is Flow Sensi/ve

Strong updates to singleton objects

Weak updates to collec/ons of objects

Dic/onary Objects Tag-‐Tests Mutable Objects Prototypes

parent

grandpa

Upon construc/on, each object links to a prototype object

Dic/onary Objects Tag-‐Tests Prototypes Mutable Objects

If child contains k, then Read k from child

Else if parent contains k, then Read k from parent

Else if grandpa contains k, then Read k from grandpa

Else if …

Else Return undefined

parent

grandpa

var k = “first”; child[k];Seman/cs of Key Lookup

parent

grandpa

(Rest of Heap)

Else if …

{ v | if has(child,k) then{ v | ifv = sel(child,k)

parent

grandpa

(Rest of Heap)

Else if …

{ v | else if has(parent,k) then{ v | ifv = sel(parent,k)

Else if …

parent

grandpa ???

(Rest of Heap)

{ v | else{ v | ifv = HeapSel(H,grandpa,k)) }

parent

grandpa ???

(Rest of Heap)

Abstract predicate to summarize the unknown por>on

of the prototype chain

{ “first” : “John” }child

parent { “first” : “Ida” , “last” : “McCarthy” }

grandpa ???

(Rest of Heap)

{ v | v = “John” }

var k = “first”; child[k];

{ “first” : “John” }child

parent { “first” : “Ida” , “last” : “McCarthy” }

grandpa ???

(Rest of Heap)

var k = “last”; child[k];

{ v | v = “McCarthy” }

Key Idea:

Reduce prototype seman/cs to decidable

theory of arrays

Prototype Chain Unrolling

reflec/on

arrays

eval()*

lambdas

JavaScript

objects

✓ ✓

EXTRA SLIDES

Outline

Mo/va/on and Thesis

Evalua/on

Looking Ahead

lambdas dic/onaries

tag tests

muta/on

prototypes

Transla/on à la Guha et al. (ECOOP 2010)

Dependent JavaScript (DJS)

Our Strategy:

Build an expressive type system for core language

lambdas dic/onaries

tag tests

muta/on

prototypes

(POPL 2012)

(OOPSLA 2012)

System D

System !D

System DJS (OOPSLA 2012)

Dependent JavaScript (DJS) Dependent JavaScript (DJS)

Prior Refinement Types

T ::= { x:B | p } | x:T1 → T2 | [ f1:T1; … ] | Map[A,B] | Ref(T)

base type (e.g. Int, Bool, Str) dependent func/on type

object type (a.k.a. record, struct)

dic/onary type (a.k.a. map, hash table)

reference type (a.k.a. pointer)

Predicates refine only base types

Prior Refinement

C# System DJS

✓ ✓ ✓ ✓

✓ * ✓

Haskell

lightweight reflec/on

JavaScript Encodings Flow-‐Sensi/ve Refinements Nested Refinements

* ✓ ✗

✓ ✓ ✓

Key Challenge:

Func/on Subtyping as Logical Implica/on

42 + negate (17)

⊆ { f | f :: }(x:Num) → Num “expected func/on”

{ f | f :: } (x:NumOrBool) → { y|tag(y) = tag(x) }

{ f | f :: }

(x:NumOrBool) → { y|tag(y) = tag(x) }

{ f | f :: }(x:Num) → Num⇒

How to Prove

? How to Encode Type System Inside Logic?

Prior Refinement Systems Disallow Func/on Types Inside Logic!

T ::= { x | p } | T1 → T2

Types Refinement Logic

Sa/sfiability Modulo Theories (SMT)

SAT + Decidable Theories

p ⇒ q ✓

✗ SMT Solver (e.g. Z3)

[Prior State-‐of-‐the-‐Art]

T ::= { x | p } | T1 → T2

p ::= p ∧ q | p ∨ q | ¬p | x = y | x > y | … | tag(x) = “number” | … | sel(x,k) = 17 | …

• Boolean Connec/ves • Equality • Linear Arithme/c • Uninterpreted Func/ons • McCarthy Arrays

T ::= { x | p } | T1 → T2

Enables Union Types and Lightweight Reflec>on

T ::= { x | p } | T1 → T2

Enables Dic>onary Types with Dynamic Keys …

{ d | tag(sel(d,k)) = “boolean” ∧

{ d | tag(sel(d,“f”)) = “function” ∧

{ d | sel(d,“f”) ??? }

But Disallows Func/ons in Dic/onaries!

p ::= p ∧ q | p ∨ q | ¬p | x = y | x > y | … | tag(x) = “number” | … | sel(x,k) = 17 | … | sel(x,k) :: T1 → T2 | …

Goal: Refer to Type System Inside Logic Goal: Without Giving up Decidability

T ::= { x | p } | T1 → T2

Solu/on: Nested Refinements!

T ::= { x | p } p ::= p ∧ q | p ∨ q | ¬p | x = y | x > y | … | tag(x) = “number” | … | sel(x,k) = 17 | … | sel(x,k) :: T1 → T2 | …

Nested Refinements [POPL ’12] 1. Decidable Encoding 2. Precise Subtyping 3. Type Soundness Proof

{ f | f :: }(x:Num) → Num⇒

Decidable Encoding

Uninterpreted Predicate in Logic

Dis/nct Uninterpreted Constants in Logic…

{ f | f :: }

(x:NumOrBool) → { y|tag(y) = tag(x) }

{ f | f :: }(x:Num) → Num⇒

Decidable Encoding

Uninterpreted Predicate in Logic

w/ Types Nested Inside

Dis/nct Uninterpreted Constants in Logic…

Decidable Encoding

{ f | f :: }(x:Num) → Num⇒

✗ SMT Solver

Trivially Decidable, but Imprecise

p ⇒ f ::(x:S1) → S2

⊆ { f | f :: }(x:T1) → T2{ f | p }

Precise Subtyping

Step 1:

Step 2:

Find such that (x:S1) → S2

SMT Solver ✓

T1 S1⊆ ✓ ✓ S2 T2⊆ x:T1 ∧

Compare and (x:S1) → S2 (x:T1) → T2

“contra-‐variance”

“co-‐variance”

⊆ { f | f :: }(x:Num) → Num{ f | f = negate }

Precise Subtyping

Step 1:

Step 2:

f = negate ⇒ f ::(x:NumOrBool) → { y|tag(y) = tag(x) }SMT

Solver ✓

⊆ { f | f :: }(x:Num) → Num{ f | f = negate }

Precise Subtyping

Step 1:

Step 2:

f = negate ⇒ f ::(x:NumOrBool) → { y|tag(y) = tag(x) }

Num NumOrBool⊆ ✓ ✓ { y | tag(y) = tag(x) } Num⊆ x:Num ∧

✓ SMT Solver ✓

Precise Subtyping

Step 1:

Step 2:

Decidable Reasoning via SMT

Precise Func/on Subtyping via Syntac/c Techniques

⊆ { f | f :: }{ f | f = negate } ✓ (x:Num) → Num

Type Soundness Proof

Logic 0

Conven/onal Proofs Require Logic to be an Oracle …

… but Nes/ng Introduces Circularity That Prevents Typical Induc/ve Proofs

Type System 0

Type System ∞

Type Soundness Proof

Logic 0

Logic 1

Logic 2

Type System 1

Type System 2

Type System 0

… …

Proof Technique: Stra>fy into Infinite Hierarchy

Key to Encode Dic/onary Objects (Even in Sta/cally Typed Languages!)

T ::= { x | p } p ::= p ∧ q | p ∨ q | ¬p | x = y | x > y | … | tag(x) = “number” | … | sel(x,k) = 17 | … | sel(x,k) :: T1 → T2 | …

Nested Refinements [POPL ’12]

var x = {};x.f = 7;x.f + 2;

let x = new {} in

(*x).f = 7;

(*x).f + 2;

Allocates ptr x :: Ref(Dict)

Heap update doesn’t affect type

So key lookup doesn’t type check!

Key Issue:

“Invariant” Reference Types

let x = new {} in

(*x).f = 7;

(*x).f + 2;

Lx |-> d0:{d|d =empty}

Lx |-> d1:{d|d = upd(d0,“f”,7)}

Allocates heap loca>on Lx and x :: Ref(Lx)Type of pointer doesn’t change …

But types of heap loca/ons can!

x:T1 / h1 → T2 / h2

output type

input type

x:T1 / h1 → T2 / h2

output type

input type

input heap

output heap

x:T1 / h1 → T2 / h2Our Formula/on Extends:

Alias Types (Smith et al., ESOP 2000) syntac>c types for higher-‐order programs

Low-‐Level Liquid Types (Rondon et al., POPL 2010) refinement types for first-‐order programs

let swap (x, y) = let tmp = *x in *x = *y; *y = tmp in …

//: swap :: (x:Ref(Lx), y:Ref(Ly))//: / H + (Lx |-> a:Any) + (Ly |-> b:Any) //: → Void//: / H + (Lx |-> a’:Any{a’= b})//: + (Ly |-> b’:Any{b’= a})

//: getKey :: (x:Ref(Lx), k:Str)//: / H + (Lx |-> d:Dict > Lx’) //: → { y | if has(d,k)//: then y = sel(d, k)//: else y = HeapHas(H, Lx’, k)}//: / H + (Lx |-> d’:Dict{d’= d} > Lx’)

Prototype Inheritance

x[k] getKey(*x, k)

Primi>ve Operators (Avoid Implicit Coercion)

JavaScript Arrays (Several Unusual Issues)

Prototype Inheritance

Outline

Mo/va/on and Thesis

Evalua/on

Looking Ahead

(+35%)

LOC before/a]er

14 Excerpts from: JavaScript, Good Parts SunSpider Benchmark Suite Google Closure Library

Benchmarks

Chosen to Stretch the Limits of DJS

(+35%)

LOC before/a]er

Benchmarks

9 Browser Extensions from: [Guha et al. Oakland ’11]

(+19%)

(+2%) 2 Examples from: Google Gadgets

1,637 1,831

(+12%) TOTALS

LOC before/a]er

(+35%)

Benchmarks

9 Browser Extensions from: [Guha et al. Oakland ’11]

(+19%)

2 Examples from: Google Gadgets

1,637 1,831

(+12%)

11 sec

Running Time

19 sec

33 sec TOTALS 1,831

(+12%)

33 sec

>>> Skip Optimizations >>>

Reducing Annota>on Burden • Bidirec/onal (local) type inference – Several aspects unique to this sezng

• Op/onal var declara/on invariants – Auto add to types of subsequent closures

var i /*: Int */ = 0;…//: f :: T1 / H1 + (Li |-> i1:Int) //: → T2 / H2 + (Li |-> i2:Int)var f(…) { … i … }

func/on refers to mutable variable i, so heaps must describe

the loca/on

var i /*: Int */ = 0;…//: f :: T1 / H1//: → T2 / H2var f(…) { … i … }

copy the annota/on, if any

var i /*: Int */ = 0;…//: f :: T1 / H1 + (Li |-> i1:Int) //: → T2 / H2 + (Li |-> i2:Int)var f(…) { … i … }

copy the annota/on, if any

no annota/on means “do not modify” var i = 0;…//: f :: T1 / H1 + (Li |-> i1:{x | x = 0}) //: → T2 / H2 + (Li |-> i2:{x | x = 0})var f(…) { … i … }

Improving Performance

17 :: { x:Int | x = 17 }

if b then “hi” else 17 :: { x | b = true ⇒ x = “hi”if b then 17 else “hi” :: { x ∧ b = false ⇒ x = 17 }

track syntac>c types for specialized cases …

… fall back on refinement types for general case

• Avoid making SMT queries when possible

Improving Performance • Can reduce precision for if-‐expressions

var n = 0;if (b) { n = n + 1;else { n = n + 2;}

Ln |-> m:{ x | b = true ⇒ x = 1Ln |-> m: {x ∧ b = false ⇒ x = 2 }

“exact joins” by default …

… annota/on on var triggers “inexact joins”

Improving Performance • Can reduce precision for if-‐expressions

var n /*: Int */ = 0;if (b) { n = n + 1;else { n = n + 2;}

Ln |-> m:Int

“exact joins” by default …

… annota/on on var triggers “inexact joins”

Plenty of Room for Improvement

1,637 TOTALS 33 sec 1,831

(+12%)

Rela/vely Modest Op/miza/ons Have Made Significant Impact

Outline

Mo/va/on and Thesis

Evalua/on

Looking Ahead

Immediate Direc>ons

• Type Soundness – proven for System D, but not for !D or DJS

• Expressiveness – e.g. mutual recursion, recursion through heap

• Usability – annota/on burden, performance, error messages

• Integra/on with Run-‐Time Contracts – invariants before and a]er eval()

Expressiveness

Usability

Verifica>on

TypeScript Lightweight (unsound) sta/c checking tools becoming popular

Translate for addi/onal checking and IDE support

“Gradual Gradual Typing”

Way Behind Tools for Java, etc.

• Sta/c Types in DJS Enable Refactoring, • Documenta/on Tools, Code Comple/on

• Web-‐Based Interfaces to Collect Sta>s>cs • about Programming Pa{erns, Errors

Web Development Tools

candidate annota/ons

User or

Test Cases or

Heuris>cs

Itera>ve Inference Global inference (e.g. via Liquid Types) would be nice, but no basic type structure to start with

unannotated program

Verifica>on Condi>on Genera>on

Coarsen Types

Browser Extension Security

Security = Refinement

Type Checking à la Swamy et al. (ESOP 2010) and Guha et al. (Oakland 2011)

Third-‐Party Code

Policy

Browser APIs

Secure Reference Monitor via Refinements

Thanks!

Nested Refinements + Dependent JavaScript

Ranjit Jhala Pat Rondon Dave Herman Panos Vekris

Other Projects

Sorin Lerner Jan Voung Jeff Meister Nikhil Swamy Juan Chen

EXTRA SLIDES

reflec/on

arrays

eval()*

lambdas

JavaScript

objects

var nums = [0,1,2];while (…) { nums[nums.length] = 17;}

A finite tuple…

… extended to unbounded collec/on

var nums = [0,1,2];while (…) { nums[nums.length] = 17;}

delete nums[1];

for (i = 0; i < nums.length; i++) { sum += nums[i]; }

A “hole” in the array

Missing element within “length”

Track types, “packedness,” and length of arrays where possible

{ a | a :: Arr(T) { a |∧ packed(a)

{ a |∧ len(a) = 10 }

X T T T T … X … …

T? T? T? T? T? … T? … …

T? ≡ { x | T(x) ∨ x = undefined }

-‐1 0 1 2 len(a)

X ≡ { x | x = undefined }

{ a | a :: Arr(Any) { a | ∧ packed(a) ∧ len(a) = 2

{ a | ∧ Int(sel(a,0)) { a | ∧ Str(sel(a,1)) }

Encode tuples as arrays

var tup = [17, “cacti”];

var tup = [17, “cacti”];tup[tup.length] = true;

{ a | a :: Arr(Any) { a | ∧ packed(a) ∧ len(a) = 3

{ a | ∧ … }

reflec/on

arrays

eval()*

lambdas

JavaScript

objects

What About eval?

Arbitrary code loading

eval(“…”);

Old Types

What About eval?

eval(“…”);//: #assume …

Old Types

New Types New Types

Future Work: Integrate DJS with “Contract Checking” at Run-‐/me

aka “Gradual Typing”

129 Expressiveness

Theorem Proving …

Func/on Subtyping…

{ d | sel(d,“f”) :: } (x:Any) → { y|y = x }{ d | sel(d,“f”) :: }(x:Num) → Num<:

Higher-‐Order Refinements

{ d | sel(d,“f”) :: }(x:Num) → Num{ d | sel(d,“f”) :: } (x:Any) → { y|y = x }

{ d | sel(d,“”)f :: }(x:Num) → Num{ d | sel(d,“ ”f :: } (x:Any) → { y|y = x }

… With Quan/fiers ∀x,y. true ∧ y = f(x) ⇒ y = x

∀x,y. Num(x) ∧ y = f(x) ⇒ Num(y)✓ Valid, but First-‐Order Logic is Undecidable

Heap Updates…

… With Quan/fiers

var x = {};x.f = 7; h1

∧ …

∧ sel(h1,x) = empty ∧ ∀y. x ≠ y ⇒ sel(h1,y) = sel(h0,y)

∧ sel(h2,x) = upd(sel(h1,x),“f”,7) ∧ ∀y. x ≠ y ⇒ sel(h2,y) = sel(h1,y)

Encode Heap w/ McCarthy Operators

Subtyping with Nes>ng

e.g. tag(x) = tag(y)

e.g. tag(sel(d,k)) = “number”

1) Convert q to CNF clauses (q11 ∨ … ) ∧ … ∧ (qn1 ∨ … )2) For each clause, discharge some literal qij as follows:

base predicate: p ⇒ qij

anything except HasType(x,U)

Subtyping with Nes>ng

Implica/on

SMT Solver

Subtyping Arrow Rule

base predicate: p ⇒ qij p ⇒ x :: U

Implica/on

SMT Solver

Subtyping

p ⇒ x :: U’

U’ <: U

p ⇒ qij

1) Convert q to CNF clauses (q11 ∨ … ) ∧ … ∧ (qn1 ∨ … )2) For each clause, discharge some literal qij as follows:

Type Soundness with Nes>ng

0 :: { ν | λx.x+1 :: Int → Int }_ |

λx.x+1 :: { ν | ν :: Int → Int }_ |

f:{ ν | ν :: Int → Int } 0 :: { ν | f :: Int → Int }_ |

Subs/tu/on Lemma

_ | v :: Txand If x:Tx, Γ e[:: T_ |

Γ[v/x] e[v/x] :: T[v/x]_ | then

independent of 0, and just echoes the binding from the environment

0 :: { ν | λx.x+1 :: Int → Int }_ |

SMT ν = 0 ⇒ λx.x+1 :: Int → Int✗

{ ν | ν = 0 } < { ν | λx.x+1 :: Int → Int }0 :: { ν | ν = 0 }

Subs/tu/on Lemma

Γ[v/x] e[v/x] :: T[v/x]_ | then

1st a{empt

0 :: { ν | λx.x+1 :: Int → Int }_ |

{ ν | ν = 0 } < { ν | λx.x+1 :: Int → Int }0 :: { ν | ν = 0 }

Subs/tu/on Lemma

Γ[v/x] e[v/x] :: T[v/x]_ | then ✗ SMT ν = 0 ⇒ ν :: U’

Arrow U’ <: Int → Int

+2nd a{empt ✗

λx.x+1 :: Int → Int|=I

λx.x+1 :: { ν | ν :: Int → Int }|_

SMT Γ ∧ p ⇒ q

Γ { ν | ν = p } < { ν | ν = q }_ |

[S-‐Valid-‐Uninterpreted]

|=I Γ ∧ p ⇒ q

Γ { ν | ν = p } < { ν | ν = q }_ |

[S-‐Valid-‐Interpreted]

• Rule not closed under subs/tu/on

• Interpret formulas by “hooking back” into type system

• Stra/fica/on to create ordering for induc/on

Type Soundness with Nes>ng

Stra/fied Subs/tu/on Lemma

Γ[v/x] e[v/x] :: T[v/x]_ | then n+1

Stra/fied Preserva/on

e vand If e[:: T_ | 0_ | then v[:: Tm for some m

“Level 0” for type checking source programs,

using only [S-‐Valid-‐Uninterpreted]

ar/fact of the metatheory

</Ph.D.>

nestedreﬁnement...

Documents

manoj chugh - welcome note and changing role of cio's

chugh intrev rna 2012 potential pitfalls in microrna...

reg.n s.no o. name of the student father name...

ppt live q&a session 8 with ravijot chugh

program analysis with set constraints ravi chugh

delhi public school, chandigarh - dpschd.com · 345 aanya...

amit chugh - hpmindia.com · amit chugh, avp — scm,...

nested refinement types for javascript ravi chugh...

dependent types for javascript ravi chugh ranjit jhala...

presentation by dr. td chugh

dependent types for javascript ravi chugh ranjit jhala dave...

dependent types for javascript -...

open seats pre-school admission 2018-19 list of eligible...

landslides (2005) 00 ashok k. chugh timothy d. stark doi...

getting things done while remaining happy (shobhit chugh)...

list of candidates registered for open seats … · 137 179...

ravi chugh, matthew a. hammer, …1:4 cyrus omar, ian...

sa#sﬁability+modulo+theories+ and network+veriﬁca#on ·...

quincy chugh-portfolioportfolio

knowledge ubiquity through the transfer of...