Extensible Denotational Language Speciications Extensible Denotational Language Specifications ? 2 Extensible Operational Semantics Are Expressions, with X Possibly Free in E, 4

Traditional denotational semantics assigns radically diier-ent meanings to one and the same phrase depending on the rest of the programming language. If the language is purely functional, the deno-tation 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 speciications, 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, it is also possible to construct interpreters for complete languages by composing interpreters for language fragments. A programming language like Scheme 25], Common LISP 32], or ML 19] consists of a rich functional core, augmented by destructive operations on data objects, control constructs, and possibly other imperative operators. Traditional denotational language speciications 1, 15, 27, 35] cope with these constructs by interpreting program phrases as functions that map environments stores continuations to values stores. Programmers, however, rely on simpler semantic descriptions when they reason about program phrases. Most program phrases do not exploit the full generality of the language, permitting their semantics to ? The paper is an extended and revised version of Rice be analyzed using a simpler semantic model. For example, if a program phrase is purely functional and its free variables are always bound to eeect-free procedures , it can be interpreted as a function mapping environments to values. Similarly, if an imperative program phrase does not use general control operators like callcc, goto, or catch and its free variables are always bound to values and procedures conforming to the same constraint, it can be interpreted as a function mapping environments stores into values stores. Unfortunately, denotational deenitions of practical programming languages are written in a form that makes it diicult to extract a simpliied deenition for a disciplined subset|much less prove that the deenitions are equivalent over the restricted language. Another way to describe the same problem is to observe what happens to the meanings of simple program …