Previous | Table of Contents | Next |
by Jim Veitch
Lisp is one of the oldest programming languages in existence today. In 1956, John McCarthy participated in the Dartmouth Summer Research Project in Artificial Intelligence and began designing the language; an implementation began in 1958 (McCarthy, 1991). Among non-assembler languages, only Fortran is older. Lisp was designed as a test bed for symbolic programming, reflecting the very early artificial intelligence ideas, and Lisp has survived, evolved, and thrived, paving the way for idea after idea in other languages, along the way creating dialect after dialect.
As John Foderaro put it, Lisp is a programmable programming language (Graham, 1994). The structure of Lisp lends itself to extending the language, implementing entirely new dialects, and generally experimenting with new language ideas. The reason for this is the uniform syntax, where user-defined functionality looks just like system-defined functionality and new language constructs are easily transformed into regular Lisp syntax.
Using only a small number of Lisp primitives (around a dozen), it is easy to get a Lisp-like language up and running in almost any environment or hardware platform. The uniform syntax makes it easy to implement a new dialect within an existing Lisp. The Lisp syntax allows rapid experimentation on designing and implementing new semantics. Once the semantics are suitable for the domain, a full-scale implementation, including a parser, compiler and so on, can be done.
The ability to extend and adapt the language allowed early experimentation in object-oriented ideas. For example, in the early 1970s, Carl Hewitt and others at MIT (Smith & Hewitt, 1975) built a message-passing system where every component of the program is an actor, or an agent that responds to messages. Gerry Sussman (and his students), also at MIT, turned this around in Scheme, which captured nearly all the aspects of the actor model and which remains a dialect of Lisp widely used for teaching.
By the early 1980s, frame-based languages were being used widely in Lisp. These frame-based languages, such as KRL (Knowledge Representation Language) or KEE (which also incorporated an inference engine) were used to represent objects.
In the early 1980s, the Lisp community got together to form a standard for Lisp. This standard has since gone through the American National Standards Institute (ANSI) process for language standardization and is known as Common Lisp. This includes an object system known as the Common Lisp Object System, or CLOS. Common Lisp is not a pure object-oriented programming language (like Smalltalk or Java). Like C++, but unlike Smalltalk or Java, it extends a procedural paradigm. I hasten to point out that Common Lisp is by no means the only currently widespread Lisp dialect in use today: Other dialects include Scheme, Xlisp, Elisp, Clisp, and EuLisp. In contrast to most of these other dialects, Common Lisp has a large set of libraries and pays a lot of attention to allowing efficient compilation.
CLOS came from widespread experimentation with different object protocols layered into Lisp and was adopted in 1988. Object systems that already existed in various dialects of Lisp extant in the mid-1980s were combined to form CLOS. Symbolics (1985) was using New Flavors (a message-sending object model, like Java today), Xerox was using CommonLoops, Lisp Machines Incorporated was using Object Lisp (Bobrow, 1986), and Hewlett-Packard proposed using Common Objects (Kempf, 1987). The groups vied with each other in the context of the standardization effort going on for Common Lisp at the time and finally settled on a standard based on CommonLoops and New Flavors.
Making Lisp object oriented is easy: You can do it in two pages of code (Graham, 1994). Making object-oriented Lisp as extensible and flexible as the rest of Lisp is more difficult. Although CLOS is a complete object system, CLOS is implemented in an object-oriented fashion. The object-oriented implementation of CLOS is known as the CLOS Metaobject Protocol (or MOP) and permits the object system to be customizable and extensible.
Previous | Table of Contents | Next |