Module Mechanisms CS412/413. Modules + abstract types. Abstract types. Multiple Implementations. How to type-check?

Transcription

1 CS412/413 Introduction to Compilers and Translators Andrew Mers Cornell Universit Lecture 19: ADT mechanisms 10 March 00 Module Mechanisms Last time: modules, was to implement ADTs Module collection of related values and tpes; mechanism for separate compilation, encapsulation, abstraction Record set of named fields with tpes; modules similar to records; module interface defines tpe of module value Abstract tpe allows encapsulation of values generated b module Implementation known onl at link time -- clients are insulated from changes, but harder to optimize CS 412/413 Spring '00 Lecture Andrew Mers 2 Abstract tpes Iota+abstract tpes, Modula-3 stle: list.int: declaration of abstract tpe tpe List; gth(l: List): int cons(h: int, l: List): List first(l: List): int rest(l: List): List binding to actual tpe list.mod: tpe List = {: int, : int, : List gth(l: List): int = l. cons(h: int, l: List): List = List{=l.+1,=h,l=l CS 412/413 Spring '00 Lecture Andrew Mers 3 Modules + abstract tpes Module is no longer a record: interface also contains list of abstract tpes Tpe: module(i 1..I n ) { v 1 : T 1 v m : T m tpe I 1... tpe I n v 1 : T 1 v m : T m Stripped-down module snta: tpe I 1 = T 1,, I n = T n v 1 : T 1 = e 1 v m : T m = e m CS 412/413 Spring '00 Lecture Andrew Mers 4 How to tpe-check? Additional issues: module must agree with own interface (everthing implemented, with right tpe) must recognize abstract tpes correctl: add to smbol table You should alread do most of this! A + {I i : tpe = T i (i 1..n) +{v j :T j (j 1..m ) < e k : T k m m A < tpe I 1 = T 1,, I n = T n v 1 : T 1 = e 1 v m : T m = e m (k 1..m ) : module(i 1..I n ) { v 1 : T 1,, v m : T m CS 412/413 Spring '00 Lecture Andrew Mers 5 Multiple Implementations Most (non-oo) languages: onl one implementation of (module value for) an interface Doesn t scale to large programs want multiple modules implementing an interface Approach 1: first-class module values using dependent tpes (e.g. FX-91 language) Approach 2: objects CS 412/413 Spring '00 Lecture Andrew Mers 6 1

2 First-class module values List interface: ListMod = tpe T; gth(t): int cons(int,t): T, first(t): int rest(t): T Two implementations: SimpleList: ListMod = { tpe T = {: int, : T, gth(l: T): int = (/* recurse */), LenList: ListMod = { tpe T = {: int, :int, : T, gth(l: T): int = l., CS 412/413 Spring '00 Lecture Andrew Mers 7 Ambiguit Problem: from interface, don t know which implementation we are dealing with. uses List = ListMod.T list1: List list1? LenList.T s SimpleList.T s CS 412/413 Spring '00 Lecture Andrew Mers 8 Implications Must name module value eplicitl rather than using name of interface: SimpleList.gth, LenList.T instead of ListMod.gth, ListMod.T Code written to use ADT must be passed module value too! sum(list: ListMod, a: list.t): int = if (list.gth(a) == 0) 0 else list.first(a) + sum(list, list.rest(a)) sum(a: ListMod.T): int = vs. if (ListMod.gth(a) == 0) 0 else ListMod.first(a) + sum(a, ) CS 412/413 Spring '00 Lecture Andrew Mers 9 Compiling Multiple Impls Can t stack allocate -- need to know the concrete tpe of a reference (as in C++) Don t know what code to run when an operation (e.g. gth) is invoked L: ListMod, list1: L.T list1 dependent tpe: contains epression (L) L.gth(list1) calls what? LenList.T SimpleList.T CS 412/413 Spring '00 Lecture Andrew Mers 10 Using Module Values First-class module value is record: points to proper code and global variables of module For single implementation (2 nd -class modules), linker makes module calls direct L: ListMod, list1: L.T; L.gth(list1) list1: L.T L: ListMod code (function value) gth gth(l: LenList.T) = l.; first rest CS 412/413 Spring '00 Lecture Andrew Mers 11 Using Objects as ADTs Another wa to etend records into ADTs Source code for a class defines the concrete tpe (implementation) Interface defined b public variables and methods of class class List { public static int gth(list l); public static List cons(int, List); public static int first(list); public static List rest(list); private int, ; private List ; tpe T; gth(t): int cons(int,t): T, first(t): int rest(t): T CS 412/413 Spring '00 Lecture Andrew Mers 12 2

3 Multiple implementations Can model using classes and methods: interface List { int gth(); List cons(int); int first(); List rest(); class LenList implements List { private int, ; private LenList ; private LenList(int h,t) { public int gth() { return ; public List cons(int h) { return new LenList(h, this); class SimpleList impls List { private int ; private SimpleList ; public int gth() { return 1+.gth() CS 412/413 Spring '00 Lecture Andrew Mers 13 The dispatching problem Same problem as with first-class modules: don t know what code to run at compile time. List a; a.gth() ListMod L; ListMod.T a; L.gth(a) SimpleList.gth or LenList.gth? Difference: objects know their implementation without separate module value (no L needed) CS 412/413 Spring '00 Lecture Andrew Mers 14 Objects implemented b adding etra pointer to dispatch vector (also: virtual table) with pointers to method code Code receiving :List onl knows has initial dispatch vector pointer Compiling objects SimpleList LenList List?? dispatch vector SimpleList.gth SimpleList.first SimpleList.rest dispatch vector Lenlist.gth LenList.first LenList.rest CS 412/413 Spring '00 Lecture Andrew Mers 15 Modules vs. objects Objects fold together functionalit of records, abstract tpes and modules Both mechanisms allow forms of polmorphism: code can use values of more than one tpe Mechanisms have subtl different epressive power first-class modules list1: L.T objects list1: List L: ListMod gth first rest dispatch vector gth first rest CS 412/413 Spring '00 Lecture Andrew Mers 16 Binar operations Advantage of abstract tpes: compare LenList in both stles, but with a binar prepend operation: LenList: ListMod = { tpe T = {: int, :int, : T gth(l: T): int = l. cons(h: int, l: T): T = { = l.+1, prepend(l1, l2: T): T = (if (l1. == 0) l2 else cons(l1., prepend(l1., l2))) class LenList implements List {, : int, : List gth() = Can t access l1 fields directl! prepend(l1: List) = ( if (l1.gth() == 0) this else cons(l1.first(), prepend(l1.rest())) CS 412/413 Spring '00 Lecture Andrew Mers 17 Heterogeneit Objects are better for heterogenous data structures containing different implementations of same interface Can mi different List impls in same list LenList SimpleList EmptList CS 412/413 Spring '00 Lecture Andrew Mers 18 3

4 Tpe relationships Relationship of LenList module and List interface is relationship of a value to its tpe LenList, SimpleList : ListMod Relationship of classes and object interfaces is more comple tpes related b subtpe relationship Enables heterogeneous data structures LenList <: List SimpleList <: List LenList List SimpleList CS 412/413 Spring '00 Lecture Andrew Mers 19 Subtpes Idea: one interface can etend another b adding more operations interface Point { float (); float (); interface ColoredPoint etends Point { float (); float (); Color color(); Point ColoredPoint is a subtpe of ColoredPoint <: Point (also: ) CS 412/413 Spring '00 Lecture Andrew Mers 20 Subtpe properties If tpe S is a subtpe of tpe T (S <: T) A value of tpe S ma be used wherever a value of tpe T is epected (e.g., assignment to a variable, passed as argument, returned from method) Point ; ColoredPoint ; ColoredPoint <: Point... subtpe supertpe = ; Subtpe polmorphism: code using T s can also use S s. CS 412/413 Spring '00 Lecture Andrew Mers 21 Subtpes in Java interface I etends I 2 { class C implements I { class C etends C 2 I 2 I 1 I C C 2 I 1 <: I 2 C <: I C 1 <: C 2 C 1 inh C 2 CS 412/413 Spring '00 Lecture Andrew Mers 22 C Subtpe hierarch Introduction of subtpe relation creates a hierarch of tpes: subtpe hierarch Subtpe Subset A value of tpe S ma be used wherever a value of tpe T is epected tpe or subtpe hierarch I2 I3 class/inheritance hierarch S <: T values(s) values(t) values of tpe S values of tpe T CS 412/413 Spring '00 Lecture Andrew Mers 23 CS 412/413 Spring '00 Lecture Andrew Mers 24 4

5 Subtping aioms Subtpe relation is refleive: T <: T Transitive: R <: S S <: T R <: T Usuall anti-smmetric: T 1 <: T 2 T 2 <: T 1 T 1 = T 2 Defines an ordering on tpes (partial order) Language defines subtpe judgement on various tpe kinds (primitives, records, &c) Java: C <: Object, C <: I CS 412/413 Spring '00 Lecture Andrew Mers 25 Subsumption Subsumption rule connects subtping relation and ordinar tping judgements A < E : S S <: T S <: T values(s) values(t) If epression E has tpe S, it also has tpe T for ever T such that S <: T CS 412/413 Spring '00 Lecture Andrew Mers 26 Implementing Tpe-checking Problem: static semantics is supposed to find a tpe for ever epression, but epressions have (in general) man tpes Which tpe to pick? CS 412/413 Spring '00 Lecture Andrew Mers 27 I2 I3 Principal Tpe Idea: ever epression has a principal tpe that is the most-specific tpe of the epression Can use subsumption rule to infer all supertpes if principal tpe is used CS 412/413 Spring '00 Lecture Andrew Mers 28 I2 I3 Tpe-checking interface Old method for checking tpes: abstract class Node { abstract Tpe tpecheck(smtab A); // Return the principal tpe of this // statement or epression No changes in interface needed to support subtping, ecept interpretation of result of tpecheck Tpe-checking rules Rules for checking code must allow a subtpe where a supertpe was epected Old rule for assignment: id : T A A < id = E; : T What needs to change here? CS 412/413 Spring '00 Lecture Andrew Mers 29 CS 412/413 Spring '00 Lecture Andrew Mers 30 5

6 Tpe-checking code class Assignment etends ASTNode { String id; Epr E; Tpe tpecheck(smtab A) { Tpe Tp = E.tpeCheck(A); Tpe T = A.lookupVariable(id); if (Tp.subtpeOf(T)) return T; else throw new TpecheckError(E); p T p <: T + id : T A A < id = E; : T CS 412/413 Spring '00 Lecture Andrew Mers 31 Unification Some rules more problematic: if Rule: A < E : bool A < S 1 : T A < S 2 : T A < if ( E ) S 1 else S 2 : T Problem: suppose S 1 has principal tpe T 1, S 2 has principal tpe T 2. Old check: T 1 = T 2. New check: need principal tpe T. How to unif T 1, T 2? CS 412/413 Spring '00 Lecture Andrew Mers 32 Unification in subtpe hierarch Idea: unified principal tpe is least common ancestor in tpe hierarch I2 I3 LCA(C3, ) = Logic: must be same as or subtpe of an tpe that could be the tpe of both a value of tpe C3 and a value of tpe CS 412/413 Spring '00 Lecture Andrew Mers 33 Eplicit vs Structural subtpes Java: all subtpes eplicitl declared, name equivace for tpes. Subtpe relationships inferred b transitive etension. Languages with structural equivace (e.g., Modula-3): subtpes inferred based on structure of tpes; no etends declaration Same checking done in each case; eplicitl declared subtpes must follow rules for recognizing subtpes implicitl CS 412/413 Spring '00 Lecture Andrew Mers 34 Testing subtpe relation Subtping for records S T means S has at least the fields of T {: int, : int, c: Color <: { : int, : int Subtpe rule for records {: int, : int, c: Color { : int, : int m n A < {a 1 : T 1,,a m : T m <: {a 1 : T 1,,a n : T n Implementation: c S T Similar to our rule for checking modules What about allowing field tpes to var? If Point <: ColoredPoint, allow { p: ColoredPoint, z: int <: { p: Point, z: int? p p z z c CS 412/413 Spring '00 Lecture Andrew Mers 35 CS 412/413 Spring '00 Lecture Andrew Mers 36 6

7 Field Invariance Tr { p: ColoredPoint <: { p: Point : {p: Point : {p: ColoredPoint = ;.p = new 3DPoint( ); Point ColoredPoint Mutable (assignable) fields must be invariant under subtping 3DPoint Covariance Immutable record fields ma change with subtping (ma be covariant ) Suppose we allow variables to be declared final -- : final int Safe: p z { p: final ColoredPoint, z: int { p: final Point, z: int c p z CS 412/413 Spring '00 Lecture Andrew Mers 37 CS 412/413 Spring '00 Lecture Andrew Mers 38 Immutable record subtping Corresponding fields ma be subtpes; eact match not required m n A < T i <: T (i 1..m) i A < {a 1 : T 1 a m :T m <:{a 1 : T 1 a n :T n Summar Multiple implementation of abstract tpes special case of subtping Subtping characterized b new judgement: S <: T Old judgement A < e : T plus subsumption rule, defn. of subtpe relation defines new tpe-checking process Mutable fields must be invariant in subtpe relation; immutable fields ma be covariant CS 412/413 Spring '00 Lecture Andrew Mers 39 CS 412/413 Spring '00 Lecture Andrew Mers 40 7