Mechanized Metatheory for User- Defined Type Extensions Dan Marino, Brian Chin, Todd Millstein UCLA Gang Tan Boston College Robert J. Simmons, David Walker Princeton University

2 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?

3 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

4 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

5 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 guaranteed- sound, extended type system which can be used in any future application

6 New Extension Definition and Soundness Proof TWELF Metatheory Soundness Checker Extended Type Checker Error Interpreter Source Code using TSE-defined Annotations Compiler Error Interpreter Error reported to TSE e.g. Proof obligation not satisfied Error reported to Programmer e.g. Annotation discipline not obeyed T S E Programmers Extension Independent Theory and Metatheory Us

7 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

8 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

9 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.”

10 ,  ├ E1 : iseven ,  ├ E2 : iseven ,  ├ E2 : iseven ,  ├ E1 : iseven Ex: User-Defined Qualifiers define qualifier typing rules ,  ├ C : iseven ,  ├ E1 + E2 : iseven ,  ├ E1 * E2 : iseven ,  ├ E + E : iseven C is an even constant

11 define value invariant e.g. satisfies (v, iseven)   n : v = 2 * n prove soundness ,  ├ V : Q  satisfies (V, Q) Ex: User-Defined Qualifiers ,  ├ E : Q  E  E’  ,  ├ E’ : Q Preservation Value Invariant Satisfaction

12 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

13 Effect Checking as Privileges effect checking can be viewed as granting, revoking, and checking privileges or capabilities Grant Check Revoke Grant Check Revoke Grant Check Race Condition CheckingRegion-based Memory Management acquire lock release lock protected access allocate region free region access memory Checked Exceptions try / catch block throw exception

14 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

15 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

16 Simple Effect Example : Impure specify evaluation steps that require privilege ,  ├ E1 : Ref T , ,  ├ E2 : T impure   ,  ├ E1 := E2 : Unit  ’ =  [loc  V] impure   , , loc := V  ,  ’, unit indicate static checking rules that check privilege context

17 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

18 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