Cardelli, L. (1993). Typeful programming. SRC Research Report 45, May 24, 1989.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....strongly typed functional programming languages (e.g. ML [MTH90] Miranda [Tur85] Haskell [HW88] have chosen to use the Hindley Milner type system whose core coincides with a fragment of F. There are also various programming languages using type systems based on variations of F (e.g. Quest [Car91] and LEAP [PL89] The choice to use a type system similar to F or some portion of F in real world programming languages has many reasons. The minimal requirement is that the type system rules out nonsense computations. Once that is achieved, there are other considerations. From a software ....

L. Cardelli. Typeful programming. In Formal Description of Programming Concepts. Springer-Verlag, 1991. Also DEC SRC Research Report 45.

....one s client code to operate on objects of these new subtypes using the protocol of their supertypes. However, the type systems of OO languages, like C [46] and Java [3] do not take the semantics of types into account; that is, the type system only guarantees the lack of runtime type errors [7], not the lack of behavior that would be surprising, given a speci cation of the supertype s behavior. A well known technique for preventing such surprising behavior in a modular way is behavioral subtyping [1, 2, 6, 11, 12, 21 24, 31, 34, 35, 47, 48] Behavioral subtyping ensures that objects ....

....Mikhajlova and her coauthors [36] present sound veri cation of OO programs in a re nement calculus framework. However, their work is based on class re nement and treating classes as types restricts both subclasses and subtypes [44] Abadi and Leino [1] extend the work of Cardelli s [7] structural subtyping rules on records to include behavior. They present an axiomatic semantics and provide guidance on reasoning about OO programs. However, their approach is not modular and does not provide any help to make reasoning about cross type aliasing practical. Recently, Huisman [16] ....

L. Cardelli. Typeful programming. In E. J. Neuhold and M. Paul, editors, Formal Description of Programming Concepts, IFIP State-of-the-Art Reports, pages 431{

....permission of the Associat on of .Compu ng Machinery. To copy otherwise, or to republish, requires a Tee and or specific permission. POPL 95 1 95 San Francisco CA USA ) 1995 ACM 0 89791 692 1 95 0001. 3. 50 ML module system: the dot notation as elimination con struct for abstract types [3, 4] and the notion of type sharing and its propagation through functors [7, 10] Unfortunately, some features described by operational frameworks remain unaccounted for in the abstract approach, such as structure sharing and the fully transparent behavior of higher order functors predicted by the ....

....as signature constraints can be used for the same purposes. 146 2.7 Applicative functors and side effects In an imperative language such as ML, one may wonder whether the hypothesis that functors map equals to equals is sound. In a language with side effects and modules as first class values [3, 7], the applicative semantics for functors is actually unsound: val r = ref false functor F( sig type t end = r : not r; if r then struct type t = int end else struct type t = bool end) structure A = F( structure B = F( Semantically, A.t is int and B.t is bool, but the applicative ....

L. Cardelli. Typeful programming. In E. J. Neuhold and M. Paul, editors, Formal description of programming concepts, pages 431-507. Springer-Verlag, 1989.

....types) we argue that this is a small price to pay for the overall simplifications resulting from this restric tion. 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 ....

....in this paper is the introduction of kinds at the level of core types. Kinds are required to ensure the well formedness of type expressions in the presence of type constructors, as in full ML, 120 or type operators, as in F, Kinds also provide an elegant treatment of bounded quantification [3, 4]. Introducing kinds in the module calculus is straightforward: abstract type specifications in signatures now have the form type t : n, where n is a kind. The modified typing rules check that the implementation types are of the expected kinds, and that kinds are properly included when checking ....

[Article contains additional citation context not shown here]

L. Cardelli. Typeful programming. In E. J. Neuhold and M. Paul, editors, Formal Description of Programming Concepts, pages 431-507. Springer-Verlag, 1989.

....ACM copyright notice end the title of the publication and ite date appear. and notice ie given that copying ie by permission of the Association for Computing Machinery. To copy otherwise. or to republish. requires a fee and or specific permission. POPL 94 1 94, Portland Oregon,USA ( 1994 ACM 0 89791 636 0 94 001. 3.50 programming idioms; the language may be easily restricted to second class modules found in ML like languages. I Introduction Modularity is an essential technique for developing and maintaining large software systems [46, 24, 36] Most modern programming languages provide ....

.... I Introduction Modularity is an essential technique for developing and maintaining large software systems [46, 24, 36] Most modern programming languages provide some form of module system that supports the construction of large systems from a collection of separately defined program units [7, 8, 26, 32] A fundamental problem is the man agement of the tension between the need to treat the components of a large system in relative isolation (for both conceptual and pragmatic reasons) and the need to combine these components into a coherent whole. In typical cases this problem is ....

[Article contains additional citation context not shown here]

Luca Cardelli. Typeful programming. Technical Report 45, DEC SRC, 1989.

....of the same abstract datatype. The paper focuses on the issue of data abstraction, and does not directly address other desirable features of modules languages, notably mechanisms for name space control and subtyping on module interfaces. 2.3.1. 2 Cardelli s Quest Cardelli s language Quest [6, 8, 11, 9] is an early type theoretic programming language designed explicitly for the construction of modular programs. Quest is equipped with a form of dependent record, which allows sequences of related type and term definitions to be treated collectively. Dependent records are essentially a ....

Luca Cardelli. Typeful Programming. In E. J. Neuhold and M. Paul, editors, Formal Description of Programming Concepts, IFIP State of the Art Reports Series. Springer-Verlag, February 1989.

....file s value heap. When given a bound, a type label is like a partially abstract type. The typing rules allow a bounded type label to be unrolled to its bound but do not allow a roll operation on that type label. This approach is based upon standard type theory on singleton kinds and power kinds [Car88, Car91] respectively. However, as we only sup port globally scoped type labels, the setting is greatly simplified because we do not need both internal and external names for types as in Harper and Lillibridge. Again, the price paid is that programmers or compilers must manage the fiat name space. In ....

Luca Cardelli. Typeful programming. In Formal Description of Programming Concepts. Springer-Verlag, 1991.

....is enforced. This abstract approach has since been extended to account for the main features of the Standard To appear in the proceedings of the 22nd symposium Principles of Programming Languages, january 1995. ML module system: the dot notation as elimination construct for abstract types [3, 4] and the notion of type sharing and its propagation through functors [7, 10] Unfortunately, some features described by operational frameworks remain unaccounted for in the abstract approach, such as structure sharing and the fully transparent behavior of higher order functors predicted by the ....

....such as signature constraints can be used for the same purposes. 5 2.7 Applicative functors and side e ects In an imperative language such as ML, one may wonder whether the hypothesis that functors map equals to equals is sound. In a language with side e ects and modules as rst class values [3, 7], the applicative semantics for functors is actually unsound: val r = ref false functor F( sig type t end = r : not r; if r then struct type t = int end else struct type t = bool end) structure A = F( structure B = F( Semantically, A.t is int and B.t is bool, but the applicative ....

L. Cardelli. Typeful programming. In E. J. Neuhold and M. Paul, editors, Formal description of programming concepts, pages 431-507. Springer-Verlag, 1989.

....types) we argue that this is a small price to pay for the overall simpli cations resulting from this 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 ....

....presented in this paper is the introduction of kinds at the level of core types. Kinds are required to ensure the well formedness of type expressions in the presence of type constructors, as in full ML, or type operators, as in F . Kinds also provide an elegant treatment of bounded quanti cation [3, 4]. Introducing kinds in the module calculus is straightforward: abstract type speci cations in signatures now have the form type t : where is a kind. The modi ed typing rules check that the implementation types are of the expected kinds, and that kinds are properly included when checking ....

[Article contains additional citation context not shown here]

L. Cardelli. Typeful programming. In E. J. Neuhold and M. Paul, editors, Formal Description of Programming Concepts, pages 431-507. Springer-Verlag, 1989.

....hence they correctly generalize it. This aw of our method has little impact on actual programming, however. 4.2 Quest In our system, we made no attempt at restricting the creation of mutable values, and concentrated on type generalization instead. We were inspired by Cardelli s Quest language [2], which departs signi cantly from ML, but features mutable data structures and polymorphic typing. Quest makes almost no typing restrictions for mutable values. Soundness is ensured by di erent semantics for type specialization. Namely, an expression with polymorphic type is evaluated each time ....

L. Cardelli. Typeful programming. In E. J. Neuhold and M. Paul, editors, Formal Description of Programming Concepts, pages 431-507. Springer-Verlag, 1989.

....Nishizaki s environment calculus, ## only supports a simple type system. Aside from Piccola, various other languages have supported explicit environments. Scheme [Dyb87] is the best known, and is dynamically typed. Pebble [BL84] is the other well known example, and is statically typed. Quest [Car91] was inspired by Pebble, and supports explicit import and export of first class modules. The contracts expressed by contractual types are technically very weak, and do not capture behavioural contracts, such as pre or post conditions to services, or protocols over sets of services. Regular ....

Luca Cardelli. Typeful programming. In E. J. Neuhold and M. Paul, editors, Formal Description of Programming Concepts, IFIP State of the Art Reports Series, pages 431--507. Springer-Verlag, 1991.

....value is shared between all specializations of the polymorphic term produced. With polymorphism by name, generalization has lazy semantics: it suspends the evaluation of its argument, and each specialization re evaluates this suspension in the current context. Polymorphism by name is used in Quest [2]; viewed as a restricted form of polymorphism, the generics of Clu or Ada also follows this semantics. Drawing the parallel with function application, polymorphism by value is analogous to call by value, and polymorphism by name is analogous to call by name. These two semantics for polymorphism ....

....to references and continuations, and provide excellent support for the imperative programming style. This fact is folk lore, and the author does not claim originality for noticing it. It is brie y mentioned in several discussions of imperative languages with polymorphic type systems [7, 2]. This fact is also apparent in Harper and Lillibridge s recent work on CPS conversion for polymorphic languages [9, 10] which shows that an ML like language (i.e. one with call by value and polymorphism by value) does not admit any type preserving CPS transform, in contrast to languages with ....

[Article contains additional citation context not shown here]

L. Cardelli. Typeful programming. In E. J. Neuhold and M. Paul, editors, Formal Description of Programming Concepts, pages 431-507. Springer-Verlag, 1989.

....one s client code to operate on objects of these new subtypes using the protocol of their supertypes. However, the type systems of OO languages, like C [46] and Java [3] do not take the semantics of types into account; that is, the type system only guarantees the lack of runtime type errors [7], not the lack of behavior that would be surprising, given a specification of the supertype s behavior. A well known technique for preventing such surprising behavior in a modular way is behavioral subtyping [1, 2, 6, 11, 12, 21 24, 31, 34, 35, 47, 48] Behavioral subtyping ensures that objects ....

....Mikhajlova and her coauthors [36] present sound verification of OO programs in a refinement calculus framework. However, their work is based on class refinement and treating classes as types restricts both subclasses and subtypes [44] Abadi and Leino [1] extend the work of Cardelli s [7] structural subtyping rules on records to include behavior. They present an axiomatic semantics and provide guidance on reasoning about OO programs. However, their approach is not modular and does not provide any help to make reasoning about cross type aliasing practical. Recently, Huisman [16] ....

L. Cardelli. Typeful programming. In E. J. Neuhold and M. Paul, editors, Formal Description of Programming Concepts, IFIP State-of-the-Art Reports, pages 431--

.... that is enforced by statically typed OO languages, like C [44] and Java [4] does not take the semantics of types into account; that is, the type system of such languages merely checks that declared subtype relationships satisfy certain restrictions that guarantee the lack of runtime type errors [8]. These checks are modular in the sense that the type checker only needs access to type information for the supertypes and the code of the new subtypes; it does not need to re typecheckunchanged code that is reused. Modularityallows type checking to be practical. However, suchchecks are not ....

....Mikhajlova and her coauthors [35] present sound veri cation of OO programs in a re nement calculus framework. However, their work is based on class re nement and treating classes as types restricts both subclasses and subtypes [42] Abadi and Leino [2] extend the work of Cardelli s [8] structural subtyping rules on records to include behavior. They present an axiomatic semantics and provide guidance on reasoning about OO programs. However, their approachisnot modular. Recently, Huisman [16] and Oheimb [47] havegiven sound (and in the case of Oheimb, relatively complete) veri ....

L. Cardelli. Typeful programming. In E. J. Neuhold and M. Paul, editors, Formal Description of Programming Concepts, IFIP State-of-the-Art Reports, pages 431-507. Springer-Verlag, New York, NY, 1991.

No context found.

Cardelli, L., Typeful programming. In Formal Description of Programming Concepts, E.J. Neuhold and M. Paul, ed. Springer-Verlag. 431-507. 1991.

No context found.

Cardelli, L. (1993). Typeful programming. SRC Research Report 45, May 24, 1989.

No context found.

Luca Cardelli. Typeful programming. In IFIP Advanced Seminar on Formal Description of Programming Concepts, 1989.

No context found.

CARDELLI, L. 1989. Typeful programming. Rep. 45, DEC Systems Research Center, Palo Alto, Calif., May.

No context found.

L. Cardelli. Typeful programming. pages 471--522. Springer-Verlag, 1991.

No context found.

Luca Cardelli. Typeful Programming. In Formal Description of Programming Concepts, Springer-Verlag, 1991.

No context found.

Luca Cardelli. Typeful programming. In E. J. Neuhold and M. Paul, editors, Formal Description of Programming Concepts, IFIP State of the Art Reports Series, pages 431-- 507. Springer-Verlag, 1991.

No context found.

L. Cardelli. Typeful programming. Research Report 45, DEC SRC, May 24, 1989.

No context found.

Luca Cardelli. Typeful programming. Technical Report 45, DEC SRC, 1989.

No context found.

L. Cardelli, `Typeful programming', Technical Report #45, Systems Research Center, Digital Equipment Corporation, Palo Alto, California, May 1989.

No context found.

L. Cardelli. Typeful programming. pages 471-522. Springer-Verlag, 1991.

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