Principles of Programming Languages

Transcription

1 Principles of Programming Languages Lesson 14 Type Checking Collaboration and Management Dana Fisman 1

2 Type Checking We return to the issue of type safety we discussed informally, in the introduction to FP via Typescript. A program is type-safe if we can guarantee that in no run we will encounter a type-error A type-error occurs when a procedure is applied to inappropriate data Example: (+ 7 'ok) + contract violation Expected: number? Given: 'ok argument position: 2nd

3 Type annotation As you recall Typesctipt extends Javascript with optional type annotation. Scheme does not support type annotation We will define L5, an extension of L4 that allows type annotation L5, unlike L1-L4, is not a subset of Scheme

4 L5 Scheme L4 define L1 only primitive ops and types L2 L3 cond lambda cons car cdr '() list letrec L5

5 Type annotation Ex. (define f (lambda ([n : number]) : number (+ n 3)))

6 Type checker Expression E Type Checker Type of E Type-Error #...

7 Program Correctness When is a program correct? We distinguish two type of plausibility criteria for programs correctness: PL Safety: o Type correctness o No division by zero o No array out-of-bounds accesses o No null-dereferences Verification: Correctness with regard to its specification E.g. o For a factorial program: Given a positive integer it returns n! o For a resource allocation program: a process requiring resource will eventually be granted access to the resource

8 Program Analysis We distinguish two approaches for checking correctness criteria for programs: Static Analysis o Only the text of the program is analyzed Dynamic Analysis o The program is analyzed in a runtime environment Static analysis provides stronger guarantees, since it proves correctness (of the criterion at hand) on every possible run.

9 Type Checking Checking there are no type errors, is easier with full type declaration. But scheme has no type declaration. We will tackle the problem in two phases: 1. We first analyze programs that include full type annotations and verify that they satisfy their type declarations. 2. We then analyze programs that include partial type annotations (and possibly no annotations at all) and infer the types of all variable declarations and functions.

10 Types Types are sets of values The set of all possible computed values of a program is partitioned into subsets In some PL partition is not the correct word, since a value can belong to several subsets (belong to several types)

11 Types in L4 Value = Number Boolean Prim-op Closure Void Sexp SExp = Symbol Number Boolean List(Sexp) Pair(Sexp, Sexp) List(Sexp) = '() Pair(SExp, List(Sexp)) Pair(Sexp) = (Sexp, Sexp) Closure = defined inductively as a mapping from tuple to values

12 Type Systems The semantics of a programming language defines a type system: it determines which types exist across the domain of computed values, how new types can be constructed o (through the usage of type constructors - such as Pair or List or Procedures) the possible relations among types o o o typea is contained in typeb typea is disjoint from typeb there is an overlap between typea and typeb

13 Type Compatibility If a variable was declared to have typea, can we assign it an expression with value of typeb? Simplest form: Identity: if typea is identical to typeb Aka invariance (the set of values passed cannot vary) Method used in Scheme More complex forms: Subtyping: if typea is a subtype of typeb Method used in TypeScript

14 Soundness A given expression is type safe if its evaluation will never lead to type errors. The goal of type checking is to verify that o if an expression E is assigned type T, o then, whenever E is computed, its value will be of type T. If the type system has this property, we say that it is sound.

15 Type Errors The type checker inspects every application node in the AST When checking an application node, it examines the types of the operands. If the operands are not of the expected type, this is an operator invocation error. This is a potential type error. The type checker then needs to take some actions o The kind of actions is part of the language design o Examples of action: Refuse to execute / compile Preform corrective measures (e.g. type casting).

16 Associating Expressions with Types Type checking and type inference requires associating program expressions with types. In order to achieve this, we need to define two syntactic extensions to our language: Define a type language to specify type expressions. Define a way in the language to associate variables and procedures to type expressions.

17 Type Language We now formally define the type language we have actually already been using: ;; Purpose: Identity ;; Signature: id(x) ;; Type: [T -> T] (define id (lambda (x) x))

18 Type Language - Ex Examples of type expressions we d like to be able to derive: number boolean void [number -> boolean] [number * number -> boolean] [number -> [number -> boolean]] [Empty -> number] [Empty -> void] [T1 -> T1]

19 Type Language - Def <texp> ::= <atomic-te> <composite-te> <tvar> <atomic-te> ::= <num-te> <bool-te> <void-te> <num-te> ::= number // num-te() <bool-te> ::= boolean // bool-te() <void-te> ::= void // void-te() <composite-te> ::= <proc-te> <tuple-te> <non-tuple-te> ::= <atomic-te> <proc-te> <tvar> <proc-te> ::= [ <tuple-te> -> <non-tuple-te> ] // proc-te(param-tes: list(te), return-te: te) <tuple-te> ::= <non-empty-tuple-te> <empty-te> <non-empty-tuple-te> ::= ( <non-tuple-te> * )* <non-tuple-te> // tuple-te(tes: list(te)) <empty-te> ::= Empty <tvar> ::= a symbol starting with T // tvar(id: Symbol)

20 Type Annotations L5 extends L4 with type annotation from the type language we just defined Type annotations can occur in two specific places o As part of a variable declarations o As part of a procedure expression, to specify the expected return type

21 Type Annotations Def. <program> ::= (L5 <exp>+) <exp> ::= <define-exp> <cexp> <define-exp> ::= (define <var-decl> <cexp>) <binding> ::= ( <var-decl> <cexp> ) // var-decl(var:symbol, type:texp) <var-decl> ::= <symbol> [ <symbol> : <texp>] <cexp> ::= <num-exp> // num-exp(val:number) <bool-exp> // bool-exp(val:boolean) <prim-op> // prim-op(op:symbol) <var-ref> // var-ref(var:symbol) (if <exp> <exp> <exp>) // if-exp(test,then,else) (quote <sexp>) // lit-exp(val:sexp) (let (<binding>*) <cexp>+) // let-exp(bindings:list(binding), body:list(cexp)) (letrec (<binding>*) <cexp>+) // letrec-exp(bindings:list(binding), body:list(cexp)) (<cexp> <cexp>*) // app-exp(rator:cexp, rands:list(cexp)) // proc-exp(params:list(var-decl), body:list(cexp), return-te: Texp) (lambda ( <var-decl>*) [: <texp>]? <cexp>+) <prim-op> ::= + - * / < > = not eq? cons car cdr pair? list? number? boolean? symbol? display newline <num-exp> ::= a number token <bool-exp> ::= #t #f <var-ref> ::= an identifier token <sexp> ::= a symbol token ( <sexp>* )

22 Type Annotations Ex. (define [x : number] 5) (define [f : [number -> number]] (lambda ([x : number]) : number (* x x)) (define [g : [number * number -> number]] (lambda ([x : number] [y : number]) : number (+ x y)) (let (([a : number] 1) ([b : boolean] #t)) (if b a (+ a 1))) (letrec (([a : (number -> number)] (lambda ([x : number]) : number (* x x)))) (a 3)) (define [id : (T1 -> T1)] (lambda ([x : T1]) : T1 x))

23 Type Annotations Ex. The type annotations are optional. Thus the following is also legal: (define f (lambda ([x : number]) (* x x))) (let ((a 1)) (+ a a))

24 L5 parsing implementation Code in L5-ast.rkt Functions: parse-texp(concrete-type-expression) --> texp AST unparse-texp(texp) --> concrete-type-expression parsel5(concrete-l5) --> L5 AST unparsel5(l5ast) --> concrete L5 program

25 Type expression ASTs (parse-texp 'number) => 'num-te (parse-texp 'boolean) => 'bool-te (parse-texp 'void) => 'void-te (parse-texp 'T1) => '(tvar T1) (parse-texp '(T * T -> boolean)) => '(proc-te ((tvar T) (tvar T)) bool-te) (parse-texp '(number -> (number -> number))) => '(proc-te (num-te) (proc-te (num-te) num-te)) (parse-texp '(Empty -> void)) => '(proc-te () void-te)

26 L5 ASTs (parsel5 '(define [x : number] 1)) => '(def-exp (var-decl x num-te) (num-exp 1)) (parsel5 '(lambda ([x : number]) : number x)) => '(proc-exp ((var-decl x num-te)) ((var-ref x)) num-te)

27 Type Analysis Alg. The type checker alg: Input: L5-AST of fully typed L5-expr E Output: o o Type of E if E is type safe, one of the following errors otherwise: An attempt to apply a value which is neither a primitive nor a closure in an application expression. An attempt to apply a procedure or a primitive operator to the wrong number of arguments. An attempt to apply primitives to wrong type of arguments (for example, + to a non-number value) An attempt to use a non-boolean expression as the test in an if-expression.

28 Type of typeof-exp What should be the type of typeof-exp? Perhaps: typeof-exp: Expr -> TExp Works for atomic expressions typeof-exp(<num-exp val>) => num-te But what if the expression has variables? It depends on the value assigned to the variable We must then also provide the typeof-exp procedure a type-environment typeof-exp: Expr * TEnv-> TExp

29 Type checker Fully typed expression E, type environment TEnv Type Checker Type of E Applying non-proc / Wrong # of args / Wrong type of args / Non-boolean test

30 Type Environment A type environment is a mapping of a finite set of variables to type expressions (i.e. a substitution) o E.g. {x : number, y : [number -> T] } Built inductively: 1. The empty type environment, denoted {}, makes no assumptions about types of variables. 2. An extended-environment combines new assumptions about variable-type mappings with an existing type environment (i.e. a substitution composition) o E.g. {x : number, y : [number -> T] } o {z: Boolean} = {x : number, y : [number -> T], z: Boolean}

31 Typeof on atoms & var-ref typeof-exp: Expr * TEnv-> Texp typeof-exp(<num-exp val>, Tenv) => num-te typeof-exp(<bool-exp val>, Tenv) => bool-te typeof-exp(<varref var>, Tenv) => Tenv(var) What if v is not in Tenv? For now, we throw an error, because we consider only fully-typed programs. We will come back to this when we consider type inference.

32 Typing Statements A typing statement is a true or false formula stating a judgment about whether it is true that a certain expression e has type Te in type environment Tenv Notation: Tenv ` e:t Examples: {x:number} ` (+ x 5):Number {x:boolean} ` (+ x 5):Number {f:[t1 -> T2], g:t1} ` (f g):t2 {f:[t1 -> T2]} ` (f g):t2 {f:[empty -> T2], g:t2} ` (f g):t2 {f:[empty -> T2], g:t2} ` (f):t2

33 Typing Axioms As in any deductive systems, we have axioms and inference rules. Typing axiom Number: For every type environment _Tenv and number _n: _Tenv ` (num_exp _n) : Number Typing axiom Boolean : For every type environment _Tenv and boolean _b: _Tenv ` (bool_exp _b) : Boolean Typing axiom Variable : For every type environment _Tenv and variable _v: _Tenv ` (varref _v) : _Tenv(_v)

34 Typing Axioms Typing Axioms for primitive operators: Typing axiom for +: For every type environment _Tenv: _Tenv ` + : [Number * * Number -> Number ] Typing axiom for <: For every type environment _Tenv: _Tenv ` < : [Number * Number -> Boolean] Typing axiom for not: For every type environment _Tenv and type expressions _S: _Tenv ` not: [_S -> Boolean]

35 Typing Rule for Procedures Typing inference rule for Procedure Def: For every type environment _Tenv, variables _x1,..., _xn, n >= 0 expressions _e1,..., _em, m >= 1, and type expressions _S1,...,_Sn, _U1,...,_Um : Procedure with parameters (n > 0): If _Tenv o {_x1:_s1,..., _xn:_sn } ` _ei:_ui for all i = 1..m, Then _Tenv ` (lambda (_x1... _xn ) _e1... _em) : [_S1 *... * _Sn -> _Um] Parameter-less Procedure (n = 0): If _Tenv ` _ei:_ui for all i=1..m, Then _Tenv `(lambda () _e1... _em) : [Empty -> _Um]

36 Exhaustive Sub-Expression Typing Every typing rule for expression E requires typing statements for all sub-expressions of E. This property guarantees type safety the typing algorithm assign a type to every subexpression which is evaluated at run-time. Still missing: Typing rule for if-exp Typing rule for application expressions Typing rules for let and letrec expressions Later on

37 Type Checking Algorithm ;; Purpose: Compute the type of an expression ;; Signature: typeof=exp(exp, tenv) ;; Type: [Exp * Tenv -> TExp] ;; Precondition: Exp is fully typed ;; Postcondition: Texp is the type Exp in TEnv ;; Traverse the AST and check the type according to the exp type. (define typeof-exp (lambda (exp tenv) (cond [(num-exp? exp) (typeof-num-exp exp)] [(bool-exp? exp) (typeof-bool-exp exp)] [(prim-op? exp) (typeof-prim-op exp)] [(var-ref? exp) (apply-tenv tenv (var-ref->var exp))] [(if-exp? exp) (typeof-if-exp exp tenv)] [(proc-exp? exp) (typeof-proc-exp exp tenv)] [(let-exp? exp) (typeof-let-exp exp tenv)] [(letrec-exp? exp) (typeof-letrec-exp exp tenv)] [(app-exp? exp) (typeof-app-exp exp tenv)] [else (error "Unknown exp type" exp)])))

38 Type Checking Algorithm The atomic cases are simple, and don t require the Tenv ;; a number literal has type num-te ;; Type: [Num-exp -> Num-te] (define typeof-num-exp (lambda (num) (make-num-te))) ;; a boolean literal has type bool-te ;; Type: [Bool-exp -> Bool-te] (define typeof-bool-exp (lambda (bool) (make-bool-te)))

39 Type Checking Algorithm Primitive operators are mapped to their type expression: ;; primitive ops have known proc-te types ;; Type: [Prim-op -> Proc-te] (define typeof-prim-op (lambda (x) (let ([num-op-te (parse-texp '(number * number -> number))] [num-comp-op-te (parse-texp '(number * number -> boolean))] [bool-op-te (parse-texp '(boolean -> boolean))] [x (prim-op->op x)]) (cond [(eq? x '+) num-op-te] [(eq? x '-) num-op-te] [(eq? x '*) num-op-te] [(eq? x '/) num-op-te] [(eq? x '<) num-comp-op-te] [(eq? x '>) num-comp-op-te] [(eq? x '=) num-comp-op-te] [(eq? x 'not) bool-op-te] ))))

40 Type Inference for If What should be the type inference rule for if? o Clearly we should demand the test to be of type Boolean o What about the then-expr and else-expr? Should they be of the same type? Allowing them to have different type will complicate the type inference system. We thus require them to be of the same type. Typing inference rule for If: For every type environment _Tenv, expressions _test, _then, _else type expressions _S If _Tenv ` _test: Boolean _Tenv ` _then: _S _Tenv ` _else: _S Then _Tenv ` (if _test _then _else) : _S

41 Type Checking Algorithm For if expression : ;; Purpose: compute the type of an if-exp ;; Signature: typeof-if-exp(ifexp, tenv) ;; Type: [If-exp * Tenv -> Texp] ;; Typing rule: ;; if type<test>(tenv) = boolean ;; type<then>(tenv) = t1 ;; type<else>(tenv) = t1 ;; then type<(if test then else)>(tenv) = t1 (define typeof-if-exp (lambda (ifexp tenv) (let ([test-te (typeof-exp (if-exp->test ifexp) tenv)] [then-te (typeof-exp (if-exp->then ifexp) tenv)] [else-te (typeof-exp (if-exp->else ifexp) tenv)]) (check-equal-type! test-te (make-bool-te) ifexp) (check-equal-type! then-te else-te ifexp) then-te)))

42 Type Constraint Check For type checking, the type-constraint check is a simple equality We will change this when we consider type inference. ;; Purpose: Check that type expressions are equivalent ;; as part of a fully-annotated type check process of exp. ;; Throws an error if the types are different ;; - void otherwise. ;; Exp is only passed for documentation purposes. ;; Type: [TE * TE * Exp -> Void] (define check-equal-type! (lambda (te1 te2 exp) (or (equal? te1 te2) (error "Incompatible types " (unparse-texp te1) (unparse-texp te2) (unparse exp)))))

43 Type Checking Algorithm For procedures: ;; Purpose: compute the type of a proc-exp ;; Signature: typeof-proc-exp(proc, tenv) ;; Type: [proc-exp * Tenv -> Texp] ;; Typing rule: ;; If type<body>(extend-tenv(x1=t1,...,xn=tn; tenv)) = t ;; then type<lambda (x1:t1,...,xn:tn) : t exp)>(tenv) = (t1 *... * tn -> t) (define typeof-proc-exp (lambda (proc tenv) (let ([params (proc-exp->params proc)] [body (proc-exp->body proc)]) (let ([params-tes (map var-decl->texp params)] [return-te (proc-exp->return-te proc)]) (check-equal-type! (typeof-exps body (extend-tenv tenv (map var-decl->var params) params-tes)) return-te proc) (make-proc-te params-tes return-te)))))

44 Typing Rule for Application Typing inference rule for Application: For every: type environment _Tenv, expressions _f, _e1,..., _en, n 0, and type expressions _S1,..., _Sn, _S: Procedure with parameters (n > 0): If _Tenv ` _f:[_s1*...*_sn -> _S], _Tenv ` _e1:_s1,..., _Tenv ` _en:_sn Then _Tenv ` (_f _e1... _en):_s Parameter-less Procedure (n = 0): If _Tenv ` _f:[empty -> _S] Then _Tenv ` (_f):_s

45 Type Checking Algorithm ;; Purpose: compute the type of an app-exp ;; Signature: typeof-app-exp(app, tenv) ;; Type: [app-exp * Tenv -> Texp] ;; Typing rule: ;; If type<rator>(tenv) = (t1*..*tn -> t) ;; type<rand1>(tenv) = t1 ;;... ;; type<randn>(tenv) = tn ;; then type<(rator rand1...randn)>(tenv) = t ;; We also check the correct number of arguments is passed. (define typeof-app-exp (lambda (app tenv) (let ([rator (app-exp->rator app)] [rands (app-exp->rands app)]) (let ([rator-te (typeof-exp rator tenv)]) (if (not (= (length rands) (length (proc-te->param-tes rator-te)))) (error "Wrong number of arguments passed to procedure" (unparse app)) 'number-or-args-ok) (for-each (lambda (rand-i t-i) (check-equal-type! (typeof-exp rand-i tenv) t-i app)) rands (proc-te->param-tes rator-te)) (proc-te->return-te rator-te)))))

46 Type Checking Examples (if (> 1 2) 1 2)) => 'number (if (= 1 2) #t #f)) => 'boolean (lambda ([x : number]) : number x)) => '(number -> number) (lambda ([x : number]) : boolean (> x 1))) => '(number -> boolean) (lambda ([x : number]) : (number -> number) (lambda ([y : number]) : number (* y x)))) => (number -> (number -> number))

47 Type Checking Examples (lambda ([f : (number -> number)]) : number (f 2))) => ((number -> number) -> number) (let (([x : number] 1)) (* x 2))) => 'number (let (([x : number] 1) ([y : number] 2)) (lambda ([a : number]) : number (+ (* x a) y)))) => (number -> number) (lambda ([x : number]) : number (let (([y : number] x)) (+ x y)))) => (number -> number)

48 Type Checking Alg. Overview It is a typical syntax-driven traversal of the expression AST. All the nodes in the AST are exhaustively traversed. On each node, we apply a typing rule and compute a type value. We maintain an environment reflecting the scope of variables o When a new scope is created (in procedure expressions), we extend the environment with the type of the declared parameters. o When variables are bound (e.g. in application expressions, let or letrec expressions) we check they adhere to the declared type

49 Type Checker vs. Interpreter Type Checker Interpreter Static Analysis: sees only program text Binds identifiers to types Compresses set of values (even of size) into types Always terminates Parses the body of an expr exactly once Dynamic Analysis: runs over actual data Binds identifiers to values (or locations) Treats elements of a certain type distinctly Might not terminate Parses the body of an expr zero to times

50 Summary We designed a type language to specify the expected type of variables and expressions in the language. We extend the syntax of the programming language to allow association of type annotations (in the type language) with variable declarations and procedures. The semantics of the programming language specifies typing rules Typing rules determine the type of each expression type o under the assumption that the variables are associated to specific types. The assumptions we make about the typing of variables are specified in a type environment. The type checking algorithm determines how to traverse the AST of an expression to check that all the nodes in the expression are correctly typed and compatible with the type annotations.

51 Summary Type safety is one of the conditions we must check to prove correctness: Type checking consists of verifying the type of all sub-expressions, o and possibly infer missing types. Program correctness can be checked either statically or dynamically. In static program correctness the program text is analyzed without running it.

52 Summary We designed a type language to specify the expected type of variables and expressions in the language. We extend the syntax of the programming language to allow association of type annotations (in the type language) with variable declarations and procedures. The semantics of the programming language specifies typing rules

53 Summary Typing rules determine the type of each expression type o under the assumption that the variables are associated to specific types. The assumptions we make about the typing of variables are specified in a type environment. The type checking algorithm determines how to traverse the AST of an expression to check that all the nodes in the expression are correctly typed and compatible with the type annotations.