Safe Explicitly Staged Programming
Frank Pfenning
Carnegie Mellon University
Joint work with Peter Lee, Rowan Davies, Aleksandar Nanevski, and Philip Wickline
PCES PI Meeting Feb 2001 2
The Fox Project at Carnegie Mellon
Advanced Programming Languages for Systems Software
• Karl Crary
• Robert Harper
• Peter Lee
• Frank Pfenning
• Many former and current students...
PCES PI Meeting Feb 2001 3
Threads of Research
• Typed Intermediate and Low-Level Languages– Karl Crary, Robert Harper– Collaboration with Cornell
• Proof-Carrying Code and Logical Frameworks– Peter Lee, Frank Pfenning– Collaborations: Berkeley, Princeton, Yale, Stanford– Commercial Java tech transfer to Cedilla Systems
Staged Computation– Peter Lee, Frank Pfenning
PCES PI Meeting Feb 2001 4
Unifying Themes
• Problems motivated by the practice of software development
• Logic and type theory as indispensible tools for their solution
• Theory and system building go hand-in-hand
PCES PI Meeting Feb 2001 5
Talk Outline
Motivation
• Explicit Staging and Types
• Assessment
• Summary and Future Work
PCES PI Meeting Feb 2001 6
Modularity vs. Efficiency
• Goal: building systems that are– highly modular– correct– easy to adapt– fast to construct
• How can we achieve this and attain efficiency?
Our approach:
Types and explicitly staged computation
PCES PI Meeting Feb 2001 7
Configuration in the Foxnet
appTCP
ICMP
IP
Eth
appTCPEth
plug & play for specialized configurations
comm.app
“fused” stack via staging and code specialization?
PCES PI Meeting Feb 2001 8
What is Staged Computation?
Explicit or implicit division of a computation into static or dynamic phases
• Run-time code generation
• Partial evaluation
• In-lining
• Macro processing
PCES PI Meeting Feb 2001 9
Staging in Algorithm Design
• Standard informal practice
• Example: Sparse matrix multiplication
• Example: JIT compilation [e.g. packet filter] Widely applicable Flexible Difficult to automate Hard to maintain during program evolution
PCES PI Meeting Feb 2001 10
Example: Just-in-Time Compilation
byte code data
JVM
results
byte code
data
results
JIT compiler
binary
PCES PI Meeting Feb 2001 11
Partial Evaluation
• Binding-time analysis: static (early) and dynamic (late) data
• One-time global program specialization
• Serious implementations [e.g. Tempo] Well-developed theory Binding-time analysis automatic Can be unpredictable for programmer Difficult to maintain under program changes
PCES PI Meeting Feb 2001 12
Run-Time Code Generation
• Dynamic generation of code based on values only available at run-time
• Serious implementations [e.g. `C, Cyclone] Widely applicable, including systems
programming and middleware Performance hard to predict Programs (very) difficult to write
PCES PI Meeting Feb 2001 13
Example: Run-Time Code Generation
byte code
data
results
JIT compiler
binary
PCES PI Meeting Feb 2001 15
Why is Staged Programming Difficult?
• Departure from simple operational model
• Reasoning about program-generating programs
• Automation leading to unpredictability
• Instability under program evolution
PCES PI Meeting Feb 2001 16
Our Thesis
The inherent tensions between modularity, safety, and efficiency can be relieved through programming with explicit, transparent, and statically verifiable constructs for staging
• Applications particularly in complex systems where modularity and data abstraction are critical
PCES PI Meeting Feb 2001 17
Explicit Staging
Staging behavior should be explicit in programs
• Promotes readability and maintainability
• Supports reliable reasoning about behavior
• Ameliorates unpredictability of optimizations
• Not unduly burdensome
PCES PI Meeting Feb 2001 18
Transparency
The meaning of staging constructs should be clearly and unambiguously specified
• Portability across platforms and compilers
• Evolution from an art to a science
• Some independence from language paradigm
• Issues of efficient implementation remain
PCES PI Meeting Feb 2001 19
Static Verification
Correct staging should be statically enforced
• Catch mistakes early
• Diagnose notoriously difficult staging errors
• Support safe program revision
• Prevent inconsistencies at module boundaries
PCES PI Meeting Feb 2001 20
Talk Outline
• Motivation Explicit Staging and Types
• Assessment
• Summary and Future Work
PCES PI Meeting Feb 2001 21
Types to Guide Language Design
• Elegance and uniformity
• Static verifiability
• Orthogonality to other constructs
• Conservative extension property
• Consistency across module boundaries
• Some measure of language independence
• Reasoning about programs
PCES PI Meeting Feb 2001 22
Intensional Expressions
A type of intensional expressions is a good model for many forms of staged computation
• Intensional Expression = Source Code
• Term = Compiled Code
• Coerce to programs by evaluation (abstractly)
• Analyze and transform structurally
• In contrast, programs (terms) can only be executed
PCES PI Meeting Feb 2001 23
Manipulating Expressions
• E — expression, u — expression variable
• box E — term, x — term variable
• let box u = M in N — substitute expression denoted by M for u in N
• embed(x) = let box u = x in box (...u...)
• eval(x) = let box u = x in u
• simplify(x) = case x of box (0*u) box (0) | ...
PCES PI Meeting Feb 2001 24
Intensional Typing
• Typing judgment
; |- M : A
declares expression variables u :: A
declares value variables x : A
M is a term
A is a type
PCES PI Meeting Feb 2001 25
Expression Types
• A — terms denoting expressions of type A�• Introduction rule (constructor)
; • |- E : A
; |- box E : A�• E depends only on expression variables!
PCES PI Meeting Feb 2001 26
Expression Types Continued
• Elimination rule (destructor)
; |- M : A � ,u::A ; |- N : C
; |- (let box u = M in N) : C
• Operational semantics captures staging
M box E [E/u] N V
box E box E let box u = M in N V
PCES PI Meeting Feb 2001 27
Some Simple Programs
• eval : A � A
eval (x) = let box u = x in u
• quote : A � A�� quote (x) = let box u = x in box (box u)
• app : (A � B) A � B� app (f) (x) =
let box g = f in
let box u = x in box (g u)
PCES PI Meeting Feb 2001 28
Some Other Examples
• match : regexp (string � bool)
• eval_poly : poly (float � float)
• iprod : int (vector � (vector � float))
• packet_filter :
instruction array int
(int � int int array int)
PCES PI Meeting Feb 2001 29
Example from Foxnet
• type connection = (msg unit) (unit unit)
a pair of functions to send and abort
• open : address
((connection � (indata � unit))
unit)
PCES PI Meeting Feb 2001 30
A Logical Analysis
• Types satisfy precisely the laws of the modal logic S4
• Multiple world semantics as computation stages
• Admits several concrete realizations
PCES PI Meeting Feb 2001 31
Requirements Revisited
Explicit staging via “box” and “let box” Transparency via simple specification Static verification via modal type-checking
PCES PI Meeting Feb 2001 32
Run-Time Code Generation
• A — generator for code of type A�• Modal restrictions guarantee that source
expression will be available at run-time
• [Davies & Pfenning ‘96, ‘00, ‘01]
• Implementation via lightweight generating extensions
• [Leone & Lee ‘96]
• [Wickline, Lee, Pfenning, Davies ‘98]
PCES PI Meeting Feb 2001 33
Reflective Programming
• Extension by pattern matching against expressions [Nanevski & Pfenning]
• Intensional interpretation guarantees soundness
• Less efficient to implement but more expressive
• Meta-ML [Taha et al. ‘99,’00] incorporates modal and temporal types
PCES PI Meeting Feb 2001 34
Partial Evaluation
• Requires different type system based on temporal logic
• OA — A at the next stage of computation
• Captures traditional binding-time analysis precisely and logically
• [Davies ‘96]
PCES PI Meeting Feb 2001 35
Talk Outline
• Motivation
• Explicit Staging and Types Assessment
• Summary and Future Work
PCES PI Meeting Feb 2001 36
Programming
Staging errors caught quickly Explicit staging not too intrusive Conservative over host language Reasonable expressive power of primitives
? Predictable programmer efficiency model
PCES PI Meeting Feb 2001 37
Modularity
Types guarantee module consistency Can express some inter-module optimizations Not as appropriate for some automatic
improvements (e.g. in-lining)
PCES PI Meeting Feb 2001 38
Implementation
• PML implementation of light-weight run-time code generation in progress
• Results with predecessor Fabius encouraging [Leone & Lee ‘96]
• Efficient implementation quite difficult
• More experiments needed
PCES PI Meeting Feb 2001 39
Matrix Multiplication in Fabius
0
2
4
6
8
10
12
14
16
18
20 40 60 80 100 120 140 160 180 200
Dimension (n)
Tim
e (s
)
Fabius, no RTCG
Fabius, dense input
Specialized C, dense input
Conventional C
Fabius, sparse input
Specialized C, sparse input
PCES PI Meeting Feb 2001 40
Reasoning about Staged Programs
• Developed type theory for reasoning about staged programs [Pfenning’01]
• Enabled by clean and minimal design
• Required formalization of “dead code”
PCES PI Meeting Feb 2001 41
Talk Outline
• Motivation
• Explicit Staging and Types
• Assessment Summary and Future Work
PCES PI Meeting Feb 2001 42
Summary
• Logical and type-theoretic foundation for staged computation
• Implementation as run-time code generation or reflective programming
• Applications in complex systems where tensions between modularity, safety, and efficiency are greatest
PCES PI Meeting Feb 2001 43
Future Work
• Complete implementation, including modules
• Optimizations
• Transfer to other languages
• Applications, including program composition for complex systems (e.g. build your own “OS”)