1 / 27

CS412/413

CS412/413. Introduction to Compilers and Translators March 15, 1999 Lecture 19: Object types. Administration. Programming Assignment 3, Part I due Friday Reading: Appel, Chapter 14. Abstraction Mechanisms.

dustya
Download Presentation

CS412/413

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS412/413 Introduction to Compilers and Translators March 15, 1999 Lecture 19: Object types

  2. Administration • Programming Assignment 3, Part Idue Friday • Reading: Appel, Chapter 14 CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  3. Abstraction Mechanisms • Last time: various ways of aggregating several pieces of data to create a user-defined data type • Records—set of named fields with types • Abstract types—pair of abstract type (interface) and concrete type (implementation) • One-to-one binding • Interface defines only operations (hence abstract); encapsulates implementation • Implementation known at link time -- clients are insulated from changes, but harder to optimize TA TC CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  4. Java Classes as Abstract Types • Source code for a class defines the concrete type (implementation) • Interface defined by public variables and methods of class • Compiler automatically decides interface based on contents of .class file (unlike Iota, with .int files) • Interface checked against implementation at run time! CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  5. TA TC1 TC2 TC3 TC4 Multiple Implementations • Allow multiple implementations (concrete types) for any given abstract type • Introduces named, purely abstract types • Implementation for typeoperations known only atrun-time • Code for abstract type operations not known until operations actually invoked • Can determine code to execute at run time by looking up in dispatch vector CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  6. Multiple Impls in Java interface Point { float x(); float y(); } class XYPoint impls Point { private float x_, y_; public float x() { return x_; } ... } class Polar impls Point { private float r, theta; public float x() { return r*cos(theta); } … } Point XYPoint (a) RTPoint(a) XYPoint (c) RTPoint(a) What is this arc? CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  7. Subtypes • Idea: one interface can extend another by adding more operations interface Point { float x(); float y(); } interface ColoredPoint extends Point { float x(); float y(); Color color(); } Point ColoredPoint is a subtype of ColoredPoint Point CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  8. Subtype properties If type S is a subtype of type T (S  T): A value of type S may be used wherever a value of type T is expected (e.g., assignment to a variable, passed as argument, returned from method) Point x; ColoredPoint y; ... x = y; ColoredPoint Point CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  9. I2 C2 (abstract) I C (abstract) C (abstract) I Subtypes in Java interface I extends I2 { … } class C implements I { … } class C extends C2 C2 (concrete) inherits C (concrete) CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  10. Subtype hierarchy • Introduction of subtype relation creates a hierarchy of types: subtype hierarchy I1 C1 type or subtype hierarchy I2 I3 C4 C2 C3 class hierarchy C5 CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  11. Subtype  Subset S  T  values(S)  values(T) “A value of type S may be used wherever a value of type T is expected” values of type S values of type T CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  12. Static Semantics values(S)  values(T) A|– E : S A|– E : T A|– S T “S is a subtype of T in environment A” CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  13. Subtyping axioms • Subtype relation is reflexive A|– T T • Transitive: A|– S T A|– R S A|– R T • Defines an ordering on types (pre-order) • Rules are needed to define judgement on various type kinds (primitives, records, &c) CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  14. Implementing Type-checking • Problem: static semantics is supposed to find a type for every expression, but expressions have (in general) many types • Which type to pick? I1 C1 I2 I3 C4 C2 C3 C5 CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  15. Principal Type • Idea: every expression has a principal type that is the most-specific type of the expression • Subsumption rule: A|– E :Tp A|– TpT A|– E :T • Using subsumption rule, can infer all supertypes if principal type is used I1 C1 I2 I3 C4 C2 C3 C5 CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  16. Type-checking interface • Old method for checking types: abstract class ASTNode { abstract Type typeCheck(SymTab A); // Return the principal type of this// statement or expression } • No changes in interface needed to support subtyping, except interpretation of result of typeCheck CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  17. Type-checking rules • Rules for checking code must allow a subtype where a supertype was expected • Old rule for assignment: id : T A A |– E : T A |– id = E; : T What needs to change here? CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  18. A |– E :Tp A |– TpT A |– E :T id : T A A |– E : T A |– id = E; : T Type-checking code class Assignment extends ASTNode { String id; Expr E; Type typeCheck(SymTab A) { Type Tp = E.typeCheck(A); Type T = A.lookupVariable(id); if (Tp.subtypeOf(T)) return T; else throw new TypecheckError(E); } } CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  19. Unification • Some rules more problematic: if • Rule: A |– E : bool A |– S1 : T A |– S2 : T A |– if ( E ) S1 else S2 : T • Problem: suppose S1 has principal type T1,S2 has principal type T2. Old check: T1 = T2 . New check: need principal type T. How to unify T1 , T2 ? CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  20. Unification in subtype hierarchy • Idea: unified principal type is least common ancestor in type hierarchy LCA(C3, C5) = I1 I1 C1 I2 I3 Logic: I1 must be same as or subtype of any type that could be the type of both a value of type C3 and a value of type C5 C4 C2 C3 C5 CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  21. Explicit vs Structural subtypes • Java: all subtypes explicitly declared, name equivalence for types. Subtype relationships inferred by transitive extension. • Languages with structural equivalence (e.g., Modula-3): subtypes inferred based on structure of types; no extends declaration • Same checking done in each case; explicitly declared subtypes must follow rules for recognizing subtypes implicitly CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  22. x x y y c T S Testing subtype relation • Subtyping for recordsS  T means S has at least the fields of T {x: int, y: int, c: Color}  { x: int, y: int } • Implementation: CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  23. x z z y Subtype rule for records {x: int, y: int, c: Color}  { x: int, y: int } i ( ai : Ti ) S A|– S  {…, ai: Ti ,…} • Question: what about allowing field types to vary? • If Point  ColoredPoint, should we allow{ p: ColoredPoint, z: int }  { p: Point, z: int } ? p x p y c CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  24. Field Invariance Try { p: ColoredPoint }  { p: Point } x: {p: Point} y: {p: ColoredPoint} x = y; x.p = new 3DPoint( ); • Mutable (assignable) fields must be invariant under subtyping Point ColoredPoint 3DPoint CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  25. Covariance • Immutable record fields may change with subtyping (may be covariant) • Suppose we allow variables to be declared final -- x : final int • Safe: { p: final ColoredPoint, z: int }  { p: final Point, z: int } p x p x y z z y c CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  26. Immutable record subtyping ( ai : T’i ) S A |– T’i Ti A|– S  {…, ai: Ti ,…} • Corresponding fields may be subtypes; exact match not required CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  27. Summary • Multiple implementation of abstract types special case of subtyping • Subtyping characterized by new judgement: A|– S T • Old judgement A|– E :T plus subsumption rule, defn. of subtype relation defines new type-checking process • Mutable fields must be invariant in subtype relation; immutable fields may be covariant CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

More Related