Xavier Leroy. Applicative Functors and Fully Transparent Higher-Order Modules. In Proc. 22nd Symposium on Principles of Programming Languages, pages 142--153, 1995.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....The functor F generates an abstract type, so we must consider when that type should be compatible with others. If two separate programs contain this preamble, they should be able to exchange values of their respective SummedIntSet.t types. This mirrors the behaviour of OCaml s applicative functors [18], in which another instance of the application F(IntSet) within the same program would have a type compatible with SummedIntSet.t. Should the functorised and non functorised (P8a ) SummedIntSet.t be compatible Again following existing module systems, we should make them incompatible, as ....

....computations should be hashes, whereas those of structures with effectful computations should have freshly generated names. Functors (Sec. 2.9) are a more substantial extension, but, at least for a restricted but useful class, should be straightforward. Consider first order applicative functors [18] and module expressions that are either (i) an explicit structure, possibly multiply abstracted, or (ii) pure, i.e. constructed from module identifiers, abstraction and application. These give rise to functions from hashes to hashes; applying these functions gives run time representations of the ....

X. Leroy. Applicative functors and fully transparent higher-order modules. In Proc. 22nd POPL, pages 142--153, 1995.

....from a module and used as a type We say that a module is comparable iff it can be compared for equivalence with another module, and that a module is projectible iff its type components may be projected and used as type expressions. In the literature most presentations emphasize projectibility [11, 14, 15]. structure S1 = struct type s = bool type t = bool int structure S = struct type u = string val f = fn y:u = true) end val g = fn y:t = hello world ) is compiled as . bool] #t = boolint] #S #u = string] # f = #y:Typ u.true] ####, #g = #y:Typ ....

....have computational effects. In the literature different accounts of higher order modules provide different classes of pure modules. For example, in Harper and Lillibridge s first class module system [11] only syntactic values are considered pure. In Leroy s second class module calculi [14, 15], purity is limited to the syntactic category of paths. In Harper et al. s early phase distinction calculus [12] all modules are deemed to be pure, but no means of abstraction is provided. Abstraction via Sealing The principal means for defining abstract types is sealing, written M: #. Sealing ....

[Article contains additional citation context not shown here]

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Conference Record of POPL '95: ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 142--153, San Francisco, CA, January 1995.

.... appeared in the literature, induding the non standard structure typing rule of Harper, Mitchell, and Moggi [8] the VALUE rules of Harper and Lillibridge s translucent sums [7] the strengthening operation of Leroy s manifest type system [10] and the self rule of Leroy s applicative functors [11]. In the presence of singletons, these rules give constructors more precise kinds than would otherwise be possible. See Section 2.3. 2.2 Examples of Term Equivalence As mentioned in the introduction, singletons in the context can act as definitions and partial definitions for variables. So the ....

Xavier Leroy. Applicative Functors and Fully Transparent Higher-Order Modules. In Proc. 22nd Symposium on Principles of Programming Languages, pages 142- 153, 1995.

....foundations for modular program ning provide valuable insights into the desigu of more powerful, and more effective module systems for practical programming languages. During the past decade, there have been several attempts to provide type theoretic foundations for modular program ming [23, 16, 21, 7, 22, 27, 1, 6, 13, 15, 3]. The main propos als can be distinguished by their use of different constructs to describe the type of a module. To illustrate these alternatives, suppose that we wish to construct a complex number Permission to make digital hard copies of all or part of this material for personal or classroom ....

.... beeit the difficulty in providing sufficiently general aud accurate types to capture the fully transparent behaviour of higherorder functors that is predicted by operational frameworks [27, 17] In recent work, Leroy has shown how a calculus of manifest types can be modified to avoid this problem [15]. His solution requires an extension of the type language to include functor application, further blurring the distinction between types and terms; that is, between static and dynamic semantics. This work, and an alternative solution, are discussed in more detail in the next section. 3 ....

[Article contains additional citation context not shown here]

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Conference record of POPL '95: 22nd A UM SIGPLA N-SIGA CT Symposium on Principles of Programming Languages. ACM, Jan- uary 1995.

....to translate ML modules to TAL object files. However the problem with this approach is that it leads to two di#erent models of linking: 1. At the source language level, linking is based on applying parameterized modules. Higher order parameterized modules may be useful for separate compilation [16,15,18,24,19], but there are still problems with supporting recursive modules [8] as are found in Java and C) 2. At the assembly language level, linking is based on a type safe version of the Unix ld command. Circular imports present no problem at this level, but much of the sophistication of the type ....

