Shao, Z. 1999. Transparent modules with fully syntactic signatures. In 1999 ACM International Conference on Functional Programming. Paris, 220--232.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....languages [34, 2] has been particularly influential. Much effort has gone into the design of modular programming mechanisms for the ML family of languages, notably Standard ML [23] and Objective Caml [27] Numerous extensions and variations of these designs have been considered in the literature [21, 18, 28, 31, 5]. Despite (or perhaps because of) these substantial efforts, the field has remained somewhat fragmented, with no clear unifying theory of modularity having yet emerged. Several competing designs have been proposed, often seemingly at odds with one another. These decisions are as often motivated ....

....induces a static effect, which we think of as occurring once during type checking; strong sealing induces a dynamic effect, which we think of as occurring during execution. Dynamic effects induce partiality, static effects preserve totality. Existential Signatures In a manner similar to Shao [31], our type system is carefully crafted to circumvent the avoidance problem, so that every module enjoys a principal signature. However, this requires imposing restrictions on the programmer. To lift these restrictions, we propose the use of existential signatures to provide principal signatures ....

[Article contains additional citation context not shown here]

Zhong Shao. Transparent modules with fully syntactic signatures. In International Conference on Functional Programming, pages 220--232, Paris, France, September 1999.

....allows method bodies and their types to be instantiated appropriately at the point where they are used. 5. RELATED WORK A great deal of work in module languages has been done in the last few years in the functional programming community, specifically in the context of the ML functional language [21, 20, 27, 28, 34, 14, 16]. ML provides a rich module structure where implementations are separated from interfaces (similarly to Modula 3) and where modules can parameterize over their imports. Such parameterized modules can then be instantiated by applying them to a collection of imports matching the required interface. ....

Z. Shao. Transparent modules with fully syntactic signatures. In Proceedings of ACM International Conference on Functional Programming, Paris, France, September 1999.

.... also has the benefit that the dynamic type check cannot violate encapsulation of abstract types; this is explained in more detail in [12] 9 Related Work There has been a great deal of work on the semantics of module interconnection languages, particularly in the context of the ML module system [16,15,18,19, 33]. The notion of separating external and internal field names, with the latter allowing renaming to avoid name clashes, originated with Harper and Lillibridge [15] A related idea is used by Riecke and Stone to allow fields of an object to be made private, and the object then extended with a field ....

Zhong Shao. Transparent modules with fully syntactic signatures. In Proceedings of ACM International Conference on Functional Programming, Paris, France, September 1999.

....of languages [31, 2] has been particularly influential. Much e#ort has gone into the design of modular programming mechanisms for the ML family of languages, notably Standard ML [20] and Objective Caml [24] Numerous extensions and variations of these designs have been considered in the literature [18, 16, 26, 28, 5]. Despite (or perhaps because of) these substantial e#orts, the field has remained somewhat fragmented, with no clear unifying theory of modularity having yet emerged. Several competing designs have been proposed, often seemingly at odds with one another. These decisions are as often motivated by ....

....one that respects static equivalence of its arguments. This models the behavior of functors in Objective Caml. A generative, or non applicative, functor does not respect equivalence the abstract types in the result di#er on each application. Existential Signatures In a manner similar to Shao [28], our type system is carefully crafted to circumvent the avoidance problem, so that every module enjoys a principal signature. However, this requires imposing restrictions on the programmer. To lift these restrictions, we follow Russo [26] generalizing Harper and Stone [11] and employ ....

[Article contains additional citation context not shown here]

Zhong Shao. Transparent modules with fully syntactic signatures. In International Conference on Functional Programming, pages 220--232, Paris, France, September 1999.

....of languages [33, 2] has been particularly influential. Much e#ort has gone into the design of modular programming mechanisms for the ML family of languages, notably Standard ML [22] and Objective Caml [26] Numerous extensions and variations of these designs have been considered in the literature [20, 17, 27, 30, 5]. Despite (or perhaps because of) these substantial e#orts, the field has remained somewhat fragmented, with no clear unifying theory of modularity having yet emerged. Several competing designs have been proposed, often seemingly at odds with one another. These decisions are as often motivated by ....

....sealing induces a static e#ect, which we think of as occurring once during type checking; strong sealing induces a dynamic e#ect, which we think of as occurring during execution. Dynamic e#ects induce partiality, static e#ects preserve totality. Existential Signatures In a manner similar to Shao [30], our type system is carefully crafted to circumvent the avoidance problem, so that every module enjoys a principal signature. However, this requires imposing restrictions on the programmer. To lift these restrictions, we propose the use of existential signatures to provide principal signatures ....

[Article contains additional citation context not shown here]

Zhong Shao. Transparent modules with fully syntactic signatures. In International Conference on Functional Programming, pages 220--232, Paris, France, September 1999.

