Semantic Analysis Type Checking

Type Checking Type checking Example typing rules Check type safety against typing rules During the semantic analysis phase Example typing rules Type rule for built in arithmetic operators E.g., operands of % should be integer E.g., operands of + have to be consistent (all integers or all floats) A function has the same number of formal and actual parameters The types of the formal and actual parameters of a function have to match The array range is not violated

Type Checking -- Attribute Grammar First handle type definitions Statement for basic type definitions (discussed earlier) D  id L addtype (id.entry, L.type) L  , id L1 L.type := L1.type; addtype (id.entry, L1.type) L  : T L.type := T.type T  int T.type := integer T  real T.type := real … Then perform type checking within statements

Type Checking -- Attribute Grammar Type checking for the statements from bottom up L  S; L1 L.type  if (S.type = void and L1.type = void) then void else type error S  id := E S.type := if (id.type = E.type) then void else type error E  E1 + T if (E1.type = T.type) then E.type = E1.type else type error S  while C do S1 S.type := if C.type = Boolean then S1.type else type error S  if C then S1 else S2 S.type := if C.type = Boolean then ? else type error if (S1.Type = void and S2.Type = void) then return void

Type Definitions Basic Types Compound types Integer, real, Boolean, char, etc. Compound types Pointers Type = pointer (basic-type) Array Type = array (dimension) Structure Type = structure with the types of all fields Function Type = function with the types of all parameters

Type Definitions Type equivalence Subtypes array(a,b) array(c,d) In some situations, like parameter passing, they are structurally equivalent, or they have a common super type of 2D array struct A { int ai; char ac; } struct B { int bi; char bc; } A and B are structurally equivalent Subtypes Define subtype relation e.g., A  B: A is a subtype of B A may be accepted anywhere B is expected

Static and Dynamic Type Checking Static typing Types can be determined and checked at compilation time A variable has a single type throughout its lifetime More conservative, correct program may be rejected Dynamic typing Types are defined and checked at execution time Type may change during execution Degrading performance for type checking at run time Combined Some type checking may not be done fully statically Do all possible checking statically, and leave the uncertain type checking till run time

Static and Dynamic Type Checking Example: static type checking is conservative Class A { cat: Category; a(): …; } Class B inherits A { cat = B; b(): …; } Class C inherits A { cat = C; c(): …; } B  A, C  A F (obj: A) { switch obj.cat: B: obj.a(); obj.b(); C: obj.a(); obj.c(); default: … endcase; } The program would be correct with dynamic type checking But will fail on static type checking No function b() in class A

Static and Dynamic Type Checking Example: static type checking is conservative function f(x) { return x < 10 ? y : z(); } if (…) then f(5); else f(15); The program would be correct with dynamic type checking Because only one branch is executed and type checked But will fail on static type checking Inconsistent function type Assume that y and z() are of different types

Static and Dynamic Type Checking Static type checking -- example rules Type matching for functions and expressions Type matching (Boolean) for conditional statements Java also checks Illegitimate type casting (only allowed between sub-super types) Accesses to private fields Dynamic type checking -- example rules Divide by 0, array bound OCaml combines static and dynamic type checking E.g., check array bound errors during dynamic type checking Script languages such as Python, Ruby only perform dynamic type checking: Use general static typing rules

Static Type Checking -- Correctness Soundness Given type rule X, a static checker is supposed to assure X A static checker is sound if it never accepts a program that may violate X during execution (given any input) No false negatives, never have: “a faulty behavior is not caught” Completeness A static checker is complete if it never rejects a program P if P will never violate X during its execution with any input No false positives In general, static checker is designed to be sound, but not complete

Static Type Checking -- Type Inference Language without type definitions Still can perform static type checking Need to perform type inference to assign types to variables First proposed and applied to -calculus, then ML, then Haskell Type inference method Build parse tree (or AST) Assign type variables to identifiers Generate constraints based on (1) Constants (2) Built-in operators +. *, %, etc., (3) Typed functions (e.g. in ML, first, tail) All the steps above can be done during parsing (attribute grammar) Solve constraints Undetermined type variables  Has polymorphic type  Use the closest super type for the variable Haskell uses bottom up type inference on parse tree Possible because it has very strict typing rules - Overloaded operators should be type consistent e.g., int = int + int, real = real + real - IO has strict type assignments

Static Type Checking -- Type Inference You can build a graph (matrix or list) to show the relations of variables. If a type variable has relation to another, mark the matrix. During inference, whenever one type variable changes value, check all those that has relations to it and propagate the check. Or, you can maintain another list to record the type variables that have changed in a round, and propagate the check round by round. Static Type Checking -- Type Inference Example Example type rules Operands of arithmetic operators have to be one of the number types (int, float, double) (sub-super type is fine), and the result should be a super type of the operands Operands and the result of % have to be integer Array index has to be natural numbers (integer) Example program Input (a, s, t, n); x := a + 2.5; y := s % t; L = (“this”, “is”, “a”, “list”); elem = L[n]; m := y / n; v = m * a; If / is overloaded for int and float/double, then “y / n” should be integer division Type error: y := s % x float  x.type  double a.type double y.type = s.type = t.type = int L.type = array of strings elem.type = string n.type = int m.type = int v.type  double

Strong Typing and Weak Typing A language is strongly typed Type errors are always detected, statically or dynamically There is strict enforcement of type rules with no exceptions The line between strong/week typing does not have consensus Ada, Java, and Haskell are strongly typed C is almost strongly typed, but union is the loophole Cannot assure type consistency with union

Strong Typing and Weak Typing Coercion and polymorphism blurs the line on strong or weak typing Coercion: such as type casting in C Especially dangerous for pointer type casting Coercion example x = 1; y = “2”; z = x + y JavaScript: z = 12 Visual Basic: z = 3 Polymorphism Earlier example of inconsistent return type  Make type checking difficult Python is strongly or weakly typed Still being debated, mostly consider it as strongly typed But how it handles polymorphism makes this debatable

Type Checking -- Summary Read Chapter 6 Sections 6.3, 6.5