Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
LISP
Foderaro J. Communications of the ACM34 (9):271991.Type:Article
Date Reviewed: Dec 1 1992
Comparative Review

Foderaro

Foderaro’s introduction to this set of papers presents LISP as a chameleon: because a program in LISP is a list, LISP is a programmable language.

Gabriel, White, and Bobrow

Gabriel, White, and Bobrow present CLOS (the Common LISP object system), a system that brings object-oriented programming into LISP. The essential fact is polymorphism of functions. In strictly functional languages, an argument-type conditionality is expressed by code explicitly programmed by the user. In CLOS, generic functions support automatic selection from among separately defined type-specific implementational parts. The authors present data-driven, pattern-directed, and object-based traditions; the last is divided into class-centric and operation-centric. Examples illustrate these traditions. The problem of multi-argument polymorphism is discussed. CLOS supports the notion of classes separate from but integrated with Common LISP types. This flexibility allows CLOS to cover all system-defined data types and to retain their low-level implementations. CLOS also allows multiple inheritance between classes. A method can be composed from subpieces that are designated as playing different roles in the operation through declarative method combination. Reflection (the ability of a program to manipulate as data something representing the state of the program during its own execution) can be explored in four dimensions: structure, program, process, and development. Each dimension contains three points: implicit (present in the source code, but not represented as data), introspective (a first-class object that can be analyzed by the program), and effectual (its representation can be altered, modifying the behavior of the program). CLOS reaches all these points. Thus, CLOS has provided many lessons for language designers and software developers.

Sinclair and Moon

The philosophy of LISP is given by Sinclair and Moon. In LISP, the value of a variable is an object: the type is attached to the object, not to the variable. Thus, types are considered at run time, so functions are generic. LISP expresses all computation in terms of the application of functions to objects. A function is also an object. Functions may be written and tested separately, so LISP encourages modularity, and LISP programs may be easily modified. LISP provides means for high-level abstractions. It evolves to meet new demands. Nevertheless, it has some weaknesses. It obscures performance problems at the application level. It cannot be easily mixed with other languages. It does not enforce good programming practices.

Gajek

The Metal system is a Siemens-Nixdorf program for machine translation between pairs of natural languages. The main functions of this system are briefly stated. Gajek gives reasons for the use of LISP to write Metal: programs are data; a large address space is available; LISP has automatic dynamic storage management; and good user interfaces are provided.

Layer and Richardson

Layer and Richardson consider the features of modern LISP systems, the way in which they are implemented, and possible future developments of LISP. Due to the interactivity of LISP, program development is not slowed by the edit-compile-link-run cycle. It has powerful debugging facilities, allowing programmers to trace functions for restart from errors. But it is also possible to use an editor such as EMACS, which has a thorough knowledge of LISP syntax. Dynamic typing means that types of operands must be examined before each operation, slowing program execution. Tagged instructions or fast user-accessible traps would greatly improve the efficiency of LISP systems. Garbage collection is another critical issue for efficiency. Although good algorithms have been developed on stock hardware, fast traps should allow incremental garbage collection, greatly enhancing the runtime efficiency. The authors discuss using foreign code in LISP (such as functions written in C). LISP systems provide an interface that allows loading foreign functions and linking them to LISP code. But much work remains to be done to make that as natural as using native LISP code. Ways in which the size of a LISP application may be reduced are presented (selective loading and tree shaking).

McKay

McKay presents CLIM, the Common LISP Interface Manager. Using CLIM, programmers describe the user interface of an application in a high-level language independent of any particular window substrate. The programmers indicate their intent, and CLIM hides the details of how the tasks are performed. CLIM provides a number of basic facilities, including geometric modeling, affine transformations, text with multiple fonts, and graphics. It has a presentation facility that remembers not only the output to a stream, but also the underlying application object it represents and the presentation type associated with the output. It also has facilities for input, with a translator that coerces objects of one presentation type into objects of another type. Thus, since the objects and commands used in the interface are built on objects and operations in the application, the user interface becomes a by-product of the application rather than an artifact of graphic design.

Muller

A wide variety of applications are now being developed with LispView in both commercial and research areas. Although LISP was the host for many graphical user interfaces, activity in this domain has shifted to languages such as C and C++ for reasons of efficiency (either at run time or through the use of existing packages in C). The integration of standard C toolkits into LISP is discussed. The difficulty is in building the interface that translates definitions from a C include or header file into the appropriate LISP syntax. Translation is easily done by hand for small libraries. A short LISP program has been written to translate, but it requires some care due to the garbage collector of LISP and the impact of the preemptive LISP scheduler on non-reentrant C code. This difficulty has been resolved using CLOS classes.

