The syntactic theories of control and state are conservative extensions of the v -calculus for equational reasoning about imperative programming facilities in higher-order languages. Unlike the simple v -calculus, the extended theories are mixtures of equivalence relations and compatible congruence relations on the term language, which significantly complicates the reasoning process. In this paper we develop fully compatible equational theories of the same imperative higher-order programming languages. The new theories subsume the original calculi of control and state and satisfy the usual Church-Rosser and Standardization Theorems. With the new calculi, equational reasoning about imperative programs becomes as simple as reasoning about functional programs. 1 The syntactic theories of control and state Most -calculus-based programming languages provide imperative programming facilities such as assignment statements, exceptions, and continuations. Typical examples are ML [16], Schem...

The literature on programming languages contains an abundance of informal claims on the relative expressive power of programming languages, but there is no framework for formalizing such statements nor for deriving interesting consequences. As a first step in this direction, we develop a formal notion of expressiveness and investigate its properties. To validate the theory, we analyze some widely held beliefs about the expressive power of several extensions of functional languages. Based on these results, we believe that our system correctly captures many of the informal ideas on expressiveness, and that it constitutes a foundation for further research in this direction. 1 Comparing Programming Languages The literature on programming languages contains an abundance of informal claims on the expressive power of programming languages. Arguments in these contexts typically assert the expressibility or non-expressibility of programming constructs relative to a language. Unfortunately, pro...

This is a description of the programming language Forsythe, which is a descendant of Algol 60 intended to be as uniform and general as possible, while retaining the basic character of its progenitor. This document supercedes Report CMU--CS--88--159, "Preliminary Design of the Programming Language Forsythe" [1]. c fl1996 John C. Reynolds Research suuported by National Science Foundation Grant CCR-9409997. Keywords: Forsythe, Algol-like languages, Algol 60, intersection types 1. Introduction In retrospect, it is clear that Algol 60 [2, 3] was an heroic and surprisingly successful attempt to design a programming language from first principles. Its creation gave a formidable impetus to the development and use of theory in language design and implementation, which has borne rich fruit in the intervening thirty-six years. Most of this work has led to languages that are quite different than Algol 60, but there has been a continuing thread of concern with languages that retain the essentia...

We give a brief account of the discoveries of continuations and related concepts by, A. Van Wijngaarden , A. W. Mazurkiewicz , F. L. Morris , C. P. Wadsworth , J. H. Morris , M. J. Fischer , and S. K. Abdali.

The IEEE/ANSI standard for Scheme requires implementations to be properly tail recursive. This ensures that portable code can rely upon the space efficiency of continuation-passing style and other idioms. On its face, proper tail recursion concerns the efficiency of procedure calls that occur within a tail context. When examined closely, proper tail recursion also depends upon the fact that garbage collection can be asymptotically more space-efficient than Algol-like stack allocation. Proper tail recursion is not the same as ad hoc tail call optimization in stack-based languages. Proper tail recursion often precludes stack allocation of variables, but yields a well-defined asymptotic space complexity that can be relied upon by portable programs. This paper offers a formal and implementation-independent definition of proper tail recursion for Scheme. It also shows how an entire family of reference implementations can be used to characterize related safe-for-space properties, and proves ...

Traditional first-class continuation mechanisms allow a captured continuation to be invoked multiple times. Many continuations, however, are invoked only once. This paper introduces one-shot continuations, shows how they interact with traditional multi-shot continuations, and describes a stack-based implementation of control that handles both one-shot and multi-shot continuations. The implementation eliminates the copying overhead for one-shot continuations that is inherent in multi-shot continuations. 1 Introduction Scheme [5] and some implementations of ML [17] provide continuations as first-class data objects. Continuations can be used to implement, at the source level, a number of interesting control features, such as loops, nonlocal exits, nonblind backtracking [22], nondeterministic computations [10, 14], and coroutines [7]. Source-level implementations of thread systems [9, 15, 21], especially in the area of graphical user interfaces (GUIs) [12, 13, 20, 23], are an important ...

We describe a small set of additions to Scheme to support objectoriented programming, including a form of multiple inheritance. The extensions proposed are in keeping with the spirit of the Scheme language and consequently differ from Lisp-based object systems such as Flavors and the Common Lisp Object System. Our extensions mesh neatly with the underlying Scheme system. We motivate our design with examples, and then describe implementation techniques that yield efficiency comparable to dynamic object-oriented language implementations considered to be high performance. The complete design has an almost-portable implementation, and the core of this design comprises the object system used in T, a dialect of Scheme. The applicative bias of our approach is unusual in object-oriented programming systems. This report describes research done at the Artificial Intelligence Laboratory of the Massachusetts Institute of Technology. Support for the laboratory's artificial intelligence research is ...

Traditional denotational semantics assigns radically different meanings to one and the same phrase depending on the rest of the programming language. If the language is purely functional, the denotation of a numeral is a function from environments to integers. But, in a functional language with imperative control operators, a numeral denotes a function from environments and continuations to integers. This paper introduces a new format for denotational language specifications, extended direct semantics, that accommodates orthogonal extensions of a language without changing the denotations of existing phrases. An extended direct semantics always maps a numeral to the same denotation: the injection of the corresponding number into the domain of values. In general, the denotation of a phrase in a functional language is always a projection of the denotation of the same phrase in the semantics of an extended language---no matter what the extension is. Based on extended direct semantics, i...

A fully abstract model of a programming language assigns the same meaning to two terms if and only if they have the same operational behavior. Such models are well-known for functional languages but little is known about extended functional languages with sophisticated control structures. We show that a direct model with error values and the conventional continuation model are adequate for functional languages augmented with first- and higher-order control facilities, respectively. Furthermore, both models become fully abstract on adding a control delimiter and a parallel conditional to the programming languages.

: We exhibit a set of functions coded in Haskell that can be used as building blocks to construct a variety of interpreters for Lisp-like languages. The building blocks are joined merely through functional composition. Each building block contributes code to support a specific feature, such as numbers, continuations, functions calls, or nondeterminism. The result of composing some number of building blocks is a parser, an interpreter, and a printer that support exactly the expression forms and data types needed for the combined set of features, and no more. The data structures are organized as pseudomonads, a generalization of monads that allows composition. Functional composition of the building blocks implies type composition of the relevant pseudomonads. Our intent was that the Haskell type resolution system ought to be able to deduce the approprate data types automatically. Unfortunately there is a deficiency in current Haskell implementations related to recursive data types: circ...