....languages [34, 2] has been particularly influential. Much effort has gone into the design of modular programming mechanisms for the ML family of languages, notably Standard ML [23] and Objective Caml [27] Numerous extensions and variations of these designs have been considered in the literature [21, 18, 28, 31, 5]. Despite (or perhaps because of) these substantial efforts, the field has remained somewhat fragmented, with no clear unifying theory of modularity having yet emerged. Several competing designs have been proposed, often seemingly at odds with one another. These decisions are as often motivated ....

....induces a static effect, which we think of as occurring once during type checking; strong sealing induces a dynamic effect, which we think of as occurring during execution. Dynamic effects induce partiality, static effects preserve totality. Existential Signatures In a manner similar to Shao [31], our type system is carefully crafted to circumvent the avoidance problem, so that every module enjoys a principal signature. However, this requires imposing restrictions on the programmer. To lift these restrictions, we propose the use of existential signatures to provide principal signatures ....

[Article contains additional citation context not shown here]

Zhong Shao. Transparent modules with fully syntactic signatures. In International Conference on Functional Programming, pages 220--232, Paris, France, September 1999.

.... sharing ) information would initially be expressed using singleton kinds, but at some point singleton kind elimination would be exploited to eliminate them. Thereafter, with singleton kinds no longer available, type information would be propagated by substitution, as in Harper et al. 7] Shao [18] proposes a different approach for dealing with type equality in module languages. Shao s approach resembles the approach in this paper, in that it substitutes definitions for variables. However, it does so less thoroughly than the approach here, since, in keeping with the module based accounts, ....

Zhong Shao. Transparent modules with fully syntactic signatures. In

....two or more structure arguments and those arguments have to interact within the functor body based on types that they share in common. This sharing has to be expressed in some way in the functor parameter signatures. See the various ML tutorials (e.g. 18] and textbooks for further details, and [19, 23, 24, 25, 38] for alternative theoretical approaches. 6 Object Oriented Programming It is hard to pin down the essence of object oriented programming, because there are many different feature sets, languages, and methodologies espoused by different camps within the OO community. One major division is ....

Zhong Shao. Transparent modules with fully syntactic signatures. In Proc. 4th ACM SIGPLAN International Conference on Functional Programming (ICFP '99), pages 220--232, September 1999.

....a revision in security policy [32] this real time guarantee will be critical. Module interconnection languages (MILs) are recognized as an essential tool in managing the complexity of increasingly vast software systems. The last few years have seen several developments in the semantics of MILs [30, 29, 39, 40, 52, 21, 9, 23, 27]. While much of the work has centered on the module system for the ML functional language, because of some of the ambitious design goals of this MIL, more recent work has looked at more low level semantics for MILs, essentially giving a type theoretic semantics for linking in the Unix and Windows ....

Zhong Shao. Transparent modules with fully syntactic signatures. In Proceedings of ACM International Conference on Functional Programming, Paris, France, September 1999.

.... to Standard ML for fully transparent higher order modules in the presence of abstraction [15] Shao has also presented a type theory for higher order modules that extends applicative functors and solves the problems we encountered with applicative functors using fully syntactic signatures [24]. In his system, the set type above would be expressed as MakeSetFn( type key = sos ) set, where MakeSetFn denotes the static part of MakeSetFn in essence, Fst (MakeSetFn) This type could be extracted into the opaque fixed point with no di#culty. The reason Shao s system is successful, as he ....

Zhong Shao. Transparent modules with fully syntactic signatures. In 1999 ACM SIGPLAN International Conference on Functional Programming, pages 220--232, Paris, France, September 1999.

.... to Standard ML for fully transparent higher order modules in the presence of abstraction [15] Shao has also presented a type theory for higher order modules that extends applicative functors and solves the problems we encountered with applicative functors using fully syntactic signatures [24]. In his system, the set type above would be expressed as MakeSetFn(ftype key = sosg) set, where MakeSetFn denotes the static part of MakeSetFn in essence, Fst (MakeSetFn) This type could be extracted into the opaque xed point with no diculty. The reason Shao s system is successful, as he ....

Zhong Shao. Transparent modules with fully syntactic signatures. In 1999 ACM SIGPLAN International Conference on Functional Programming, pages 220-232, Paris, France, September 1999.

....et al. 1979; Intermetrics 1995; Nelson 1991] have demonstrated the usefulness of module interconnection languages for organizing software in the large. There has also been more formal work on the design and semantics of MILs [Harper et al. 1990; Harper and Lillibridge 1994; Leroy 1994; 1995; Shao 1999; Duggan and Sourelis 1996; Flatt and Felleisen 1998] This work has explored significant extensions to the aforesaid MILs, developing designs for explicit linking constructs, type safe linking, type sharing and separate compilation. While much of the work has centered on the module system for the ....