Barber and Imlah

Although LISP is extensively used in academia and by some research and development groups in industry, it is hardly ever used in applications in the real world. LISP is perceived as making this offer: “You can develop really tremendous programs very rapidly, but you cannot deliver them cost-effectively.” One difficulty is the size of LISP, which makes it incompatible with current PC architectures. This problem is exemplified by a case study from 1989, presenting a choice of the delivery platform (hardware and software) and performance (their discussion emphasizes garbage collection). Since then, hardware has been improved, but the interfaces remain problematic; nonetheless, both the development and the delivery of LISP solutions are achievable on industry-standard PC systems.

Allard and Hawkinson

G2 is a real-time expert system for applications in manufacturing, process control, financial trading, and telecommunications. It is written in Common LISP and runs in five different implementations on 14 different hardware platforms. LISP is not an obvious choice for a real-time application; it is generally accepted as a powerful language for artificial intelligence or symbolic processing. Common LISP programs are criticized as slow, unpredictable in response due to garbage collection, and overly large. To overcome the unpredictability of the garbage collector, memory is managed explicitly. Pointers to allocated objects are retained, data structures are recycled, and dynamic objects are used only when no other possibility is found. Some facilities have been re-implemented by writing the underlying primitives in C. Macros have been used to select specific parts of code according to their arguments, allowing compile-time determination of the appropriate dispatching code. Type declarations have been used to avoid dynamic typing. Program size reduction has been achieved through tree shaking.

Stewart

Stewart describes Biosphere 2, an experiment in closed-system ecology, as an application of G2. G2’s ability to reason about classes of objects, focus on rule sets, and perform both backward and forward chaining contributes to its usefulness. The graphic interface provides a flexible, user-friendly system.

Conclusion

Stating the impact of these papers is not easy. For LISPers, it is certainly pleasant to see how wonderful LISP is, the great variety of programming styles it allows, the simplicity of its use, and the efficiency it can provide even for real-time applications. For non-LISPers, things are a little more complicated. LISP may be used for real-time applications through sophisticated programming techniques to avoid its main advantages: dynamic typing, dynamic memory storage, and garbage collection. A simplistic view of programming languages considers four programming paradigms, each characterized by an archetypal language: imperative with FORTRAN, functional with LISP, logical with Prolog, and object-oriented with Smalltalk. But LISP may be used for each of these paradigms. Is that a true advantage? Is LISP equally efficient in all of them? Why should I exchange my favorite language for LISP? Many questions are left unanswered by these papers.

Reviewer:  J. Arsac Review #: CR116875
Comparative Review
This review compares the following items:
  • LISP:
  • CLOS:
  • The Metal system:
  • Lisp systems in the 1990s:
  • CLIM:
  • Delivering the goods with Lisp:
  • Real-time programming in Common Lisp:
  • Biosphere 2 nerve system:
  • LispView:
  • The philosophy of Lisp:
  • Bookmark and Share
     
    Common Lisp (D.3.2 ... )
     
     
    Lisp (D.3.2 ... )
     
     
    Interactive Environments (D.2.6 ... )
     
     
    Real-Time Systems And Embedded Systems (D.4.7 ... )
     
     
    User Interface Management Systems (UIMS) (H.5.2 ... )
     
     
    User Interfaces (D.2.2 ... )
     
      more  
    Would you recommend this review?
    yes
    no
    Other reviews under "Lisp": Date
    The architecture of Lisp machines
    Pleszkun A., Thazhuthaveetil M. Computer 20(3): 35-44, 1987. Type: Article
    Aug 1 1988
    A programmer’s guide to Common LISP
    Tatar D., Digital Press, Newton, MA, 1986. Type: Book (9780932376879)
    Dec 1 1988
    Introduction to Common LISP
    Yuasa T. (ed), Hagiya M. (ed), Academic Press Prof., Inc., San Diego, CA, 1986. Type: Book (9789780127748603)
    Dec 1 1988
    more...

    E-Mail This Printer-Friendly
    Send Your Comments
    Contact Us
    Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
    Terms of Use
    | Privacy Policy