1 / 55

Transparent Modules with Fully Syntactic Signatures

Transparent Modules with Fully Syntactic Signatures. Zong Shao Presented by Edward Wertz Fall Semester, 2002. Motivation. Shortcomings of SML ’97 Cannot fully specify interfaces of arbitrary ML programs No higher-order functors

gavin
Télécharger la présentation

Transparent Modules with Fully Syntactic Signatures

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. Transparent Modules with Fully Syntactic Signatures Zong Shao Presented by Edward Wertz Fall Semester, 2002

  2. Motivation Shortcomings of SML ’97 • Cannot fully specify interfaces of arbitrary ML programs • No higher-order functors • Principal signatures are not expressible in the syntax of SML ’97 • Cannot support separate compilation

  3. Motivation • MacQueen and Tofte extended SML ’97 with fully transparent higher-order functors but failed to have type-theoretic semantics and thus fails to have fully syntactic signatures. • Harper-Lillibridge and Leroy used translucent sums and manifest types to support fully syntactic signatures but fail to provide fully transparent higher-order functors

  4. Goals • Fully Syntactic Signatures • Simple Type-Theoretical Semantics • Fully Transparent Higher-order Functors • Opaque Types and Signatures • Efficient Elaboration and Implementation

  5. Solution: Phase-splitting Flexroot constructor Given a signature S we extract all the undefined types or module components (the flexible components of S) into a single variable u. We call this u the Flexroot constructor of Signature S.

  6. Flexroots signature SIG = sig type t val x : t end Can be viewed as a template of the form SIG = u:KSIG.(sig type t = #t(u) val x : t end) KSIG is equal to {t:} #t(u) is the t component of the constructor record u

  7. Flexroots Transparency through instantiating the flexroot with type constructors Instantiating SIG with constructor {t = int} yields a signature of the form: sig type t = int val x : t end

  8. Flexroots Opacity through sealing structures to signatures structure X :> SIG = struct type t = int val x = 1 end has type 9u:KSIG.(SIG[u]) where SIG[u] = sig type = #t(u) val x : t end

  9. Flexroots Let X be a module identifier • Xy denotes the flexroot constructor of X Let S be a signature • By default signature matching is opaque • We say that X has signature S if X has type 9u:KS.(S[u])

  10. Flexroots In the case of Manifest Types and Translucent Sums, X.t may refer to an abstract type. In the flexroot notation, X.t will always refer to an actual type definition for the t component of module X. (X.t = #t(Xy))

  11. Flexroots and Functors Flexroots ease the sharing of type information in functors (X.t = #t(Xy)) • Functor functor F1(X:SIG) = struct type t = X.t val x = X.x end • Signature fsig (X: SIG): sig type t = X.t val x : t end • Type X:(9u.SIG[u]).(sig type t = X.t val x : t end)

  12. Flexroots and Functors • NFSIG – signature for an abstract functor that always creates new types funsig NFSIG = fsig (X: SIG) :> SIG • TFSIG – signature for a fully transparent functor that propegates sharing information from the argument funsig TFSIG = fsig (X: SIG) : SIG

  13. Flexroots and Functors • NFSIG Template NFSIG = u1:KNFSIG.X:(9u2.SIG[u2]).(9u3.SIG[u3]) (KNFSIG = KSIG! {}) • TFSIG Template TFSIG = u1:KTFSIG.X:(9u2.SIG[u2]).(SIG[u1[Xy]]) (KTFSIG = KSIG! KSIG) The kind parameter identifies the flexible components in a signature

  14. Flexroots and Functors NFSIG Higher-order Functor Example functor APPS (F: NFSIG) = F(S) Type: F:(9u1.NFSIG[u1]).(9u2.SIG[u2]) Signature: fsig (F: NFSIG) :> SIG

  15. Flexroots and Functors TFSIG Higher-order Functor Example functor APPS (F: TFSIG) = F(S) Type: F:(9u1:KTFSIG.TFSIG[u1]).(SIG[Fy[{t=S.t}]) Signature: fsig (F: TFSIG): sig type t= #t(Fy[{t=S.t}]) val x : t end

  16. Flexroots and Functors Leroy’s Applicative Functors are obtained by sealing a functor to a transparent signature. Functor F3 :> TFSIG = F1 Type: 9u1:KTFSIG.X:(9u2.SIG[u2]).(SIG[u1[Xy]])

  17. Flexroots and Functors Leroy’s Applicative functors fail to have a signature for PAPP because sharing information is restricted to paths. functor PAPP (F: TFSIG) (X: SIG) = let structure Y = struct type t = X.t * X.t val x = X.x * X.x end in F(Y) The flexroot signature is: fsig (F : TFSIG) (X: SIG) : sig type t = #t(Fy({t = #t(Xy)*#t(Xy)})) val x : t end

  18. AMC The Abstract Module Calculus is a system based on Translucent Sums and Manifest Types, picking up where Harper-Lillibridge and Leroy left off. The AMC will then be modified into the Extended Module Calclulus (EMC) which will utilize phase splitting via flexroots.

  19. AMC Syntax Module expression and declaration: path p ::= xi | p.x mexp m ::= p | str d1,…,dn end | fct(xi:S)m | p1(p2) | (p:>S) | let d in m mdec d ::= xi=m | ti= | vi=e Module signature and specification: sig S ::= sig H1,…,Hn end | fsig(xi:S):>S’ spec H ::= xi:S | ti | ti= | vi: Core Language: ctyp  ::= ti | p.t | … cexp e ::= vi | p.v | … Elaboration Context: ctxt  ::=  | ;H

  20. AMC Syntax Within structures (str d1,…,dn end) and signatures (sig H1,…,Hn end), declarations and specifications occurring later may use the internal identifiers (xi, vi, ti) defined earlier Outside the structure or signature the path p.x, p.t, or p.v must be used to access subcomponents where p is a path and x, v, and t are external labels.

  21. AMC Signature Strengthening

  22. AMC Signature Strengthening Type sharing is propagated through signature strengthening. A module identifier xi with signature S is strengthened to have the selfified signature S/xi Functor application (p1(p2)) propagates sharing information into the result signature by substituting xi with the argument p2

  23. AMC Signature Subsumption

  24. AMC Signature Subsumption

  25. AMC Selected Typing Rules

  26. AMC Selected Typing Rules

  27. EMC The Extended Module Calculus improves upon the Abstract Module Calculus in two ways: • Flexroots become the new method of propagating sharing information, allowing for fully transparent higher order functors • A more expressive signature calculus is provided, allowing functors to have fully syntactic signatures.

  28. EMC Syntax All of AMC plus: sig S ::= … | fsig(xi:S):S0 ctyp  ::= … | #t(C) ctxt  ::= … | ;u:K Module constructor and kind: mcon C ::= xi | u | u:K.C | C1[C2] | {F1,…,Fn} | #x(C) mcfd F ::= t= | x=C mknd K ::= {Q1,…,Qn} | K1! K2 mkfd Q ::= t: | x:K

  29. EMC Constructor Formation

  30. EMC Constructor Formation

  31. EMC Kind Calculation

  32. EMC Signature Strengthening

  33. EMC Signature Strengthening

  34. EMC Signature Strengthening Whereas AMC uses paths to strengthen signatures and propagate sharing information, EMC uses flexroot constructors which are more expressive and allow for propagating more sharing information.

  35. EMC Instantiated Signatures

  36. EMC Instantiated Signatures The kind parameter is used to identify flexible components in a signature. Kind {}, K ! {},and {{},…,{}} are dummy kinds indicating that the signature has no flexible components S/(C:K) ) S0 means that instantiating S by constructor C of kind K yeilds signature S0. If S is an instantiated signature then knd(S) is a dummy kind

  37. EMC Instantiated Signatures Lemma 3.1 Given an EMC context , a signature S, a kind K, and a constructor C, if ` S and ` C:K and` K ·knd(S) then S/C is an instantiated signature and ` S/C

  38. EMC Signature Subsumption All subsumption rules in AMC plus:

  39. EMC Selected Typing Rules Same as with AMC except for these two:

  40. EMC Selected Typing Rules By Lemma 3.1 and typing for paths: If ` p:S, then S is an instantiated signature. In the case of p1(p2) we can assume p1 has signature fsig(xi:S):>S0 and p2 has an instantiated signature S00. Let C be all the flexroot information of p2. Because we substitute C in for xiy in addition to substituting p2 in for xi we propegate more sharing information and support fully transparent higher order functions.

  41. EMC Unique Typing Two signatures are equivalent in EMC (` S ´ S0) if and only if both ` S· S0 and ` S0 · S are true. Theorem 3.4 (EMC unique typing) Given context , two sgnatures S and S0, and a module expression m, if ` m:S and ` m:S0then` S ´ S0

  42. EMC Type Checking The typing rules can be turned into a type-checking algorithm because the signature subsumption rules are only used at functor application and opaque signature matching.

  43. AMC Reduction to EMC Let b¢ca denote the translation from AMC to EMC. Theorem 4.1 shows that the reduction preserves the static semantics. Proof is structural induction on the derivation tree. b¢ca acts pretty much like an identity function. The biggest difference between AMC and EMC is with the typing rules and flexroot constructors

  44. AMC Reduction to EMC Lemma 4.2 Given an AMC context , if S is an AMC signature and xi:S 2, then bca`b{S}/xica´b{S}ca/xiyis a valid deduction in EMC. Proof: let xi be the root identifier in p, and F(p) denotes the EMC constructor xiy if p = xi, and #x0(F(p0) if p = p0.x0, then ` p.t ´ #t(F(p)) is valid in EMC

  45. TMC The Transparent Module Calculus is a representative of the strong-sum approach. Module signatures (S) are distinguished from module types (M and L): signatures are source level specifications while types are semantic objects

  46. TMC Syntax path p ::= x | 1(p) | 2(p) mexp m ::= p | v(e) | t() | (x=m1,m2) | x:S.m | p1(p2) | let x=m1 in m2 sig S ::= V() | TYP | x:M1.M2 | x:L.M ctsp  ::= t(p) | … cexp e ::= v(p) mtyp M ::= V() | EQ()| x:M1.M2 | x:L.M L ::= V() | TYP| x:L1.L2 | x:L1.L2 ctyp  ::= t(m0) ctme m0 ::= x | v(e0 | t() |  x::L.m0 | m10(m20) | let x=m10 in m20 | <x=m10, m20> | 1(m0), 2(m0) ctce e0 ::= v(m0) | … ctxt  ::=  | ;x:M | ;x:L

  47. TMC Reduction to EMC b¢cn mapping ctxt-to-ctxt bcn ctsp-to-ctyp bcn  sig-to-sig bScn S cexp-to-cexp becn e path-to-path bpcn p mexp-to-mexp bmcn m

  48. TMC Reduction to EMC Ã mapping ctyp-to-ctyp `Ã0 mtyp-to-sig ` M Ã S mtyp-to-sig ` L Ã S mtyp-to-mcon ` M Ã C ctme-to-mcon ` m0:M Ã C

  49. TMC Reduction to EMC b¢cc mapping mtyp-to-kind bMcc K mtyp-to-kind bLcc K

  50. TMC Reduction to EMC Lemma 4.4 Given a TMC context , suppose ` m10:M1. Then the substitution mapping  = {x  m10} preserves type equivalence. Example: ;x:M1`(M2) ´ M2

More Related