PLaC-6.1 6. Type specification and type analysis A type characterizes a set of (simple or structured) values and the applicable operations. The language design constrains the way how values may interact. Strongly typed language: The implementation can guarantee that all type constraints can be checked * at compile time (static typing): compiler finds type errors (developer), or * at run time (dynamic typing): run time checks find type errors (tester, user). static typing (plus run time checks): Java (strong); C, C++, Pascal, Ada (almost strong) dynamic: script languages like Perl, PHP, JavaScript no typing: Prolog, Lisp Statically typed language: Programmer declares type property - compiler checks (most languages) Programmer uses typed entities - compiler infers their type properties (e.g. SML) Compiler keeps track of the type of any * defined entity that has a value (e. g. variable); stores type property in the definition module * program construct elaborates to a value (e. g. expressions); stores type in an attribute -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 601 Objectives: Fundamentals of typing constrains In the lecture: * Motivate type analysis tasks with typical properties of strongly typed languages; * give examples Suggested reading: Kastens / Übersetzerbau, Section 6.1 Questions: * Give examples for program entities that have a type property and for others which don't. * Enumerate at least 5 properties of types in Java, C or Pascal. * Give an example for a recursively defined type, and show its representation using keys. -------------------------------------------------------------------------------- PLaC-6.2 Concepts for type analysis Type: characterization of a subset of the values in the universe of operands available to the program. "a triple of int values" Type denotation: a source-language construct used to denote a user-defined typ (language-defined types do not require type denotations). typedef struct {int year, month, day;} Date; sameType: a partition defining type denotations that might denote the same type. Type identifier: a name used in a source-language program to specify a type. typedef struct {int year, month, day;} Date; Typed identifier: a name used in a source-language program to specify an entity (such as a variable) that can take any value of a given type. int count; Operator: an entity having a signature that relates operand types to a result type. iAdd: int x int -> int Indication: a set of operators with different signatures. {iAdd, fAdd, union, concat} acceptableAs: a partial order defining the types that can be used in a context where a specific type is expected. short -> int -> long (c) 2011 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 602 Objectives: Understand fundamental concepts In the lecture: * concepts are language independent, * give examples of different languages Suggested reading: Kastens / Übersetzerbau, Section 6.1 Questions: * Give further examples for instances of these concepts -------------------------------------------------------------------------------- PLaC-6.3 Taxonomy of type systems [Luca Cardelli and Peter Wegner. On understanding types, data abstraction, and polymorphism. ACM Computing Surveys, 17(4):471endash 523, 1985.] - monomorphism: Every entity has a unique type. Consequence: different operators for similar operations (e.g. for int and float addition) - polymorphism: An operand may belong to several types. -- ad hoc polymorphism: --- overloading: a construct may different meanings depending on the context in which it appears (e.g. + with 4 different signatures in Algol 60) --- coercion: implicit conversion of a value into a corresponding value of a different type, which the compiler can insert wherever it is appropriate (only 2 add operators) -- universal polymorphism: operations work uniformly on a range of types that have a common structure --- inclusion polymorphism: sub-typing as in object-oriented languages --- parametric polymorphism: polytypes are type denotations with type parameters, e.g. ('a x 'a), ('a list x ('a -> 'b) -> 'b list) All types derivable from a polytype have the same type abstraction. Type parameters are substituted by type inference (SML, Haskell) or by generic instantiation (C++, Java) see GPS 5.9 - 5.10 (c) 2011 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 603 Objectives: Understand characteristics of type systems In the lecture: * different polymorphisms are explained using examples of different languages; * consequences for type analysis are pointed out. Suggested reading: Kastens / Übersetzerbau, Section 6.1 Questions: * Which characteristics are exhibited in Java and in C? -------------------------------------------------------------------------------- PLaC-6.3a Monomorphism and ad hoc polymorphism monomorphism monomorphism (1): (1) polymorphism 4 different names for addition: ad hoc polymorphism addII: int x int -> int overloading (2) addIF: int x float -> float coercion (3) addFI: float x int -> float universal polymorphism inclusion polymorphism (4) addFF: float x float -> float parametric polymorphism (5) overloading (2): coercion (3): 1 name for addition +; int is acceptableAs float, 4 signatures are distinguished by actual 2 names for two signatures: operand and result types: addII: int x int -> int +: int x int -> int addFF: float x float -> float +: int x float -> float +: float x int -> float +: float x float -> float (c) 2011 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 603a Objectives: Examples illustrate monomorphism and ad hoc polymorphism In the lecture: * The examples are explained Suggested reading: Kastens / Übersetzerbau, Section 6.1 -------------------------------------------------------------------------------- PLaC-6.3b Examples for inclusion polymorphism (4) Sub-typing: S ist a sub-type of type T, S <: T, if each value of S is acceptable where a value of type T is expected. Sub-type relation established by Lattice of set types in Pascal: classes in object-oriented languages: Animal set of integer (top) Bird Fish set of 1..6 A function of type fS can be called where set of 2..4 set of 3..5 set of 4..5 a function of type fT is expected, i.e. fS <: fT, if fT = paramT -> resultT paramT <: paramS set of 3..3 set of 4..4 fS = paramS -> resultS resultS <: resultT set of bottom fT fS paramT <: paramS resultS <: resultT (c) 2011 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 603b Objectives: Understand inclusion polymorphism In the lecture: * The central rule, * OO sub-typing, * type safe overriding, * contravariant parameter types are explained. Suggested reading: Kastens / Übersetzerbau, Section 6.1 -------------------------------------------------------------------------------- PLaC-6.4 Compiler's definition module Central data structure, stores properties of program entities e. g. type of a variable, element type of an array type A program entity is identified by the key of its entry in this data structure. Operations: NewKey ( ) yields a new key ResetP (k, v) sets the property P to have the value v for key k SetP (k, v, d) as ResetP; but the property is set to d if it has been set before GetP (k, d) yields the value of the Property P for the key k; yields the default value d, if P has not been set Operations are called in tree contexts, dependences control accesses, e. g. SetP before GetP Implementation of data structure:a property list for every key Definition module is generated from specifications of the form Property name : property type; ElementNumber: int; Generated functions: ResetElementNumber, SetElementNumber, GetElementNumber -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 604 Objectives: Properties of program entities In the lecture: * Explain the operations, * explain the generator, * give examples. Assignments: * Use the PDL tool of Eli to specify properties of SetLan entities. Questions: * Give examples where calls of the operations are specified as computations in tree contexts. Describe how they depend on each other. -------------------------------------------------------------------------------- PLaC-6.5 Language defined entities Language-defined types, operators, and indications are represented by known keys - definition table keys, created by initialization and made available as named constants. Eli's specification language OIL can be used to specify language defined types, operators, and indications, e.g.: OPER iAdd (intType,intType):intType; rAdd (floatType,floatType):floatType; INDICATION PlusOp: iAdd, rAdd; COERCION (intType):floatType; It results in known keys for two types, two operators, and an indication. The following identifiers can be used to name those keys in tree computations: intType, floatType, iAdd, rAdd, PlusOp RULE: Operator ::= '+' COMPUTE Operator.Indic = PlusOp;END; The coercion establishes the language-defined relation intType acceptableAs floatType (c) 2009 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 605 Objectives: Specification of overloaded operators and coercion In the lecture: Explain the signatures, indications, and coercions Assignments: * Use the OIL tool of Eli to specify SetLan operators -------------------------------------------------------------------------------- PLaC-6.6 Language-defined and user-defined types A language-defined type is represented by a keyword in a program. The compiler determines sets an attribute Type.Type: RULE: Type ::= 'int' COMPUTE Type.Type = intType; END; The type analysis modules of Eli export a computational role for user-defined types: TypeDenotation: denotation of a user-defined type. The Type attribute of the symbol inheriting this role is set to a new definition table key by a module computation. RULE: Type ::= ArrayType COMPUTE Type.Type = ArrayType.Type; END; SYMBOL ArrayType INHERITS TypeDenotation END; RULE: ArrayType ::= Type '[' ']' END; (c) 2011 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 606 Objectives: Eli specification of language- and user-defined types In the lecture: Explain the computation and the use of the attributes Assignments: * Specify the SetLan types. -------------------------------------------------------------------------------- PLaC-6.7 Classification of identifiers (1) The type analysis modules export four computational roles to classify identifiers: TypeDefDefId: definition of a type identifier. The designer must write a computation setting the Type attribute of this symbol to the type bound to the identifier. TypeDefUseId: reference to a type identifier defined elsewhere. The Type attribute of this symbol is set by a module computation to the type bound to the identifier. TypedDefId: definition of a typed identifier. The designer must write a computation setting the Type attribute of this symbol to the type bound to the identifier. TypedUseId: reference to a typed identifier defined elsewhere. The Type attribute of this symbol is set by a module computation to the type bound to the identifier. SYMBOL ClassBody INHERITS TypeDenotation END; SYMBOL TypIdDef INHERITS TypeDefDefId END; SYMBOL TypIdUse INHERITS TypeDefUseId END; RULE: ClassDecl ::= OptModifiers 'class' TypIdDef OptSuper OptInterfaces ClassBody COMPUTE TypIdDef.Type = ClassBody.Type; END; RULE: Type ::= TypIdUse COMPUTE Type.Type = TypIdUse.Type; END; (c) 2009 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 607 Objectives: Specifiy the roles of identifiers In the lecture: Explain the meaning of the roles Assignments: * Specify the SetLan types. -------------------------------------------------------------------------------- PLaC-6.7a Classification of identifiers (2) A declaration introduces typed entities; it plays the role TypedDefinition. TypedDefId is the role for identifiers in a context where the type of the bound entity is determined TypedUseId is the role for identifiers in a context where the type of the bound entity is used. The role ChkTypedUseId checks whether a type can be determined for the particular entity: RULE: Declaration ::= Type VarNameDefs quotesingle ;quotesingle COMPUTE Declaration.Type = Type.Type; END; SYMBOL Declaration INHERITS TypedDefinition END; SYMBOL VarNameDef INHERITS TypedDefId END; SYMBOL VarNameUse INHERITS TypedUseId, ChkTypedUseId END; (c) 2009 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 607a Objectives: Specifiy the roles of identifiers In the lecture: Explain the use of the roles Assignments: * Specify the SetLan types. -------------------------------------------------------------------------------- PLaC-6.8 Type analysis for expressions (1): trees An expression node represents a program construct that yields a value, and an expression tree is a subtree of the AST made up entirely of expression nodes. Type analysis within an expression tree is uniform; additional specifications are needed only at the roots and leaves. The type analysis modules export the role ExpressionSymbol to classify expression nodes. It carries two attributes that characterize the node inheriting it: Type: the type of value delivered by the node. It is always set by a module computation. Required: the type of value required by the context in which the node appears. The designer may write a computation to set this inherited attribute in the upper context if the node is the root of an expression tree; otherwise it is set by a module computation. A node n is type-correct if (n.Type acceptableAs n.Required). PrimaryContext expands to attribute computations that set the Type attribute of an expression tree leaf. The first argument must be the grammar symbol representing the expression leaf, which must inherit the ExpressionSymbol role. The second argument must be the result type of the expression leaf. DyadicContext characterizes expression nodes with two operands. All four arguments of DyadicContext are grammar symbols: the result expression, the indication, and the two operand expressions. The second argument symbol must inherit the OperatorSymbol role; the others must inherit ExpressionSymbol. (c) 2012 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 608 Objectives: Specifiy type analysis for expressions In the lecture: Explain the meaning of the roles Assignments: * Specify the typing of SetLan expressions. -------------------------------------------------------------------------------- PLaC-6.9 Type analysis for expressions (2): leaves, operators The nodes of expression trees are characterized by the roles ExpressionSymbol and OperatorSymbol. The tree contexts are characterized by the roles PrimaryContext (for leaf nodes), MonadicContext, DyadicContext, ListContext (for inner nodes), and RootContext: SYMBOL Expr INHERITS ExpressionSymbol END; SYMBOL Operator INHERITS OperatorSymbol END; SYMBOL ExpIdUse INHERITS TypedUseId END; RULE: Expr ::= Integer COMPUTE PrimaryContext(Expr, intType); END; RULE: Expr ::= ExpIdUse COMPUTE PrimaryContext(Expr, ExpIdUse.Type); END; RULE: Expr ::= Expr Operator Expr COMPUTE DyadicContext(Expr[1], Operator, Expr[2], Expr[3]); END; RULE: Operator ::= '+' COMPUTE Operator.Indic = PlusOp; END; (c) 2012 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 609 Objectives: Specifiy type analysis for expressions In the lecture: Explain the use of the roles Assignments: * Specify the typing of SetLan expressions. -------------------------------------------------------------------------------- PLaC-6.9a Type analysis for expressions (3): Balancing The conditional expression of C is an example of a balance context: The type of each branch (Expr[3],Expr[4]) has to be acceptable as the type of the whole conditional expression (Expr[1]): RULE: Expr ::= Expr quotesingle ?quotesingle Expr quotesingle :quotesingle Expr COMPUTE BalanceContext(Expr[1],Expr[3],Expr[4]); END; For the condition the pattern of slide PLaC-6.10 applies. Balancing can also occur with an arbitrary number of expressions the type of which is balanced to yield a common type at the root node of that list, e.g. in SYMBOL CaseExps INHERITS BalanceListRoot, ExpressionSymbolEND; SYMBOL CaseExp INHERITS BalanceListElem, ExpressionSymbolEND; RULE: Expr ::= quotesingle casequotesingle Expr quotesingle inquotesingle CaseExps quotesingle esacquotesingle COMPUTE TransferContext(Expr[1],CaseExps); END; RULE: CaseExps LISTOF CaseExp END; RULE: CaseExp ::= Expr COMPUTE TransferContext(CaseExp,Expr); END; (c) 2012 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 609a Objectives: Understand the notion of balancing of types In the lecture: Explain the use of the roles Assignments: * Specify the typing of SetLan expressions. -------------------------------------------------------------------------------- PLaC-6.10 Type analysis for expressions (4) Each expression tree has a root. The the RULE context in which the expression root in on the left-hand side specifies which requirements are imposed to the type of the expression. In the context of an assignment statement below, both occurrences of Expr are expression tree roots: RULE: Stmt ::= Expr ':=' Expr COMPUTE Expr[2].Required = Expr[2].Type; END; In principle there are 2 different cases how the context states requirements on the type of the Expression root: * no requirement: Expr.Required = NoKey; (can be omitted, is set by default) Expr[1] in the example above * a specific type: Expr.Required = computation of some type; Expr[2] in the example above (c) 2012 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 610 Objectives: Specifiy type analysis for expressions In the lecture: Explain the use of the role in the context of the root of an expression tree Assignments: * Specify the typing of SetLan expressions. -------------------------------------------------------------------------------- PLaC-6.10a Operators of user-defined types User-defined types may introduce operators that have operands of that type, e.g. the indexing operator of an array type: SYMBOL ArrayType INHERITS OperatorDefs END; RULE: ArrayType ::= Type '[' ']' COMPUTE ArrayType.GotOper = DyadicOperator( ArrayAccessor, NoOprName, ArrayType.Type, intType, Type.Type); END; The above introduces an operator definition that has the signature ArrayType.Type x intType -> Type.Type and adds it to the operator set of the indication ArrayAccessor. The context below identifies an operator in that set, using the types of Expr[2] and Subscript. Instead of an operator nonterminal the Indication is given. SYMBOL Subscript INHERITS ExpressionSymbol END; RULE: Expr ::= Expr '[' Subscript ']' COMPUTE DyadicContext(Expr[1], , Expr[2], Subscript); Indication(ArrayAccessor); IF(BadOperator, message(ERROR,"Invalid array reference",0,COORDREF)); END; (c) 2009 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 610a Objectives: Definition and application of user-defined operators In the lecture: Explain the use of the roles Assignments: * Specify the typing of SetLan expressions. -------------------------------------------------------------------------------- PLaC-6.10b Functions and calls Functions (methods) can be considered as operators having n => 0 operands (parameters). Roles: OperatorDefs, ListOperator, and TypeListRoot: SYMBOL MethodHeader INHERITS OperatorDefs END; SYMBOL Parameters INHERITS TypeListRoot END; RULE: MethodHeader ::= OptModifiers Type FctIdDef '(' Parameters ')' OptThrows COMPUTE MethodHeader.GotOper = ListOperator( FctIdDef.Key, NoOprName, Parameters, Type.Type); END; A call of a function (method) with its arguments is then considered as part of an expression tree. The function name (FctIdUse) contributes the Indication: SYMBOL Arguments INHERITS OperandListRoot END; RULE: Expr ::= Expr '.' FctIdUse '(' Arguments ')' COMPUTE ListContext(Expr[1], , Arguments); Indication(FctIdUse.Key); IF(BadOperator,message(ERROR, "Not a function", 0, COORDREF)); END; The specification allows for overloaded functions. (c) 2009 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 610b Objectives: Functions considered as user-defined n-ary operators In the lecture: Explain the use of the roles Assignments: * Specify the typing of SetLan expressions. -------------------------------------------------------------------------------- PLaC-6.10c Type equivalence: name equivalence Two types t and s are name equivalent if their names tn and sn are the same or if tn is defined to be sn or sn defined to be tn. An anonymous type is different from any other type. Name equivalence is applied for example in Pascal, and for classes and interfaces in Java. type a = record x: char; y: real end; b = record x: char; y: real end; c = b; e = record x: char; y: arrowup e end; f = record x: char; y: arrowup g end; g = record x: char; y: arrowup f end; var s, t: record x: char; y: real end; u: a; v: b; w: c; k: e; l: f; m: g; Which types are equivalent? The value of which variable may be assigned to which variable? (c) 2011 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 610c Objectives: Understand name equivalence In the lecture: Explain the examples Questions: Answer the questions on the slide. -------------------------------------------------------------------------------- PLaC-6.10d Type equivalence: structural equivalence In general, two types t and s are structurally equivalent if their definitions become the same when all type identifiers in the definitions of t and in s are recursively substituted by their definitions. (That may lead to infinite trees.) Structural equivalence is applied for example in Algol-68, and for array types in Java. The example of the previous slide is interpreted under structural equivalence: type a = record x: char; y: real end; b = record x: char; y: real end; c = b; e = record x: char; y: arrowup e end; f = record x: char; y: arrowup g end; g = record x: char; y: arrowup f end; var s, t: record x: char; y: real end; u: a; v: b; w: c; k: e; l: f; m: g; Which types are equivalent? The value of which variable may be assigned to which variable? Algorithms determine structural equivalence by decomposing the whole set of types into maximal partitions, which each contain only equivalent types. (c) 2011 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 610d Objectives: Understand structural equivalence In the lecture: Explain the examples Questions: Answer the questions on the slide. -------------------------------------------------------------------------------- PLaC-6.11 Type analysis for object-oriented languages (1) Class hierarchy is a type hierarchy: Circle k = new Circle (...); implicit type coercion: class -> super class explicit type cast: class -> subclass GeometricShape f = k; Variable of class type may contain k = (Circle) f; an object (reference) of its subclass Analyze dynamic method binding; try to decide it statically: static analysis tries to further restrict the run-time type: GeometricShape f;...; f = new Circle(...);...; a = f.area(); (c) 2009 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 611 Objectives: Understand classes as types In the lecture: Explain * class hierarchy - type coercion; * type checking for dynamically bound method calls with compile time information, * predict the runtime class of objects Questions: * Why can it be useful for the compiler to know the bound method exactly? -------------------------------------------------------------------------------- PLaC-6.12 Type analysis for object-oriented languages (2) Check signature of overriding methods: calls must be type safe Java requires the same signature weaker requirements would be sufficient (contra variant parameters, language Sather): call of dynamically X x; A a; P p; a = x.m (p); Variable: bound method: C c; B b; super class class X { C m (Q q) { use of q;... return c; } } subclass class Y { B m (R r) { use of r;... return b; } } Language Eiffel requires covariant parameter types: type unsafe! (c) 2009 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 612 Objectives: Understand classes as types In the lecture: Explain * type checking for dynamically bound method calls with compile time information: * x has type X, * signature of m in X, * m in Y safely overrides m in X; Questions: * Why would overridden methods not be type safe if they had "covariant" parameters (all 3 arrows between the classes X and Y would point up)? That is the situation in Eiffel. -------------------------------------------------------------------------------- PLaC-6.13 Type analysis for functional languages (1) Static typing and type checking without types in declarations Type inference: Types of program entities are inferred from the context where they are used Example in ML: fun choice (cnt, fct) = if fct cnt then cnt else cnt - 1; (i) (ii) (iii) describe the types of entities using type variables: cnt: quotesingle a, fct: quotesingle b->quotesingle c, choice: (quotesingle a * (quotesingle b->quotesingle c)) -> quotesingle d form equations that describe the uses of typed entities (i) quotesingle c= bool (i) quotesingle b= quotesingle a (ii) quotesingle d= quotesingle a (iii) quotesingle a= int solve the system of equations: choice: (int * (int->bool)) -> int (c) 2009 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 613 Objectives: Understand type inference In the lecture: Explain how types are computed using the types of operations and program entities without having typed declarations Questions: * How would type inference find type errors? -------------------------------------------------------------------------------- PLaC-6.14 Type analysis for functional languages (2) Parametrically polymorphic types: types having type parameters Example in ML: fun map (l, f) = if null l then nil else (f (hd l)) :: map (tl l, f) polymorphic signature: map: (quotesingle a list * (quotesingle a -> quotesingle b)) -> quotesingle b list Type inference yields most general type of the function, such that all uses of entities in operations are correct; i. e. as many unbound type parameters as possible calls with different concrete types, consistently substituted for the type parameter: map([1,2,3], fn i => i*i) quotesingle a = int, quotesingle b = int map([1,2,3], even) quotesingle a = int, quotesingle b = bool map([1,2,3], fn i =(i,i)) quotesingle a = int, quotesingle b = (quotesingle a*quotesingle a) (c) 2009 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 614 Objectives: Understand polymorphic types In the lecture: * Explain analysis with polymorphic types. * Explain the difference of polymorphic types and generic types from the view of type analysis. -------------------------------------------------------------------------------- PLaC-6.15 Semantic error handling Design rules: Error reports are to be related to the source code: * Any explicit or implicit requirement of the language definition needs to be checked by an operation in the tree, e. g. if (IdUse.Bind == NoBinding) message (...) * Checks have to be associated to the smallest relevant context yields precise source position for the report; information is to be propagated to that context. wrong: "some arguments have wrong types" * Meaningfull error reports. wrong: "type error" * Different reports for different violations; do not connect symptoms by or All operations specified for the tree are executed, even if errors occur: * introduce error values, e. g. NoKey, NoType, NoOpr * operations that yield results have to yield a reasonable one in case of error, * operations have to accept error values as parameters, * avoid messages for avalanche errors by suitable extension of relations, e. g. every type is compatible with NoType (c) 2009 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Lecture Programming Languages and Compilers WS 2011/12 / Slide 615 Objectives: Design rules for error handling In the lecture: Explanations and examples Suggested reading: Kastens / Übersetzerbau, Section 6.3 --------------------------------------------------------------------------------