Designing Precise Pushdown Higher-Order Flow Analyses
|
|
|
- Noel Lyons
- 6 years ago
- Views:
Transcription
1 Designing Precise Pushdown Higher-Order Flow Analyses J. Ian Johnson, David Van Horn and Olin Shivers Northeastern University Boston, MA, USA 1
2 Flow analysis is indispensible 2
3 Flow analysis is indispensible Every language should have one 3
4 Analysis is great Compiler optimizations 4
5 Analysis is great Compiler optimizations Type reconstruction 5
6 Analysis is great Compiler optimizations Type reconstruction Deadlock detection 6
7 Analysis is great Compiler optimizations Type reconstruction Deadlock detection Data race detection 7
8 Analysis is great Compiler optimizations Type reconstruction Deadlock detection Data race detection Code quality enforcement 8
9 Analysis is great Compiler optimizations Type reconstruction Deadlock detection Data race detection Code quality enforcement Hundreds more 9
10 Analysis is terrible Annoying false positives 10
11 Analysis is terrible Annoying false positives Takes too long 11
12 Analysis is terrible Annoying false positives Takes too long Hard to implement 12
13 Analysis is terrible Annoying false positives Takes too long Hard to implement Hard to show correct 13
14 Analysis is terrible Annoying false positives Takes too long Hard to implement Hard to show correct The good ones inherently first-order 14
15 Analysis is terrible Annoying false positives Takes too long Hard to implement Hard to show correct The good ones inherently first-order We can fix this 15
16 Analysis is terrible Annoying false positives Takes too long Hard to implement Hard to show correct The good ones inherently first-order We can fix this First some history 16
17 Flow Graphs vs. Programs Higher-order First-order (Hecht 77) CFG + lattice 17
18 Flow Graphs vs. Programs Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Hecht 77) CFG + lattice (Sharir & Pnueli 81) CFG + lattice + summaries 18
19 Flow Graphs vs. Programs Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Shivers 91) CPS + set constraints (Hecht 77) CFG + lattice (Sharir & Pnueli 81) CFG + lattice + summaries (Reps 95) PDS + idempotent semiring 19
20 Flow Graphs vs. Programs Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Hecht 77) CFG + lattice (Shivers 91) CPS + set constraints (Might 07) CPS + abstract small step semantics (Sharir & Pnueli 81) CFG + lattice + summaries (Reps 95) PDS + idempotent semiring 20
21 Flow Graphs vs. Programs Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Hecht 77) CFG + lattice (Sharir & Pnueli 81) CFG + lattice + summaries (Shivers 91) CPS + set constraints (Might 07) CPS + abstract small step semantics (Might & Van Horn 10) Derived from concrete (Reps 95) PDS + idempotent semiring 21
22 Flow Graphs vs. Programs Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Hecht 77) CFG + lattice (Sharir & Pnueli 81) CFG + lattice + summaries (Reps 95) PDS + idempotent semiring (Shivers 91) CPS + set constraints (Might 07) CPS + abstract small step semantics (Might & Van Horn 10) Derived from concrete (Vardoulakis & Shivers 10) CPS + summaries (Earl et al. 10) ANF + Dyck state graph 22
23 Flow Graphs vs. Programs Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Hecht 77) CFG + lattice (Sharir & Pnueli 81) CFG + lattice + summaries (Reps 95) PDS + idempotent semiring (Shivers 91) CPS + set constraints (Might 07) CPS + abstract small step semantics (Might & Van Horn 10) Derived from concrete (Vardoulakis & Shivers 10) CPS + summaries (Earl et al. 10) ANF + Dyck state graph Graphs are a bad abstraction 23
24 Flow Graphs vs. Programs Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Hecht 77) CFG + lattice (Sharir & Pnueli 81) CFG + lattice + summaries (Reps 95) PDS + idempotent semiring (Shivers 91) CPS + set constraints (Might 07) CPS + abstract small step semantics (Might & Van Horn 10) Derived from concrete (Vardoulakis & Shivers 10) CPS + summaries (Earl et al. 10) ANF + Dyck state graph Graphs are a bad abstraction 24
25 Flow Graphs vs. Programs Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Hecht 77) CFG + lattice (Sharir & Pnueli 81) CFG + lattice + summaries (Reps 95) PDS + idempotent semiring (Shivers 91) CPS + set constraints (Might 07) CPS + abstract small step semantics (Might & Van Horn 10) Derived from concrete (Vardoulakis & Shivers 10) CPS + summaries (Earl et al. 10) ANF + Dyck state graph 25
26 Flow Graphs vs. Programs Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Hecht 77) CFG + lattice (Sharir & Pnueli 81) CFG + lattice + summaries (Reps 95) PDS + idempotent semiring (Shivers 91) CPS + set constraints (Might 07) CPS + abstract small step semantics (Might & Van Horn 10) Derived from concrete (Vardoulakis & Shivers 10) CPS + summaries (Earl et al. 10) ANF + Dyck state graph? 26
27 Analyses are derivable [Might & Van Horn 2010] Start: concrete machine semantics 27
28 Analyses are derivable [Might & Van Horn 2010] Start: concrete machine semantics Simple transforms: put semantics in right form 28
29 Analyses are derivable [Might & Van Horn 2010] Start: concrete machine semantics Simple transforms: put semantics in right form Analysis: pointwise-abstraction 29
30 Functions Without Stack (define (sqr x) (* x x)) (sqrt (+ (sqr y) (sqr z))) 30
31 Functions Without Stack (define (sqr x) (* x x)) (sqrt (+ (sqr y) (sqr z))) 31
32 Functions Without Stack (define (sqr x) (* x x)) (sqrt (+ (sqr y) (sqr z))) 0CFA: Not even terminating! 32
33 Pushdown Higher-Order Flow Analysis 33
34 Pushdown Higher-Order Flow Analysis 34
35 Pushdown Higher-Order Flow Analysis 35
36 Pushdown Higher-Order Flow Analysis 36
37 Pushdown Higher-Order Flow Analysis 37
38 Pushdown Higher-Order Flow Analysis 38
39 Pushdown Higher-Order Flow Analysis 39
40 Pushdown Higher-Order Flow Analysis 40
41 Pushdown Higher-Order Flow Analysis 41
42 Analysis is terrible salvagable Annoying false positives Takes too long Hard to implement Hard to show correct The good ones inherently first-order 42
43 Deriving Pushdown Analyses Start: Concrete machine semantics 43
44 Deriving Pushdown Analyses Start: Concrete machine semantics Simple transform: memoize functions 44
45 Deriving Pushdown Analyses Start: Concrete machine semantics Simple transform: memoize functions Simple transform: store functions calling contexts 45
46 Deriving Pushdown Analyses Start: Concrete machine semantics Simple transform: memoize functions Simple transform: store functions calling contexts Simple transform: heap-allocate data 46
47 Deriving Pushdown Analyses Start: Concrete machine semantics Simple transform: memoize functions Simple transform: store functions calling contexts Simple transform: heap-allocate data Analysis: pointwise-abstraction 47
48 Deriving Pushdown Analyses Start: Concrete machine semantics Simple transform: memoize functions Simple transform: store functions calling contexts Simple transform: heap-allocate data Analysis: pointwise-abstraction Gives semantic account of summaries 48
49 Analysis is terrible salvagable Annoying false positives Takes too long Hard to implement Hard to show correct The good ones inherently first-order 49
50 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo Environment: id... app... Contexts 50
51 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo Environment: id... f id y 1 Contexts app id 1 (let* (... [n1 ]...)...) 51
52 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo Environment: x 1 Contexts app id 1 (let* (... [n1 ]...)...) id 1 (let* (... [app (λ (f y) )]...)...) 52
53 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id 1 1 Environment: Contexts app id 1 (let* (... [n1 ]...)...) id 1 (let* (... [app (λ (f y) )]...)...) 53
54 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id 1 1 app id 1 1 Environment: Contexts app id 1 (let* (... [n1 ]...)...) id 1 (let* (... [app (λ (f y) )]...)...) 54
55 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id 1 1 app id 1 1 Environment: id... app... n1 1 Contexts app id 1 (let* (... [n1 ]...)...) id 1 (let* (... [app (λ (f y) )]...)...) 55
56 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id 1 1 app id 1 1 Environment: id... f id y 2 Contexts app id 1 (let* (... [n1 ]...)...) id 1 (let* (... [app (λ (f y) )]...)...) app id 2 (let* (... [n2 ])...) 56
57 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id 1 1 app id 1 1 Environment: x 2 Contexts app id 1 (let* (... [n1 ]...)...) id 1 (let* (... [app (λ (f y) )]...)...) app id 2 (let* (... [n2 ])...) id 2 (let* (... [app (λ (f y) )]...)...) 57
58 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id 1 1 app id 1 1 id 2 2 Environment: Contexts app id 1 (let* (... [n1 ]...)...) id 1 (let* (... [app (λ (f y) )]...)...) app id 2 (let* (... [n2 ])...) id 2 (let* (... [app (λ (f y) )]...)...) 58
59 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id 1 1 app id 1 1 id 2 2 app id 2 2 Environment: Contexts app id 1 (let* (... [n1 ]...)...) id 1 (let* (... [app (λ (f y) )]...)...) app id 2 (let* (... [n2 ])...) id 2 (let* (... [app (λ (f y) )]...)...) 59
60 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id 1 1 app id 1 1 id 2 2 app id 2 2 Environment: id... app... n1 1 n2 2 Contexts app id 1 (let* (... [n1 ]...)...) id 1 (let* (... [app (λ (f y) )]...)...) app id 2 (let* (... [n2 ])...) id 2 (let* (... [app (λ (f y) )]...)...) 60
61 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo Store: σ₀ Start Store: σ₀ Contexts 61
62 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo Store: σ₁ f id y 1 Start Store: σ₁ Contexts app σ₁ ((let* (... [n1 ]...)...) σ₀) 62
63 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo Store: σ₂ f id y 1 x 1 Start Store: σ₂ Contexts app σ₁ id σ₂ ((let* (... [n1 ]...)...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₁) 63
64 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id σ₂ (1 σ₂) Store: σ₂ f id y 1 x 1 Start Store: σ₂ Contexts app σ₁ id σ₂ ((let* (... [n1 ]...)...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₁) 64
65 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id σ₂ app σ₁ (1 σ₂) (1 σ₂) Store: σ₂ f id y 1 x 1 Start Store: σ₁ Contexts app σ₁ id σ₂ ((let* (... [n1 ]...)...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₁) 65
66 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id σ₂ app σ₁ (1 σ₂) (1 σ₂) Store: σ₃ f id y 1 x 1 n1 1 Start Store: σ₀ Contexts app σ₁ id σ₂ ((let* (... [n1 ]...)...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₁) 66
67 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id σ₂ app σ₁ (1 σ₂) (1 σ₂) Store: σ₄ f id y (1 2) x 1 n1 1 Start Store: σ₄ Contexts app σ₁ id σ₂ app σ₄ ((let* (... [n1 ]...)...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₁) ((let* (... [n2 ])...) σ₀) 67
68 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id σ₂ app σ₁ (1 σ₂) (1 σ₂) Store: σ₅ f id y (1 2) x (1 2) n1 1 Start Store: σ₅ Contexts app σ₁ id σ₂ app σ₄ id σ₅ ((let* (... [n1 ]...)...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₁) ((let* (... [n2 ])...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₄) 68
69 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id σ₂ app σ₁ id σ₅ (1 σ₂) (1 σ₂) (2 σ₅) Store: σ₅ f id y (1 2) x (1 2) n1 1 Start Store: σ₅ Contexts app σ₁ id σ₂ app σ₄ id σ₅ ((let* (... [n1 ]...)...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₁) ((let* (... [n2 ])...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₄) 69
70 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id σ₂ app σ₁ id σ₅ app σ₄ (1 σ₂) (1 σ₂) (2 σ₅) (2 σ₅) Store: σ₅ f id y (1 2) x (1 2) n1 1 Start Store: σ₄ Contexts app σ₁ id σ₂ app σ₄ id σ₅ ((let* (... [n1 ]...)...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₁) ((let* (... [n2 ])...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₄) 70
71 (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id σ₂ app σ₁ id σ₅ app σ₄ (1 σ₂) (1 σ₂) (2 σ₅) (2 σ₅) Store: σ₆ f id y (1 2) x (1 2) n1 1 n2 (1 2) Start Store: σ₀ Contexts app σ₁ id σ₂ app σ₄ id σ₅ ((let* (... [n1 ]...)...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₁) ((let* (... [n2 ])...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₄) 71
72 Heaps are imprecise (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id σ₂ app σ₁ id σ₅ app σ₄ (1 σ₂) (1 σ₂) (2 σ₅) (2 σ₅) Store: σ₆ f id y (1 2) x (1 2) n1 1 n2 (1 2) Start Store: σ₀ Contexts app σ₁ id σ₂ app σ₄ id σ₅ ((let* (... [n1 ]...)...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₁) ((let* (... [n2 ])...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₄) 72
73 Fixed [Vardoulakis & Shivers 10] Local storage (stack frames) 73
74 (define (foldr f b lst) (letrec ([loop (λ (lst) (cond [(empty? lst) b] [else (cons (f (car lst)) (loop (cdr lst)))]))]) (loop lst))) 74
75 (define (foldr f b lst) (letrec ([loop (λ (lst) (cond [(empty? lst) b] [else (cons (f (car lst)) (loop (cdr lst)))]))]) (loop lst))) 75
76 (define (foldr f b lst) (letrec ([loop (λ (lst) (cond [(empty? lst) b] [else (cons (f (car lst)) (loop (cdr lst)))]))]) (loop lst))) 76
77 Fixed Instrument your escape analysis 77
78 Escape Analysis Which addresses outlive their creator s context? 78
79 Escape Analysis Which addresses outlive their creator s context? We introduce three components: Escaped addresses E Addresses owned by current function O The random access stack Ξ 79
80 Escape Analysis Which addresses outlive their creator s context? We introduce three components: Escaped addresses E Addresses owned by current function O The random access stack Ξ Lookup is now defined with L(a,σ,Ξ,E) = a E σ(a), Ξ(a) 80
81 (x, ρ),σ,ξ,κ v,σ,ξ,κ where v L(ρ(x), σ, Ξ, E) 81
82 (x, ρ),σ,ξ,κ v,σ,ξ,κ where v L(ρ(x), σ, Ξ, E) v,σ,ξ,fn((λ x.e, ρ),κ) c,σnext,ξ[a v],[] c where c = (e, ρ[x a]) σnext = σ[a v] E' = E R(T(c), σnext) 82
83 (x, ρ),σ,ξ,κ v,σ,ξ,κ where v L(ρ(x), σ, Ξ, E) v,σ,ξ,fn((λ x.e, ρ),κ) c,σnext,ξ[a v],[] c where c = (e, ρ[x a]) σnext = σ[a v] E' = E R(T(c), σnext) O ' = {a} 83
84 (x, ρ),σ,ξ,κ v,σ,ξ,κ where v L(ρ(x), σ, Ξ, E) v,σ,ξ,fn((λ x.e, ρ),κ) c,σnext,ξ[a v],[] c where c = (e, ρ[x a]) σnext = σ[a v] E' = E R(T(c), σnext) O ' = {a} L' = L [(c, σnext) (κ, σcur, Ξ, E, O)] 84
85 v,σ,ξ,[] c v,σ,ξ',κ if (κ, σnext, Ξ', E', O) ' L(c, σcur) M' = M[(c, σcur) (v, σ)] E'' = E' ((E O) R(T(v),σ)) 85
86 Analysis is terrible salvagable Annoying false positives Takes too long Hard to implement Hard to show correct The good ones inherently first-order 86
87 We're not done yet 87
88 Too context-sensitive (let* ([id (λ (x) x)] [app (λ (f y) (f y))] [n1 (app id 1)] [n2 (app id 2)]) (+ n1 n2)) Memo id σ₂ app σ₁ id σ₅ app σ₄ (1 σ₂) (1 σ₂) (2 σ₅) (2 σ₅) Store: σ₆ f id y (1 2) x (1 2) n1 1 n2 (1 2) Start Store: σ₀ Contexts app σ₁ id σ₂ app σ₄ id σ₅ ((let* (... [n1 ]...)...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₁) ((let* (... [n2 ])...) σ₀) ((let* (... [app (λ (f y) )]...)...) σ₄) 88
89 First-Order Influence Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Hecht 77) CFG + lattice (Sharir & Pnueli 81) CFG + lattice + summaries (Reps 95) PDS + idempotent semiring (Shivers 91) CPS + set constraints (Might 07) CPS + abstract small step semantics (Might & Van Horn 10) Derived from concrete (Vardoulakis & Shivers 10) CPS + summaries (Earl et al. 10) ANF + Dyck state graph Today's talk? 89
90 First-Order Influence Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Hecht 77) CFG + lattice (Sharir & Pnueli 81) CFG + lattice + summaries (Reps 95) PDS + idempotent semiring (Oh et al. 12) CFG + lattice + bypassing (Shivers 91) CPS + set constraints (Might 07) CPS + abstract small step semantics (Might & Van Horn 10) Derived from concrete (Vardoulakis & Shivers 10) CPS + summaries (Earl et al. 10) ANF + Dyck state graph Today's talk? 90
91 Higher-order (Jones & Muchnick 82) Program + set constraints First-order (Hecht 77) CFG + lattice (Sharir & Pnueli 81) CFG + lattice + summaries (Reps 95) PDS + idempotent semiring (Oh et al. 12) CFG + lattice + bypassing (Shivers 91) CPS + set constraints (Might 07) CPS + abstract small step semantics (Might & Van Horn 10) Derived from concrete (Vardoulakis & Shivers 10) CPS + summaries (Earl et al. 10) ANF + Dyck state graph Today's talk? 91
92 To Conclude Design: Model abstract mechanisms concretely 92
93 To Conclude Design: Model abstract mechanisms concretely Pushdown: Memo and local continuation tables 93
94 To Conclude Design: Model abstract mechanisms concretely Pushdown: Memo and local continuation tables Precise analyses: Stack allocation precision 94
95 To Conclude Design: Model abstract mechanisms concretely Pushdown: Memo and local continuation tables Precise analyses: Stack allocation precision (Not shown) works for control operators / GC 95
96 To Conclude Design: Model abstract mechanisms concretely Pushdown: Memo and local continuation tables Precise analyses: Stack allocation precision (Not shown) works for control operators / GC Future work: sparse analysis via time travel 96
97 To Conclude Design: Model abstract mechanisms concretely Pushdown: Memo and local continuation tables Precise analyses: Stack allocation precision (Not shown) works for control operators / GC Future work: sparse analysis via time travel Thank you 97
Concrete Semantics for Pushdown Analysis: The Essence of Summarization
Concrete Semantics for Pushdown Analysis: The Essence of Summarization J. Ian Johnson and David Van Horn Northeastern University {ianj,dvanhorn}@ccs.neu.edu Abstract. Pushdown analysis is better than finite-state
Extensible Pattern Matching
Extensible Pattern Matching Sam Tobin-Hochstadt PLT @ Northeastern University IFL, September 3, 2010 Extensible Pattern Matching in an Extensible Language Sam Tobin-Hochstadt PLT @ Northeastern University
Abstracting Definitional Interpreters
Abstracting Definitional Interpreters David Darais University of Maryland Nicholas Labich University of Maryland Phúc C. Nguyễn University of Maryland David Van Horn University of Maryland Does my program
COP4020 Programming Languages. Functional Programming Prof. Robert van Engelen
COP4020 Programming Languages Functional Programming Prof. Robert van Engelen Overview What is functional programming? Historical origins of functional programming Functional programming today Concepts
Computer Science 21b (Spring Term, 2015) Structure and Interpretation of Computer Programs. Lexical addressing
Computer Science 21b (Spring Term, 2015) Structure and Interpretation of Computer Programs Lexical addressing The difference between a interpreter and a compiler is really two points on a spectrum of possible
Wrap-Up. December 5, Systems and Internet Infrastructure Security Laboratory (SIIS) Page 1
Wrap-Up December 5, 2011 Page 1 What do I think you know? Exam Sharir-Pnueli Key elements of papers Page 2 Exam Vulnerability definition Static analysis Chapter 2 Definitions for basic concepts Abstract
Streams, Delayed Evaluation and a Normal Order Interpreter. CS 550 Programming Languages Jeremy Johnson
Streams, Delayed Evaluation and a Normal Order Interpreter CS 550 Programming Languages Jeremy Johnson 1 Theme This lecture discusses the stream model of computation and an efficient method of implementation
Flow Analysis. Data-flow analysis, Control-flow analysis, Abstract interpretation, AAM
Flow Analysis Data-flow analysis, Control-flow analysis, Abstract interpretation, AAM Helpful Reading: Sections 1.1-1.5, 2.1 Data-flow analysis (DFA) A framework for statically proving facts about program
School of Computer Science. Scheme Flow Analysis Note 2 4/27/90. Useless-Variable Elimination. Olin Shivers.
Carnegie Mellon School of Computer Science Scheme Flow Analysis Note 2 4/27/90 Useless-Variable Elimination Olin Shivers shivers@cs.cmu.edu 1 Intro In my 1988 SIGPLAN paper Control-Flow Analysis in Scheme,
Control Flow Analysis with SAT Solvers
Control Flow Analysis with SAT Solvers Steven Lyde, Matthew Might University of Utah, Salt Lake City, Utah, USA Abstract. Control flow analyses statically determine the control flow of programs. This is
A Dynamic Evaluation of the Precision of Static Heap Abstractions
A Dynamic Evaluation of the Precision of Static Heap Abstractions OOSPLA - Reno, NV October 20, 2010 Percy Liang Omer Tripp Mayur Naik Mooly Sagiv UC Berkeley Tel-Aviv Univ. Intel Labs Berkeley Tel-Aviv
Abstracting Definitional Interpreters (Functional Pearl)
Abstracting Definitional Interpreters (Functional Pearl) DAVID DARAIS, Univeristy of Maryland, USA NICHOLAS LABICH, Univeristy of Maryland, USA PHÚC C. NGUYỄN, Univeristy of Maryland, USA DAVID VAN HORN,
Programming Languages
Programming Languages Tevfik Koşar Lecture - XIII March 2 nd, 2006 1 Roadmap Functional Languages Lambda Calculus Intro to Scheme Basics Functions Bindings Equality Testing Searching 2 1 Functional Languages
Functional Programming. Pure Functional Programming
Functional Programming Pure Functional Programming Computation is largely performed by applying functions to values. The value of an expression depends only on the values of its sub-expressions (if any).
Module 10: Imperative Programming, Modularization, and The Future
Module 10: Imperative Programming, Modularization, and The Future If you have not already, make sure you Read How to Design Programs Sections 18. 1 CS 115 Module 10: Imperative Programming, Modularization,
Static Analysis of Dynamically Typed Languages made Easy
Static Analysis of Dynamically Typed Languages made Easy Yin Wang School of Informatics and Computing Indiana University Overview Work done as two internships at Google (2009 summer and 2010 summer) Motivation:
Logic-Flow Analysis of Higher-Order Programs
Logic-Flow Analysis of Higher-Order Programs Matt Might http://matt.might.net/ POPL 2007 Why? Tim Sweeney, POPL 2006 Static array-bounds checking. Example... a[i]... Will 0 i < a.length always hold? 3
Normal Order (Lazy) Evaluation SICP. Applicative Order vs. Normal (Lazy) Order. Applicative vs. Normal? How can we implement lazy evaluation?
Normal Order (Lazy) Evaluation Alternative models for computation: Normal (Lazy) Order Evaluation Memoization Streams Applicative Order: evaluate all arguments, then apply operator Normal Order: pass unevaluated
CFA2: Pushdown Flow Analysis for Higher-Order Languages
CFA2: Pushdown Flow Analysis for Higher-Order Languages A dissertation presented by Dimitrios Vardoulakis to the Faculty of the Graduate School of the College of Computer and Information Science in partial
6.184 Lecture 4. Interpretation. Tweaked by Ben Vandiver Compiled by Mike Phillips Original material by Eric Grimson
6.184 Lecture 4 Interpretation Tweaked by Ben Vandiver Compiled by Mike Phillips Original material by Eric Grimson 1 Interpretation Parts of an interpreter Arithmetic calculator
CS 415 Midterm Exam Spring 2002
CS 415 Midterm Exam Spring 2002 Name KEY Email Address Student ID # Pledge: This exam is closed note, closed book. Good Luck! Score Fortran Algol 60 Compilation Names, Bindings, Scope Functional Programming
Scheme as implemented by Racket
Scheme as implemented by Racket (Simple view:) Racket is a version of Scheme. (Full view:) Racket is a platform for implementing and using many languages, and Scheme is one of those that come out of the
Program verification. Generalities about software Verification Model Checking. September 20, 2016
Program verification Generalities about software Verification Model Checking Laure Gonnord David Monniaux September 20, 2016 1 / 43 The teaching staff Laure Gonnord, associate professor, LIP laboratory,
Sample Final Exam Questions
91.301, Organization of Programming Languages Fall 2015, Prof. Yanco Sample Final Exam Questions Note that the final is a 3 hour exam and will have more questions than this handout. The final exam will
regsim.scm ~/umb/cs450/ch5.base/ 1 11/11/13
1 File: regsim.scm Register machine simulator from section 5.2 of STRUCTURE AND INTERPRETATION OF COMPUTER PROGRAMS This file can be loaded into Scheme as a whole. Then you can define and simulate machines
Languages as Libraries
Languages as Libraries or, implementing the next 700 programming languages Sam Tobin-Hochstadt PLT @ Northeastern University May 11, 2011 MIT 1 A domain specific language is the ultimate abstraction. Paul
Recursion & Iteration
Recursion & Iteration York University Department of Computer Science and Engineering 1 Overview Recursion Examples Iteration Examples Iteration vs. Recursion Example [ref.: Chap 5,6 Wilensky] 2 Recursion
Optimizing Scheme, part I
Optimizing Scheme, part I cons should not cons its arguments, part I a Lazy Alloc is a Smart Alloc Alex Gal COMP 621 cancelled stack-storage optimization for short-lived data a one slide summary most object
A Gentle Introduction to Program Analysis
A Gentle Introduction to Program Analysis Işıl Dillig University of Texas, Austin January 21, 2014 Programming Languages Mentoring Workshop 1 / 24 What is Program Analysis? Very broad topic, but generally
Graph reduction. Simple graph reduction with visualisation
Simple graph reduction with visualisation Outline The minifp language Graph representation of terms Tying the knot The compiler The reduction engine Literature The minifp language Small functional language,
CS 415 Midterm Exam Spring SOLUTION
CS 415 Midterm Exam Spring 2005 - SOLUTION Name Email Address Student ID # Pledge: This exam is closed note, closed book. Questions will be graded on quality of answer. Please supply the best answer you
Advanced Programming Methods. Introduction in program analysis
Advanced Programming Methods Introduction in program analysis What is Program Analysis? Very broad topic, but generally speaking, automated analysis of program behavior Program analysis is about developing
LECTURE 16. Functional Programming
LECTURE 16 Functional Programming WHAT IS FUNCTIONAL PROGRAMMING? Functional programming defines the outputs of a program as a mathematical function of the inputs. Functional programming is a declarative
From Syntactic Sugar to the Syntactic Meth Lab:
From Syntactic Sugar to the Syntactic Meth Lab: Using Macros to Cook the Language You Want a V E N E TRUT H Brandeis S PA R T U N T O I T S I N N E R M OS T COMPUTER SCIENCE 21B: Structure and Interpretation
CSE 341 Section Handout #6 Cheat Sheet
Cheat Sheet Types numbers: integers (3, 802), reals (3.4), rationals (3/4), complex (2+3.4i) symbols: x, y, hello, r2d2 booleans: #t, #f strings: "hello", "how are you?" lists: (list 3 4 5) (list 98.5
Principles of Programming Languages
Principles of Programming Languages Slides by Yaron Gonen and Dana Fisman Based on Book by Mira Balaban and Lesson 20 Lazy Lists Collaboration and Management Dana Fisman www.cs.bgu.ac.il/~ppl172 1 Lazy
Optimizing Abstract Abstract Machines
Optimizing Abstract Abstract Machines J. Ian Johnson Northeastern University ianj@ccs.neu.edu Matthew Might University of Utah might@cs.utah.edu David Van Horn Northeastern University dvanhorn@ccs.neu.edu
6.037 Lecture 4. Interpretation. What is an interpreter? Why do we need an interpreter? Stages of an interpreter. Role of each part of the interpreter
6.037 Lecture 4 Interpretation Interpretation Parts of an interpreter Meta-circular Evaluator (Scheme-in-scheme!) A slight variation: dynamic scoping Original material by Eric Grimson Tweaked by Zev Benjamin,
Static Program Analysis Part 9 pointer analysis. Anders Møller & Michael I. Schwartzbach Computer Science, Aarhus University
Static Program Analysis Part 9 pointer analysis Anders Møller & Michael I. Schwartzbach Computer Science, Aarhus University Agenda Introduction to points-to analysis Andersen s analysis Steensgaards s
Functional programming languages
Functional programming languages Part V: functional intermediate representations Xavier Leroy INRIA Paris-Rocquencourt MPRI 2-4, 2015 2017 X. Leroy (INRIA) Functional programming languages MPRI 2-4, 2015
Continuation Passing Style. Continuation Passing Style
161 162 Agenda functional programming recap problem: regular expression matcher continuation passing style (CPS) movie regular expression matcher based on CPS correctness proof, verification change of
Static Analysis Basics II
Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA Static Analysis Basics
The Typed Racket Guide
The Typed Racket Guide Version 5.3.6 Sam Tobin-Hochstadt and Vincent St-Amour August 9, 2013 Typed Racket is a family of languages, each of which enforce
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
CS 135 Winter 2018 Tutorial 7: Accumulative Recursion and Binary Trees. CS 135 Winter 2018 Tutorial 7: Accumulative Recursion and Binary Trees 1
CS 135 Winter 2018 Tutorial 7: Accumulative Recursion and Binary Trees CS 135 Winter 2018 Tutorial 7: Accumulative Recursion and Binary Trees 1 Goals of this tutorial You should be able to... understand
Functional Programming - 2. Higher Order Functions
Functional Programming - 2 Higher Order Functions Map on a list Apply Reductions: foldr, foldl Lexical scoping with let s Functional-11, CS5314, Sp16 BGRyder 1 Higher Order Functions Functions as 1st class
;;; Determines if e is a primitive by looking it up in the primitive environment. ;;; Define indentation and output routines for the output for
Page 1/11 (require (lib "trace")) Allow tracing to be turned on and off (define tracing #f) Define a string to hold the error messages created during syntax checking (define error msg ""); Used for fancy
Scheme in Scheme: The Metacircular Evaluator Eval and Apply
Scheme in Scheme: The Metacircular Evaluator Eval and Apply CS21b: Structure and Interpretation of Computer Programs Brandeis University Spring Term, 2015 The metacircular evaluator is A rendition of Scheme,
A Brief Introduction to Scheme (II)
A Brief Introduction to Scheme (II) Philip W. L. Fong pwlfong@cs.uregina.ca Department of Computer Science University of Regina Regina, Saskatchewan, Canada Lists Scheme II p.1/29 Lists Aggregate data
Typed Racket: Racket with Static Types
Typed Racket: Racket with Static Types Version 5.0.2 Sam Tobin-Hochstadt November 6, 2010 Typed Racket is a family of languages, each of which enforce that programs written in the language obey a type
Scheme Quick Reference
Scheme Quick Reference COSC 18 Winter 2003 February 10, 2003 1 Introduction This document is a quick reference guide to common features of the Scheme language. It is by no means intended to be a complete
Introduction to Functional Programming in Racket. CS 550 Programming Languages Jeremy Johnson
Introduction to Functional Programming in Racket CS 550 Programming Languages Jeremy Johnson 1 Objective To introduce functional programming in racket Programs are functions and their semantics involve
Fall Semester, The Metacircular Evaluator. Today we shift perspective from that of a user of computer langugaes to that of a designer of
1 MASSACHVSETTS INSTITVTE OF TECHNOLOGY Department of Electrical Engineering and Computer Science 6.001 Structure and Interpretation of Computer Programs Fall Semester, 1996 Lecture Notes { October 31,
Principles of Program Analysis. Lecture 1 Harry Xu Spring 2013
Principles of Program Analysis Lecture 1 Harry Xu Spring 2013 An Imperfect World Software has bugs The northeast blackout of 2003, affected 10 million people in Ontario and 45 million in eight U.S. states
CS1102: Macros and Recursion
CS1102: Macros and Recursion Kathi Fisler, WPI October 5, 2009 This lecture looks at several more macro examples. It aims to show you when you can use recursion safely with macros and when you can t. 1
Functions and Recursion. Dr. Philip Cannata 1
Functions and Recursion Dr. Philip Cannata 1 10 High Level Languages This Course Java (Object Oriented) Jython in Java Relation ASP RDF (Horn Clause Deduction, Semantic Web) Dr. Philip Cannata 2 let transformation,
Lexical vs. Dynamic Scope
Intro Lexical vs. Dynamic Scope where do I point to? Remember in Scheme whenever we call a procedure we pop a frame and point it to where the procedure points to (its defining environment). This is called
(add1 3) 4 (check-expect (add1 3) 4)
(add1 3) 4 (check-expect (add1 3) 4) ;; A Dict is one of: ;; - '() ;; - (cons (list String String) Dict) ;; Interp: a collection of definitions where each element is a ;; two-element list of a word (first)
STREAMS 10. Basics of Streams. Practice with Streams COMPUTER SCIENCE 61AS. 1. What is a stream? 2. How does memoization work?
STREAMS 10 COMPUTER SCIENCE 61AS Basics of Streams 1. What is a stream? 2. How does memoization work? 3. Is a cons-stream a special form? Practice with Streams 1. Define a procedure (ones) that, when run
Principles of Programming Languages Topic: Scope and Memory Professor Louis Steinberg Fall 2004
Principles of Programming Languages Topic: Scope and Memory Professor Louis Steinberg Fall 2004 CS 314, LS,BR,LTM: Scope and Memory 1 Review Functions as first-class objects What can you do with an integer?
Racket Pattern Matching
Racket Pattern Matching Principles of Programming Languages https://lambda.mines.edu if evaluates a predicate, and returns either the consequent or the alternative depending on the result: (if predicate
First-class continuations. call/cc, stack-passing CEK machines
First-class continuations call/cc, stack-passing CEK machines But first Assignment 2 e ::= (letrec* ([x e]...) e) (letrec ([x e]...) e) (let* ([x e]...) e) (let ([x e]...) e) (let x ([x e]...) e) (lambda
Abstracting Abstract Control
Abstracting Abstract Control (Extended) J. Ian Johnson Northeastern University ianj@ccs.neu.edu David Van Horn University of Maryland dvanhorn@cs.umd.edu Static analysis is the process of soundly predicting
Static Analysis. Systems and Internet Infrastructure Security
Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA Static Analysis Trent
Scheme Quick Reference
Scheme Quick Reference COSC 18 Fall 2003 This document is a quick reference guide to common features of the Scheme language. It is not intended to be a complete language reference, but it gives terse summaries
Freeing memory is a pain. Need to decide on a protocol (who frees what?) Pollutes interfaces Errors hard to track down
Freeing memory is a pain Need to decide on a protocol (who frees what?) Pollutes interfaces Errors hard to track down 1 Freeing memory is a pain Need to decide on a protocol (who frees what?) Pollutes
Relaxing a Linear Typing for In-Place Update
T R H E U N I V E R S I T Y O H F G E D I N B U Relaxing a Linear Typing for In-Place Update Michal Konečný LFCS, University of Edinburgh Joint work with David Aspinall, Martin Hofmann, Robert Atkey M.
More Scheme CS 331. Quiz. 4. What is the length of the list (()()()())? Which element does (car (cdr (x y z))) extract from the list?
More Scheme CS 331 Quiz 1. What is (car ((2) 3 4))? (2) 2. What is (cdr ((2) (3) (4)))? ((3)(4)) 3. What is (cons 2 (2 3 4))? (2 2 3 4) 4. What is the length of the list (()()()())? 4 5. Which element
Announcements. The current topic: Scheme. Review: BST functions. Review: Representing trees in Scheme. Reminder: Lab 2 is due on Monday at 10:30 am.
The current topic: Scheme! Introduction! Object-oriented programming: Python Functional programming: Scheme! Introduction! Numeric operators, REPL, quotes, functions, conditionals! Function examples, helper
Semantics of an Intermediate Language for Program Transformation
Semantics of an Intermediate Language for Program Transformation Sigurd Schneider Advisors: Sebastian Hack, Gert Smolka Student Session at POPL 2013 Saarland University Graduate School of Computer Science
YOUR NAME PLEASE: *** SOLUTIONS ***
YOUR NAME PLEASE: *** SOLUTIONS *** Computer Science 201b SAMPLE Exam 1 SOLUTIONS February 15, 2015 Closed book and closed notes. No electronic devices. Show ALL work you want graded on the test itself.
CS162 - Operating Systems and Systems Programming. Address Translation => Paging"
CS162 - Operating Systems and Systems Programming Address Translation => Paging" David E. Culler! http://cs162.eecs.berkeley.edu/! Lecture #15! Oct 3, 2014!! Reading: A&D 8.1-2, 8.3.1. 9.7 HW 3 out (due
Fall 2018 Discussion 8: October 24, 2018 Solutions. 1 Introduction. 2 Primitives
CS 6A Scheme Fall 208 Discussion 8: October 24, 208 Solutions Introduction In the next part of the course, we will be working with the Scheme programming language. In addition to learning how to write
Architecture of LISP Machines. Kshitij Sudan March 6, 2008
Architecture of LISP Machines Kshitij Sudan March 6, 2008 A Short History Lesson Alonzo Church and Stephen Kleene (1930) λ Calculus ( to cleanly define "computable functions" ) John McCarthy (late 60 s)
Static and Dynamic Program Analysis: Synergies and Applications
Static and Dynamic Program Analysis: Synergies and Applications Mayur Naik Intel Labs, Berkeley CS 243, Stanford University March 9, 2011 Today s Computing Platforms Trends: parallel cloud mobile Traits:
Assertions, pre/postconditions
Programming as a contract Assertions, pre/postconditions Assertions: Section 4.2 in Savitch (p. 239) Specifying what each method does q Specify it in a comment before method's header Precondition q What
Functional Languages. Hwansoo Han
Functional Languages Hwansoo Han Historical Origins Imperative and functional models Alan Turing, Alonzo Church, Stephen Kleene, Emil Post, etc. ~1930s Different formalizations of the notion of an algorithm
Type Systems Winter Semester 2006
Type Systems Winter Semester 2006 Week 9 December 13 December 13, 2006 - version 1.0 Plan PREVIOUSLY: unit, sequencing, let, pairs, sums TODAY: 1. recursion 2. state 3.??? NEXT: exceptions? NEXT: polymorphic
Class 6: Efficiency in Scheme
Class 6: Efficiency in Scheme SI 413 - Programming Languages and Implementation Dr. Daniel S. Roche United States Naval Academy Fall 2011 Roche (USNA) SI413 - Class 6 Fall 2011 1 / 10 Objects in Scheme
6.037 Lecture 7B. Scheme Variants Normal Order Lazy Evaluation Streams
6.037 Lecture 7B Scheme Variants Normal Order Lazy Evaluation Streams Edited by Mike Phillips & Ben Vandiver Original Material by Eric Grimson & Duane Boning Further Variations on a Scheme Beyond Scheme
Building a Modular Static Analysis Framework in Scala (Tool Paper)
Building a Modular Static Analysis Framework in Scala (Tool Paper) Quentin Stiévenart Jens Nicolay Wolfgang De Meuter Coen De Roover Vrije Universiteit Brussel, Belgium {qstieven,jnicolay,wdmeuter,cderoove}@vub.ac.be
Defining Recursive Procedures. Lecture 8: Recursing Lists. list? Tracing list? sumlist. Defining Recursive Procedures on Lists
Lecture 8: Recursing Lists CS15: Computer Science University of Virginia Computer Science David Evans http://www.cs.virginia.edu/evans Defining Recursive Procedures 1. Be optimistic! Assume you can solve
CSCC24 Functional Programming Scheme Part 2
CSCC24 Functional Programming Scheme Part 2 Carolyn MacLeod 1 winter 2012 1 Based on slides from Anya Tafliovich, and with many thanks to Gerald Penn and Prabhakar Ragde. 1 The Spirit of Lisp-like Languages
CSc 520 Principles of Programming Languages
CSc 520 Principles of Programming Languages 9: Scheme Metacircular Interpretation Christian Collberg collberg@cs.arizona.edu Department of Computer Science University of Arizona Copyright c 2005 Christian
An Introduction to Heap Analysis. Pietro Ferrara. Chair of Programming Methodology ETH Zurich, Switzerland
An Introduction to Heap Analysis Pietro Ferrara Chair of Programming Methodology ETH Zurich, Switzerland Analisi e Verifica di Programmi Universita Ca Foscari, Venice, Italy Outline 1. Recall of numerical
Agenda. CS301 Session 11. Common type constructors. Things we could add to Impcore. Discussion: midterm exam - take-home or inclass?
Agenda CS301 Session 11 Discussion: midterm exam - take-home or inclass? Interlude: common type constructors Type soundness 1 2 Things we could add to Impcore Common type constructors Array is a type constructor,
A subtle problem. An obvious problem. An obvious problem. An obvious problem. t ss
A subtle problem An obvious problem when LC = t do S doesn t make sense for Lamport clocks! there is no guarantee that LC will ever be t S is anyway executed after LC = t Fixes: if e is internal/send and
MIDTERM EXAMINATION - CS130 - Spring 2005
MIDTERM EAMINATION - CS130 - Spring 2005 Your full name: Your UCSD ID number: This exam is closed book and closed notes Total number of points in this exam: 231 + 25 extra credit This exam counts for 25%
Wellesley College CS251 Programming Languages Spring, 2000 FINAL EXAM REVIEW PROBLEM SOLUTIONS
Wellesley College CS251 Programming Languages Spring, 2000 FINAL EXAM REVIEW PROBLEM SOLUTIONS This document contains solutions to the problems on the final exam review problems posted earlier except for
Quis Custodiet Ipsos Custodes The Java memory model
Quis Custodiet Ipsos Custodes The Java memory model Andreas Lochbihler funded by DFG Ni491/11, Sn11/10 PROGRAMMING PARADIGMS GROUP = Isabelle λ β HOL α 1 KIT 9University Oct 2012 of the Andreas State of
Flow Analysis, Linearity and PTIME. David Van Horn and Harry Mairson
Flow Analysis, Linearity and PTIME David Van Horn and Harry Mairson What is a lower bound? Higher-order control-flow analysis in retrospect: Lessons learned, lessons abandoned. Shivers, Best of PLDI retrospective:
Syntactic Sugar: Using the Metacircular Evaluator to Implement the Language You Want
Computer Science 21b (Spring Term, 2017) Structure and Interpretation of Computer Programs Syntactic Sugar: Using the Metacircular Evaluator to Implement the Language You Want Here is one of the big ideas
CS 275 Name Final Exam Solutions December 16, 2016
CS 275 Name Final Exam Solutions December 16, 2016 You may assume that atom? is a primitive procedure; you don t need to define it. Other helper functions that aren t a standard part of Scheme you need
Principles of Programming Languages 2017W, Functional Programming
Principles of Programming Languages 2017W, Functional Programming Assignment 3: Lisp Machine (16 points) Lisp is a language based on the lambda calculus with strict execution semantics and dynamic typing.
CS115 - Module 10 - General Trees
Fall 2017 Reminder: if you have not already, ensure you: Read How to Design Programs, Sections 15 and 16. Arithmetic Expressions Recall with binary trees we could represent an expression containing binary
Pierce Ch. 3, 8, 11, 15. Type Systems
Pierce Ch. 3, 8, 11, 15 Type Systems Goals Define the simple language of expressions A small subset of Lisp, with minor modifications Define the type system of this language Mathematical definition using
Programming Languages. Thunks, Laziness, Streams, Memoization. Adapted from Dan Grossman s PL class, U. of Washington
Programming Languages Thunks, Laziness, Streams, Memoization Adapted from Dan Grossman s PL class, U. of Washington You ve been lied to Everything that looks like a function call in Racket is not necessarily
CS 342 Lecture 7 Syntax Abstraction By: Hridesh Rajan
CS 342 Lecture 7 Syntax Abstraction By: Hridesh Rajan 1 Reading SICP, page 11-19, Section 1.1.6 Little Schemer, Chapter 2 2 The Idea of Syntax Abstraction Problem. Often programming tasks are repetitive,
CS61A Midterm 2 Review (v1.1)
Spring 2006 1 CS61A Midterm 2 Review (v1.1) Basic Info Your login: Your section number: Your TA s name: Midterm 2 is going to be held on Tuesday 7-9p, at 1 Pimentel. What will Scheme print? What will the
Lecture #13: Type Inference and Unification. Typing In the Language ML. Type Inference. Doing Type Inference
Lecture #13: Type Inference and Unification Typing In the Language ML Examples from the language ML: fun map f [] = [] map f (a :: y) = (f a) :: (map f y) fun reduce f init [] = init reduce f init (a ::