Strongly Typed Research Articles

Explaining type errors in polymorphic languages

Strongly-typed languages present programmers with compile-time feedback about the type correctness of programs. Errors during polymorphic type checking take the form of a unification failure for two types. Finding the source of the type error in the code is often difficult because the error may occur far from the spot where the inconsistency is detected. As functional languages use more and more complex type systems, the difficulty of interpreting and locating these errors will increase. To locate the source of type errors the programmer must unravel the long chain of deductions and type instantiations made during type reconstruction. This paper describes an approach that maintains the deductive steps of type inference and the reasons for type instantiations. The approach could be used in an interactive system to guide the programmer to the source of a type error or to explain why the compiler assigned a particular type to an expression.

Constraint-driven programming in strongly-typed object-oriented languages

Strongly-typed object-oriented languages are well suited for software engineering. In this paper the difficulty of implementing specification of overall properties of an object in such languages is addressed and solved by introducing constraint-driven reevaluation into strongly-typed object-oriented programming. The programming language Eiffel forms the basis of this work, and its syntax and semantics are enhanced with a constraint-driven system from Thinglab II. The benefits of this enhancement to software specification and development are demonstrated. It is shown that Eiffel's strong typing and its inheritance discipline make it possible to improve on Thinglab II in specification of inputs and outputs of constraint fixes, and allows refinement of constraints through inheritance.

Ensuring strong typing in an object-oriented language (abstract)

No abstract available.

A static type system for message passing

Much research has been performed with the aim of isolating the basic notions of object-oriented languages and of describing them by basic operators which can be embedded in strongly-typed languages. In this context we define an atomic linguistic construct to capture the notion of message passing, and we define a static and strong type system, based on subtyping, for this construct. Message passing is modelled as the application of an overloaded function, whose behavior is determined only at compile-time on the basis of the class which created a distinguished argument, the object “receiving” the message. By embedding this mechanism in a strongly-typed language with subtyping and abstract data types we can obtain the full functionality of object-oriented languages. We show that this approach is strictly more expressive then the usual interpretation of message passing as selection plus application of a functional record field.

MELDing transactions and objects

MELD is an experimental object system under development at Columbia University. The object-oriented programming language supports classes, strong typing of instance variables, active values, multiple inheritance, and separate compilation of modular units called features that bundle together related classes and objects. These facilities were developed for an early version of MELD [3, 4], without persistence, concurrency or distribution.

Dynamic binding in strongly typed programming languages

Dynamic binding, delaying the binding of a name in a program to an object implementing that name, is generally considered to be a property of weakly typed languages. Many strongly typed languages, however, provide methods to dynamically link subprogram bodies to names, although most require static definition of the alternative bodies to maintain compile-time type checking. In strongly typed languages without this feature, access to operating system facilities is a common substitute, but such a mechanism typically is incompatible with compile-time type checking across the interface to the subprograms. A third approach is needed for dynamic binding of separately compiled subprograms under program control. This approach, incorporated into a language, provides the flexibility of the latter method while maintaining strong typing and is useful in many applications, including data base programming and monolingual programming environments.

Strong typing of object-oriented languages revisited

This paper is concerned with the relation between subtyping and subclassing and their influence on programming language design. Traditionally subclassing as introduced by Simula has also been used for defining a hierarchical type system. The type system of a language can be characterized as strong or weak and the type checking mechanism as static or dynamic . Parameterized classes in combination with a hierarchical type-system is an example of a language construct that is known to create complicated type checking situations. In this paper these situations are analyzed and several different solutions are found. It is argued that an approach with a combination of static and dynamic type checking gives a reasonable balance also here. It is also concluded that this approach makes it possible to base the type system on the class/subclass mechanism.

A parallel object-oriented language with inheritance and subtyping

This paper shows that inheritance and subtyping can be introduced advantageously into a parallel object-oriented language, POOL-I. These concepts are clearly distinguished, because they deal with different aspects of programming. In this way several problems traditionally adhering to inheritance can be solved. The language POOL-I is a parallel object-oriented language with a strong typing scheme which includes genericity and dynamic binding. A novel and particularly powerful mechanism offers the possibility to manipulate and analyse types dynamically.

Strong typing of object-oriented languages revisited

This paper is concerned with the relation between <em>subtyping</em> and <em>subclassing</em> and their influence on programming language design. Traditionally subclassing as introduced by Simula has also been used for defining a hierarchical type system. The type system of a language can be characterized as <em>strong</em> or <em> weak</em> and the type checking mechanism as <em>static</em> or <em>dynamic</em>. Parameterized classes in combination with a hierarchical type-system is an example of a language construct that is known to create complicated type checking situations. In this paper these situations are analyzed and several different solutions are found. It is argued that an approach with a combination of static and dynamic type checking gives a reasonable balance also here. It is also concluded that this approach makes it possible to base the type system on the class/subclass mechanism.

The object-oriented functional data language

The object-oriented functional data language (O/sup 2/FDL) is an interactive strongly typed database programming language that integrates the object-oriented and functional programming paradigms. It was designed for advanced applications that require a powerful and uniform database programming language supporting the software engineering principles of these tow paradigms. To this end, the O/sup 2/FDL supports inheritance and encapsulation of object-oriented languages, and an equational notation and strong typing of functional programming. Strong typing is extended with type restrictions to constrain the instantiations of type variables in function interfaces, while inheritance is augmented with a monotonic subtype rule for function redefinition. The O/sup 2/FDL also supports novel features. For the core of the O/sup 2/FDL, a denotational semantics based on an extended lambda -calculus is provided. For selected system-defined functions, operational semantics are provided and it is demonstrated that a subset of the O/sup 2/FDL is at least as expressive as the relational algebra.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