.... 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 ....

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Proceedings of ACM Symposium on Principles of Programming Languages, pages 154--163, San Francisco, California, January 1995. ACM Press.

....dynamic or static purity alone does provide some privileges not enjoyed by arbitrary modules. For example, dynamically pure modules (which may contain opaque but non generative types) may appear within the body of an applicative functor. Applicative and Generative Functors An applicative functor [13] is 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 ....

....non values could compute di#erent modules containing di#erent types each time they are evaluated. Thus, the type components of a non value are not well determined (hence the phrase indeterminate ) and cannot meaningfully be compared for equivalence. In Leroy s second class module calculi [12, 13], determinacy is limited to the syntactic category of paths. In Leroy s case this was not necessary for type soundness, since modules were never produced by run time computations, but it served to provide a certain degree of abstraction. In Harper, et al. s phase distinction calculus [10] an ....

[Article contains additional citation context not shown here]

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Conference Record of POPL '95: ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 142--153, San Francisco, CA, January 1995.

....u bs.de. knowledge [13] and programming in the large is essentially typed functional programming [27] a lan guage for programming in the large should generate individual product architectures by the evaluation of functional architectural programs. The Standard ML (SML) module language [20, 19, 16] supports a functional style for programming in the large: Structures are elementary components, functors are component valued functions and signatures are component specifications. Large systems can be built by successively applying componentvalued functions to previously constructed components. ....

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In POPL-22

....of its argument. Similarly, the calculus employs a non standard elimination rule for dependent functions. The formulation of this rule varies slightly from one presentation of Leroy s calculus to another. To preserve the syntactic invariant of restricting projections to paths, in both [28] and [29], a dependent functor may only be applied if its argument is a path; if its argument is not a path, the functor must first be given a suitable non dependent supertype (by using a covariant subtyping rule) Similar to Harper and Lillibridge s calculus [18] the calculi of both these papers have the ....

....it in this thesis. Although Leroy s calculi in [28, 31] support a natural notion of higher order functor, like Harper and Lillibridge s system, they fail to have the fully transparent behaviour of higher order functors desired by MacQueen and Tofte [36] Building on his previous work, Leroy [29] o#ers a partial solution to the full transparency problem. It relies on extending the syntax of paths to include the application of a (functor) path to an (argument) path, allowing type components to be projected directly from functor applications, not merely from named structures. In this way, ....

[Article contains additional citation context not shown here]

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Proc. 22nd Symp. Principles of Prog. Lang., pages 142--153. ACM Press, 1995.

....our approach allows a straight forward efficient run time implementation. Section 2 provides several examples to motivate mixin modules Section 3 presents the formal type system for mixin modules; this type system is an extension of recent reformulations which have beenproposed for SML modules [13, 18, 19]. Section 4 presents an operational semantics for mixin modules, in the form of areduction system which maps mixin modules to ordinary SML modules. A semantic soundnessresult verifies that the semantics does not fail due to type errors during reduction. Section 5 considers related and future ....

....type system with generativity. This simplifi cation is inessential, and we may assume a source level translation which converts from a more liberal syntax to this one [18] We only allow simple paths S.Sl. sn; in particular we do not have functor applications in paths, as suggested by Leroy [19] for typing higher order functors. We do this to simplify the presentation, since higher order functors do not materially affect the semantics of mixin modules. We make the simplifying assumption that functots are first order, as in Standard ML, although this is not strictly enforced in the type ....

[Article contains additional citation context not shown here]

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Proceedings of ACM Symposium on Principles of Programming Languages, pages 154-163, San Francisco, Califomia, January 1995. ACM Press.

....Figure 3: ML Structure Example We say that a module is comparable i# it can be compared for equivalence with another module, and that a module is projectible i# its type components may be projected and used as type expressions. In the literature most presentations emphasize projectibility [10, 13, 14]. A simple analysis of the properties of comparability and projectibility suggests that they are closely related. Suppose that M is a projectible module with signature [ T ] so that Typ M is a type. Since type equality is an equivalence relation, this type may be compared with any other, in ....

....components have computational e#ects. In the literature di#erent accounts of higher order modules provide di#erent classes of pure modules. For example, in Harper and Lillibridge s first class module system [10] only syntactic values are considered pure. In Leroy s second class module calculi [13, 14], purity is limited to the syntactic category of paths. In Harper et al. s early phase distinction calculus [11] all modules are deemed to be pure, but no means of abstraction is provided. Abstraction via Sealing The principal means for defining abstract types is sealing, written M : #. Sealing ....

