Non-Dependent Types for Standard ML Modules

1. Non-Dependent Types for Standard ML Modules Claudio V. Russo Presented by Joe Vanderwaart Fall 2002

2. One-Slide Summary • Gives an account of SML’s module system that does not involve dependent types. • First presents a generative stamp semantics, then gives a type-theoretic alternative (kind of like Leroy). • But: • The formalism is very similar to the Definition. • Not all aspects of SML modules are covered (notably sharing constraints).

3. Introduction • How do we explain the dot notation? • MacQueen, H-M, H-L, etc. interpret it as suggesting dependent types. • But dependent types are “hard”: • Dependency + Higher-Order = ?? • Type-on-implementation dependency? • Decidability problems. • (Aside: Russo omits Leroy from his list of systems with the Avoidance Problem.)

4. Aside: First-Order? • Russo uses the terms First-Order and Second-Order differently from what I’ve seen before. • First-Order means terms can take term arguments that influence the type of the result, e.g.P x:t1.t2. • Second-Order means terms can take type arguments that influence the type of the result, e.g.8a:T.t. • i.e., as in “second-order l-calculus” • So, second-order is less unusual than first-order. • (Have I got this right?)

5. Plan • Introduce Mini-SML language (external) syntax. • Describe static semantic objects. • Give “shared” (i.e., uninteresting) rules. • Variant 1: Stamp-based static semantics • Variant 2: Type-based static semantics • Equivalence

6. Mini-SML • Syntax of types:

7. Mini-SML (2) • Syntax of Terms (minus core):

8. Semantic Objects • Usually, static semantics assign types to terms, signatures to modules, etc. • However, in The Definition, and in this paper, we assign semantic objects to things. • (H-S, by contrast, elaborates EL phrases to IL phrases, and gives IL classifiers for those phrases.)

9. Kinds of Semantic Objects • Easy things first: • Realizations (type substitutions): (Action lifted to other semantic objects in “the obvious way”, avoiding capture.)

10. Kinds of Semantic Objects (2) • Semantic Structures: • Really like (fully transparent) signatures. • Map type labels to their definitions; • Map term labels to their types • Map substructure labels to their “signatures”.

11. Kinds of Semantic Objects (3) • Three “different” kinds of variable binding: • LP.S is called a semantic signature. • Semantic functor8P.S!9Q.S’ is like Leroy’s functor signature, but with the right quantifiers. • Notice: No type-on-term dependencies here!

12. Kinds of Semantic Objects (4) • Semantic Contexts: • Extension operations defined the obvious way.

13. Common Rules • Figure 4 in paper gives rules that are shared between the two type system formulations. • They include the rules for: • C` u Bu, denotation of a type. • C` S BL, denotation of a signature body. • C` e : u, core language typing. • C` sp : S, typing for structure paths. • We’ll show some of the interesting ones.

14. Signatures: Intuition • A signature S denotes the semantic signature LP.S, where S is basically S with all the abstract types defined as names in P. • LP.S describes any structure whose “real” signature is some f(S). • L is not the perfect letter for this. • But 9 is used for something different.

15. Denotation of Signatures • Rules for abstract and transparent types: In case of abstract type, choose a fresh type variable to stand for the type, and add it to the quantified set in the semantic signature.

16. Denotation of Signatures (2) • Rule for substructure specifications: Side conditions (non-judgment premises): • Bound variables in denotation of S are fresh. • X is not redeclared later in this signature. • Bound variables of the rest of the sig are chosen to be new.

17. Generative Classification • Initial version of static semantics of Mini-SML. • Judgments carry sets of names, e.g.: C,M` s : S)N Meaning: In context C, where names M have already been used, elaborating structure s gives semantic structure S and generates names N. • Generativity property: NÅM = ;. • Why isn’t M always FV(C)? Shadowing.

18. Easy Generative Rules • Type definitions, substructures, local:

19. Datatype Generativity • For a datatype, choose a fresh new name: • Remember: • Datatype may be recursive (u can refer to t). • x,x’ are constructor/destructor for datatype.

20. Classifying Functors • When typing a functor, record the new names from the body in the signature: Remember that functors don’t show up in signatures.

21. Signature Matching • Before going on, we need some definitions. Def. (Enrichment): SºS’ iff • Dom(S) ¶ Dom(S’), • S and S’ agree on all type and value variables in Dom(S’), and • For X in Dom(S’), S(X) ºS’(X). (Observe: if SºS’, then S is a subtype of S’) Def. (Instantiation): 8P.S!X > S’!X’ iff for some f, Dom(f)=P and f(S) = S’ and f(X) = X’. Def. (Matching): S matches LP.S’ iff for some f,Dom(f)=P and S º f(S’).

22. Signature Ascription • Transparent: return semantic structure with definitions patched in. • Opaque: Leave names abstract; remember they were generated.

23. Functor Generativity At each application of a functor, get a fresh copy of the names in the result: Key: a-vary the result of the functor so that the names it generates are fresh.

24. Stamps are Ugly • Premises in rules are implicitly “ordered” because of threading of variable sets. • Can’t really consider well-typedness of any expression in isolation. • Type variables are never declared, seem to have global scope. • Solution: Type-theoretic judgments return an existential signature. • “Free” type variables now existentially bound. • Renaming avoids duplication/clashes.

25. T-T Classification: Easy Rules • The simple rules don’t change much:

26. Type-Theoretic Datatype Rule • Still basically analogous to the generative: Generate a new type variable for the datatype, add it to the set of vars that must be fresh. (There’s a font mistake in the paper. Can you find it?)

27. Type-Theoretic Functor Rule • Because existentials are now built-in, this rule is a bit simpler: • Notice: functor definition doesn’t produce any new type variables. • Remember: functors are not exported.

28. Signature Ascription • Two rules are more similar now that the freshness side-conditions are gone:

29. Functor Application • Vary argument and result signatures to get fresh abstract variables. • Only need BV of argument to be fresh w.r.t. the functor, not “all names previously generated”. • Abstract types in result can come from the argument, or be generated by the functor.

30. Two Systems are Equivalent • Before we can state the main result, we need some definitions: • Def. (Rigid): C,Nrigid iff FV(C) µN • Def. (Ground): • `8P.S!XGnd iff Pµ FV(S). • `CGnd iff for F 2 Dom(C), `C(F) Gnd. • Lemma 1: If `CGnd and C` b/s : X, then FV(X) µ FV(C).

31. Main Theorem • If C,Nrigid and `CGnd, then: • If C,N` b/s : S)M, then C ` b/s : 9M.S. • If C` b/s : X, then X = 9M.S and C,N` b/s : S)M. • In other words, the type-theoretic judgments are complete and sound w.r.t. the generative ones.

32. Proofs • Completeness is by induction. (Do on whiteboard?) • Soundness is harder. • Because type-theoretic rules do not require variables to be globally fresh, but generative rules do. • To prove soundness, reformulate rules so that premises of each must hold for all possible renamings of bound variables. • Detailed proofs are in Russo’s thesis.

33. Summary • Equivalence of two formalizations of generativity: • Stateful, “generative” judgments • Stateless, “type-theoretic” judgments • “Non-dependent” types for modules. • In plain English: When applying a functor, you can get the type of the result just by instantiating it with the types from the argument. • ... but isn’t that just the same as phase separation?