Extensible programming
Extensible programming is a term used in computer science to describe a style of computer programming that focuses on mechanisms to extend the programming language, compiler and runtime environment. Extensible programming languages, supporting this style of programming, were an active area of work in the 1960s, but the movement was marginalized in the 1970s. Extensible programming has become a topic of renewed interest in the 21st century.
Historical movement
The first paper usually associated with the extensible programming language movement is M. Douglas McIlroy's 1960 paper on macros for higher-level programming languages. Another early description of the principle of extensibility occurs in Brooker and Morris's 1960 paper on the Compiler-Compiler. The peak of the movement was marked by two academic symposia, in 1969 and 1971. By 1975, a survey article on the movement by Thomas A. Standish was essentially a post mortem. The Forth programming language was an exception, but it went essentially unnoticed.Character of the historical movement
As typically envisioned, an extensible programming language consisted of a base language providing elementary computing facilities, and a meta-language capable of modifying the base language. A program then consisted of meta-language modifications and code in the modified base language.The most prominent language-extension technique used in the movement was macro definition. Grammar modification was also closely associated with the movement, resulting in the eventual development of adaptive grammar formalisms. The Lisp language community remained separate from the extensible language community, apparently because, as one researcher observed,
any programming language in which programs and data are essentially interchangeable can be regarded as an extendible language. ... this can be seen very easily from the fact that Lisp has been used as an extendible language for years.
At the 1969 conference, Simula was presented as an extensible programming language.
Standish described three classes of language extension, which he called paraphrase, orthophrase, and metaphrase.
- Paraphrase defines a facility by showing how to exchange it for something previously defined. As examples, he mentions macro definitions, ordinary procedure definitions, grammatical extensions, data definitions, operator definitions, and control structure extensions.
- Orthophrase adds features to a language that could not be achieved using the base language, such as adding an i/o system to a base language that previously had no i/o primitives. Extensions must be understood as orthophrase relative to some given base language, since a feature not defined in terms of the base language must be defined in terms of some other language. Orthophrase corresponds to the modern notion of plug-ins.
- Metaphrase modifies the interpretation rules used for pre-existing expressions. It corresponds to the modern notion of reflection.
Death of the historical movement
Despite the earlier presentation of Simula as extensible, by 1975, Standish's survey does not seem in practice to have included the newer abstraction-based technologies. A 1978 history of programming abstraction from the invention of the computer to the present day made no mention of macros, and gave no hint that the extensible languages movement had ever occurred. Macros were tentatively admitted into the abstraction movement by the late 1980s, by being granted the pseudonym syntactic abstractions.
Modern movement
In the modern sense, a system that supports extensible programming will provide all of the features described below.Extensible syntax
This simply means that the source language to be compiled must not be closed, fixed, or static. It must be possible to add new keywords, concepts, and structures to the source language. Languages which allow the addition of constructs with user defined syntax include Camlp4, OpenC++, Seed7, Red, Rebol, and Felix. While it is acceptable for some fundamental and intrinsic language features to be immutable, the system must not rely solely on those language features. It must be possible to add new ones.Extensible compiler
In extensible programming, a compiler is not a monolithic program that converts source code input into binary executable output. The compiler itself must be extensible to the point that it is really a collection of plugins that assist with the translation of source language input into anything. For example, an extensible compiler will support the generation of object code, code documentation, re-formatted source code, or any other desired output. The architecture of the compiler must permit its users to "get inside" the compilation process and provide alternative processing tasks at every reasonable step in the compilation process.For just the task of translating source code into something that can be executed on a computer, an extensible compiler should:
- use a plug-in or component architecture for nearly every aspect of its function
- determine which language or language variant is being compiled and locate the appropriate plug-in to recognize and validate that language
- use formal language specifications to syntactically and structurally validate arbitrary source languages
- assist with the semantic validation of arbitrary source languages by invoking an appropriate validation plug-in
- allow users to select from different kinds of code generators so that the resulting executable can be targeted for different processors, operating systems, virtual machines, or other execution environment.
- provide facilities for error generation and extensions to it
- allow new kinds of nodes in the abstract syntax tree,
- allow new values in nodes of the AST,
- allow new kinds of edges between nodes,
- support the transformation of the input AST, or portions thereof, by some external "pass"
- support the translation of the input AST, or portions thereof, into another form by some external "pass"
- assist with the flow of information between internal and external passes as they both transform and translate the AST into new ASTs or other representations
Extensible runtime
Content separated from form
Extensible programming systems should regard programs as data to be processed. Those programs should be completely devoid of any kind of formatting information. The visual display and editing of programs to users should be a translation function, supported by the extensible compiler, that translates the program data into forms more suitable for viewing or editing. Naturally, this should be a two-way translation. This is important because it must be possible to easily process extensible programs in a variety of ways. It is unacceptable for the only uses of source language input to be editing, viewing and translation to machine code. The arbitrary processing of programs is facilitated by de-coupling the source input from specifications of how it should be processed.Examples
- - A paper from Daniel Zingaro
Tools
- —
- — eXtensible Programming System
- — JetBrains Metaprogramming system
Programming languages with extensible syntax
- - a programming language with syntax and semantics that are mutable at runtime
- - another programming language with extensible syntax, implemented using an Earley parser