Xavier Leroy. Manifest types, modules and separate compilation. In Twenty-First ACM Symposium on Principles of Programming Languages, pages 109--122, Portland, Oregon, January 1994.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....to separate compilation as happens in our framework, simply because its validity requires the type environment extracted from the compilation environment to be well formed. Finally, several interesting papers can be found in literature on separate compilation for ML (see among many others [17, 16, 7]) All these papers clearly show that separate compilation in ML is not a simple issue, and for this reason, needs to be properly formalized. However, ML separate compilation is based on traditional static linking, therefore many problems arising in Java disappear in ML; for instance, the static ....

....results and to understand how they can contribute all together to the design of a better compiler linker for ML. For instance, using the terminology used in our paper to model the overall compilation process, 17] is mainly concerned with the de nition of the type extraction function, while [16] with the typechecking of sources and [7] with the de nition of the dependency function. 6 Conclusion We have introduced a formal framework modeling Java separate compilation. The overall compilation process is modeled by the formal notion of compilation schema, in which the aspects which ....

X. Leroy. Manifest types, modules and separate compilation. In ACM Symp. on Principles of Programming Languages 1994, pages 109-122. ACM Press, 1994.

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

.... without careful restrictions and extensions to ensure a suitable phase distinction [7] and to support features like sharing [14] Even then, it is still not possible to support true separate compilation [2] or to use modules as firstclass wlues [22, 12] Manifest types (transluscent sums) [6, 13] are an attempt to bridge the gap between the weak and strong sum approaches described above. A module type c = r. Complex c is much like an existential, except that it exposes the fact that a particular implementation type r was chosen. An extra rule in the type system can be used to make the ....

[Article contains additional citation context not shown here]

Xavier Leroy. Manifest types, modules and separate compilation. In Con.ference record of POPL 'gd: 21st A CA[ SIGPLA N-SIGA UT Symposium on Principles of Programming Languages, pages 109-122, Portland, OR, Jumary 1994.

....links implementations in order to form an executable program. The formal foundation for the module language is an extended typed A calculus called the AS calculus, which permits the syntactic control of generativity. The typing is based on dependent types [2, 29] due to manifest specifications [10, 14, 15] in signatures. The calculus is es sentially simply typed, with elementary modules and types as simple values, with elementary signatures and kinds as simple types, and with value dependent functions and systems as type constructors. Implementations of elementary modules are not part of the ....

....int0rd, the system makeInt0rd only declares the structure name int0rd and exports this structure. The module expression (id int0rd) is correctly typed, because the interface of int0rd is a subinterface of the required interface for the argument x, according to the usual notion of module subtyping [10, 14]. The normal form for makeInt0rd is a complete module expression without any free identifiers. In order to access the export part an additional construct bind is needed. For example bind m to makeIntfird in (id m) permits to use the export part of system makeIntfird by the name m in the module ....

[Article contains additional citation context not shown here]

Xavier Leroy. Manifest types, modules and separate compilation. In POPL-21 [24], pages 109- 122.

.... a variable (as x) component names are used for external referencing of deferred and defined components but they are not expressions, while variables are used for accessing deferred and local components inside mixins (for further details on the separation between variables and component names see [Ler94], HL94] AZ02] Local components are not visible from the outside and can be mutually recursive. Note that deferred, defined and local components can be declared in any order; in particular, definitions of defined and local components can be interleaved. Besides this construct, CMS do ....

X. Leroy. Manifest types, modules and separate compilation. In Proc. 21st ACM Symp. on Principles of Programming Languages, pages 109--122. ACM Press, 1994.

....SIG, the type theory must ensure that S.t is interchangeable with int in any code having access to S. The standard account of sharing in type theory was developed independently by Harper and Lillibridge, under the name translucent sums [6, 13] and by Leroy, under the name manifest types [10] (and extended in Leroy [11] These type theories provide a facility for stating type abbreviations in signatures and (importantly) ensure the correct propagation of type information resulting from those abbreviations. Exactly what is meant by correct propagation is discussed in Section 2.1. ....

....derived without using that rule. If this aim is achieved, any singleton kinds remaining within the constructors are not used (in any essential way) and can simply be erased, resulting in valid constructors and derivations in the singleton free system. 2 As an aside, in the module based accounts [6, 13, 10, 11] it is impossible to discover that the module analogues of these types are equal because comparisons can be made only on expressions in named form. Naming the expressions ff:T:ff and ff:T:int obscures the possible connection between them, which depends essentially on their actual code. In the ....

Xavier Leroy. Manifest types, modules and separate compilation. In TwentyFirst ACM Symposium on Principles of Programming Languages, pages 109--122, Portland, Oregon, January 1994.

.... MH88] This has started an ongoing discussion on the adequacy of defining abstract types through an advanced module system, such as in SML [Mac85, MTH90] It has also lead to the development of several proposals for the treatment of structures as first class values (see, e.g. MMM91, HL94, Ler94] Another important point is the conflict between the use of abstract types and the definition of functions by pattern matching, essentially based on data representation. None of the previous described approaches for the definition of abstract types allow the use of values of abstract types in ....

