Mechanized Metatheory for UserDefined Type Extensions
Dan Marino, Brian Chin, Todd Millstein
UCLA
Gang Tan
Boston College
Robert J. Simmons, David Walker
Princeton University
Motivation




statically proving program properties is
useful
traditional type systems check (prove) a
limited set of properties
language users may want to check
additional properties in specific
applications
how do we do this?
2
One Approach: Fancy Types

allow new properties to be encoded directly as
types
+ very expressive
+ no undue restriction on programming style
– increased expressivity  increased annotation
(i.e. proofs)
– complex type checking harder to understand
3
Our Approach: User-Defined
Type Systems

allow type system extension via definition of
new annotations and associated static
checking rules
+ separation of roles
• type system extender (TSE)
• programmers
+ domain-specific coding disciplines
– less expressive
– restricted programming style
4
Natural Application for
Mechanized Metatheory



new static checking rules
 extended soundness proof
TSE has burden of convincing proof
assistant that extension is sound
TSE is rewarded with a guaranteedsound, extended type system which can
be used in any future application
5
Us
Extension Independent
Theory and Metatheory
TSE
New Extension
Definition and
Soundness Proof
Error reported to TSE
e.g. Proof obligation not satisfied
Programmers
Source Code using
TSE-defined
Annotations
Error reported to Programmer
e.g. Annotation discipline not obeyed
TWELF
Error
Interpreter
Metatheory
Soundness
Checker
Compiler
Extended
Type Checker
Error
Interpreter
6
Designing an Extension
Framework


goal: facilitate adding an extension
our approach
1. identify a useful class of extensions
2. extract the commonalities within the class
3. provide specialized interface to TSE
7
Two Extension Frameworks
user-defined type qualifiers
•
•
•

e.g. positive, tainted, unaliased
simple annotations on expressions
qualifier soundness establishes invariants about values
and closely mirrors type soundness
user-defined type-and-effect systems
•
•
•
e.g. checked exceptions, synchronization, region-based
memory management
specify how effects are generated and when allowed
soundness establishes correspondence between static
rules and instrumented, effect-generating operational
semantics
8
Example: User-Defined
Qualifiers


goal: allow TSE to define discipline that
enforces an invariant about values
e.g. “I want a discipline that
programmers can use to statically verify
that certain values will always be even
numbers.”
9
Ex: User-Defined Qualifiers

define qualifier typing rules
,  ├ E + E : iseven
C is an even constant
,  ├ E1 : iseven
,  ├ E2 : iseven
,  ├ C : iseven
,  ├ E1 + E2 : iseven
,  ├ E1 : iseven
,  ├ E2 : iseven
,  ├ E1 * E2 : iseven
,  ├ E1 * E2 : iseven
10
Ex: User-Defined Qualifiers


define value invariant
• e.g.
satisfies (v, iseven) 
 n : v = 2 * n
prove soundness
Value Invariant Satisfaction
,  ├ V : Q  satisfies (V, Q)
Preservation
 ,  ├ E : Q  E  E’ 
11
,  ├ E’ : Q
Two Extension Frameworks

user-defined type qualifiers
•
•
•
e.g. positive, tainted, unaliased
simple annotations on expressions
qualifier soundness establishes invariants about values
and closely mirrors type soundness
user-defined type-and-effect systems
•
•
e.g. checked exceptions, synchronization, region-based
memory management
specify how effects are generated and when allowed
12
Effect Checking as Privileges

effect checking can be viewed as granting, revoking, and
checking privileges or capabilities
Race Condition Checking
Region-based Memory Management
Grant
acquire lock
Grant
allocate region
Check
protected access
Check
access memory
Revoke
release lock
Revoke
free region
Checked Exceptions
Grant
try / catch block
Check
throw exception
13
Type-and-Effect Framework


framework provides generic rules with hooks
for TSE-defined privilege operations
TSE defines static and dynamic privilege ops
•
•

During static checking of which expressions do we
grant, revoke, check privileges?
Which steps of evaluation cause privilege ops?
TSE proof obligations are limited to lemmas
about newly defined privilege operations
14
Simple Effect Example : Impure



TSE says “I want programmers to indicate
explicitly any code that might change
memory”
define new privilege “impure”
source language provides generic form for
annotating expressions
•
e.g. grant P in E
15
Simple Effect Example : Impure

specify evaluation steps that require privilege
’ =  [locV]
, , loc := V


impure  
, ’, unit
indicate static checking rules that check
privilege context
 , ├ E1 : Ref T
,, ├ E2 : T
 , ├ E1 := E2 : Unit
16
impure  
Current Status

complete formalization of Fun in Twelf

qualifier / type-and-effect frameworks
• versions of the extension-independent
•
theory/metatheory complete
experimenting with example extensions to
gauge expressiveness
17
Summary



defining statically-checkable programming
disciplines has been limited to the realm of
language designers
mechanized metatheory clears the way to
allow a wider group to take advantage of this
technique
separating the roles of TSE and Programmer
maintains language ease-of-use while allowing
for powerful static guarantees
18