[Article contains additional citation context not shown here]

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Conference Record of POPL '95: ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 142--153, San Francisco, CA, January 1995.

....from a module and used as a type We say that a module is comparable iff it can be compared for equivalence with another module, and that a module is projectible iff its type components may be projected and used as type expressions. In the literature most presentations emphasize projectibility [11, 14, 15]. structure S1 = struct type s = bool type t = bool int structure S = struct type u = string val f = fn y:u = true) end val g = fn y:t = hello world ) is compiled as . bool] #t = bool int] #S #u = string] # f = ly:Typ u.true] ####, #g = ly:Typ ....

....have computational effects. In the literature different accounts of higher order modules provide different classes of pure modules. For example, in Harper and Lillibridge s first class module system [11] only syntactic values are considered pure. In Leroy s second class module calculi [14, 15], purity is limited to the syntactic category of paths. In Harper et al. s early phase distinction calculus [12] all modules are deemed to be pure, but no means of abstraction is provided. Abstraction via Sealing The principal means for defining abstract types is sealing, written M: s. Sealing ....

[Article contains additional citation context not shown here]

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Conference Record of POPL '95: ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 142--153, San Francisco, CA, January 1995.

....indexing operation aborts if it receives an out of bounds index, and the division operation aborts if it receives zero as a divisor. Together these two techniques dramatically improve the quality of software built in HOT languages. With the advent of module languages that support type abstraction [32, 43], HOT languages empower programmers to enforce their own abstractions at the type level. These abstractions have the same expressive power that the language designer uses when specifying the language s primitives. The dynamic aspect, however, has become a second class citizen. The programmer must ....

Leroy, X. Applicative functors and fully transparent higher-order modules. In Proceedings of ACM Conference Principles of Programming Languages, pages 142--153. ACM Press, 1995.

.... appeared in the literature, including the non standard structure typing rule of Harper, Mitchell, and Moggi [7] the VALUE rules of Harper and Lillibridge s translucent sums [6] the strengthening operation of Leroy s manifest type system [8] and the self rule of Leroy s applicative functors [9]. In the presence of singletons, these rules give constructors more precise kinds than would otherwise be possible. See Section 2.3. 2.2 Examples of Term Equivalence As mentioned in the introduction, singletons in the context can act as definitions and partial definitions for variables. So the ....

Xavier Leroy. ApplicativeFunctors and Fully Transparent Higher-Order Modules. In Proc. 22nd Symposium on Principles of Programming Languages, pages 142--153, 1995.

No context found.

Xavier Leroy. Applicative Functors and Fully Transparent Higher-Order Modules. In Proc. 22nd Symposium on Principles of Programming Languages, pages 142--153, 1995.

No context found.

Leroy, X. 1995. Applicative functors and fully transparent higher-order modules. In TwentySecond ACM Symposium on Principles of Programming Languages. San Francisco.

No context found.

Xavier Leroy. Applicative Functors and Fully Transparent Higher-Order Modules. In Proc. 22nd Symposium on Principles of Programming Languages, pages 142--153, 1995.

No context found.

Xavier Leroy. Applicative functors and fully transparent higherorder modules. In Twenty-Second ACM Symposium on Principles of Programming Languages, San Francisco, January 1995.

No context found.

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Conference Record of POPL '95: ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 142--153, San Francisco, CA, January 1995.

No context found.

X. Leroy. Applicative functors and fully transparent higher-order modules. In Proc. 22nd ACM Symp. on Principles of Programming Languages. ACM Press, 1995.

No context found.

Xavier Leroy. Applicative functors and fully transparent higherorder modules. In ACM Symposium on Principles of Programming Languages, pages 142-153. ACM Press, 1995.

No context found.

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Proceedings of the 22th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 1995.

No context found.

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Proc. 22nd POPL, pages 142--153, 1995.

No context found.

Xavier Leroy. Applicative functors and fully transparent higherorder modules. In Proceedings of ACM Symposium on Principles of Programming Languages, pages 154--163, San Francisco, California, January 1995. ACM Press.

No context found.

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Proc. 22nd POPL, pages 142--153, 1995.

No context found.

Xavier Leroy. Applicative functors and fully transparent higher-order modules. In Twenty-Second ACM Symposium on Principles of Programming Languages, San Francisco, January 1995.

First 50 documents  Next 50

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