An extensible interpreter

Abstract

The purpose of this brief paper is to propose an alternative approach for the implementation of an extensible language. The idea outlined here will be referred to as an extensible interpreter . In this particular case, the term itself constitutes an exceptionally concise description of the basic concept, even though there exists another, equally valid way of viewing the same notion, namely as a strategy for integrating an optimizing compiler into an essentially interpretive system. Regardless of which point of view is preferred, however, both are indicative of the fundamental assumption which underlies the present proposal: that the “semantics” of a programming language must ultimately be defined by means of an interpreter. This is to say that the definition of a given language must finally be formulated in terms of an “abstract machine” which is capable of carrying out, in an appropriate environment, the “unit operations” comprising the semantic primitives that language. Thus, an implementation which reflects the definition of the language in question must necessarily include a realization of this abstract machine, whether it is present implicitly, in the processing performed by the compiler, or whether it appears explicitly. In the latter case, the abstact machine may be represented in the form of a conventional software interpreter, or more directly, by means of a suitable set of micro-instructions, the only distinction being the number of different “layers” of interpretation which are actually interposed between this machine and the supporting hardware. In the context of an extensible language, one can immediately identify the natural instruction set for such an abstract machine: it corresponds to the repertoire of primitive operations provided by the base language. Since it is axiomatic to extensibility that new linguistic elements are constructed by systematic composition of previously defined and/or primitive constructs, the “meaning” of every operation in any subsequent extended language is ultimately defined by its derivation in terms of the operations belonging to the base language. Given that it is, conceptually, the definition of the language which is expected to evolve as a consequence of extension, there are strong motivations for explicitly representing the definition itself in any implementation of that language. The logical point of departure, therefore, is to implement an interpreter for the base language, thereby providing a direct realization of the underlying abstract machine.

Abstraction and Verification in Alphard: Introduction to Language and Methodology

“…All of this is, of course , very similar to the notions found in extensible languages (Schuman7l]. However , the emphasis is considerably differen t: we are not interested in general syntactic extension.…”

The impact of abstraction concerns on modern programming languages

“…The objectives of the extensible language work included allowing individual programmers to extend the syntax of the programming language, to define new data structures, to add new operators (including infix operators as well as ordinary functions) for both old and new data structures, and to add new control structures to the base language. This work on extensibility [60] died out, in part because it underestimated the difficulty of defining interesting extensions. The problems included difficulty with keeping independent extensions compatible when all of them modify the syntax of the base language, with organizing definitions so that related information was grouped in common locations, and with finding techniques for describing an extension accurately (other than by exhibiting the code for the extension).…”