X. Leroy. Manifest types, modules and separate compilation. In Proc. 21th ACM Symp. on Principles of Programming Languages, pages 109--123, January 1994.

....with this approach. First, it requires first class modules; in the context of a rich type system, first class modules require a complicated formalization (e.g. Lillibridge [28] with restrictions on expressiveness; as a result, in most ML variants (and TAL as well) modules are second class [17] [26], 30] Second, it requires a type passing semantics as the type passed to load 0 must be checked against the actual type of the module at run time. This kind of semantics provides implicit type information to polymorphic functions, contrary to the e#orts of TAL to make all computation explicit. ....

X. Leroy. Manifest types, modules and separate compilation. In Twenty-First ACM Symposium on Principles of Programming Languages, pages 109--122, Portland, Oregon, Jan. 1994.

.... extern list a ; The and type parameter list a are used only if needed (they should be omitted if the type cannot be null and or is not polymorphic) Abstraction with abstract is enforced by the TAL module system, and follows ML style module systems notion of opaque types (e.g. see [HL94, Ler94] The second way of defining abstract types is via a more first class mechanism called abstype s. Since abstype s are an important part of our dynamic linking implementation, we include a complete tutorial below, taken (with slight formatting changes) from the Popcorn manual that comes with ....

.... context of a rich type system, first class modules require a complicated formalization (e.g. Lillibridge [Lil97] with restrictions on expressiveness; as a result, most ML variants (and TAL as well) do not permit modules to be manipulable as data, relegating them to second class status [HMM90, Ler94, MTHM97] 2. The signature argument to load 0 is essentially a type being used as data. Implementing types as data is typically done using a type passing semantics, which requires that types have a runtime representation, but one that is not under the explicit control of the programmer. TAL ....

[Article contains additional citation context not shown here]

Xavier Leroy. Manifest types, modules and separate compilation. In TwentyFirst ACM Symposium on Principles of Programming Languages, pages 109-- 122, Portland, Oregon, January 1994.

....of original SML [AM91] incZero could be typed as follows. def incZero (x: S, y: S sharing x.t = y.t) x.inc(y. zero) The unification based sharing constraints of original SML have been superseded in SML 97 [MTHM97] by translucent sums [HL94] and closely related manifest types [Ler94] which give a more logical approach to sharing and also have better properties for separate compilation. Using manifest types, the incZero example would be formulated as follows. def incZero (x: S, y: S type t = x.t ) x.inc(y.zero) In other words, we constrain the y parameter to range ....

Xavier Leroy. Manifest types, modules and separate compilation. In Conference record of POPL '94: 21st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 109--122, Portland, OR, January 1994.

....SIG, the type theory must ensure that S.t is interchangeable with int in any code having access to S. The standard account of sharing in type theory was developed independently by Harper and Lillibridge, under the name translucent sums [6, 13] and by Leroy, under the name manifest types [10] (and extended in Leroy [11] These type theories provide a facility for stating type abbreviations in signatures and (importantly) ensure the correct propagation of type information resulting from those abbreviations. Exactly what is meant by correct propagation is discussed in Section 2.1. ....

....singleton kinds, all product and sum kinds may be written in non dependent form. Also, all kinds in the singleton free calculus are well formed. The inference rules for the singleton free system are obtained by removing from the singleton calculus all 2 As an aside, in the module based accounts [6, 13, 10, 11] it is impossible to discover that the module analogues of these types are equal because comparisons can be made only on expressions in named form. Naming the expressions ff:T:ff and ff:T:int obscures the possible connection between them, which depends essentially on their actual code. In the ....

Xavier Leroy. Manifest types, modules and separate compilation. In Twenty-First ACM Symposium on Principles of Programming Languages, pages 109--122, Portland, Oregon, January 1994.

....theoretical foundations for modular programming provide valuable insights into the design 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 programming [23, 16, 21, 7, 22, 27, 1, 6, 13, 15, 3]. The main proposals 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 To appear in the Twenty Third Annual ACM SIGPLANSIGACT Symposium on Principles of Programming ....

.... without careful restrictions and extensions to ensure a suitable phase distinction [7] and to support features like sharing [14] Even then, it is still not possible to support true separate compilation [2] or to use modules as firstclass values [22, 12] ffl Manifest types (transluscent sums) [6, 13] are an attempt to bridge the gap between the weak and strong sum approaches described above. A module type 9c = Complex c is much like an existential, except that it exposes the fact that a particular implementation type was chosen. An extra rule in the type system can be used to make the ....

[Article contains additional citation context not shown here]

Xavier Leroy. Manifest types, modules and separate compilation. In Conference record of POPL '94: 21st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 109--122, Portland, OR, January 1994.

....split in independent modules. 1 Introduction In the last years, considerable e ort has been invested in studying theoretical foundations and developing new forms of module systems; let us mention the wide literature about foundations and improvements of Standard ML module system (see, e.g. [18, 17]) the notions of mixins (see, e.g. 15, 3, 2] and units [14] the type theoretical analysis of recursion between modules proposed in [9] A principle which seems to emerge as common idea of all these approaches is that a module system should have two linguistic levels: a module language ....

....calculus CMS considered in [4] this also allows the independence from the core language. Analogous distinctions are those between program variables and labels that connects fragments in [17] variables and eld method names in the Abadi Cardelli s object calculus [1] and names and identi ers in [18]; also in MzScheme s units [14] imported and exported variables have separate internal (binding) and external (linking) names, and the internal names within a unit can be renamed. In the following, we assume a special internal (resp. external) class name object (resp. Object) Other prede ned ....

X. Leroy. Manifest types, modules and separate compilation. In ACM Symp. on Principles of Programming Languages 1994, pages 109-122. ACM Press, 1994.

....provided by a richer module system. 1 Introduction In the last years, considerable e ort has been invested in studying theoretical foundations and developing new forms of module systems; let us mention the wide literature about foundations and improvements of Standard ML module system (see e.g. [15, 13]) the notions of mixins (see e.g. 12, 1, 8] and units [11] the type theoretical analysis of recursion between modules proposed in [7] A principle which seems to emerge as common idea of all these approaches is that a module system should have two linguistic levels: a module language ....

X. Leroy. Manifest types, modules and separate compilation. In ACM Symp. on Principles of Programming Languages 1994, pages 109-122. ACM Press, 1994.

....another through two independent paths, and the type checker must be able to verify that the two paths really lead to the same module. This is an essential problem to solve in any module mechanism which allows parametric import and the co existence of multiple implementations of the same interface ([15, 16]) Furthermore the combination of existential types with abstract, semi abstract or concrete witness (point 5) is to our knowledge unique to Fibonacci. This combination allows several interfaces to be defined for one module, so that other modules can access its contents with various degrees of ....

Xavier Leroy. Manifest types, modules and separate compilation. In Conference record of POPL '94: 21st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 109--122, Portland, OR, January 1994.

....S( 0 ) then = 0 . The necessary subsignature relationship is obtained by observing that S(int) is a subkind of the kind T of all types. The management of type information for modules using formalisms similar to singleton kinds are explored in detail by Harper and Lillibridge [4] and Leroy [7]. Despite providing a very elegant solution to the type propagation problem, singleton kinds can substantially complicate type checking, for reasons discussed in Section 2. Stone and Harper [15] have recently shown that, despite these complications, type checking is decidable in the presence of ....

Xavier Leroy. Manifest types, modules and separate compilation. In Twenty-First ACM Symposium on Principles of Programming Languages, pages 109--122, Portland, Oregon, January 1994.

No context found.

Xavier Leroy. Manifest types, modules and separate compilation. In Twenty-First ACM Symposium on Principles of Programming Languages, pages 109--122, Portland, Oregon, January 1994.

No context found.

X. Leroy. Manifest types, modules and separate compilation. In Proc. 21st ACM Symp. on Principles of Programming Languages, pages 109-122. ACM Press, 1994. 12

No context found.

X. Leroy. Manifest types, modules and separate compilation. In Proc. 21st ACM Symp. on Principles of Programming Languages, pages 109-122. ACM Press, 1994.

No context found.

X. Leroy. Manifest types, modules and separate compilation. In Proc. 21st ACM Symp. on Principles of Programming Languages, pages 109--122. ACM Press, 1994.

No context found.

X. Leroy. Manifest types, modules and separate compilation. In ACM Symp. on Principles of Programming Languages 1994, pages 109-122. ACM Press, 1994.

No context found.

Xavier Leroy. Manifest types, modules and separate compilation. In Proc.ofACM POPL, pages 109--122, Portland, OR, January 1994.

No context found.

X. Leroy. Manifest types, modules and separate compilation. In ACM Symp. on Principles of Programming Languages 1994, pages 109--122. ACM Press, 1994.

No context found.

X. Leroy. Manifest types, modules and separate compilation. In ACM Symp. on Principles of Programming Languages 1994, pages 109--122. ACM Press, 1994.

No context found.

X. Leroy. Manifest types, modules and separate compilation. In ACM Symp. on Principles of Programming Languages 1994, pages 109--122. ACM Press, 1994.

No context found.

Xavier Leroy. Manifest types, modules and separate compilation. In TwentyFirst ACM Symposium on Principles of Programming Languages, pages 109#122, Portland, Oregon, January 1994.

First 50 documents

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