....; # # # ; #;# # # # ## ; # # # # # # ## ; # # # val L : LT . 7. RELATED WORK As already mentioned, there has been a great deal of work on the semantics of MILs, particularly in the context of the ML module system [Harper et al. 1990; Harper and Lillibridge 1994; Leroy 1994; 1995; Shao 1999]. Much of the work on the ML module system has been focussed on higher order functors, motivated by concerns with separate compilation: module Server = functor (A: SIG1) SIG2 # struct . end module Client = functor (SVR: funsig(A:SIG1) SIG2) # struct module A = module B = SVR(A) end ....

Shao, Z. 1999. Transparent modules with fully syntactic signatures. In Proceedings of ACM International Conference on Functional Programming. Paris, France.

....two or more structures arguments and those arguments have to interact within the functor body based on types that they share in common. This sharing has to be expressed in some way in the functor parameter signatures. See the various ML tutorials (e.g. 17] and textbooks for further details, and [18, 22, 23, 24, 37] for alternative theoretical approaches. 21 6 Object Oriented Programming It is hard to pin down the essence of object oriented programming, because there are many different feature sets, languages, and methodologies espoused by different camps within the OO community. One major division is ....

Zhong Shao. Transparent modules with fully syntactic signatures. In Proc. 4th ACM SIGPLAN International Conference on Functional Programming (ICFP '99), pages 220--232, September 1999.

....information would initially be expressed using singleton kinds, but at some point singleton kind elimination would be exploited to eliminate them. Thereafter, with singleton kinds no longer available, type information would be propagated by substitution, as in Harper et al. 7] 21 Shao [18] proposes a different approach for dealing with type equality in module languages. Shao s approach resembles the approach in this paper, in that it substitutes definitions for variables. However, it does so less thoroughly than the approach here, since, in keeping with the module based accounts, ....

Zhong Shao. Transparent modules with fully syntactic signatures. In 1999 ACM International Conference on Functional Programming, pages 220--232, Paris, September 1999.

....number of branches in the typecase, one for each kind; or by restricting type analysis to a finite set of kinds. Both of these approaches are clearly impractical. Recent work on typed compilation of ML and Java has shown that both would require an F# like calculus with arbitrarily complex kinds [21, 22, 9]. 2.3 Requirements for a solution Before we discuss our solution, let us look at the properties we want it to have. First, our language must support type analysis in the manner of Harper Morrisett. That is, we want to include type analysis primitives that will analyze the entire syntax tree ....

Z. Shao. Transparent modules with fully syntactic signatures. In Proc. 1999 ACM SIGPLAN International Conf. on Functional Programming (ICFP'99), pages 220--232. ACM Press, September 1999.

....the translation. The translation of translucent sums is even more problematic: Crary et al. [8] have to extend F with singleton and dependent kinds to capture the sharing information in the surface language. The translation based on our new interpretation (given in the companion technical report [34]) rightly turns opaque modules and abstract types into simple existential types. Furthermore, it does not need to use singleton and dependent kinds. This is significant because typechecking singleton and dependent kinds is notoriously difficult [8] 2 Informal Development 2.1 Fully transparent ....

....Module Calculus (AMC) 19] as a representative of the system based on translucent sums [12] and manifest types [19, 21] The syntax of AMC is given in Figure 1. The static semantics for AMC is summarized in Figure 2. The complete typing rules are given in Figures 3 to 5 and in the companion TR [34]. AMC is a typical ML style module calculus containing constructs such as module expressions (mexp) module declarations (mdec) module access paths (path) signatures (sig, specifications (spec) core language types (ctyp) and expressions (cexp) Following Leroy [21] we use x i , t i , and v i ....

[Article contains additional citation context not shown here]

Z. Shao. Transparent modules with fully syntactic signatures (extended version). Technical Report YALEU/DCS/RR-1181, Dept. of Computer Science, Yale Univ., New Haven, CT, June 1999.

No context found.

Shao, Z. 1999. Transparent modules with fully syntactic signatures. In 1999 ACM International Conference on Functional Programming. Paris, 220--232.

No context found.

Zhong Shao. Transparent modules with fully syntactic signatures. In International Conference on Functional Programming, pages 220--232, Paris, France, September 1999.

No context found.

Zhong Shao. Transparent modules with fully syntactic signatures. In Proceedings of ACM International Conference on Functional Programming, Paris, France, September 1999.

No context found.

Z. Shao. Transparent modules with fully syntactic signatures. In Proc. 1999 Int'l Conf. Functional Programming, pp. 220--232. ACM Press, 1999.

No context found.

Zhong Shao. Transparent modules with fully syntactic signatures. In 1999 ACM International ConferenceonFunctional Programming, pages 220#232, Paris, September 1999.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC