| David MacQueen. Using dependent types to express modular structure. In Thirteenth ACM Symposium on Principles of Programming Languages, 1986. |
....(Section 4.2, 3] Faxen s work is consistent with the report in that it does not specify how to treat mutually recursive modules. Our specification of the Haskell module system is relatively independent of Haskell itself. In this respect it is similar to Leroy s work on ML s module system [7]. There have been numerous studies on advanced module systems, and the use of type theory to formalize them [4, 8] In the same spirit, there has recently been a proposal for a replacement of the Haskell module system by Shields and Peyton Jones [11] 9 Conclusions and discussion We have ....
D. B. MacQueen. Using dependent types to express modular structure. In Proc. of 1986.
....e as s:# in (e # : #) e#(#s:#.e ) Compare the definition of with the standard encoding of the existential type ##.# ##. ##.###)##. The main limitation of existentially packaged modules is the closed scope elimination construct. It has been observed repeatedly in the literature [20, 3, 18] that this construct is too restrictive to be very useful. For one, in unpack e as s:# in (e # : #) the result type # may not mention s. As a consequence, functions over packaged modules may not be dependent; that is, the result type may not mention the argument. This deficiency is mitigated in ....
David MacQueen. Using dependent types to express modular structure. In Thirteenth ACM Symposium on Principles of Programming Languages, 1986.
....system [10, 11] 2.2 Restriction of projections to paths An obvious generalization of type paths is to allow projections of type components from arbitrary structure expressions: then, m. t would be a valid type expression for any structure expression m whose result contains a t component [12, 9]. This extension adds considerable expressive power, but raises delicate issues. First, when are two type expressions m.t and m .t compatible Clearly, we cannot check that m and m reduce to the same structure, since equality of structure expressions is undecidable. Second, even if we compare ....
....functors that take Diet or PrioDueue as arguments must also be modified. Hoisting the application Set(IntGrder) from the points where it is actually used to a common ancestor of these points in the dependency graph is a non local program transformation, as in MacQueen s diamond import example [12]. 144 Introducing functor applications in paths enables a much more elegant solution: the functors Dict and PrioQueue can apply Set locally, as in the original attempt, and receive the following signatures: functor Dict(Key: ORD) sig type key = Key.t type a dict val domain: a dict ....
[Article contains additional citation context not shown here]
D. B. MacQueen. Using dependent types to express modular structure. In 13th syrup. Principles of Progr. Lang., pages 277-286. ACM Press, 1986.
....studies were generally based on consideration of the ML core language alone, and did not take modules into account. We will adopt the view of modules proposed by MacQueen, in which the main constructs are reduced to the and l types (the so called dependent types) of Martin LSFs type theory [29]. Using the typed calculus with these constructs, we are able to show that universes play an important role. Our examination of universes involves close study of a restricted subset of the language. In the fragment of Standard ML, without recursion or recursively defined types, every ....
....5, the identifier 5.x refers to the x component of 5, and hence evaluates to 3. Similarly, t refers to the t component of and is equivalent to the type Int during type checking. This transparency of type definitions distinguishes ML structures from abstract data type declarations (see MacQueen [29] and Mitchell and Plotkin [47] for related discussion) Signatures are a form of type or interface for structures, and may be bound to signature identifiers using a signature binding, as follows: signature SIG = sig type t val x: t This signature describes the class of structures having ....
[Article contains additional citation context not shown here]
MACQUeEN, D.B. Using dependent types to express modular structure. In Proceedzngs of the 13th ACM Symposium on Principles of Programming Languages (1986), 277-286
....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 ....
....packages to be treated as first class values and is fully compatible with separate compilation. However, for the purposes of modular programming, existentials are often too good at hiding implementation types because they do not allow adequate propagation of type infor mation between packages [16]. Dependent types (transparent, or strong sums) 18, 16, 21] A module of type P,c. Coraplex c is represented by a pair r, M) containing the type r used to represent complex numbers and an implementation M of type Complex r for the complex number operators. The ability to include type ....
[Article contains additional citation context not shown here]
David MacQueen. Using dependent types to express modular structure. In lSth Annual ACM Symposium o Prtncple's of Pvgrammmg lctnguages, pages 277- 286, St. Petersburg Beach, FL, January 1986.
....issue that they do not consider, which is central to our work, is what model dynamic linking should use for software components and for linking components. An obvious candidate is the ML module system [26] which provides fairly sophisticated support for type safe linking as a language construct [23,6]. Indeed this is the philosophy underlying MTAL, which relies on a phase splitting transformation 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 ....
David MacQueen. Using dependent types to express modular structure. In Proceedings of ACM Symposium on Principles of Programming Languages, pages 277--286. ACM Press, 1986.
....failure is a symptom of an intrinsic incoherence in the language, or is merely an artifact of the semantic method. a In an effort to gain some insight into the complexi ties of the static semantics several authors have under taken a type theoretic analysis of SML, especially its module system [27, 33, 35, 7, 20, 19] Previous studies of the module system foc used on the transparency of SML style structures through the use of strong sum or dependent product types. These are types of the form Ex:A.B(x) whose elements are pairs (M,M2) that are accessed via projections r(M) and r2(M) The ....
....(M,M2) that are accessed via projections r(M) and r2(M) The crucial properties of strong sums [29] are that if M : Ex:A.B(x) then r(M) B(h(M) and that rq( M1, M) M. Together, these properties ensure that type information is propagated in rough accord with the SML static semantics. See [27, 33, 20, 19] for further discussion. Substitution based methods are problematic in the presence of computational effects, unless care is taken to account for the phase distinction [20] Moreover, strong sums fail to account for sharing specifications and the abstract nature ( generativity ) of ....
[Article contains additional citation context not shown here]
David MacQueen. Using dependent types to express modular structure. In Thirteenth ACM Symposium on Principles of Programming Languages, 1986.
....the main inspiration for our module language. Man ifest type specifications have also been used in [15, 14, 10] Contrary to these approaches, we also allow manifest structure specifications. The semantics of higher order functors in SML s module language has been treated by several authors. In [11, 17], a treatment based on strong sums has been given. Leroy [14] provides a description based on weak sums, which is able to treat generative and nongenerative type specifications. The stamp based approach by Biswas [4] does not handle type generativity. Only MacQueen and Tofte s work [18] takes into ....
....implementation and module language, other authors try to integrate module and implementation language into a single calculus. Harper and Lillebridge [10] suggest an impredicative calculus with modules as first class values based on Girards F (see for example [8, 2] The seminal work of MacQueen [17] uses a predicative (ramified) calculus based on strong sums. 5 Conclusion We started this work from a software engineering point of view. The motivation was to describe ref 10 erence architectures for an entire product line. The functorized style suggested by SML s module lan guage [23] was ....
David MacQueen. Using dependent types to express modular structure. In 13th Symposium on Principles of Programming Languages, pages 277-286. ACM Press, January 1986. 11
....of the functor will propagate the realisation of type components from the functor s actual argument to its result. Like SOL, Quest supports first class modules and avoids Standard ML s stratification between Core and Modules. 2.3.1. 3 MacQueen s DL In an influential position paper, MacQueen [35] criticises module languages in which the only facility for grouping related definitions of types and terms is provided by existential types. MacQueen s argument is that existential types do not give adequate support for modular programming because the abstraction a#orded by existential ....
....for generative type definitions: every type component is transparent and there is no primitive support for type abstraction. 2.3.2 Type Theoretic Accounts of Standard ML Modules 2.3.2. 1 Harper and Mitchell s XML Harper and Mitchell s calculus XML [20] is an attempt to apply MacQueen s ideas [35] to provide a type theoretic semantics of Standard ML. Surprisingly, they make no e#ort to relate their calculus to the published semantics of Standard ML [43] As a model of Standard ML Modules, XML exhibits essentially the same successes and shortcomings of DL. The use of weak existential types ....
[Article contains additional citation context not shown here]
David MacQueen. Using dependent types to express modular structure. In 13th ACM Symp. on Principles of Prog. Lang., 1986. 351
....system [10, 7, 11] 2. 2 Restriction of projections to paths An obvious generalization of type paths is to allow projections of type components from arbitrary structure expressions: then, m:t would be a valid type expression for any structure expression m whose result contains a t component [12, 9]. This extension adds considerable expressive power, but raises delicate issues. First, when are two type expressions m:t and m :t compatible Clearly, we cannot check that m and m reduce to the same structure, since equality of structure expressions is undecidable. Second, even if we ....
....functors that take Dict or PrioQueue as arguments must also be modi ed. Hoisting the application Set(IntOrder) from the points where it is actually used to a common ancestor of these points in the dependency graph is a non local program transformation, as in MacQueen s diamond import example [12]. 3 Introducing functor applications in paths enables a much more elegant solution: the functors Dict and PrioQueue can apply Set locally, as in the original attempt, and receive the following signatures: functor Dict(Key: ORD) sig type key = Key.t type a dict . val domain: a dict ....
[Article contains additional citation context not shown here]
D. B. MacQueen. Using dependent types to express modular structure. In 13th symp. Principles of Progr. Lang., pages 277-286. ACM Press, 1986.
....are transparent is no accident: it accounts for a large part of the expressive power of SML modules. Treating type speci cations as opaque, that is, making all exported types abstract, would x the problem with separate compilation but drastically reduce the expressiveness of the module system [15]. 1.3 This work This paper proposes a way out of this dilemma: make type speci cations opaque (so that the users of a structure can only assume what is declared in its signature) but enrich signatures with manifest type speci cations. A manifest type speci cation of the form type t = not ....
....restriction. On the technical side, the main originality of this paper is the use of what is essentially weak sums [19, 7] albeit with an unusual elimination construct: the dot notation [4, 5] instead of the strong sums that have been used so far to give type theoretic accounts of SML modules [15, 12, 13]. Unlike strong sums, weak sums provide direct support for type abstraction and make the phase distinction [13] obvious. The well known inadequacies of weak sums for modular programming [15] are here o set by the extra expressiveness brought by manifest types. The present paper also puts ....
[Article contains additional citation context not shown here]
D. MacQueen. Using dependent types to express modular structure. In 13th symposium Principles of Programming Languages, pages 277-286. ACM Press, 1986.
....s:# in (e # : #) e # (#s:#.e # ) Compare the definition of with the standard encoding of the existential type ##.# as ##. ##. ##)##. The main limitation of existentially packaged modules is the closed scope elimination construct. It has been observed repeatedly in the literature [19, 3, 17] that this construct is too restrictive to be very useful. For one, in unpack e as s:# in (e # : # ) the result type # may not mention s. As a consequence, functions over packaged modules may not be dependent; that is, the result type may not mention the argument. This deficiency is mitigated ....
David MacQueen. Using dependent types to express modular structure. In Thirteenth ACM Symposium on Principles of Programming Languages, 1986.
....e as s:s in (e # : t) et(Ls:s.e # ) Compare the definition of with the standard encoding of the existential type #b.t #a. #b.t#a)#a. The main limitation of existentially packaged modules is the closed scope elimination construct. It has been observed repeatedly in the literature [20, 3, 18] that this construct is too restrictive to be very useful. For one, in unpack e as s:s in (e # : t) the result type t may not mention s. As a consequence, functions over packaged modules may not be dependent; that is, the result type may not mention the argument. This deficiency is mitigated in ....
David MacQueen. Using dependent types to express modular structure. In Thirteenth ACM Symposium on Principles of Programming Languages, 1986.
....this failure is a symptom of an intrinsic incoherence in the language, or is merely an artifact of the semantic method. In an e#ort to gain some insight into the complexities of the static semantics several authors have undertaken a type theoretic analysis of SML, especially its module system [27, 33, 35, 7, 20, 19]. Previous studies of the module system focused on the transparency of SML style structures through the use of strong sum or dependent product types. These are types of the form #x:A.B(x) whose elements are pairs #M 1 ,M 2 that are accessed via projections # 1 (M) and # 2 (M ) The ....
....accessed via projections # 1 (M) and # 2 (M ) The crucial properties of strong sums [29] are that if M :#x:A.B(x) then # 2 (M) B(# 1 (M ) and that # 1 (#M 1 ,M 2 #) M 1 . Together, these properties ensure that type information is propagated in rough accord with the SML static semantics. See [27, 33, 20, 19] for further discussion. Substitution based methods are problematic in the presence of computational e#ects, unless care is taken to account for the phase distinction [20] Moreover, strong sums fail to account for sharing specifications and the abstract nature ( generativity ) of structure and ....
[Article contains additional citation context not shown here]
David MacQueen. Using dependent types to express modular structure. In Thirteenth ACM Symposium on Principles of Programming Languages, 1986.
.... techniques of the more powerful Calculus of Constructions [Coquand 1985b, Mobring 1986, Coquand Huet 1988] For example, we can define a form of dependent pair type, also called a general sum or an existential type, that is useful for modelling abstract data types [Mitchell Plotkin 1985, MacQueen 1986] The combination of dependent function types and the type of all types yields enormous expressive power at very little apparent cost, and it does so in a conceptually clean and uniform way by treating types as values. Unfortunately, we shall see that the typechecking problem for a language with ....
....a lefthand projection and out, but lacking a right hand projection, the dependent pairs definable in the X calculus lie between the two. Mitchell : Plotkin 1985] observe that implementations of abstract data types in languages such as Ada, cLu, and ML can be modelled by weak dependent pairs. [MacQueen 1986] argues that weak dependent pairs are not flexible enough for full fledged programming in the large, and proposes instead the use of strong de pendent pairs. Unfortunately, the familiar polymorphic h calculus of [Girard 1972] and [Reynolds 1974] augmented with strong dependent pairs admits the ....
David B. MacQueen. Using dependent types to express modular structure. In Principles of Programming Languages, pages 277-286, ACM, January 1986.
....system, if there exists, for some type oe, a derivation of Gamma e : oe, in this type system. In this work, we present some examples of type systems that support the definition of constructs used in modern programming languages. Some recent research topics, like dependent types [ML78, ML84, Mac86, C 86, CH88] intersection types [Jim96] impredicative polymorphism [Gir71, Gir89, Rey74] and works related with module systems [HL94, Mac85, MTH90, Mac86, MMM91] will not be treated here. It should be noted that formal systems can be used to define not only types, but also other ....
....support the definition of constructs used in modern programming languages. Some recent research topics, like dependent types [ML78, ML84, Mac86, C 86, CH88] intersection types [Jim96] impredicative polymorphism [Gir71, Gir89, Rey74] and works related with module systems [HL94, Mac85, MTH90, Mac86, MMM91] will not be treated here. It should be noted that formal systems can be used to define not only types, but also other properties of programming language constructs. 2.1 Types and meanings Well typed programs, as well as types used in these programs, have a meaning. In this section, we ....
[Article contains additional citation context not shown here]
D. MacQueen. Using Dependent Types to Express Modular Structure. In Proc. of the 13th ACM Symp. on Principles of Programming Languages, pages 277--286, 1986.
....reader may be alarmed by our use of existential quanti cation over higher kinded type variables. Haskell uses a simple but incomplete uni cation algorithm for higher kinded types which turns out to work very well in practice [4] stract, but equal types, known as the diamond import problem [9] in the literature. For example, assume we have a function which, given any implementation of sets, generates some additional helper functions: record SetHelp a f = unionAll : f a] f a mkSetHelp : forall a f . Set a f SetHelp a f mkSetHelp set = SetHelp unionAll = foldr ....
D. B. MacQueen. Using dependent types to express modular structure. Proceedings of the 13th ACM Symposium on Principles of Programming Languages, St. Petersburg, USSR, pages 277-286, Jan. 1986.
....structures, to ordinary modules. In the original Standard ML module system ( 7,10] functors were first order, because their parameters and results could only be structures, and functors could not be components of structures. But the type theoretic analysis of the module system carried out in [8,11,5] made it clear that it was natural to extend the notion of functors to higher orders by allowing functors as param eters and results (or, equivalently, allowing structures to contain functor components) Doing so makes the language more symmetrical and supports useful new modes of pa ....
David MacQueen. Using dependent types to express modular structure. In Thirteenth Annual ACM Symp. on Principles of Prog. Languages, pages 277 286, New York, Jan 1986. ACM Press.
....the revision of ML that led to the Standard ML language was the inclusion of module facilities for the support of programming in the large. The design of these facilities went through several versions [8] and was supported by concurrent investigations of the type theory of ML and related systems [9,11]. The central idea behind the design was to support modularity by introducing a stratified system of dependent types as suggested by Martin L6f s Intuitionistic Type Theory [10] In late 1985 Bob Harper added a prototype implementation of most of the module facilities to the Edinburgh ML compiler, ....
....through functor applications, so that after the declaration structure IntLexOrd = LexOrd (IntOrd) IntLexOrd. le has type int list int list bool. This reflects the dependent product nature of functor signatures, and the fact that structures represent a form of strong dependent sum (see [9,11] for discussion of the relation between ML modules and dependent types) 3. Implementation of modules The principal tasks that an implementation must deal with are as follows: 1) representation of signatures, structures, and functors. 2) signature matching, including instantiation of the ....
D. MacQueen, Using dependent types to express modular structure, Proceedings 13th ACM Symposium on Principles of Programming Languages, St. Petersburg Beach, 1986, 277-286.
No context found.
David MacQueen. Using dependent types to express modular structure. In Thirteenth ACM Symposium on Principles of Programming Languages, 1986.
No context found.
D. MacQueen. Using dependent types to express modular structure. In POPL'86, 1986.
No context found.
David MacQueen. Using dependent types to express modular structure. In Proceedings of the 13th ACM Symposium on Principles of Programming Languages. ACM Press, 1986.
No context found.
David MacQueen. Using dependent types to express modular structure. In Proceedings of the 13th ACM Symposium on Principles of Programming Languages. ACM Press, 1986.
No context found.
MacQueen, D.B., Using dependent types to express modular structure. Proc. 13th An- nual ACM Symposium on Principles of Programming Languages. 277-286. 1986.
No context found.
D. MacQueen. Using dependent types to express modular structure. In Proc. 13th Annual ACM SIGPLAN-SIGACT Symp. on Principles of Programming Languages, pages 277-286. ACM Press, 1986.
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