Conception, evolution, and application of functional programming languages

The foundations of functional programming languages are examined from both historical and technical perspectives. Their evolution is traced through several critical periods: early work on lambda calculus and combinatory calculus, Lisp, Iswim, FP, ML, and modern functional languages such as Miranda 1 and Haskell. The fundamental premises on which the functional programming methodology stands are critically analyzed with respect to philosophical, theoretical, and pragmatic concerns. Particular attention is paid to the main features that characterize modern functional languages: higher-order functions, lazy evaluation, equations and pattern matching, strong static typing and type inference, and data abstraction. In addition, current research areas—such as parallelism, nondeterminism, input/output, and state-oriented computations—are examined with the goal of predicting the future development and application of functional languages.

Using a frame-based language for information retrieval

With the advent of the information society, many researchers are turning to artificial intelligence techniques to provide effective retrieval over large bodies of textual information. In the CODER system, the mission of which is to provide an environment for experiments in applying AI to information retrieval, a factual representation language (FRL) serves as a tool for knowledge engineering and experimentation. the FRL is a hybrid AI language supporting strong typing for attribute values, a frame system, and Prolog-like relational structures. Inheritance is enforced throughout, and the semantics of type subsumption and object matching are formally defined. A collection of type and object managers called the knowledge administration complex implements this common language for storing knowledge and communicating it within the system. Storage of large numbers of complete knowledge objects (statements in the language) is supported by a system of external knowledge bases. Of the three types of knowledge structures in the language, the frame facility has proven most useful in the retrieval domain. This article discusses the frame construct itself, the implementation of the relevant portions of the knowledge administration complex and external knowledge bases, and the use of frames in retrieval research. It closes with a discussion of the utility of the FRL.

O2, an object-oriented data model

The Altair group is currently designing an object-oriented data base system called O 2 . This paper presents a formal description of the object-oriented data model of this system. It proposes a type system defined in the framework of a set-and-tuple data model. It models the well known inheritance mechanism and enforces strong typing.

Dimensions of object-based language design

The design space of object-based languages is characterized in terms of objects, classes, inheritance, data abstraction, strong typing, concurrency, and persistence. Language classes (paradigms) associated with interesting subsets of these features are identified and language design issues for selected paradigms are examined. Orthogonal dimensions that span the object-oriented design space are related to non-orthogonal features of real languages. The self-referential application of object-oriented methodology to the development of object-based language paradigms is demonstrated. Delegation is defined as a generalization of inheritance and design alternatives such as non-strict, multiple, and abstract inheritance are considered. Actors and prototypes are presented as examples of classless (delegation based) languages. Processes are classified by their degree of internal concurrency. The potential inconsistency of object-oriented sharing and distributed autonomy is discussed, suggesting that compromises between sharing and autonomy will be necessary in designing strongly typed object-oriented distributed database languages.

Controlling dynamic objects in large Ada systems

This paper describes a generalized technique for controlling the growth of dynamically allocated objects within an Ada system due to the careless, yet innocent misuse of access types, allocators and instantiations of the generic procedure UNCHECKED_DEALLOCATION . The technique outlined here involves reliance on Ada's strong typing model and in particular, the judicious use of limited private data types in conjunction with generic packages and data abstraction facilities.

Implementation of physical units

This paper describes an implementation of strong typing with physical units. The typing system of a commercial Pascal compiler was minimally extended to allow compile-time checking of expressions involving physical units to ensure that the familiar semantics of dimensional analysis are not violated. The key concepts and mechanisms are described, as are the differences between ordinary type checking and that for physical units.

The role of PASCAL in software engineering

The second of a series of papers on modern high-level programming languages for microprocessors introduces PASCAL, which was the first language to implement strong data typing and support for structured programming. The major language constructs — program structures, control structures, simple and structured data types etc. — are discussed with respect to their support for good software engineering practice. The development of a program to simulate the behaviour of a simple computer is outlined as a programming example.

Strong typing and physical units

This paper proposes a syntactic extension of high level languages like PASCAL or ADA to allow the usage of physical quantities, i.e. numbers with units, instead of just numbers. It offers enhanced type checking for expressions and assignments during compilation time. Additionally, it allows problem oriented simple scaling of variables and local scale selection. Furthermore, it reduces the number of coding errors due to wrongly chosen scales. After a discussion of mutual relations between strong typing in programming languages and physical units, examples are shown to demonstrate the usefulness of the proposed extension. Finally a graph representation of the new syntactic elements is given.

Yacc in sasl — an exercise in functional programming

AbstractAmong the advantages claimed for a purely functional programming style is ease of designing and implementing large programs. However, little experience of actually doing so has been gained so far. The experience of writing a particular medium sized program in a functional language is described here, with particular emphasis on the differences in programming style that were appropriate. This is compared with the experience of writing a very similar program in an imperative language. The main conclusions appear to be that the functional version was significantly easier to write, and was considerably smaller, though not by as large a factor as is sometimes claimed; that strong typing is, if anything, more desirable than in imperative systems; and that the question of debugging functional programs needs further research attention.

A cognitively-based methodology for designing languages/environments/methodologies

In designing a programming language, programming environment, or programming methodology there are a whole lot of both implicit and explicit “shoulds.” By a “should” we mean the claim that the appropriate use of language/environment/methodology X will lead to good habits and result in good products. For example, ADA's commitment to strong typing and mechanisms for constructing data types implies that these components are good and should result in more effective programming. The top-down design methodology implies that designers should start at the specifications and refine downward; this process will result in a good design. Etectera. The problem is that it is not clear that the current crop of languages/environments/methodologies (L/E/M's) do result in more productive programming and design, and that the “shoulds” implied by them are really all that good ([7]).