Type Generativity and Sharing

1. Type Generativity and Sharing Aaron White Fall Semester, 2002

2. Generativity? • Generative type declarations yield “new” types • datatype t • F(S).t • Incompatible w/ all other types • Incompatible w/ concrete rep (outside the scope of its definition)

3. Generativity? • Mitchell & Plotkins existentials for abstraction were ok, but open failed to provide a unique witness. • Dot notation alleviates this, but “type identity” is lost. • Generativity, along with manifest types (translucent sums) resolves this (in the syntactic approach)

4. Why Generativity? • Key mechanism for abstraction • Would like functor applications to yield new type F(S1).t != F(S2).t • Still, type propagation must be respected • Would like result types to be compatible w/ argument types (for instance: we wish F to propagate input type t to the result structure) S.t = F(S).t

5. Two Approaches to Generativity • Stamp based • SML style • Syntactic • Modula-2 • Does not extend well

6. Leroy proposes… … a syntactic theory of generativity, that is equivalent to stamp based “operational” account for generativity. Also claims, syntactic approach is more powerful.

7. Stamp-based Generativity • Syntactic objects elaborated into semantic objects • Mapping environment from types t to stamp τ • “New types” generate fresh stamps • Sharing specifications are checked during elaboration for stamp equality

8. Programs are of the form: structure x = struct datatype t type t’ = t (etc…) end; functor f(x:S) = struct .. end Stamp-based elaboration formalism

9. Stamp-based elaboration formalism • FS(Σ) is the set of stamps occurring free in Σ • Г is an elaboration environment (identifiers to semantic objects) • W is the set of “active” stamps

10. Stamp-based elaboration formalism

11. Path Elaboration Selected Elaboration Rules

12. Structure binding Type binding Selected Elaboration Rules

13. Selected Elaboration Rules Opening structures Datatype definition (generative)

14. Selected Elaboration Rules Elaborating type declaration in a signature Elaborating sharing in a signature

15. Selected Elaboration Rules Functor application (generative)

16. Problems w/ Syntactic Generativity • Not so straightforward as one would hope • F(struct … end).t should not equal F(struct … end).t, despite being syntactically the same • structure x = struct datatype t; val v end structure y = (x : sig type t end) x.t != y.t syntactically, though a different view shouldn’t generate a new type.

17. Problems cont. • More problems… structure s : (sig type t; val v:t end); val x: s.t structure s = struct datatype t end x : s.t??

18. Solutions… • Restrict functor applications to paths in the usual way. • Use of manifest (translucent) types to propagate sharing information. • Separate identifiers and names

19. Identifiers and Names • Each time an name for an identifier is written down, append a mark to ensure the identifier is unique. • Use the name for component access in a structure, but use the identifier to bind variables and check for type equivalence. • Identifiers can be ‘marked’ during type checking, and needn’t appear in the program text.

20. Example structure s = … val y = s.t structure s = … val x: s.t structure s = … x: ?, y: ? structure s = … val y = s.t structure s’ = … val x: s’.t structure s’’ = … x: s’.t, y: s.t

21. Programs are of the form: structure x = struct datatype t type t’ = t (etc…) end; etc. Syntactic type system formalism • Except now manifest (translucent) types can appear in a signature specification: • type ti = T

22. Syntactic type system formalism • BV(D) is the set of bound identifiers in the specification D (specification = contents of a signature) • S/p strengthens the signature s that can be assigned to path p. Selfification.

23. Datatype declaration (generative) Type binding (non generative) Selected syntactic typing rules

24. Selected syntactic elaboration rules • Datatype elaboration • Type binding elaboration

25. Signature strengthening • Allows selfification • (type ti; D)/p = type ti = p.t; D/p • This would not be possible w/o the manifest type construct, and w/o signature strengthening, we lose type propagation in his framework

26. The Reduction • To inject TypModl (stamp based) into TypModl’ (path based), TypModl programs must first be normalized • A-Normalization • S-Normalization • Finally, some syntactic swapping

27. A-Normalization • Since TypModl restricts functor arguments to paths, must massage TypModl to the same. Intermediate applications are bound to temporary structures (N is the set of fresh identifiers)

28. S-Normalization • Since TypModl’ can only express sharing constraints in the form of manifest types in signatures (type t = p.t), TypModl must be massaged once more to ‘localize’ sharing constraints.

29. Localize? • The sharing constraint must immediately follow what it is locally constraining; sig specs must end up in the form “type t; sharing t = p”

30. Why normalization? • Because, once we have A-Normalized, and S-Normalized, we are prepared to express TypModl in TypModl’ after swapping some syntax:

31. The Claim (modulo the remaining syntactic differences)

32. To prove the claim… • Establishes relation between the semantic objects, and the signature expressions. • This translation from signature expressions to semantic objects is deterministic! (as opposed to elaboration of non-manifest types in signatures in TypModl)

33. To prove the claim… By normalizing and then using manifest types, our constraint on the stamp for ti is immediately obvious, making elaboration deterministic.

34. To prove the claim… • Using the translation, it can be shown that if T is a type expression, [T] is what T would elaborate into. • Further, if S is a TypModl signature, [S] is principal • This is because sharing constraints in the signature get satisfied immediately, and generative types are assigned fresh stamps in the usual fashion

35. To prove the claim… • The ‘big’ inductive claim, if s is a TypModl signature, then there exists S in TypModl’ such that the following holds. • The converse relating TypModl’ signature translation to TypModl signature elaboration results is proven true. then and

36. Conclusion • TypModl reduces to TypModl’ • The path-based model at least as expressive as the stamp based model presented. • Somewhat deceiving, as the path-based system is fragile, and fails at extension, whereas the stamp-based model, despite its shortcomings, is somewhat more robust.