Results 1 - 10
of
114
Order-Sorted Algebra I: Equational Deduction for Multiple Inheritance, Overloading, Exceptions and Partial Operations
- Theoretical Computer Science
, 1992
"... This paper generalizes many-sorted algebra (hereafter, MSA) to order-sorted algebra (hereafter, OSA) by allowing a partial ordering relation on the set of sorts. This supports abstract data types with multiple inheritance (in roughly the sense of object-oriented programming), several forms of pol ..."
Abstract
-
Cited by 203 (34 self)
- Add to MetaCart
This paper generalizes many-sorted algebra (hereafter, MSA) to order-sorted algebra (hereafter, OSA) by allowing a partial ordering relation on the set of sorts. This supports abstract data types with multiple inheritance (in roughly the sense of object-oriented programming), several forms of polymorphism and overloading, partial operations (as total on equationally defined subsorts), exception handling, and an operational semantics based on term rewriting. We give the basic algebraic constructions for OSA, including quotient, image, product and term algebra, and we prove their basic properties, including Quotient, Homomorphism, and Initiality Theorems. The paper's major mathematical results include a notion of OSA deduction, a Completeness Theorem for it, and an OSA Birkhoff Variety Theorem. We also develop conditional OSA, including Initiality, Completeness, and McKinsey-Malcev Quasivariety Theorems, and we reduce OSA to (conditional) MSA, which allows lifting many known MSA results to OSA. Retracts, which intuitively are left inverses to subsort inclusions, provide relatively inexpensive run-time error handling. We show that it is safe to add retracts to any OSA signature, in the sense that it gives rise to a conservative extension. A final section compares and contrasts many different approaches to OSA. This paper also includes several examples demonstrating the flexibility and applicability of OSA, including some standard benchmarks like STACK and LIST, as well as a much more substantial example, the number hierarchy from the naturals up to the quaternions.
Typeful programming
, 1989
"... There exists an identifiable programming style based on the widespread use of type information handled through mechanical typechecking techniques. This typeful programming style is in a sense independent of the language it is embedded in; it adapts equally well to functional, imperative, object-orie ..."
Abstract
-
Cited by 133 (2 self)
- Add to MetaCart
There exists an identifiable programming style based on the widespread use of type information handled through mechanical typechecking techniques. This typeful programming style is in a sense independent of the language it is embedded in; it adapts equally well to functional, imperative, object-oriented, and algebraic programming, and it is not incompatible with relational and concurrent programming. The main purpose of this paper is to show how typeful programming is best supported by sophisticated type systems, and how these systems can help in clarifying programming issues and in adding power and regularity to languages. We start with an introduction to the notions of types, subtypes and polymorphism. Then we introduce a general framework, derived in part from constructive logic, into which most of the known type systems can be accommodated and extended. The main part of the paper shows how this framework can be adapted systematically to cope with actual programming constructs. For concreteness we describe a particular programming language with advanced features; the emphasis here is on the combination of subtyping and polymorphism. We then discuss how typing concepts apply to large programs, made of collections of modules, and very large programs, made of collections of large programs. We also sketch how typing applies to system programming; an area which by nature escapes rigid typing. In summary, we compare the most common programming styles, suggesting that many of them are compatible with, and benefit from, a typeful discipline.
Graph Types
- IN PROC. 20TH ACM POPL
, 1993
"... Recursive data structures are abstractions of simple records and pointers. They impose a shape invariant, which is verified at compiletime and exploited to automatically generate code for building, copying, comparing, and traversing values without loss of efficiency. However, such values are alw ..."
Abstract
-
Cited by 119 (9 self)
- Add to MetaCart
Recursive data structures are abstractions of simple records and pointers. They impose a shape invariant, which is verified at compiletime and exploited to automatically generate code for building, copying, comparing, and traversing values without loss of efficiency. However, such values are always tree shaped, which is a major obstacle to practical use. We propose a notion of graph types , which allow common shapes, such as doubly-linked lists or threaded trees, to be expressed concisely and efficiently. We define regular languages of routing expressions to specify relative addresses of extra pointers in a canonical spanning tree. An efficient algorithm for computing such addresses is developed. We employ a second-order monadic logic to decide well-formedness of graph type specifications. This logic can also be used for automated reasoning about pointer structures.
Views: A way for pattern matching to cohabit with data abstraction
, 1986
"... Pattern matching and dta abstraction are important concepts in designing programs, but they do not it well together. Pattern matching depend on making public a free data type mpresentaiion, while data abstraction depends on hiding the repreentaiion. This paper proposes the vdws mechanism at a means ..."
Abstract
-
Cited by 119 (0 self)
- Add to MetaCart
Pattern matching and dta abstraction are important concepts in designing programs, but they do not it well together. Pattern matching depend on making public a free data type mpresentaiion, while data abstraction depends on hiding the repreentaiion. This paper proposes the vdws mechanism at a means of reconc'dlng this conflict. A view allows any type to be viewed at a free data type, thus combining the clarity of pattern matching with the eiclency of data abstraction.
Object Ownership and Containment
, 2001
"... Object-oriented programming relies on inter-object aliases to implement data structures and other abstractions. Objects have mutable state, but it is when mutable state interacts with aliasing that problems arise. Through aliasing an object's state can be changed without the object being aware of t ..."
Abstract
-
Cited by 112 (17 self)
- Add to MetaCart
Object-oriented programming relies on inter-object aliases to implement data structures and other abstractions. Objects have mutable state, but it is when mutable state interacts with aliasing that problems arise. Through aliasing an object's state can be changed without the object being aware of the changes, potentially violating the object's invariants. This problem is fundamentally unresolvable. Many idioms such as the Observer design pattern rely on it. Hence aliasing cannot be eliminated from object-oriented programming, it can only be managed. Various proposals have appeared in the literature addressing the issue of alias management. The most promising are based on alias encapsulation, which limits access to objects to within certain well-defined boundaries. Our approach called ownership types falls into this category. An object can specify the objects it owns, called its representation, and which objects can access its representation. A type system protects the representation by enforcing a well-defined containment invariant. Our approach is a formal one. Ownership types are cast as a type system using an minor extension to Abadi and Cardelli's object calculus with subtyping. With this formalisation we prove the soundness of our ownership types system and demonstrate that well-typed programs satisfy the containment invariant. In addition, we also provide a firm grounding to enable ownership types to be safely added to an objectoriented programming language with inheritance, subtyping, and nested classes, as well as offering a sound basis for future work. Our type system can model aggregate objects with multiple interface objects sharing representation and friendly functions which access multiple objects' private representations, among other examples, thus over...
Complete restrictions of the intersection type discipline
- Theoretical Computer Science
, 1992
"... In this paper the intersection type discipline as defined in [Barendregt et al. ’83] is studied. We will present two different and independent complete restrictions of the intersection type discipline. The first restricted system, the strict type assignment system, is presented in section two. Its m ..."
Abstract
-
Cited by 92 (34 self)
- Add to MetaCart
In this paper the intersection type discipline as defined in [Barendregt et al. ’83] is studied. We will present two different and independent complete restrictions of the intersection type discipline. The first restricted system, the strict type assignment system, is presented in section two. Its major feature is the absence of the derivation rule (≤) and it is based on a set of strict types. We will show that these together give rise to a strict filter lambda model that is essentially different from the one presented in [Barendregt et al. ’83]. We will show that the strict type assignment system is the nucleus of the full system, i.e. for every derivation in the intersection type discipline there is a derivation in which (≤) is used only at the very end. Finally we will prove that strict type assignment is complete for inference semantics. The second restricted system is presented in section three. Its major feature is the absence of the type ω. We will show that this system gives rise to a filter λI-model and that type assignment without ω is complete for the λI-calculus. Finally we will prove that a lambda term is typeable in this system if and only if it is strongly normalizable.
Declarative debugging for lazy functional languages
, 1998
"... Lazy functional languages are declarative and allow the programmer to write programs where operational issues such as the evaluation order are left implicit. It is desirable to maintain a declarative view also during debugging so as to avoid burdening the programmer with operational details, for e ..."
Abstract
-
Cited by 77 (8 self)
- Add to MetaCart
Lazy functional languages are declarative and allow the programmer to write programs where operational issues such as the evaluation order are left implicit. It is desirable to maintain a declarative view also during debugging so as to avoid burdening the programmer with operational details, for example concerning the actual evaluation order which tends to be difficult to follow. Conventional debugging techniques focus on the operational behaviour of a program and thus do not constitute a suitable foundation for a general-purpose debugger for lazy functional languages. Yet, the only readily available, general-purpose debugging tools for this class of languages are simple, operational tracers. This thesis presents a technique for debugging lazy functional programs declaratively and an efficient implementation of a declarative debugger for a large subset of Haskell. As far as we know, this is the first implementation of such a debugger which is sufficiently efficient to be useful in practice. Our approach is to construct a declarative trace which hides the operational details,
A direct algorithm for type inference in the rank-2 fragment of the second-order λ-calculus
, 1993
"... We study the problem of type inference for a family of polymorphic type disciplines containing the power of Core-ML. This family comprises all levels of the stratification of the second-order lambda-calculus by "rank" of types. We show that typability is an undecidable problem at every rank k >= 3 o ..."
Abstract
-
Cited by 70 (14 self)
- Add to MetaCart
We study the problem of type inference for a family of polymorphic type disciplines containing the power of Core-ML. This family comprises all levels of the stratification of the second-order lambda-calculus by "rank" of types. We show that typability is an undecidable problem at every rank k >= 3 of this stratification. While it was already known that typability is decidable at rank 2, no direct and easy-to-implement algorithm was available. To design such an algorithm, we develop a new notion of reduction and show howto use it to reduce the problem of typability at rank 2 to the problem of acyclic semi-unification. A by-product of our analysis is the publication of a simple solution procedure for acyclic semi-unification.
Strictness Analysis on Non-Flat Domains (by Abstract Interpretation over Finite Domains)
- Abstract Interpretation of Declarative Languages
"... Interpretation over Finite Domains) Philip Wadler Programming Research Group Oxford University Recent work shows that lazy functional languages can be compiled to run on conventional architectures with very good speed [Johnsson 84, PeytonJones 86]. Strictness analysis is one way to make such impl ..."
Abstract
-
Cited by 52 (1 self)
- Add to MetaCart
Interpretation over Finite Domains) Philip Wadler Programming Research Group Oxford University Recent work shows that lazy functional languages can be compiled to run on conventional architectures with very good speed [Johnsson 84, PeytonJones 86]. Strictness analysis is one way to make such implementations even faster. This is because when an argument to a function is known to be strict then one may evaluate the argument directly rather than build a data structure to be evaluated later. One of the most promising techniques of strictness analysis is by abstract interpretation [Mycroft 83], which recently has been extended to include higher-order functions [Burn et al 85, Hudak and Young 85, 86] and polymorphism [Abramsky 85]. One of the remaining problems of great interest is whether this method can be extended to non-flat domains. Accordingly, strictness analysis on non-flat domains has received a great deal of attention [Hughes 85, Karlsson 85, Kieburtz 85]. Unfortunately, the wor...
Explaining Type Inference
- Science of Computer Programming
, 1995
"... Type inference is the compile-time process of reconstructing missing type information in a program based on the usage of its variables. ML and Haskell are two languages where this aspect of compilation has enjoyed some popularity, allowing type information to be omitted while static type checking is ..."
Abstract
-
Cited by 52 (0 self)
- Add to MetaCart
Type inference is the compile-time process of reconstructing missing type information in a program based on the usage of its variables. ML and Haskell are two languages where this aspect of compilation has enjoyed some popularity, allowing type information to be omitted while static type checking is still performed. Type inference may be expected to have some application in the prototyping and scripting languages which are becoming increasingly popular. A difficulty with type inference is the confusing and sometimes counter-intuitive diagnostics produced by the type checker as a result of type errors. A modification of the Hindley-Milner type inference algorithm is presented, which allows the specific reasoning which led to a program variable having a particular type to be recorded for type explanation. This approach is close to the intuitive process used in practice for debugging type errors. 1 Introduction Type inference refers to the compile-time process of reconstructing missing t...

