Substructural Typestates
|
|
|
- Leona Bradley
- 6 years ago
- Views:
Transcription
1 Programming Languages meets Program Verification 2014 Substructural Typestates Filipe Militão (CMU & UNL) Jonathan Aldrich (CMU) Luís Caires (UNL)
2 Motivation! File file = new File( out.txt );! file.write( stuff );! file.close();! file.write( more stuff ); Note: consider a simplified File object, similar to Java s FileOutputStream. 2
3 Motivation! File file = new File( out.txt );! file.write( stuff );! file.close();! file.write( more stuff ); FAILS with runtime exception ( invalid file descriptor ) 3
4 Motivation class File { FileDescriptor fd; File( string filename ){ fd = OS.createFile( filename ); } void write( string s ){ if( fd == null ) throw Exception( invalid file descriptor ); fd.write( s ); } void close(){ fd = null; } } 4
5 Motivation class File { FileDescriptor fd; File( string filename ){ fd = OS.createFile( filename ); File } File void write( string s ){ if( fd == null ) throw Exception( invalid file descriptor ); fd.write( s ); File File File } } void close(){ fd = null; } The File type abstraction does not precisely express the changing properties of File s internal state (fd). 4
6 Motivation class File { FileDescriptor fd; File( string filename ){ fd = OS.createFile( filename ); } void write( string s ){ if( fd == null ) throw Exception( invalid file descriptor ); fd.write( s ); Open Open Open Open Closed } } void close(){ fd = null; } Superfluous if statically ensured to only be used when File is open. 5
7 Motivation class File { FileDescriptor fd; File( string filename ){ fd = OS.createFile( filename ); } void write( string s ){ if( fd == null ) throw Exception( invalid file descriptor ); fd.write( s ); Open Open Open Open Closed } } void close(){ fd = null; } Open and Close are typestates. Superfluous if statically ensured to only be used when File is open. 5
8 Contributions 1. Reconstruct typestate features from standard type-theoretic programming language primitives. We focus on the following set of typestate features: a) state abstraction, hiding an object representation while expressing the type of the state; b) state dimensions, enabling multiple orthogonal typestates over the same object; c) dynamic state tests, allowing a case analysis over the abstract state. 2. We show how to idiomatically support both state-based (typestate) and transition-based (behavioral types) specifications of abstract state evolution. 6
9 Language Polymorphic λ-calculus with mutable references (and immutable records, tagged sums,...). Technically, we use a variant of L 3 adapted for usability (by simplifying the handling of capabilities, adding support for sum types, universal/existential type quantification, alternatives, labeled records,...). Ahmed, Fluet, and Morrisett. L 3 : A linear language with locations. Fundam. Inform
10 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. 8
11 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. ref A 8
12 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. type of contents of cell ref A 8
13 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. type of contents of cell ref A becomes ref p rw p A 8
14 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. type of contents of cell ref A becomes ref p rw p A location p links ref to read+write capability that tracks the contents of that cell 8
15 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. type of contents of cell type of contents of cell p (linear - cannot be duplicated) ref A becomes ref p rw p A location p links ref to read+write capability that tracks the contents of that cell 8
16 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. type of contents of cell ref A can be freely copied (pure) becomes ref p type of contents of cell p (linear - cannot be duplicated) rw p A location p links ref to read+write capability that tracks the contents of that cell 8
17 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. 9
18 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. y : ref p z : ref q x : ref p 9
19 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. y : ref p z : ref q x : ref p rw q B rw p A 9
20 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. y : ref p z : ref q x : ref p rw q B rw p A!x ( de-reference x ) 9
21 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. y : ref p z : ref q x : ref p rw q B rw p A!x ( de-reference x ) 9
22 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. y : ref p z : ref q x : ref p rw q B rw p A!x ( de-reference x ) 9
23 Language Mutable state handled as a linear resource: - split in pure references and linear capabilities. - use location-dependent types to link both. y : ref p z : ref q x : ref p!x ( de-reference x ) rw q B rw p A A 9
24 Language Capabilities are (linear) typing artifacts (not values) that are threaded and stacked implicitly. For that, we use a Type-and-Effect system. Typing judgement format: 10
25 Language Capabilities are (linear) typing artifacts (not values) that are threaded and stacked implicitly. For that, we use a Type-and-Effect system. Typing judgement format: Lexical Typing Environment 10
26 Language Capabilities are (linear) typing artifacts (not values) that are threaded and stacked implicitly. For that, we use a Type-and-Effect system. Typing judgement format: Lexical Typing Environment Initial Linear Typing Environment 10
27 Language Capabilities are (linear) typing artifacts (not values) that are threaded and stacked implicitly. For that, we use a Type-and-Effect system. Typing judgement format: Lexical Typing Environment Initial Linear Typing Environment Type of Expression 10
28 Language Capabilities are (linear) typing artifacts (not values) that are threaded and stacked implicitly. For that, we use a Type-and-Effect system. Typing judgement format: Lexical Typing Environment Resulting Effects Initial Linear Typing Environment Type of Expression 10
29 Language Capabilities are (linear) typing artifacts (not values) that are threaded and stacked implicitly. For that, we use a Type-and-Effect system. Typing judgement format: resources are either consumed 11
30 Language Capabilities are (linear) typing artifacts (not values) that are threaded and stacked implicitly. For that, we use a Type-and-Effect system. Typing judgement format: resources are either consumed 11
31 Language Capabilities are (linear) typing artifacts (not values) that are threaded and stacked implicitly. For that, we use a Type-and-Effect system. Typing judgement format: or, threaded through 12
32 Language Capabilities are (linear) typing artifacts (not values) that are threaded and stacked implicitly. For that, we use a Type-and-Effect system. Typing judgement format: or, threaded through 12
33 Language Capabilities can be stacked and unstacked on top of some type, allowing them to accompany that type. 13
34 Language Capabilities can be stacked and unstacked on top of some type, allowing them to accompany that type. 13
35 Language Capabilities can be stacked and unstacked on top of some type, allowing them to accompany that type. 13
36 Language Capabilities can be stacked and unstacked on top of some type, allowing them to accompany that type. 13
37 Language Capabilities can be stacked and unstacked on top of some type, allowing them to accompany that type. 13
38 Language Capabilities can be stacked and unstacked on top of some type, allowing them to accompany that type. 13
39 Language Capabilities can be stacked and unstacked on top of some type, allowing them to accompany that type. 13
40 Language Capabilities can be stacked and unstacked on top of some type, allowing them to accompany that type. 13
41 Types 14
42 Syntax 15
43 Syntax let-expanded 15
44 Syntax let-expanded 15
45 Pair Example Function that creates stateful Pair objects. The Pair s components (left and right) are private, not accessible to clients. The state of Pair is changed indirectly by calling functions contained in a labeled record (which are technically closures). 16
46 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end delete l; delete r 17
47 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end delete l; delete r 18
48 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end delete l; delete r 18
49 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end Γ = pl : loc, l : ref pl Δ = rw pl [] delete l; delete r 18
50 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end Γ = pl : loc, l : ref pl, pr : loc, r : ref pr Δ = rw pl [], rw pr [] delete l; delete r 19
51 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end Γ = pl : loc, l : ref pl, pr : loc, r : ref pr Δ = rw pl [], rw pr [] delete l; delete r 20
52 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end delete l; delete r 21
53 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end delete l; delete r 22
54 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end Δ = rw pl [] delete l; delete r 22
55 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end delete l; delete r Δ = rw pl int 23
56 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun(!( ( _ int : [] :: :: rw rw pl pl [] ) int * ( rw [] :: pr rw int pl ). int!l+!r, ) ) destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end delete l; delete r 24
57 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun(!( ( _ int : [] :: :: rw rw pl pl [] ) int * ( rw [] :: pr rw int pl ). int!l+!r, ) ) destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end delete l; delete r 24
58 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end [ ] delete l; delete r initl :!( ( int :: rw pl [] ) ( [] :: rw pl int ) ), initr :!( ( int :: rw pr [] ) ( [] :: rw pr int ) ), sum :!( ( [] :: rw pl int * rw pr int ) ( int :: rw pl int * rw pr int ) ), destroy :!( ( [] :: rw pl int * rw pr int ) [] ) 25
59 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end [ ] delete l; delete r initl :!( ( int :: rw pl [] ) ( [] :: rw pl int ) ), initr :!( ( int :: rw pr [] ) ( [] :: rw pr int ) ), sum :!( ( [] :: rw pl int * rw pr int ) ( int :: rw pl int * rw pr int ) ), destroy :!( ( [] :: rw pl int * rw pr int ) [] ) 25 Δ = rw pl [], rw pr []
60 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). } end end [ delete l; delete r initl :!( ( int :: rw pl [] ) ( [] :: rw pl int ) ), initr :!( ( int :: rw pr [] ) ( [] :: rw pr int ) ), sum :!( ( [] :: rw pl int * rw pr int ) ( int :: rw pl int * rw pr int ) ), destroy :!( ( [] :: rw pl int * rw pr int ) [] ) ] :: ( rw pl [] * rw pr [] ) 26
61 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in <pl, <pr,{ initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). }> > end end ll. lr.( [ delete l; delete r initl :!( ( int :: rw ll [] ) ( [] :: rw ll int ) ), initr :!( ( int :: rw lr [] ) ( [] :: rw lr int ) ), sum :!( ( [] :: rw ll int * rw lr int ) ( int :: rw ll int * rw lr int ) ), destroy :!( ( [] :: rw ll int * rw lr int ) [] ) ] :: ( rw ll [] * rw lr [] ) ) 27
62 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in <pl, <pr,{ initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). }> > end end The object s representation is exposed! ll. lr.( [ delete l; delete r initl :!( ( int :: rw ll [] ) ( [] :: rw ll int ) ), initr :!( ( int :: rw lr [] ) ( [] :: rw lr int ) ), sum :!( ( [] :: rw ll int * rw lr int ) 27 ( int :: rw ll int * rw lr int ) ), destroy :!( ( [] :: rw ll int * rw lr int ) [] ) ] :: ( rw ll [] * rw lr [] ) )
63 let newpair = fun( _ : [] ). open <pl,l> = new {} in open <pr,r> = new {} in < rw pl [], < rw pl int, < rw pr [], < rw pr int { initl = fun( i : int :: rw pl [] ). l := i, initr = fun( i : int :: rw pr [] ). r := i, sum = fun( _ : [] :: rw pl int * rw pr int ).!l+!r, destroy = fun( _ : [] :: rw pl int * rw pr int ). }> > > > end end EL. L. ER. R.( [ delete l; delete r initl :!( int :: EL [] :: L ), initr :!( int :: ER [] :: R ), sum :!( [] :: L * R int :: L * R ), destroy :!( [] :: L * R [] ) ] :: EL * ER ) 28
64 Pair Typestate newpair :!( [] EL. L. ER. R.([ initl :!( int :: EL [] :: L ), initr :!( int :: ER [] :: R ), sum :!( [] :: L * R int :: L * R ), destroy :!( [] :: L * R [] ) ] :: EL * ER ) ) Type expresses the changing properties of the object s state, typestate (EmptyLeft, Left, EmptyRight and Right). Orthogonal typestates, state dimensions (EL/L and ER/R), correlate to separate internal state that operates independently. 29
65 Stack Typestate Type of a function (polymorphic in the contents to be stored in the stack) that creates stack objects. Each stack has two states: Empty and NonEmpty. Imprecision in the exact state of the stack is typed with E NE (alternative): we either have the E typestate or NE the typestate. 30
66 Stack Typestate Type of a function (polymorphic in the contents to be stored in the stack) that creates stack objects. Each stack has two states: Empty and NonEmpty. Imprecision in the exact state of the stack is typed with E NE (alternative): we either have the E typestate or NE the typestate. Typestates do not exist at runtime. How can client code distinguish between different states without breaking the abstraction? 30
67 newstack : T.( [] E. NE.[ push : T :: E NE [] :: NE, pop : [] :: NE T :: E NE, isempty : [] :: E NE Empty#([]::E) + NonEmpty#([]::NE), ] :: E ) del : [] :: E [] Note:! s omitted from the type for brevity. 31
68 newstack : T.( [] E. NE.[ push : T :: E NE [] :: NE, pop : [] :: NE T :: E NE, isempty : [] :: E NE Empty#([]::E) + NonEmpty#([]::NE), ] :: E ) del : [] :: E [] Note:! s omitted from the type for brevity. 32
![newstack : T.( [] E. NE.](/docs-images/76/73238280/images/69-0.jpg "[ push : T :: E NE [] :: NE, pop : [] :: NE T :: E NE, isempty : [] :: E NE Empty#([]::E) + NonEmpty#([]::NE), del : [] :: E [] ] :: E ) Clients can use case analysis to determine")
69 newstack : T.( [] E. NE.[ push : T :: E NE [] :: NE, pop : [] :: NE T :: E NE, isempty : [] :: E NE Empty#([]::E) + NonEmpty#([]::NE), del : [] :: E [] ] :: E ) Clients can use case analysis to determine precisely in which state the stack is at, dynamic state test, anchoring values to the abstract stack states. Note:! s omitted from the type for brevity. 32
70 Contributions 1. Reconstruct typestate features from standard type-theoretic programming language primitives. We focus on the following set of typestate features: a) state abstraction, hiding an object representation while expressing the type of the state; b) state dimensions, enabling multiple orthogonal typestates over the same object; c) dynamic state tests, allowing a case analysis over the abstract state. 2. We show how to idiomatically support both state-based (typestate) and transition-based (behavioral types) specifications of abstract state evolution. 33
71 Back to Pair... The evolution of the abstract state can be specified using a state-machine/automaton/protocol. EL initl L L sum * * destroy none ER initr R R 34
72 Back to Pair... The evolution of the abstract state can be specified using a state-machine/automaton/protocol. EL initl L L sum * * destroy none ER initr R R Typestates focus on the states that model the abstracted changes of the mutable state. 35
73 Back to Pair... The evolution of the abstract state can be specified using a state-machine/automaton/protocol. EL initl L L sum * * destroy none ER initr R R Behavioral Types focus on the transitions ( behavior ) keeping the states anonymous. 36
74 Abstracting and Hiding State In our system, the notion of typestates is related to state abstraction, while the notion of behavior is related to hiding state. With typestates, states are named which can be convenient when there are multiple paths through the protocol. With behavioral types, states are implicit which simplifies descriptions of linear usages and makes it easier to provide structural equivalences. Caires and Seco. The type discipline of behavioral separation. POPL
75 Abstracting and Hiding State We have already seen how to model typestates through standard existential abstraction. Interestingly, the notion of behavior can be modeled with what was already shown! However, it requires using an idiom to capture the typestate inside a function effectively hiding it. 38
76 Borrowing and Capturing A typestate can be borrowed by a function if that function requires the typestate as an argument but the function returns the typestate as a result. initl :!( int :: EL [] :: L ) 39
77 Borrowing and Capturing Alternatively, a function may depend on state that was captured from the enclosing linear environment (similar to a closure, but with state). 40
78 Borrowing and Capturing Alternatively, a function may depend on state that was captured from the enclosing linear environment (similar to a closure, but with state). fun( x : int ).(initl x) 40
79 Borrowing and Capturing Alternatively, a function may depend on state that was captured from the enclosing linear environment (similar to a closure, but with state). Γ = initl :!( int :: EL [] :: L ) fun( x : int ).(initl x) 40
80 Borrowing and Capturing Alternatively, a function may depend on state that was captured from the enclosing linear environment (similar to a closure, but with state). Γ = initl :!( int :: EL [] :: L ) Δ = EL fun( x : int ).(initl x) 40
81 Borrowing and Capturing Alternatively, a function may depend on state that was captured from the enclosing linear environment (similar to a closure, but with state). Γ = initl :!( int :: EL [] :: L ) Δ = EL fun( x : int ).(initl x) 40
82 Borrowing and Capturing Alternatively, a function may depend on state that was captured from the enclosing linear environment (similar to a closure, but with state). Γ = initl :!( int :: EL [] :: L ) Δ = EL fun( x : int ).(initl x) Δ =. 40
83 Borrowing and Capturing Alternatively, a function may depend on state that was captured from the enclosing linear environment (similar to a closure, but with state). Γ = initl :!( int :: EL [] :: L ) Δ = EL fun( x : int ).(initl x) Δ =. int [] :: L 40
84 Hiding (Type)state Capturing the typestate enables us to hide the typestate needed by the function s argument. Hiding the typestate from the result is not immediately possible. However, we can define a complete sequence of uses ( behavior ) that ends in a function that destroys the (type)state. One possible linear behavior for the Pair is: initr R R R sum destroy initl none ER EL EL L 41 L
85 Hiding (Type)state Capturing the typestate enables us to hide the typestate needed by the function s argument. Hiding the typestate from the result is not immediately possible. However, we can define a complete sequence of uses ( behavior ) that ends in a function that destroys the (type)state. One possible linear behavior for the Pair is: initr R R R sum destroy initl none ER EL EL L 42 L
86 fun( a : int ). { initr(a), fun( b : int ).! {! initl(b),! fun( _ : [] ).!! { sum(_), fun( _ : [] ).destroy(_) } } } 43
87 fun( a : int ). { initr(a), fun( b : int ).! {! initl(b),! fun( _ : [] ).!! { sum(_), [] [] fun( _ : [] ).destroy(_) } } [] :: L * R [] } 44
88 fun( a : int ). { initr(a), fun( b : int ).! {! initl(b),! fun( _ : [] ).!! { sum(_) [] :: L * R int :: L * R, [] [] fun( _ : [] ).destroy(_) } } [] :: L * R [] } 45
89 fun( a : int ). { initr(a) int :: ER [] :: R, fun( b : int ).! {! initl(b) int :: EL [] :: L,! fun( _ : [] ).!! { sum(_) [] :: L * R int :: L * R, [] [] fun( _ : [] ).destroy(_) } } [] :: L * R [] } 46
90 Δ = EL, ER fun( a : int ). { initr(a) int :: ER [] :: R, fun( b : int ).! {! initl(b) int :: EL [] :: L,! fun( _ : [] ).!! { sum(_) [] :: L * R int :: L * R, [] [] fun( _ : [] ).destroy(_) } } [] :: L * R [] } 46
91 47
92 Clients never see the underlying typestates. They only see the usage requirement ( behavior ). 47
93 Technical Results 48
94 Related Work DeLine and Fähndrich. Typestates for objects. ECOOP DeLine and Fähndrich. Enforcing high-level protocols in low-level software. PLDI Bierhoff and Aldrich. Modular typestate checking of aliased objects. OOPSLA Beckman, Bierhoff, and Aldrich. Verifying correct usage of atomic blocks and typestate. OOPSLA Sunshine, Naden, Stork, Aldrich, and Tanter. First-class state change in Plaid. OOPSLA They support many advanced uses (method dispatch, inheritance, sharing mechanisms, concurrency, etc). We focus on reconstructing a smaller set of typestate features from type-theoretic primitives (separation and linear logic). Which enables combining abstracting and hiding state. 49
95 Related Work Ahmed, Fluet, and Morrisett. L3: A linear language with locations. Fundam. Inform Walker and Morrisett. Alias types for recursive data structures. TIC Smith, Walker, and Morrisett. Alias types. ESOP We extend their work with usability related changes (implicitly threaded capabilities, alternatives, etc). Parkinson and Bierman. Separation logic and abstraction. POPL Abstract predicates can represent a richer domain of abstract state (not limited to a finite number, can be parametric, etc). Typestates encode a simpler notion of abstraction, generally targets a more lightweight verification. Paper includes additional Related Work. 50
96 Summary 1. Encoding typestates using existential types in a substructural type-and-effect system. 2. Support both state-based and transition-based specifications of abstract state evolution. Experimental Prototype Implementation: Future Work: Sharing of resources through disconnected variables. 51
97 Prototype JavaScript-based implementation, runs in browser. 52
98 Summary 1. Encoding typestates using existential types in a substructural type-and-effect system. 2. Support both state-based and transition-based specifications of abstract state evolution. Experimental Prototype Implementation: Future Work: Sharing of resources through disconnected variables. 53
Rely-Guarantee Protocols for Safe Interference over Shared Memory
Rely-Guarantee Protocols for Safe Interference over Shared Memory Thesis Defense Filipe Militão December 15, 2015. Co-advised by Jonathan Aldrich (CMU) and Luís Caires (UNL). Software Defects Our over
Typestate-Oriented Programming
Typestate-Oriented Programming Jonathan Aldrich Joshua Sunshine Darpan Saini Zachary Sparks Object-Oriented Modeling History: Simula 67 was created to facilitate modeling Object-orientation still works
Plural and : Protocols in Practice. Jonathan Aldrich Workshop on Behavioral Types April School of Computer Science
Plural and : Protocols in Practice Jonathan Aldrich Workshop on Behavioral Types April 2011 School of Computer Science Empirical Study: Protocols in Java Object Protocol [Beckman, Kim, & A to appear in
Refinement Types for TypeScript
Refinement Types for TypeScript Panagiotis Vekris Benjamin Cosman Ranjit Jhala University of California, San Diego PLDI 16 Thursday, June 16 Extensible static analyses for modern scripting languages 2
The practice of Mezzo
The practice of Mezzo François Pottier INRIA IHP, April 2014 1 / 83 Acknowledgements Jonathan Protzenko, Thibaut Balabonski, Henri Chataing, Armaël Guéneau, Cyprien Mangin 2 / 83 Overview Two lectures
6.005 Elements of Software Construction Fall 2008
MIT OpenCourseWare http://ocw.mit.edu 6.005 Elements of Software Construction Fall 2008 For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms. 6.005 elements
Mutation. COS 326 David Walker Princeton University
Mutation COS 326 David Walker Princeton University Mutation? 2 Thus far We have considered the (almost) purely functional subset of Ocaml. We ve had a few side effects: printing & raising exceptions. Two
COS 320. Compiling Techniques
Topic 5: Types COS 320 Compiling Techniques Princeton University Spring 2016 Lennart Beringer 1 Types: potential benefits (I) 2 For programmers: help to eliminate common programming mistakes, particularly
Controlling Mutation and Aliases with Fractional Permissions
Controlling Mutation and Aliases with Fractional Permissions John Boyland University of Wisconsin- Milwaukee ECOOP 12 Outline of Session I. Fractional Permissions II. Applications III. Problems I. Fractional
Resource-Based Programming in. Jonathan Aldrich Carnegie Mellon University Fun and Interesting Thoughts Session PLDI June 8, 2010
Jonathan Aldrich Carnegie Mellon University Fun and Interesting Thoughts Session PLDI June 8, 2010 Resources and Composition Resource: stateful object whose use is constrained I/O: files, database connections,
Typestate Checking for Actionscript 3
Typestate Checking for Actionscript 3 Yun-En Liu and Qi Shan December 10, 2010 1 Introduction This project proposes a compile-time check for function calls in a game system written in Actionscript 3, based
An overview of Mezzo
An overview of Mezzo François Pottier INRIA Bertinoro, June 2015 1 / 91 Acknowledgements Jonathan Protzenko, Thibaut Balabonski, Henri Chataing, Armaël Guéneau, Cyprien Mangin 2 / 91 What is Mezzo? An
Rely-Guarantee Protocols
Rely-Guarantee Protocols Filipe Militão 1,2, Jonathan Aldrich 1, and Luís Caires 2 1 Carnegie Mellon University, Pittsburgh, USA 2 Universidade Nova de Lisboa, Lisboa, Portugal {filipe.militao,jonathan.aldrich}@cs.cmu.edu
CS 360 Programming Languages Day 14 Closure Idioms
CS 360 Programming Languages Day 14 Closure Idioms Why lexical scope rocks Last time: currying Today: implementing callbacks and object-oriented programming. Review: mutable state Racket's variables are
Delegation vs Inheritance for Typestate Analysis
Delegation vs Inheritance for Typestate Analysis Du Li, Alex Potanin, 1 and Jonathan Aldrich Carnegie Mellon University and Victoria University of Wellington 1 {duli, aldrich}@cs.cmu.edu, alex@ecs.vuw.ac.nz
Programming Languages (PL)
1 2 3 4 5 6 7 8 9 10 11 Programming Languages (PL) Programming languages are the medium through which programmers precisely describe concepts, formulate algorithms, and reason about solutions. In the course
Type Soundness and Race Freedom for Mezzo
Type Soundness and Race Freedom for Mezzo Thibaut Balabonski François Pottier Jonathan Protzenko INRIA FLOPS 2014 1 / 42 Mezzo in a few words Mezzo is a high-level programming language, equipped with:
Verification of Snapshotable Trees using Access Permissions and Typestate
Verification of Snapshotable Trees using Access Permissions and Typestate Hannes Mehnert 1 and Jonathan Aldrich 2 1 IT University of Copenhagen, 2300 København, Danmark hame@itu.dk 2 School of Computer
Capabilities for Uniqueness and Borrowing
Capabilities for Uniqueness and Borrowing Philipp Haller and Martin Odersky EPFL 24 th European Conference on Object Oriented Programming June 24, 2010 Maribor, Slovenia Motivating Example actor { val
CSE332: Data Abstractions Lecture 23: Programming with Locks and Critical Sections. Tyler Robison Summer 2010
CSE332: Data Abstractions Lecture 23: Programming with Locks and Critical Sections Tyler Robison Summer 2010 1 Concurrency: where are we Done: The semantics of locks Locks in Java Using locks for mutual
Composing Interfering Abstract Protocols
Composing Interfering Abstract Protocols Filipe Militão 1,2, Jonathan Aldrich 1, and Luís Caires 2 1 Carnegie Mellon University, Pittsburgh, USA filipe.militao@cs.cmu.edu, aldrich@cs.cmu.edu 2 Universidade
CIS 120 Midterm II November 16, 2012 SOLUTIONS
CIS 120 Midterm II November 16, 2012 SOLUTIONS 1 1. Java vs. OCaml (22 points) a. In OCaml, the proper way to check whether two string values s and t are structurally equal is: s == t s = t s.equals(t)
Hoare logic. A proof system for separation logic. Introduction. Separation logic
Introduction Hoare logic Lecture 6: Examples in separation logic In the previous lecture, we saw how reasoning about pointers in Hoare logic was problematic, which motivated introducing separation logic.
Grafting Functional Support on Top of an Imperative Language
Grafting Functional Support on Top of an Imperative Language How D 2.0 implements immutability and functional purity Andrei Alexandrescu Grafting Functional Support on Top of an Imperative Language p.
A Type System for Borrowing Permissions
A Type System for Borrowing Permissions Karl Naden Jonathan Aldrich May 2012 CMU-CS-11-142 Robert Bocchino Kevin Bierhoff School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 This
CS152: Programming Languages. Lecture 11 STLC Extensions and Related Topics. Dan Grossman Spring 2011
CS152: Programming Languages Lecture 11 STLC Extensions and Related Topics Dan Grossman Spring 2011 Review e ::= λx. e x e e c v ::= λx. e c τ ::= int τ τ Γ ::= Γ, x : τ (λx. e) v e[v/x] e 1 e 1 e 1 e
Programming Languages Lecture 15: Recursive Types & Subtyping
CSE 230: Winter 2008 Principles of Programming Languages Lecture 15: Recursive Types & Subtyping Ranjit Jhala UC San Diego News? Formalize first-order type systems Simple types (integers and booleans)
Whidbey Enhancements to C# Jeff Vaughan MSBuild Team July 21, 2004
Whidbey Enhancements to C# Jeff Vaughan MSBuild Team July 21, 2004 Outline Practical Partial types Static classes Extern and the namespace alias qualifier Cool (and practical too) Generics Nullable Types
Hoare logic. WHILE p, a language with pointers. Introduction. Syntax of WHILE p. Lecture 5: Introduction to separation logic
Introduction Hoare logic Lecture 5: Introduction to separation logic In the previous lectures, we have considered a language, WHILE, where mutability only concerned program variables. Jean Pichon-Pharabod
Hoare logic. Lecture 5: Introduction to separation logic. Jean Pichon-Pharabod University of Cambridge. CST Part II 2017/18
Hoare logic Lecture 5: Introduction to separation logic Jean Pichon-Pharabod University of Cambridge CST Part II 2017/18 Introduction In the previous lectures, we have considered a language, WHILE, where
CMSC330. Objects, Functional Programming, and lambda calculus
CMSC330 Objects, Functional Programming, and lambda calculus 1 OOP vs. FP Object-oriented programming (OOP) Computation as interactions between objects Objects encapsulate mutable data (state) Accessed
Lectures Basics in Procedural Programming: Machinery
Lectures 3-4-5-6 Basics in Procedural Programming: Machinery February 21-28, 2014 2014-03-01 11:04:07 1/48 Lecture3-6E-2014.pdf (#21) Basics in Procedural Programming: Machinery Naming and Binding Mutable
Closures. Mooly Sagiv. Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming
Closures Mooly Sagiv Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming Summary 1. Predictive Parsing 2. Large Step Operational Semantics (Natural) 3. Small Step Operational Semantics
Weiss Chapter 1 terminology (parenthesized numbers are page numbers)
Weiss Chapter 1 terminology (parenthesized numbers are page numbers) assignment operators In Java, used to alter the value of a variable. These operators include =, +=, -=, *=, and /=. (9) autoincrement
ÆMINIUM, Freeing Programmers from the Shackles of Sequentiality
ÆMINIUM Freeing Programmers from the Shackles of Sequentiality Sven Stork Supervisors: Jonathan Aldrich Paulo Marques Carnegie Mellon University University of Coimbra June 15, 2010 1 / 21 Motivation 2
+ Today. Lecture 26: Concurrency 3/31/14. n Reading. n Objectives. n Announcements. n P&C Section 7. n Race conditions.
+ Lecture 26: Concurrency Slides adapted from Dan Grossman + Today n Reading n P&C Section 7 n Objectives n Race conditions n Announcements n Quiz on Friday 1 + This week s programming assignment n Answer
Programming in Scala Second Edition
Programming in Scala Second Edition Martin Odersky, Lex Spoon, Bill Venners artima ARTIMA PRESS WALNUT CREEK, CALIFORNIA Contents Contents List of Figures List of Tables List of Listings Foreword Foreword
CIS 120 Midterm II November 16, Name (printed): Pennkey (login id):
CIS 120 Midterm II November 16, 2012 Name (printed): Pennkey (login id): My signature below certifies that I have complied with the University of Pennsylvania s Code of Academic Integrity in completing
1. true / false By a compiler we mean a program that translates to code that will run natively on some machine.
1. true / false By a compiler we mean a program that translates to code that will run natively on some machine. 2. true / false ML can be compiled. 3. true / false FORTRAN can reasonably be considered
Safe Runtime Downcasts With Ownership Types
Safe Runtime Downcasts With Ownership Types Chandrasekhar Boyapati, Robert Lee, and Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology 200 Technology Square, Cambridge,
COMPUTER SCIENCE TRIPOS
CST1.2018.4.1 COMPUTER SCIENCE TRIPOS Part IB Monday 4 June 2018 1.30 to 4.30 COMPUTER SCIENCE Paper 4 Answer five questions: up to four questions from Section A, and at least one question from Section
Checking Concurrent Typestate with Access Permissions in Plural: A Retrospective
Checking Concurrent Typestate with Access Permissions in Plural: A Retrospective Kevin Bierhoff, Nels E. Beckman, and Jonathan Aldrich Abstract Objects often define usage protocols that clients must follow
TRELLYS and Beyond: Type Systems for Advanced Functional Programming
TRELLYS and Beyond: Type Systems for Advanced Functional Programming Aaron Stump Computer Science The University of Iowa Joint work with Tim Sheard, Vilhelm Sjöberg, and Stephanie Weirich. Supported by
Programming Languages. Function-Closure Idioms. Adapted from Dan Grossman's PL class, U. of Washington
Programming Languages Function-Closure Idioms Adapted from Dan Grossman's PL class, U. of Washington More idioms We know the rule for lexical scope and function closures Now what is it good for A partial
CSE 413 Languages & Implementation. Hal Perkins Winter 2019 Structs, Implementing Languages (credits: Dan Grossman, CSE 341)
CSE 413 Languages & Implementation Hal Perkins Winter 2019 Structs, Implementing Languages (credits: Dan Grossman, CSE 341) 1 Goals Representing programs as data Racket structs as a better way to represent
Weeks 6&7: Procedures and Parameter Passing
CS320 Principles of Programming Languages Weeks 6&7: Procedures and Parameter Passing Jingke Li Portland State University Fall 2017 PSU CS320 Fall 17 Weeks 6&7: Procedures and Parameter Passing 1 / 45
Project Compiler. CS031 TA Help Session November 28, 2011
Project Compiler CS031 TA Help Session November 28, 2011 Motivation Generally, it s easier to program in higher-level languages than in assembly. Our goal is to automate the conversion from a higher-level
Consistent Subtyping for All
Consistent Subtyping for All Ningning Xie Xuan Bi Bruno C. d. S. Oliveira 11 May, 2018 The University of Hong Kong 1 Background There has been ongoing debate about which language paradigm, static typing
Programming language design and analysis
Programming language design and analysis Introduction Marius Minea 25 September 2017 Why this course? Programming languages are fundamental and one of the oldest CS fields Language design is an important
Chapter 6 Introduction to Defining Classes
Introduction to Defining Classes Fundamentals of Java: AP Computer Science Essentials, 4th Edition 1 Objectives Design and implement a simple class from user requirements. Organize a program in terms of
Permissions to Specify the Composite Design Pattern
Permissions to Specify the Composite Design Pattern Kevin Bierhoff Jonathan Aldrich Institute for Software Research, Carnegie Mellon University 5000 Forbes Avenue, Pittsburgh, PA 15213, USA {kevin.bierhoff,jonathan.aldrich
Programming Languages and Techniques (CIS120)
Programming Languages and Techniques (CIS120) Lecture 26 March 23, 2016 Inheritance and Dynamic Dispatch Chapter 24 Inheritance Example public class { private int x; public () { x = 0; } public void incby(int
Review. CS152: Programming Languages. Lecture 11 STLC Extensions and Related Topics. Let bindings (CBV) Adding Stuff. Booleans and Conditionals
Review CS152: Programming Languages Lecture 11 STLC Extensions and Related Topics e ::= λx. e x ee c v ::= λx. e c (λx. e) v e[v/x] e 1 e 2 e 1 e 2 τ ::= int τ τ Γ ::= Γ,x : τ e 2 e 2 ve 2 ve 2 e[e /x]:
Cpt S 122 Data Structures. Course Review FINAL. Nirmalya Roy School of Electrical Engineering and Computer Science Washington State University
Cpt S 122 Data Structures Course Review FINAL Nirmalya Roy School of Electrical Engineering and Computer Science Washington State University Final When: Wednesday (12/12) 1:00 pm -3:00 pm Where: In Class
CSE413: Programming Languages and Implementation Racket structs Implementing languages with interpreters Implementing closures
CSE413: Programming Languages and Implementation Racket structs Implementing languages with interpreters Implementing closures Dan Grossman Fall 2014 Hi! I m not Hal J I love this stuff and have taught
September 10,
September 10, 2013 1 Bjarne Stroustrup, AT&T Bell Labs, early 80s cfront original C++ to C translator Difficult to debug Potentially inefficient Many native compilers exist today C++ is mostly upward compatible
Type Hierarchy. Comp-303 : Programming Techniques Lecture 9. Alexandre Denault Computer Science McGill University Winter 2004
Type Hierarchy Comp-303 : Programming Techniques Lecture 9 Alexandre Denault Computer Science McGill University Winter 2004 February 16, 2004 Lecture 9 Comp 303 : Programming Techniques Page 1 Last lecture...
Homework 6. Reading. Problems. Handout 7 CS242: Autumn November
Homework 6 Due 14 November, 5PM Handout 7 CS242: Autumn 2012 7 November Reading 1. Chapter 10, section 10.2.3 2. Chapter 11, sections 11.3.2, and 11.7 3. Chapter 12, section 12.4 4. Chapter 13, section
Software Verification for Java 5
Software Verification for Java 5 KeY Symposium 2007 Mattias Ulbrich June 14, 2007 Content KeY + Java 5 Typesafe Enumeration Datatypes Enhanced For Loops Generic Classes 1. Keep pace with the progress of
CSCI-GA Scripting Languages
CSCI-GA.3033.003 Scripting Languages 12/02/2013 OCaml 1 Acknowledgement The material on these slides is based on notes provided by Dexter Kozen. 2 About OCaml A functional programming language All computation
Lecture 6. COMP1006/1406 (the OOP course) Summer M. Jason Hinek Carleton University
Lecture 6 COMP1006/1406 (the OOP course) Summer 2014 M. Jason Hinek Carleton University today s agenda assignments A1,A2,A3 are all marked A4 marking just started A5 is due Friday, A6 is due Monday a quick
Concepts of Object Oriented Programming
Concepts of Object Oriented Programming Dr. Axel Kohlmeyer Senior Scientific Computing Expert Information and Telecommunication Section The Abdus Salam International Centre for Theoretical Physics http://sites.google.com/site/akohlmey/
Type Checking and Type Inference
Type Checking and Type Inference Principles of Programming Languages CSE 307 1 Types in Programming Languages 2 Static Type Checking 3 Polymorphic Type Inference Version: 1.8 17:20:56 2014/08/25 Compiled
Outline. Example stack Version 1 -- int stack with fixed array Version 2 -- int stack with flexible array Version 3 -- with interface
Outline Example stack Version 1 -- int stack with fixed array Version 2 -- int stack with flexible array Version 3 -- with interface Visibility issues 6 :: 2 0024 Spring 2010 Stacks push(value) -- store
Modular Typestate Checking of Aliased Objects
Modular Typestate Checking of Aliased Objects Kevin Bierhoff Jonathan Aldrich Institute for Software Research, School of Computer Science Carnegie Mellon University, 5000 Forbes Avenue, Pittsburgh, PA
Reminder of the last lecture. Aliasing Issues: Call by reference, Pointer programs. Introducing Aliasing Issues. Home Work from previous lecture
Reminder of the last lecture Aliasing Issues: Call by reference, Pointer programs Claude Marché Cours MPRI 2-36-1 Preuve de Programme 18 janvier 2017 Additional features of the specification language Abstract
Index. object lifetimes, and ownership, use after change by an alias errors, use after drop errors, BTreeMap, 309
A Arithmetic operation floating-point arithmetic, 11 12 integer numbers, 9 11 Arrays, 97 copying, 59 60 creation, 48 elements, 48 empty arrays and vectors, 57 58 executable program, 49 expressions, 48
Assignment 4: Semantics
Assignment 4: Semantics 15-411: Compiler Design Jan Hoffmann Jonathan Burns, DeeDee Han, Anatol Liu, Alice Rao Due Thursday, November 3, 2016 (9:00am) Reminder: Assignments are individual assignments,
Functional Programming in Java. CSE 219 Department of Computer Science, Stony Brook University
Functional Programming in Java CSE 219, Stony Brook University What is functional programming? There is no single precise definition of functional programming (FP) We should think of it as a programming
Typing Data. Chapter Recursive Types Declaring Recursive Types
Chapter 27 Typing Data 27.1 Recursive Types 27.1.1 Declaring Recursive Types We saw in the previous lecture how rec was necessary to write recursive programs. But what about defining recursive types? Recursive
Announcements. Scope, Function Calls and Storage Management. Block Structured Languages. Topics. Examples. Simplified Machine Model.
CS 242 2007 Scope, Function Calls and Storage Management John Mitchell Announcements Homework Returned in class Wed; afterwards in 4 th Floor Gates Cabinet SCPD students: attach routing slip, will be returned
Uniqueness and Reference Immutability for Safe Parallelism
Uniqueness and Reference Immutability for Safe Parallelism Colin Gordon (UW), Matt Parkinson (MSR), Jared Parsons (MS), Aleks Bromfield (MS), Joe Duffy (MS) OOPSLA 2012 A Prototype Extension to C# Extend
NOTE: Answer ANY FOUR of the following 6 sections:
A-PDF MERGER DEMO Philadelphia University Lecturer: Dr. Nadia Y. Yousif Coordinator: Dr. Nadia Y. Yousif Internal Examiner: Dr. Raad Fadhel Examination Paper... Programming Languages Paradigms (750321)
Type structure is a syntactic discipline for maintaining levels of abstraction John Reynolds, Types, Abstraction and Parametric Polymorphism
Chapter 6 Abstraction Type structure is a syntactic discipline for maintaining levels of abstraction John Reynolds, Types, Abstraction and Parametric Polymorphism Abstraction, also known as information
Introduction to Visual Basic and Visual C++ Introduction to Java. JDK Editions. Overview. Lesson 13. Overview
Introduction to Visual Basic and Visual C++ Introduction to Java Lesson 13 Overview I154-1-A A @ Peter Lo 2010 1 I154-1-A A @ Peter Lo 2010 2 Overview JDK Editions Before you can write and run the simple
Thanks! Review. Course Goals. General Themes in this Course. There are many programming languages. Teaching Assistants. John Mitchell.
1 CS 242 Thanks! Review John Mitchell Final Exam Wednesday Dec 8 8:30 11:30 AM Gates B01, B03 Teaching Assistants Mike Cammarano TJ Giuli Hendra Tjahayadi Graders Andrew Adams Kenny Lau Vishal Patel and
CS 565: Programming Languages. Spring 2008 Tu, Th: 16:30-17:45 Room LWSN 1106
CS 565: Programming Languages Spring 2008 Tu, Th: 16:30-17:45 Room LWSN 1106 Administrivia Who am I? Course web page http://www.cs.purdue.edu/homes/peugster/cs565spring08/ Office hours By appointment Main
A Java Execution Simulator
A Java Execution Simulator Steven Robbins Department of Computer Science University of Texas at San Antonio srobbins@cs.utsa.edu ABSTRACT This paper describes JES, a Java Execution Simulator that allows
CS 11 C track: lecture 6
CS 11 C track: lecture 6 Last week: pointer arithmetic This week: The gdb program struct typedef linked lists gdb for debugging (1) gdb: the Gnu DeBugger http://courses.cms.caltech.edu/cs11/material /c/mike/misc/gdb.html
Modular Reasoning about Aliasing using Permissions
Modular Reasoning about Aliasing using Permissions John Boyland University of Wisconsin- Milwaukee FOAL 2015 Summary Permissions are non-duplicable tokens that give access to state. Permissions give effective
CMSC 331 Final Exam Section 0201 December 18, 2000
CMSC 331 Final Exam Section 0201 December 18, 2000 Name: Student ID#: You will have two hours to complete this closed book exam. We reserve the right to assign partial credit, and to deduct points for
Recitation 6: System F and Existential Types : Foundations of Programming Languages
Recitation 6: System F and Existential Types 15-312: Foundations of Programming Languages Serena Wang, Charles Yuan February 21, 2018 We saw how to use inductive and coinductive types last recitation.
Closures. Mooly Sagiv. Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming
Closures Mooly Sagiv Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming t ::= x x. t t t Call-by-value big-step Operational Semantics terms variable v ::= values abstraction x.
CS-XXX: Graduate Programming Languages. Lecture 22 Class-Based Object-Oriented Programming. Dan Grossman 2012
CS-XXX: Graduate Programming Languages Lecture 22 Class-Based Object-Oriented Programming Dan Grossman 2012 PL Issues for OOP? OOP lets you: 1. Build some extensible software concisely 2. Exploit an intuitive
Programming Language Concepts, CS2104 Lecture 7
Reminder of Last Lecture Programming Language Concepts, CS2104 Lecture 7 Tupled Recursion Exceptions Types, ADT, Haskell, Components 5th Oct 2007 CS2104, Lecture 7 1 Overview 5th Oct 2007 CS2104, Lecture
Advances in Programming Languages
Advances in Programming Languages Lecture 18: Concurrency and More in Rust Ian Stark School of Informatics The University of Edinburgh Friday 24 November 2016 Semester 1 Week 10 https://blog.inf.ed.ac.uk/apl16
COMP 2355 Introduction to Systems Programming
COMP 2355 Introduction to Systems Programming Christian Grothoff christian@grothoff.org http://grothoff.org/christian/ 1 Today Class syntax, Constructors, Destructors Static methods Inheritance, Abstract
Recitation 8: Dynamic and Unityped Languages : Foundations of Programming Languages
Recitation 8: Dynamic and Unityped Languages 15-312: Foundations of Programming Languages Jeanne Luning Prak, Charles Yuan March 7, 2018 1 Untyped Languages In this recitation, we explore two languages:
Aaron Turon! Mozilla Research
Aaron Turon Mozilla Research C/C++ ML/Haskell Rust Safe systems programming Why Mozilla? Browsers need control. Browsers need safety. Servo: Next-generation browser built in Rust. C++ What is control?
[Course Overview] After completing this module you are ready to: Develop Desktop applications, Networking & Multi-threaded programs in java.
![[Course Overview] After completing this module you are ready to: Develop Desktop applications, Networking & Multi-threaded programs in java.](/thumbs/73/69451257.jpg "[Course Overview] After completing this module you are ready to: Develop Desktop applications, Networking & Multi-threaded programs in java.")
[Course Overview] The Core Java technologies and application programming interfaces (APIs) are the foundation of the Java Platform, Standard Edition (Java SE). They are used in all classes of Java programming,
A Sophomoric Introduction to Shared-Memory Parallelism and Concurrency Lecture 5 Programming with Locks and Critical Sections
A Sophomoric Introduction to Shared-Memory Parallelism and Concurrency Lecture 5 Programming with Locks and Critical Sections Dan Grossman Last Updated: May 2012 For more information, see http://www.cs.washington.edu/homes/djg/teachingmaterials/
Implementing Symmetric Multiprocessing in LispWorks
Implementing Symmetric Multiprocessing in LispWorks Making a multithreaded application more multithreaded Martin Simmons, LispWorks Ltd Copyright 2009 LispWorks Ltd Outline Introduction Changes in LispWorks
Lambda Calculi With Polymorphism
Resources: The slides of this lecture were derived from [Järvi], with permission of the original author, by copy & x = 1 let x = 1 in... paste or by selection, annotation, or rewording. [Järvi] is in turn
Topics Covered Thus Far. CMSC 330: Organization of Programming Languages. Language Features Covered Thus Far. Programming Languages Revisited
CMSC 330: Organization of Programming Languages Type Systems, Names & Binding Topics Covered Thus Far Programming languages Syntax specification Regular expressions Context free grammars Implementation
OCaml Language Choices CMSC 330: Organization of Programming Languages
OCaml Language Choices CMSC 330: Organization of Programming Languages! Implicit or explicit declarations?! Explicit variables must be introduced with let before use! But you don t need to specify types
Don t Believe the Hype. CS152: Programming Languages. Lecture 21 Object-Oriented Programming. Class-based OOP. So what is OOP?
Don t Believe the Hype CS152: Programming Languages Lecture 21 Object-Oriented Programming Dan Grossman Spring 2011 OOP lets you: 1. Build some extensible software concisely 2. Exploit an intuitive analogy
Object Ownership in Program Verification
Object Ownership in Program Verification Werner Dietl 1 and Peter Müller 2 1 University of Washington wmdietl@cs.washington.edu 2 ETH Zurich peter.mueller@inf.ethz.ch Abstract. Dealing with aliasing is
Instantiation of Template class
Class Templates Templates are like advanced macros. They are useful for building new classes that depend on already existing user defined classes or built-in types. Example: stack of int or stack of double
Practical Affine Types and Typestate-Oriented Programming
Practical Affine Types and Typestate-Oriented Programming Philipp Haller KTH Royal Institute of Technology Stockholm, Sweden Dagstuhl Seminar 17051 Theory and Applications of Behavioural Types Schloss
Introduction to Programming Using Java (98-388)
Introduction to Programming Using Java (98-388) Understand Java fundamentals Describe the use of main in a Java application Signature of main, why it is static; how to consume an instance of your own class;