A high productivity environment reduces the work required to develop new packages and makes most efficient use of the scarce time of scientists. Generalizing the individual case to a community of researchers, sharing this kind of environment and each other's extensions maximizes the rate at which the community searches mechanism space for problem solutions. Moreover, well-abstracted code joins with self-documenting capabilities in the HTTP server to make it an effective pedagogical environment; everything is readily available for inspection, modification, and experimentation.
Common LISP embeds a native object-oriented programming language, the Common LISP Object System (CLOS). All significant datastructures in the HTTP server are implemented as CLOS objects (Bobrow et al., 1988; Keene, 1989). CLOS distinguishes classes and instance objects. The behavior of instance objects is defined by associated classes, which can inherit functionality and state variables from multiple superior classes. Instances can have local state, held by instance variables, and they can have methods, or operations, which they support. Generic operations constitute a protocol that instances of different classes all support with their own, possibly different methods. CLOS supports multimethods that can dispatch based on the types of multiple arguments. A pervasive object-oriented implementation helps enforce abstraction and modularity as it enhances flexibility and code sharing.
Modern Common LISP provides a high-level window system tool, the Common LISP Interface Manager (CLIM) (see the specification, (Rao, et al, 1991). Written in Common LISP, CLIM runs on a variety of workstations, implementing its machine-independent abstractions with native window systems and mimicking their look and feel. By introducing high-level abstractions for specifying window interfaces, CLIM makes it easier and quicker to define window interfaces. Instead of requiring many months, sophisticated user interfaces can be written in several days.
Beyond general window system abstractions, the automatic form processing in COMLINK forms relies heavily on an important CLIM abstraction: the presentation system controls how the user specifies or perceives arbitrary LISP objects. Each presentation type has a method to present (display) an object on the computer screen, and a method to accept (receive input) an object from the user, whether via the keyboard, the mouse, or other input device.
In general, presentation types specialize built-in or constructed LISP types. Presentation translators can be defined to convert from the LISP object associated with one presentation type to another. The combination of type subsumption and presentation translation allows CLIM to resolve equivalences, and thus, accept input more intelligently.
The present and accept methods are like little generators and parsers specialized to a presentation type. They can perform a simple operation, such as accepting an integer between 1 and 10, or they can execute a very complex computation. For example, in one research system (Mallery, 1991), nodes in semantic network representing natural language text can be presented through a sentence generator so that the user sees them as generated sentences or sentence fragments. Similarly, sentences or paragraphs can be accepted via a presentation type that calls a full natural language system to parse and represent the text. Thus, present and accept methods execute LISP code that can perform an arbitrary translation between what the user sees or what the user inputs and the internal datastructures manipulated by programs.
Once defined, these presentation types mediate all data entry and display, and thus, users perceive only the external, user-friendly representation, and never with the internal representation. Yet, such dynamic, bidirectional translation allows users to directly manipulate program data (viewing it in translated form) and actually simplifies the program model presented to the user.