Strict Bidirectional Type Checking Adam Chlipala, Leaf Petersen, and Robert Harper

1/10/052 Type Systems Less Type Annotation More Type Annotation ML Concise syntax. Compact representation. Complex (global) type reconstruction problem. Undecidable past a certain point. Verbose syntax. Representation issues. Simple or no type reconstruction. Powerful type systems are still decidable. Haskell Java TILT IL

1/10/053 Type Systems Less Annotation More Annotation ML Concise (enough) syntax. Compact representation. Simple syntax directed typechecking. Powerful and decidable type systems. Haskell Java TILT IL Pierce, Turner (POPL ‘98)

1/10/054 Simply Typed Calculus

1/10/055 TermsTypes 10

1/10/056 TermsTypes 10 23

1/10/057 TermsTypes

1/10/058 TermsTypes

1/10/059 TermsTypes …… ii 2 -1 Quadratic! 

1/10/0510 Algorithmic view Inputs are black. Outputs are red.

1/10/0511 Algorithmic view Inputs are black. Outputs are red. Redundant

1/10/0512 Algorithmic view Inputs are black. Outputs are red.

1/10/0513 Algorithmic view Inputs are black. Outputs are red. Redundant

1/10/0514 Bidirectional Typechecking Synthesis: Typed terms. Analysis: Checkable terms.

1/10/0515 TermsTypes 11

1/10/0516 TermsTypes 11 23

1/10/0517 TermsTypes

1/10/0518 TermsTypes

1/10/0519 TermsTypes …… i2i-1 Linear!

1/10/0520 Unnecessary! Much simpler technique works fine. Good asymptotic behavior. Syntax directed. Extends directly to sum types.

1/10/0521 Recursive types.

1/10/0522 Simple term

1/10/0523

1/10/0524 Fold Annotations Only

1/10/0525 With Sum Annotations

1/10/0526 Bidirectional version

1/10/0527 Let Binding Surprisingly, bidirectional typechecking interacts badly with let binding. –Quadratic increase in annotation size in bad cases. Bad - programmers use let. Bad - compilers use let. –Put code in “named form” (sequentialization)

1/10/0528 Binding forms Analysis binding: Synthesis binding:

1/10/0529

1/10/0530

1/10/0531

1/10/0532 Sequentializing bidirectional terms may lead to quadratic increase in type size! 

1/10/0533 Binding forms (revisited) Analysis binding: – Synthesis binding: – Undecorated analysis binding? – –Might solve our problem.

1/10/0534

1/10/0535

1/10/0536

1/10/0537 Can we typecheck it?

1/10/0538

1/10/0539

1/10/0540

1/10/0541

1/10/0542 Key points: Typecheck body first. Context of occurrence gives a unique type to z 0 because it occurs in an analysis position.

1/10/0543 Algorithmically Speaking Divide context into input and output zones. Input zone variables must declare types. –Explicitly: –Implicitly: Output zone variables get types from occurrences: – –Check A after getting type for u from E. –Must ensure variables actually occur!!

1/10/0544 Formally Look to strict logic –Substructural logic in which hypotheses must be used at least once. Normal variables in unrestricted context (  may occur zero or more times. Strict variables in restricted context (  must occur at least once. Contrast with linear logic: –Linear variables in restricted context (  ) must occur exactly once.

1/10/0545 Strict Bidirectional Typechecking Judgments: –Analysis: –Synthesis: Unrestricted context (  is input mapping variables to their types. Restricted context (  is output mapping variables to their types. Strict variables must occur in analysis positions.

1/10/0546 Cool Fact #1 Theorem: The strict bidirectional typechecking rules constitute an algorithm. –Syntax directed. –Uniquely determined outputs. –Proof is in paper.

1/10/0547 Cool Fact #2 Theorem: Sequentialization into the strict language never increases type size. –Size of sequentialized form is bounded above by the size of the original. –Proof is in paper.

1/10/0548 Recap Bidirectional representation yields asymptotic improvements in type size. Let binding destroys these benefits. Recognizing strictness allows benefits to be recaptured without unification.

1/10/0549 The End