Communications of the ACM [34]

Table of contents :
Special Section: Lisp
=====================

p.27 - Introduction (John Foderaro, guest editor)
p.28 - CLOS: Integrating Object-Oriented and Functional Programming (Richard P. Gabriel, Jon L. White, and Deniel G. Bobrow)
p.40 - Philosophy of Lisp (Kenneth H. Sinclair and David A. Moon)
+ p.46 - The Metal System (Oliver Gajek)
p.48 - Lisp Systems in the 1990s (D. Kevin Layer and Chris Richardson)
+ p.58 - CLIM: The Common Lisp Interface Manager (Scott McKay)
+ p.59 - LispView: Leverage Through Integration (Hans Muller)
+ p.61 - Delivering the Goods with Lisp (Richard Barber and George Imlah)
p.64 - Real-Time Programming in Common Lisp (James R. Allard and Lowell B. Hawkinson)
+ p.69 - Biosphere 2 Nerve System (Rocky L. Stewart)

Articles
========

p.72 - On Building Systems That Will Fail (Fernando J. Corbató)
p.82 - An Interview with Fernando Jose Corbató (Karen A. Frenkel)

Columns
=======

p.19 - International Perspectives: Computing and the Resuscitation of Romania (Seymour E. Goodman)
p.23 - Log on Education: How the Nintendo Generation Learns (Elliot Soloway)
p.122 - Inside RISKS: The Not-So-Accidental Holist (Peter G. Neumann)

Departments
===========

p.5 - Editorial Pointers
p.11 - News Track
p.13 - President's Letter
p.16 - Forum
p.96 - Calendar of Events
p.100 - Calls for Papers
p.104 - Index to Advertisers
p.116 - Career Opportunities

Cover art by Cary Henrie.

Citation preview

COMMUNICATIONS

ADAPTING TO THE ENVIRONMENT

VOLUME 34, NUMBER 9

Q'·T H E·A

SEPTEMBER 1991

I NEW FOR NETWORK ANALYSTS AND SYSTEMS ENGINEERS I

BUS 2

BUS 3

Realistic simulation of your network or embedded computer system--quick results, no programming

NETWORK 11.5 now predicts performance of computer-communication systems

N

Free trial and, if you act now, free training

ETWORK 11.5 uses simulation to predict your

network performance. You simply

Your network simulated

You can analyze embedded or distributed computer systems, or

describe your network and work­

other computer-communication net­

load.

works. Industry standard protocols

Animated simulation follows im­ mediately--no programming delays. Easy-to-understand results

You get an animated picture of your network. System bottlenecks and changing levels of utilization are apparent. Seeing your network animated in­ creases everyone's understanding of its operation and builds confidence in your results. Your reports show response

such as FDDI and IEEE Standard 802.X are built-in. Others can be modeled. You can easily study the effect of changing network parameters or even network protocols. You can simulate some portions Of the network at a detailed level and others at a coarser level. Free trial information

The free trial contains everything you need to try NETWORK 11.5®

times, messages delivered, messages

on your computer. For a limited

lost, device utilization, and queue­

time we also include free training

ing statistics.

--no cost, no obligation.

Computers with NETWORK Il.5

NETWORK 11.5 is available for most PC's, Workstations, and Mainframes.

Call Paul Gorman at (619) 457-9681, Fax (619) 457-1184. In Europe, call Nigel McNamara, in the UK, on 0276 671 671, Fax 0276 670 677. In Canada, call Peter Holt on (613) 782-2474, Fax (613) 782-2202.

1-

----- - - -- - -1

I Free trial offer I i quick OYes I want to see how NETWORK 11.5 I ly answers network performance

I _ I questions. I Limited offer--Act now for free training. I I mc J I o ga niza i n J �j I A rcss J __ zP j I [ I J I DSend details on your University Offer. J I I I I I j (619) 457-9681 (619) 457-1184 j I I I I I I 0276 671 671 I 0276 670 677 \ J I 1 j (6 782-22 (613) 782-2474 j l� � � _I Na

_ _ _ __________�

t

o r _ _ _ _ _ _ _________� d d_ _ _ _ ___ _____ _ _ ci _ _ Y 1

s a

_1 __ ___

1_c

Telephone

Fax

Computer

Op. Syst.

_ __� _

Return to: CACI Products Company 3344 North Torrey Pines Court La Jolla, California 92037 Call Paul Gorman at Fax

i

Macm

In Europe: CACI Products Division Coliseum Business Centre Watchmoor Park, Riverside Way Camberley, Surrey GUI5 3YL, UK Call Nigel McNamara on Fax In Canada: CACI Products Company 200-440 Laurier Avenue West Ottawa, Ontario KIR 7X6 Call Peter Holt on ax

_

______

NETWORK 11.5 is a registered trademark and service mark of CACI Products Company. ©1991 CACI Products Company.

CASE Was Never This Easy Before

MacAnalyst and MacDesigner D Dictionor :

Anal yzerDisplay BuildTri

er

A

B

INPUTS

ReceiverEnable j WhichDiopley · ··· ·�·P.. i l·�·Y ·.''. .. ······· • . ... . '.'.f.���-�.::. . . . ' . .. ....':.':1��-�-� := ±== : ±:: .!:::== ;:::= :' C:::= " M e uD "FALSE" "TRUE" n �o� Tree Diogrom: Poyroll §0� "TRUE" ' ! "FAL uD

"FALSE"

·

· -

mployeeRecord

Top Level Di e9rem 7 TCommend

"Bootup" Receive rEnebled =FALSE

9 TEvtHendler

[II

m T

D

ID /

l�

Cus

m.r

1

Idl e

/

1

I

Description: Poyroll.MD

STD: AnolyzerRT.STD: Stote

7.8 TTECommend

L1

ProcessPoyroll eodEmplWogeRec 4:leteErrors dWklyTimeRec 4:lotoErrors

I

QueueFull=TRUE ReceiverEnebled= FALSE

Commend=StopScen

Rece1verEne bl ed=FALSE

Commend=StertScen Rece1verEnabled-TRUE

DH

11!

l!lil

Structured Analysis Real-Time Analysis Data Modeling Object-Oriented Analysis Structured Design Data Dictionary Requirement Database Screen Prototyping

With the time you save by not having to learn a new way of doing things, you'll boost productivity as well as quality.

You'll also be in good company when you join the ranks of hundreds like Boe­ ing, Dupont, Motorola, and Visa Corpora­ tion who have made MacAnalyst and MacDesigner the standard in Macintosh CASE tools.

Perhaps best of all, its easy to justify With schedules tight you'll appreciate the hardware and software investment re­ a CASE tool with all the capabilities you quired to bring out the very best in your need, for even the most demanding project. development team. That works just as you'd expect. Like Excel Software your other Macintosh productivity tools. P.O. Box 1414 • Marshalltown, IA 50158 • Phone: 515-752-5359 • Fax: 515-752-2435 Circle # 45

on

Reader Service Card

SEPTEMBER 1991

COMMUNICATIONS OF THE ACM

--

SP ECIAL SECTION-LISP

-­

Introduction John Foderaro, guest editor

27

CLOS: Integrating Object-Oriented and Func.tional Programming Richard P. Gabriel, Jon L.White, and Daniel G.Bobrow

28

Philosophy of Lisp Kenneth H.Sinclair and David A.Moon

40

The Metal system, Oliver Gajek: 46 Lisp systems in the 1990s D.Kevin Layer and Chris Richardson

48

CLIM: The common Lisp Interface Manager, Scott Mckay: 58 Lispview: Leverage Through Integration, Hans Muller: 59 Delivering the Goods with Lisp, Richard Barber and George lmlah: &1 Real-Time Programming in common Lisp James R.Allard and Lowell B. Hawkinson

64

Biosphere 2 Nerve System, Rocky L.Stewart: 69 ------

ARTICLES -----­

on Building Systems That Will Fail Fernando J. Corbat6

72

An Interview with Fernando Jose corbato Karen A. Frenkel

82 ------

COLUMNS------

International Perspectives: computing and the Resuscitation of Romania Seymour E. Goodman

19

Log on Education: How the Nintendo c:eneration Learns Elliot Soloway

23

Inside RISKS: The Not-so-Accidental Holist P eter G.Neumann

122

DEPARTMENTS Editorial Pointers New$ Track

. .

..

President's Letter Forum

. .

..

.

..

. . . . . . .

. .

. .

... .

. . . .

.. ..

Calendar of Events . . Calls for Papers

. . . .

Index to Advertisers

.. . .. . . .

..

.

.

. . 11 .. H

.. 16

. . . . . . . . . 96

.. . .

career Opportunities

.. ....5

. . . . .

. . . .

..

. .

.

..

..

. 100

... . 104 . .

. . 116

Cover mustraition by Cary Henrie.

COMMUNICATIONS OF THE ACM/September 1991 /Vol.34, No.9

3

NEED TO KEEP UP TO DATE WITH COMPUTER SCIENCE? Computer Science is a rapidly-developing field of research. You need high-quality scientific information about the latest developments and research results in order to keep up to date.

Elsevier Science Publishers offers you an extensive high-level publication program, under the Elsevier and North-Holland imprints, with journals and books covering a wide range of subject areas, such as: Hardware, Computer Systems Organization, Software, Data, Theory of Computation, Mathematics of Computing, Information Systems, Computing Methodologies, Computer Applications, Computing Milieux. Elsevier Science Publishers' Computer Science Catalogue 1991 contains full

details of our latest books and our range of journals. Write for your personal copy of the catalogue by completing the coupon!

ELSEVIER SCIENCE PUBLISHERS IMPRINTS: Elsevier and North-Holland

COUPON

ACM/S

Send this coupon - or a photocopy - to: Elsevier Science Publishers Attn.: Petra van der Meer P.O. Box 103 1 OOO AC Amsterdam The Netherlands

D

Customers in the USNCanada: Elsevier Science Publishing Co. Inc. P.O. Box 882 Madison Square Station New York, NY 10159, USA

Yes, please send me my personal copy of the Computer Science Catalogue 1991

Institution/ Company

_____ _____________ __ _

Job Title------------

-

- - -

-------

- -

Address-------------------------

Country_

- - - - ___________________ _

Circle #3 on Reader Service Card

EDITORIAL POINTERS

A monthly publication of the Association for Computing Machinery Publications Office ACI, 11 West 4Zd st., NIW York, NIW York 10056 IZ1ZI 869-7440 FU: IZ1ZI 869-0481 email [email protected]

Director: Mark Mandelbaum; Associate Director: Janet Benton; B1s11ess 111111r: Roxanne carcaterra; Adffrtts111 11111er: waiter AndrzeJewskl; Enelltlve Editor: James Maurer; s111or Editor: Diane CraWford; Associate Edlton: Unda Feako, Thomas E. lambert; COPY Editor: Carolyn Ueberman; Edltorlal Asslstatt: Robert FoX; topyr11111t: Jane car1ton; ca111dar 1t1•s: Mickey Abbate; Slllor Writer: Karen A. Frenkel; Art Director: Dennis Ahlgrlm; Pl'Dd1dlo1 111111er: Lynn D'Addeslo

Advertising Display Representatives: lllW EQllld 11111 •1Ht111ttc:

Clsclo C0••111catl01S 13121332-5945; Fax: 13121 332-6009 contact Dean Horowitz lltlwst lld SOit•: Clsdo CO••lllcatlOIS 13121 332-5945; Fax: 13121 332-6009 contact Katll Y Capello Wiit:

llnbll 11•11 & Assodltll 18181782-1511; Fax: 18181782-2827 llClllt•Ht Dlsllllf Adllrtlslll CO••llltJ Mllftlslll 12011 487-2511; Fax: 12011 487-; the nonmember annual subscription Is $109. see top Une Of mailing label fOr subscription expiration date coded In fOur digits: the first two are year, last two, month Of expiration. Microfilm editions through 1980 can be purchased from Microfilm Dept., Publishing Services Dlv., waverty Press, 428 East Preston street, Baltimore. MD 21202. Microfilm and microfiche are also avallable from University Microfilms 1ntema­ t1ona1. 300 North zeeb Road, Dept. PR, Ann Arl>Or, Ml 48106; 18001 521-0600. 111111 coplls are $8 to members and $17 to nonmembers. Please send orders prepaid plus $4 fOr shipping and handling to ACM Order Dept., P.O. aox 64145, Baltimore. MD 21264. For credit card orders call 18001342-6626 Un Baltimore, Alaska, or canada, can 13011528-42611. Order personnel on duty 8:154:45 EST. After hours, please leave message and order personnel wlll return your call. s1••1Ss1o• lllformtlol: All manuscripts Should be submitted In qulntupUcate to the Executive Editor with a cover letter that dedares whleh section Of communicationsIS Intended to receive the material. Letters to the Forum, Teehnlcal correspondence, and Viewpoints should be submitted to the Executive Editor. Calendar Items should be submitted to Mickey Abbate.

A

t last year's AAAI conference in Boston, Communications Senior Editor Diane Crawford and Elizabeth Shook from Franz Inc. gathered together a group of Lisp developers, researchers, and commercial users to plan an issue that would portray the role of Lisp systems in the 1990s. The objective was to develop a series of articles that would address the concerns and the myths about Lisp as well as promote its potential. The lively discussion was successful. Within weeks 19 abstracts were submitted for consideration as potential articles. Of the 19 submissions, nine topics were chosen for further development. Some of the authors whose abstracts were not selected offered to participate in the reviewing process, so the end result is certainly a collaborative effort. Fifteen percent of Communicatiom's 85,000 readers currently use Lisp and, in a 1990 readership survey, 18% indicated they were interested in finding out more about the language. Whether you are currently using Lisp or not, this month's featured articles are bound to challenge some of your preconceptions of Lisp systems. In this issue the authors discuss the past, present, and future of Lisp in terms of its applications to technolo­ gies of wide interest to the computing community. Interface management, expert systems, windowing, object-oriented facilities, the implementation of Al and symbolic processing programs, and the needs of applications builders are just some of the areas covered. For readers who are particularly interested in Lisp, ACM offers a specialized publication and a conference. Lisp Pointers, a quarterly news­ letter that encompasses all aspects of the Lisp programming language, is available as a subscription from ACM's Special Interest Group on Programming Languages (SIGPLAN). ACM's 1992 Conference on Lisp and Functional Programming will be held at the Fairmont Hotel in San Francisco, June 22-24, 1992. Jon L White, one of the featured authors in this issue, is the general chair. Also presented in this issue is Fernando]. Corbat6's 1990 Turing Award Lecture " On Building Systems That Will Fail," in which Corbat6 addresses a class of systems that he calls " ambitious systems," or systems that never quite work as expected. The A.M. Turing Award is ACM's most prestigious technical award and is presented for significant contribu­ tions of a technical nature made to the computing community. Corbat6 received the Turing Award for his early work on Multics and CTSS (Computer Time Sharing Systems). Communications Senior Writer Karen Frenkel explores with Corbat6 some of his early influences in "An Inter­ view with Fernando Jose Corbat6." CTSS and Multics stand out not only as operating systems per se but also as important early examples of large-scale software engineering.

Executive Editor

COMMUNICATIONS OF THE ACM/Scptcmbcc 1991 /Vol.34, No.9

5

Are you trying

to

play Carnegie Hall If you're developing a simple application, you'll find that C++ is an adequate object­ oriented language. But if you're working on a complicated appli­ cation, you'll need a development environment that can actually handle the job. Allegro CL® with CLOS

Allegro Common LISP with CLOS (the Common LISP Object System) automates many of the tasks you'd have to do manually with C+-1; Allegro CL with CLOS has its roots in the original OOP languages. It has matured over the years into· a powerful development environment for complex applications.

Multiple Inheritance Polymorphism Encapsulation Interactive Incremental Compilation Auto. Memory Management Meta-level Facility Method Combination Dynamic Redefinition Standard Class Library

• •

Allegro CL with CLOS YllS YES YES YES YES YES YES YES YES YES

C++­ YES YES YES

NO NO NO NO NO NO NO

. with a street corner instrument? We've also made a recent breakthrough in delivery of LISP applications. AJlegro P resto is a new automatic function loading system which reduces the runtime size of each LISP application. Functions required by t h e a p p l i c a t i o n are lo aded dynamically; the LISP image is then "frozen" for delivery. Now you can get a fully-functional OOP environment, the prototyping power of LISP, and an elegant new way to deliver your application. Of course, Allegro CL tools work on all popular UNDC" plat­ forms , from the 386"' to Cray computers. True OOP virtuosity can only be obtained with the help of the best LISP instruments­ and the support of a company devoted to the success of your application.

FRANZINC.

1995 University Avenue, Berkeley, CA 94704 FAX: 415-548-8253

TEL: 415-548-3600

C> 1991 Franzlnc.AllegroCLisaregisteredtrademarkoffranzlnc. Unix isa trademarkol T&T. 386 lsa trademarkof lnlelCorp.

f

Circle #9 on Reader Service Card

ACM

A monthly publication of the Association for Computing Machinery

Founded in 194 7 as the society of the computing community, the

Editorial Board

Editor 11 Clllef: Peter J. Denning Associate Editor la Clllef: G. Scott Graham CONTRIBUTING EDITORS John Bartow; Diane CraWfortl; Seymour Goodman; Peter G. Neumann; tarry Press; Marc Rettig; Pamela Samuelson; Elliot Soloway; Maurice v. Wiikes ARTICLES EDITORIAL PANEL Jacques Cohen; Flavlu Crtstlan; Jack Dongarra; Peter Friedland; James Goodman; Robert M. Harallck; won Kim; Rob Kllng; Michael A. tangston; Henry F. ledgard; Doris Lidtke; Halm Mendelson; John RushbY; Doug Terry; Jeffrey s. Vltter COMPUTING PRACTICES EDITORIAL PANEL Chair: Edgar H. Sibley; Eric Clemons; lance B. Eliot; Christopher Fox; Donald Gantz; Chris Kemerer; Brian Ne]meh; Sol Shatz

Association for Computing Machinery is dedicated to the development of iriformation processing as a discipline, and to the responsible use of computers in an increasing diversity of applications. The purposes of ACM are to advance the sciences and arts of information processing, to promote the free interchange of iriformation among specialists and the public, and to develop and maintain the integrity and competence of individuals in the field. Executive Director: Joseph S. DeBlasi Director, Office of Membership and Strategic Services: James M. Adams Associate Director, Strategic Initiatives:

Fred Aronson; Associate Director, PUBLICATIONS BOARD Chair: Wiiiiam B. Gruener; Gwen Bell; Peter J. Denni ng; Edward A. Fox; Richard Kleburtz; Peter Wegner; David wood; Stuart ZWeben EDITORIAL C01111111TIEE Chair: Peter J. Denning; Christine A. Montgomery; Herbert D. Schwetman; Alan Shaw; Gia Wiederhold COpyr1a-. © 1991 llf tile AssodatlOI for CO•Pltl•I 1ac•111ry, 11c. copying without fee Is permitted provided that the copies are not made or distributed far direct commercial advantage and credit to the source Is given. Abstracting with credit Is permitted. For other copying Of articles that carry a code at the bottom Of the first page, copying Is permitted provided that the per-copy fee Indicated In the code Is paid through the copyright Clearance Center, 27 congress Street, salem, MA 01970. For permission to republish write to: Director Of Publications, Association far computing Machinery. TO copy otherwise, or republish, requires a fee and/or specific permission.

Membership and Marketing Services:

Lillian Israel Director, Office of Publications: Mark

Mandelbaum; Associate Director, CACM, Quarterlies, ACM Press Books, SIG Publishing: Janet Benton; Associate Director, Computing Reviews, Guide, Database and Electronic Products:

Bernard Rous

Board Chairs: Education Board: A. Joe

Turner; Management Board: John H. Esbin; SIG Board: Mark Scott Johnson; External Activities Board: Vacant; Conferences Board:

Frank Friedman; Publications Board: William B. Gruener; Local Activities Board: Lynne C. Shaw

Director, Office of Policy and

SIG Chairs: SIGACT S. Rao Kosaraju;

Administration: Patricia Ryan; Associate

SJGAda: Mark S. Gerhardt; SIGAPL:

Director, MIS: Joseph P. Sullivan

Lynne C. Shaw; SIGAPP: Hal Berghel; SIGARCH: Alan Jay Smith; SIGART

Controller, Office of Financial Services:

Stuart C. Shapiro; SIGBDP: Elias Awad;

Michael Lichtenstein; Deputy Controller, SIG Financial Reporting: John DeLorenzo;

SIGBIO: William E. Hammond; SIGCAPH:

Assistant Controller, Budgeting and Financial Planning: Russell Harris; Assistant Controller, Financial Opera­ tions: Oliver Ali Director, Office of SIG Services:

Pegotty Cooper Program Directors, Office of SIG Services: PLAN, ACT, ART, SAM, NUM:

WBPA

B. Wilson (1988-1992); William A. Wulf (1990-1994); Regional Representatives: Central Region, Helen C. Takacs Ouly 1, 199!-June 30, 1993); Eastern Region, Gwen Bell Quly I, 1991-June 30, 1994); Western Region, Anita Borg Quly 1, 1991-June 30, 1993); International Region, M aurice V. Wilkes Quly 1, 1991-June 30, 1994)

Donna Baglio; GRAPH: Lois Blankstein; CHI, Ada, GAS, CAPH, UCCS: Diane Dar­

row; BDP, CPR, LINK, OIS, SAC, DOC, IR, COMM, SOFT Lisa Ernst; DA, ARCH, MICRO, SMALL/PC: Debbie Hall; APL, APP, BIO, FORTH, MOD, OPS, SIM, METRICS, CUE, CSE: Pat McCarren ACM Council: Presid ent: John R. White; Vice-President: S. Ron Oliver; S ecretary: Barbara Simons; Treasurer: John H. Esbin; Chair, Publications Board: William B. Gruener; Chair, SIG Board: Mark Scott Johnson; Past President: Bryan S. Kocher; Members-at-Large: V inton G. Cerf (19901992); Michael R. Garey (1988-1992); Jan

COMMUNICATIONS OF THE ACM/September 1991 /Vol.34, No.9

Ephraim P. Glinert; SIGCAS: Ronald E. Anderson; SIGCHI: Austin Henderson; SIGCOMM: A. Lyman Chapin; SIGCPR: Raymond McLeod, Jr.; SIGCSE: Nell B. Dale; SIGCUE: John Lawson; SIGDA: Michael J, Lorenzetti; SIGDOC: R. John Brockmann; SIGForth: Irving Montanez; SIGGRAPH: James]. T homas; SIGIR: Edward A. Fox; SIGLINK: Robert Akscyn; SIGMETRICS: Michael K. Molloy; SIGMICRO: Joseph L. Linn; SIGMOD: Won Kim; SIGNUM: Robert B. Schnabel; SIGOIS: C arson C. Woo; SIGOPS: Henry M. Levy; SIGPLAN Stuart I. Feldman; SIGSAC: Daniel P. Faigin; SIQSAM: Keith 0. Geddes; SIGSIM: C. Michael Overstreet; SIGSMALLIPC: E.A. Unger; SIGSOFT Richard N. Taylor; SIGUCCS: Russell S. Vaught For Information from Headquarters: Membership Services Manager: Linda

Berg; Program Manager, Chapter and Local SIG Activities: Beth Olson; Program Manager, Education/ACM Conferences: Don Nowak

7

For the Latest Word in Computer Science Available January

PASCAL'S TRIANGLE: Readin�, Writing, and Analyzmg Programs

now

by Rick Decker and Stuart Hirsh.field,

both of Hamilton College

The first CS-/ book to fully embrace a lab-based

approach to programming-an active learning emphasis highly recommended by the most recent guidelines of the ACM. Two laboratory manuals

(one using THINK Pascal 3.0; the other using TURBO Pascal 6.0) accompany the text and provide directed laboratory assignments thoroughly integrated with text material. Each chapter and lab is organized around a complete, meaningful sample program developed expressly to illustrate the programming concepts described in the chapter.

AN INTRODUCTION TO ANSI C ON UNIX by Paul Wang,

Available now by Decker and Hirshfield

Kent State University

The first book to teach ANSI Con the most widely used UNIX operating systems-Berkeley UNIX and UNIX System 5. Coverage includes key concepts such as the

UNIX environment, vi and emacs, the C preprocessor, C's key constructs, standard library functions, arrays and pointers, UNIX 1/0 facilities, error handling and debugging with DBX, UNIX tools for C programming, multiprogram­ ming, and much more. An intuitive approach treats pointers as a natural and non-threatening extension of data types­ an entire chapter uses arrays as a springboard for mastering and applying this difficult concept. Many realistic examples, challenging exercises, and programming projects included as well as a syntax sum­ mary, operator precedence table, lists of library functions, and a comprehensive index. Paperbound. ©1992.

AN INTRODUCTION TO BERKELEY UNIX

Paperbound.©]988.

Also available

University of Rhode Island

-----

Contact us for the latest word on these and other Wadsworth titles:

Write (on your school or company letterhead) to Wadsworth Publishing Company Ten Davis Drive • Belmont, CA • 94002 ·

or

TIIE ANALYTICAL-ENGINE: An Introduction to Computer Science Using ToolBook

TURBO PASCAL by Richard Mojena,

University of California, San Diego

.

Also by Decker and Hirshfield Available November

AvailableJanuary

C FOR PROGRAMMERS by Walter Burkhard, -----

Winner of the 1990 EDUCOM/NCRIPT AL Higher Education Software Award for Best Curriculum Innova­ tion-Scientific Laboratory. Paperbound. ©J990.

Now the authors have used the same award-winning approach in their ToolBook version of The Analytical Engine. ToolBook is an ideal medium for illustrating a wide range of topics without the technical jargon that often makes learning difficult-and The Analytical Engine uses this powerful software for the IBM PC to full advantage. Paperbound. ©J992.

Also by Wang

Paperbound. ©]988.

TIIE ANALYTICAL ENGINE: An Introduction to Computer Science Using HyperCard

call 415-595-2350

Circle

Using the full power of TURBO Pascal 6.0-the latest TURBO release-Mojena's new book is based on three guiding principles: top-down design from the start, cohesive treatment of topics, and flexibility of coverage. Includes object-oriented programming, TURBO Vision, debugging, software engineering principles, and graphics as well as all CS- I topics. Many diverse applications and examples also included. Paperbound. ©J992.

#62 on Reader Service Card

The Society for Computing and Information Processing

Membership Application

Mail to: ACM, P.O. Box 12114, Church Street Station, New York, NY 10257 You may use this ACM Membership Application to:

1) Join ACM and take advantage of the special Publication and SIG

rates for ACM members; 2) Join the Special Interest Group(s) of your choice at the SIG Member (non-ACM member) rates on the reverse side; individuals joining SIGs using these rates are not entitled to ACM membership privileges.

Personal Information

• Please Print •

I I I I I I I I I I

First. Middle Initial, Last Name Address

Address Address City/State/Zip or City/Country/Postal Code T itle

� ���-�����-�����-�����

Day Telephone Number

ACM Membership ACM Membership includes a subscription to the monthly Communications of the ACM

I I I I I I I

D $75.00 Voting Member Applicants

You must subscribe to the Purposes of

I I I I I

I I I I

Address above is:

Degree. Institution:

I I I

I Business

For Office Use Only

1. Bachelor's

I I I I I I I Home

II I I I I I I

------

ACM; have attained professional stature as demonstrated by intellectual competence and ethical conduct in the arts and sciences of information processing; and must satisfy

2. Equivalent level of education. Institution:

at least one of the requirements at the right.

I attest the above is correct

3. Four full-time years of experience

-------

(attach a brief statement).

------

Signature

D $75.00 Associate Member Applicants

You must subscribe to the purposes of ACM. Associate Members may convert to Voting Member status at any time by writing ACM Headquarters for a "Self-Certification" form.

D $22 . 00 Student Member Applicants

Check member class desired

Institution:

--------­

You must be registered in an accredited educational institution and a Faculty

Faculty Member's Signature

Member must certify your full-time status.

Expected Graduation Date:

Joint Membership Applicants

0 $70.00 Members of the IEEE-CS

receive a $5 dues discount. (not Affiliates with "N9" member#'s)

-------­

� �� v v-�� M M

Society: Member#:

-------

D $60.00 Members of the following international computing societies

ACS (Australia). ADIG (Guatemala). AFCET (France). AICA (ltaly).API (Portugal),BCS (United Kingdom), BIRA/IBRA (Belgium), CIPS(Canada).CSZ(Zimbabwe), GI (Germany), HKCS (Hong Kong), ICS (Ireland), IPA(lsrael), IPSJ(Japan), NGI (Netherlands), NZCS (New Zealand), SCCC (Chile), SCS (Shanghai).

D Spouse Member Applicants Spouses who are both members may elect to receive only one subscription to CACM and pay the following reduced rates:

Voting Members 1 st person + CACM

Student Members ............ ..........

2nd person, no CACM

$75.00

................

$50.00

1 st person + CACM

.....................

2nd person. no CACM

$22.00

......... .......

$14.00

D $37.00 Retired Member Applicants

Your annual income1rom part time and consulting work must not exceed $2,500; your age plus years of ACM membership must

exceed 75.

SIG Membership Non-ACM Members Only

Mailing List Optional

D SIG Membership only. (Non-ACM Members only).

Membership in special interest group(s) of your choice includes a newsletter subscription. SIG non-ACM members are not eligible for ACM SIG member rates or ACM membership privileges. See "S/G Member (non-ACM) Rates" on reverse.

ACM occasionally makes its membership list available to companies and societies for

DACM announcements only.

computer-related mailings. If you wish to restric·t

DACM and sister society announcements only.

the use of your name for these purposes, please

For Office Use: Recruit/Promotion Code

CACM-9/91

check one of the following:

Purposes of ACM Signature Required Note: Membership dues include $30.00 ($20.00 for students) toward a subscription to Communications

of the ACM.

To advance the sciences -

� 8 ... �

• The ability to deal with new technologies in an ever-changing workplace.

__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __

25

LOE

Students today can't prepare bark to calculate their problems. They depend upon their slates which are more expensive. What will they do when the slate is dropped and it breaks? They will be unable to write!

Teachers as Video Producers

At the St. Louis Zoo a teacher can pop a blank V H S cassette into a VCR connected to a Mac I I , use IMRE to browse eight videodisks for relevant video clips on animals, or biology concepts, and walk away with a videocassette crammed full of professional quality video. The cost? Nothing, except for the video­ cassette itself-and the teacher's time. In fact, the key is the teacher's investment of time: Through a vis­ ually engaging and straightforward interface (Figure 4), a teacher can invest a modest amount of time and construct a videotape that is cus­ tomized to what the teacher per­ ceives as the particular needs of his/ her own class. (Figure 5 shows a Teacher's cont:erence teacher adding a video clip to his or t70:S her "shopping list" that will eventually be printed to the teacher's videocassette.) Given that personal investment, the teacher is both students today more likely and better prepared to depend upon paper use his or her custom videotape to foster interaction and discussion in too much. They class, rather than simply showing it to the class like one of those deadly don't know how to audiovisual film strips. The intellectual property lawyers write on a slate out there are probably jumping up and down by now asking who gave Wl.thout gett·1 ng '§ the teachers the right to copy some­ Chalk dust all Over � one else's images? Who paid for .f that right? In addition to developthemselves. They � ing I M RE, Burt and David of Arnowitz Productions went through Can't clean a slate �.:; all the legal gyrations so that teach� ers using I MRE will not go to jail. properly. What will � I MRE-like systems, however, raise they do when they � all those nasty copyright issues: who 1 owns an image? what is an image? run OUt pape,.-,! � what is plagiarism in the digital, Prlnclpal's Association � networked era? �

of

tats

·�

� Design Studio Learning for �"" Teachers 1i Six-thousand teachers have been

j

lining up to take a one-day work­

� shop on "a model classroom of the ·� 2 1 st century" at the Teacher Ex­

� �

plorer Center in East Lansing, Michigan. I nstead of lectures about � the classroom of tomorrow, Fred

26

D'Ignazio director and Sharon Goth-Tew, use the classroom of today plus readily available technol­ ogy to provide attendees with a genuine learning experience in multimedia research and publish­ ing. During a six hour workshop each of the five teams (four to a team) produce a videotape, using for example camcorders, and digi­ tizing cards, on I B M machines, that tells a story to the folks back home in the school district. Workshop attendees universally attest to having a "great," "wonder­ ful," and "unforgettable" experi­ ence. The demand is such that two more Teacher Explorer Centers are being opened up in Michigan (in Oakland directed by Anne Porter, and in Bay de Noe directed by Joe Clairmont). Teachers and adminis­ trators are clearly overcoming any (reasonable) apprehension they more than likely have, and are sending a clear signal that they are open to change, to new learning cultures, to new tools. Get set: it may happen faster than we expect. The Wild card: The Home Information Appliance

All the above experiments have been carried out on desktop, per­ sonal computers. But what about the consumer electronics industry? If you are in Japan and feel com­ fortable working with Japanese characters, pick up a $450 Sony Data Disk Man, a hand-held CD player that can "play" dictionaries, encyclopedias as well as music. I n the U . S . , Commodore has CD/TV, a sleek, black box sold in stereo stores, for about $ 1 ,000, that is a CD player running a 68020 under the hood. And, the software for such hardware is coming along very fast also. A whole new generation of publishing houses, such as The Voyager Company, Warner New Media, I nc., ABC News I nteractive are producing provocative "titles" solely on electronic media. What happens when the CD/ computer is $250-the price of a VCR-say, Christmas 1 993? (co ntinued o n page 95)

September 1991 /Vol .34, No.9/COMMUNICATIONS OF THE ACM

APRMBU 1991

COMMU NICATIONS OF THE ACM

It has survived by adapting to changes in its

ISP IS A C HAMELEON.

abstractions to the programmer. Lisp's abstractions are

surroundings. Moreover, Lisp has actually

high level and hide the details of the underlying hardware.

show that a programming language provides a set of

thrived on the changes. When structured

One advantage of high-level abstractions is that it is much

programming became popular in the 1970s,

easier to write portable software. The disadvantage is that

Lisp users immediately experimented with

the execution cost of some of the abstractions may be high

new structured control forms and the best

on certain hardware, and the programmer may not

ones were adopted as part of Lisp. Fortran

necessarily know this. Gajek's sidebar on The Metal System

programmers could only simulate struc­

reaffirms some of the points made by Sinclair and Moon

tured constructs by enforcing a discipline on

about the utility of Lisp's programming abstractions. One usually speaks of a Lisp system rather than the Lisp

the use of the goto statements. Object-oriented programming (OOP) was another idea that spread through the community

language because there are many components to the piece

of software called Lisp. In " Lisp Systems in the 1990s,"

several years ago. The Smalltalk language demonstrated

Layer and Richardson explain that a Lisp system contains

that OOP was a very useful approach for software develop­

a programming environment with debugging tools, a

ment. Many versions of Lisp added OOP through the addi­

storage allocation module with a garbage collector, a com­

tion of an object system called Flavors, which went beyond

piler, an interface to foreign code (e. g., C code), and often

Smalltalk and included multiple inheritance and method

an interface to a window system. This article describes the

combination. Flavors added OOP to Lisp in a very natural

state of these components today and predicts how they may

way, without upsetting existing programs. Common Lisp

evolve during this decade. McKay's sidebar " G L I M : the

Object System-CLOS-extends the object-oriented

Common Lisp Interface M anager" goes into more detail

paradigm even further and permits operation at the meta­

on one of the window toolkits mentioned in the article.

level. With CLOS the user can experiment not only with

Foreign code support is important since there is a large

OOP, but with the design of object-oriented programming

body of useful code not written in Lisp. Muller's "Lisp­

systems. I n " C LOS: Integrating Object-Oriented and

View: Leverage Through Integration" provides an exam­

Functional Programming," Gabriel, White and Bobrow

ple of Lisp, using a graphics interface toolkit written in C

describe the components of C LOS and show how CLOS

in order to make the Lisp program fit in better with non­

related to the object-oriented languages Smalltalk and C + + .

Lisp applications in the workstation. "Delivering the Goods

When Lisp adopts a new paradigm, it not only replicates

with Lisp," by Barber and Imlah, describes in more detail

existing practice, but goes beyond it to become a testbed

the choices for delivering Lisp applications in the low-end

for advancing the state of the art. Why has Lisp been able

PC market.

to adapt so easily when other languages have not? One reason is that Lisp is a programmable programming language. Not only can you program in Lisp (that makes it a program­ ming language) but you can program the language itself. This is possible, in part, because Lisp programs are represented as Lisp data objects and partly because there are places during the scanning, compiling and execution of Lisp programs where user-written programs are given control. Contrast this with the C compiler, where the only user input to the compilation process is the ability to define macros that do simple string transformations of the source code. Many more reasons for Lisp's continued popularity are found in "The Philosophy of Lisp." Sinclair and Moon

COMMUNICATIONS OF THE ACM/Scptcmbcc 1991 /Vol.34, No.9

'

-� ,

guest editor,.

...

RICHARD P. GABRIEL , .ION L WHITE , AND DANIEL G. BOBROW isp has a long history as a functional language; where action is invoked by calling a procedure, and where pro­ cedural abstraction and encapsulation provide convenient modularity boundaries. A number of attempts have been made to graft object-oriented programming into this framework without losing the essential character of Lisp­ to include the benefits of data abstraction, extensible type classification, incremental operator definition, and code reuse through an inheritance hierarchy. The Common Lisp Object System (CLOS) (3], a result of the ANSI standardization process for Common Lisp, represents a marriage of these two traditions. This article explores the landscape in which the major object-oriented facilities exist, showing how the C LOS solution is effective within the two contexts. Incremental Definition of Operations

A genericJunction, or polymorphic function as it is sometimes called, is one whose implementation depends on the types of its arguments. That is, the code that is executed for a particular set of arguments is mechanically deter­ mined by the types of the arguments. In strictly functional languages, an operation is defined by a single, monolithic piece of code. Any argument-type conditionality is expressed as code explicitly programmed in by the user. In contrast, the C LOS notion of generic functions supports automatic selection from among separately defined, type-specific implementational parts. Yet, from the client's point of view, generic functions and traditional ordinary functions are called in the same way: the procedural abstraction barrier remains. Although the concept of generic functions is familiar, its role as the foun­ dation of an object-oriented language is relatively new. The use of generic functions rather than message-passing is suggested for a number of reasons. First, they are a natural extension of the preexisting Common Lisp type­ generic functions such as the numeric functions. Second, their use helps achieve consistency for client code-all operations are invoked using function­ call syntax. Third, they allow the programmer a means for defining operations for new types of objects, providing a desirable object-oriented extensibility. Fourth, they provide the framework for the class-based inheritance of behavior. The technique of separated, incrementally defined implementation with automatic choice of code has been used in a number of different program­ ming styles: the polymorphism tradition, the data-driven tradition, the pattern-directed invocation tradition, and the object-oriented tradition. C LOS is closest to the object-oriented tradition, but shares some features of each of these. Each of these traditions will be examined in the following subsections, leading to an assessment of C LOS generic functions within this framework.

types of the arguments. Fortran does not allow users to define such polymorphic operations themselves. However, C+ + is a language that supports separated definitions of polymorphic operations-operations having the same name, but operating on arguments of different types are simply treated as independent. For example, one might have a function s iz e that is defined to take an argu­ ment of type string, and another of the same name for an argument of the user-defined structure type shoe. The C+ + compiler chooses the ap­ propriate run-time implementation based on the declared or inferred types of the arguments in the call­ ing code. Even before C LOS, Common Lisp had some polymorphic operators. All arithmetic operators perform type-specific operations depending on the types of the actu ally supplied argu m e n t s , sometimes first performing type coercions. For example, evaluating the expression (+ x y) will perform floating-point arithmetic if the value of either x or y is a floating-point number. The difference between the For­ tran and Lisp notions of arithmetic polymorphism is that Fortran deter­ mines the operator implementation at compile time, while Lisp usually delays the decision until run time. However, Lisp supports a wide spec­ trum of choices between static and run-time typing. C+ + supports a mixture of compile time and run­ time polymorphism-the operator implementation of an overload is selected at compile time while the operator implementation of a virtual function is selected at run time.

Polymorphism Tradition

Data-Driven Tradition

Some languages have polymorphic operators (4]. A polymorphic operator is one whose behavior or implementation depends on a description of its arguments. For example, Fortran has polymorphic arithmetic operators where the description is actually the types of its arguments. The types of the arguments are declared by type inferencing based on the first letter of variable names. The rule is that any variable whose name begins with one of the letters I , , N refers t o fixed-point numbers while all others refer t o floating-point numbers. For example, the code fragment I+J is a fixed-point addition while X+Y is a floating-point addition. At compile time, the appropriate operation is chosen based on the apparent

The data-driven tradition is based on the technique of explicitly dispatch­ ing to a first-class function deter­ mined by some aspect of relevant data such as the arguments to an

•

•

•

COMMUNICATIONS OF THE ACM/September 199! /Vol.34, No.9

•we use the term "functional languages" in a sense

not

restricted

to pure,

side-effect- free

languages. We refe r to a model based on fu nctional composition, application to arguments, and the return of values.

29

operation. In some situations, it might be useful to use exogenous features for method selection. Some illustrative examples would include the process in which the operation is being done, the calling environment, or the types of re­ turned results. Artificial intelli­ gence applications could make use of extensions like this to be able to select an operation based on a de­ scription of the desired effect. As an example of the data-driven technique, consider symbolic dif­ ferentiation. Suppose that algebraic expressions are represented in Lisp as lists with prefix arithmetic opera­ tors: ( + (expt X 2 ) ( * 2 X) 1 )

The function deriv i n Figure could be the driver for a data­ driven symbolic differentiation program (in Lisp syntax [ 1 2]) where each differentiation rule is implemented by one function in a table. The way to differentiate a sum is to sum the derivatives, and this behavior can be added quite easily as shown by the call to add-to­ table in Figure I . The data-driven tradition has been used extensively in symbolic algebra and artificial intelligence. Pattern-Di rected I nvocation Tradition

The pattern-directed invocation tradition is characteristic of back­ ward chaining rule languages, such as Prolog [5]. Pattern-directed invo­ cation provides a means for the programmer to describe the argu­ ments on which a particular clause of a definition is to operate. More specifically, the choice of what to do is dependent on the morphology of the argument expression. A pro­ gram to differentiate an expression like deriv( expression, variable,result)

might be written as shown m Fig­ ure 2. Each clause is simply a relation that states that the left-hand side of

:50

the clause holds true if the right­ hand side does. The control struc­ ture for pattern-directed languages is that of a goal statement whose unknowns are eliminated by match­ ing the left-hand sides of clauses against the goal statement or a part of it, and replacing the goal by zero or more subsidiary goals obtained from the right-hand side of the matching pattern, along with possi­ ble execution of attached code. Sometimes several left-hand sides match, or a single left-hand side can match more than one way, and by backward chaining or backtracking the first solution is found. Sometimes, to shorten the running time of a program , it is necessary to prune backtracking. There is an operator, called cut, that prevents failure from retreating beyond a certain point. Matching a data description to a set of supplied arguments is a suc­ cinct, powerful way to describe the code selection process. Backtrack­ ing control structure makes sense in a problem-solving setting, but few programs are run in such a setting. In many cases, the ability to select a piece of code to run based on a matching process is powerful enough without requiring an auto­ matic backtracking mechanism. I f backtracking i s necessary, i t might be preferable to provide an explicit backtracking mechanism. There­ fore it makes sense to separate the concept of selection from that of backtracking. Object-Based Prog ramming Tradition

The object-based programming tradition is often identified with message-passing, in which a mes­ sage containing the name of an operation and arguments is sent to a receiver. As with the data-driven tradition, the receiver and the name of the operation are jointly used to select a method to invoke. For example, to do the symbolic derivative problem above in Smalltalk [8] one might have a class for SymbolicSum as shown in Fig­ ure 3 .

An expression i s represented a s a nested composite of objects (like a parse tree) and each class has a method that defines how it re­ sponds to a message whose selector is deriv: . Thus, the expression ( s 1 deriv: variable)

is understood as sending a message to sl with selector deriv: and argu­ ment variable. Smalltalk occupies only one point in a spectrum of object-based pro­ gramming styles. There are four focuses for object-oriented systems: object-centric, class-centric, opera­ tion-centric, and message-centric. Object-centric systems provide the minimal amount of data abstrac­ tion, that is "state" and "operations" [ 1 5]-structure and behavior­ with no special provision for classes, although sharing may be achieved through delegation. Class-centric systems give pri­ macy to classes. Classes describe the structure of objects, contain the methods defining behavior, pro­ vide inheritance topologies, and specify data sharing between ob­ jects. Operation-centric systems give primacy to operations: the operations themselves contain all the behavior for objects, but they may use classes or objects to de­ scribe inheritance and sharing. Message-centric systems give pri­ macy to messages: messages are first class, and carry operations and data from object to object-but they also may use classes or objects to describe inheritance and sharing. Wegner [ 1 5] uses the term object­ oriented programming for object­ based systems with classes that sup­ port inheritance. Of these, only operation-centric systems are not message-passing­ based. As will be shown, CLOS is a combination of class-centric and operation-centric. In class-centric and object-centric languages, the class or object is highlighted, rather than the opera­ tions; the object receives the opera­ tion name (or message), which it examines to determine what to do.

September 1991/Vol.34, No.9/COMMUNICATIONS OF THE ACM

But in functional languages, the operation is in control-arguments are passed to the code implement­ ing the operation, and that code might examine the arguments to determine what to do. These four focuses can be di­ vided into two independent axes which can be used to partition the space of languages and program­ ming traditions, as summarized in Table 1 . The syntax of operation invoca­ tion in the two traditions reflects the difference in focus. In func­ tional languages, the operation appears leftmost in a function call form. In object-oriented languages, the receiver object appears left­ most. In early mergers of object­ oriented programming with Lisp, a send operation was introduced to perform message passing. Its first argument was the receiver object, and definitions looked much like those in Smalltalk. This contrasts starkly with how the differentiation example would be done in CLOS. The recursive call here is of the form (deriv (fi.rst expression) variable) which has the operation first (see Figure 4). I n the notation shown in Figure 4, the argument list for deriv con­ tains the pair (expression sym­ bolic-sum), which is a declaration that the first parameter for deriv is named expression, and this method is only applicable to in­ stances, direct or otherwise, of the class symbolic-sum. Any of the argument parameters of a method definition can likewise be con­ strained by a class specification. This allows all the arguments to a generic function-not just the first one-to participate in method se­ lection. Dimensions of Partitioned Operations

( defun deriv (expression variable) (if ( atom expression) (if ( eq expression variable) 1 0) (funcall ( get-from-table (first expression) *deriv-table*) (rest expression) variable ) ) ) ) (add-to-table *deriv-table* ' + #'(lambda ( expressions variable ) ' ( + ,@(mapcar #'(lambda (expression) ( deriv expression variable ) ) expressions )))) FIGUR• I Table- Driven symbolic Differentiation

deriv([ + X Y],V,[ + DX DY ]) {:::: deriv(X,V,DX), deriv(Y,V,DY). deriv( [ * X YJ,V,[ + [ * X DY] [ * Y DX ]]) {:::: deriv(X,V,DX), deriv(Y,V,DY). deriv(X,X,l ). deriv(X,Y,O ). PIGUR• 2 Pattern-Directed Symbolic Differentiation

SymbolicSum class name superclass Obj ect instance variable names s 1 s2 class methods instance creation of: first and: second jsuper new setargs: first and: second. instance methods deriv: variable jSymbolicSum of: ( s 1 deriv: variable ) and: ( s2 deriv: variable ). private setargs: first and: second s 1 �first. s2�second. FIGUR• :S Object-Oriented Symbolic Differentiation

I

In the preceding descriptions of four traditions, several different dimensions characterize the design space of languages that support incremental definition of opera­ tions. We shall review each dimen­ sion in this subsection.

COMMUNICATIONS OF THE ACM/September 1991 /Vol.34, No.9

TABLE t.

Dimensions of ObJect-Orlented Languages message-centric

operation-centric

class/type-centric

smallta l k c + + virtuals

CLOS Fortran/C+ + overloads

object-centric

Self Actors

Pro log Data-driven

31

The first dimension is whether the selection of the implementation occurs at compile time or at run time. Common Lisp is an example of a language that has chosen to let the programmer decide where along this dimension to lie. C + + has overloads, whose implementa­ tions are selected at compile time, but it also has virtual functions, whose implementations are selected at run time. A language is not object-oriented unless there is some form of run­ time polymorphism. The second dimension is whether polymorphic operators are defined only for system operators or whether the programmer can define them. For example, C + + provides mechanisms for user­ defined compile time and run-time

CLOS

polymorphic functions, but Fortran does not provide any means for user-defined polymorphic opera­ tors. A language is not object-oriented unless there is a mechanism to de­ fine polymorphic operators. The third dimension is whether operators a1·e polymorphic in one or more than one argument. CLOS provides polymorphism for all re­ quired arguments. C + + overloads provide (compile time) polymorph­ ism on the entire argument spec­ trum (including the number of ar­ guments); but, asymmetrically, virtual member functions provide (run-time) polymorphism only on their first arguments despite over­ loaded functions and virtual mem­ ber functions having a uniform cli­ ent syntax. Multiargument polymorphism can be programmed in message­ passing systems, but at a cost. In such systems, one object must be the receiver of the message, and it is this object that determines the method selected. Selection based on several arguments can proceed by a sort of currying similar to the data­ driven tradition outlined previ­ ously. Typically, a series of mes­ sages is sent, each further refining the choice of the real method. I n one scheme, each object in the chain of argument objects provides a new "message" that captures the classes of arguments seen so far. The last object in the series selects the appropriate method based on the resultant compound message [9]. A consequence of multiargu­ ment polymorphism is that meth­ ods are now associated with more than one class. It is no longer possi­ ble to think of a single class as the owner of the method, since each method parameter may refer to a different class. In C LOS, the ge­ neric function owns the methods, and its overall type signature in-

volves the set of classes on which the applicable methods are defined. The fourth dimension is whether the descriptions of the arguments are restricted to types or whether other descriptions are possible. In CLOS, object identity in addition to object type can be used as a descrip­ tion. For example, a method can be defined that operates only when the actual argument is EQL to the object in the parameter specifica­ tion (these are called eql specializa­ tions). Generalized selection is the heart of pattern-directed lan­ guages. Neither Smalltalk nor C+ + supports selection on anything other than the types of arguments. Classes and Types

CLOS supports the notion of classes separate from, but inte­ grated with, Common Lisp types. There are at least four different meanings of "type": declaration types, representational types, signa­ ture types, and methodical types. Declaration types are used to specify an invariant for the pro­ gram about what values can be stored in a particular variable or structure. Such declarations allow compilers to reason about the cor­ rectness of programs and to make decisions about optimizations. Dec­ laration types can be contrasted with the others, the value types, be­ cause they refer to the program text-a floating-point variable for example-while the value types refer to sets of data objects. A representational type is one that defines the storage layout of objects. I ndeed, a design goal of such systems is to permit optimiza­ tions. For example, a Lisp flxnum is a representational type because it is defined to be efficiently stored in computer memory-typically in a single word of memory, and when compiling an invocation of a ge­ neric arithmetic function, a Lisp compiler may emit code specialized

supports the notion of ulasses separate from, but integ 32

September 1991 /Vol.34, No.9/COMMUNICATIONS OF THE ACM

. -::i!t.�t.!t�� -�f � ..

to a more efficient type representa­ tion based on static type inferenc­ ing. A hierarchical type system can be defined where the type leaves are purely representational and the composite type nodes are Boolean and other simple combinations of subnodes. This is how the Common Lisp type system is defined; for example, the type list is defined to be the same· as (or null cons) . A signature type is one defined by the operations that can be per­ formed on objects. Such a type is sometimes called an abstract data type. In this view, the primary dis­ tinction between a cons and a number lies in their signatures: Given a cons cell, one can read and alter its car and cdr components. Given a number, one can perform arithmetic calculations with it. A methodical type is one for

include system-defined types or only new user-defined classes, whether new bit-pattern-level rep­ resentations for objects can be de­ fined along with methods on those new representations, and whether declarations can be used to opti­ mize code. With respect to the first ques­ tion-the inclusion of system­

w h ich

defined

methods

can

be

written.

Classe;s in most object-oriented lan­ guages are examples of methodical types. These different meanings are not mutually exclusive. A type sys­ tem based purely on representa­ tional types can also be a consistent signature type system, just as a me­ thodical type system can be a valid signature type system. In fact, rep­ resentational types are often de­ signed to support specific opera­ tions. A methodical type system can also be based on storage layout de­ c1s10ns. Some aspects of representational types will always be necessary, at least implicitly. For example, the mechanism by which the class of an object is determined almost always involves a selection based on repre­ sentational information. Further­ more, objects usually can store data, and the mechanism for such stor­ age and retrieval is representa­ tional. There are three design questions regarding issues of classes and types: whether methodical types

( defclass symbolic-sum ( standard-obj ect) ( ( s l :initarg :first :accessor first-part) ( s2 :initarg : second :accessor second-part))) ( defmethod deriv ( (expression symbolic-sum) variable) (make-instance 'symbolic-sum :first ( deriv (first-part expression) variable) :second (deriv ( second-part expression) variable ) ) ) lllGUR• 4 Object-Oriented symbolic Differentiation In CLOS

types-Smalltalk ,

C+ + ,

and C LOS nearly run the entire gamut. In Smalltalk types and classes are identified: There is no semantic difference between those supplied by the system and those defined by the user. In C+ + , the only methodical value types-those for which the user can declare methods-are user-defined classes. In CLOS, types and classes are sep­ arate concepts; every class corre­ sponds to a unique type, but not every type has a class behind it. However, in order to cover all system-defined data types, CLOS defines a set of classes which span the preex1stmg Common Lisp types. One set of types spans a sec­ ond set of types if every object in the second set is a member of at least one type in the spanning set. This set is large enough to encom­ pass most representational distinc­ tions within Common Lisp imple­ mentations, but small enough that each system-defined data type is directly covered by a single span­ ning type. This allows implemen­ tors to retain their historic, low-

level optimizations based on repre­ sentational types. For example, there is a class named float in the spanning set of classes that corre­ sponds to the built-in type float. The type float has four subtypes, short-float, single-float, double­ float, and long-float. Implementa­

tions of Common Lisp are not re­ quired to support distinct types cor­ responding to these subtypes of float, and therefore CLOS does not require classes for them either. Most importantly, the use of a spanning set of classes respects ab­ straction barriers by using the same syntax for polymorphic functions written on system-defined data types as for those written on user­ defined classes. With respect to the second ques­ tion-extensibility for new repre­ sentational types-neither Small­ talk, C + +, nor Lisp allows the user to define representational types. For Lisp, there is no defined way to recognize a representational tvoe. With respect to the third ques­ tion-the use of declarative types­ C+ + uses strong, static typing as much as possible, and Smalltalk uses only runtime typing. Common Lisp has a rich, extensible, but op­ tional declaration syntax. Although implementations are not required to do any static type-checking based on a program's use of type declara­ tions, a number of compilers take full advantage of this feature, espe­ cially for optimization.

rated with, Common Lisp types. COMMUNICATIONS OF THE ACM/September 1991 /Vol.34, No.9

33

Factoring Descriptions

A factored description is one that can be used in more than one context. Abstraction is the process of identi­ fying a common pattern with sys­ tematic variations. An abstraction represents the common pattern and provides a means for specify­ ing which variation to use. The sim­

plest example of a factored descrip­ tion is a subroutine or function. A subroutine is an abstraction based on a reusable code fragment, which is reused by being called or invoked dynamically from several different places. Classes are the focus of factored descriptions in object-oriented lan­ guages. New classes can be defined in terms of previously defined classes, and the new descriptions can modify and augment defini­ tions from the used classes. Behav­ ior, in terms of applicable func­ tions, can either be inherited, shadowed, or enhanced. Inheriting behavior means that the behavior defined on superclasses is used as is. Shadowing behavior means that a new definition is directly supplied to the class being defined. Enhanc­ ing behavior means that new be­ havior is added in conjunction to inherited behavior. M ultiple Su perclasses

Ideally, a description is factored into independent components, each of which is useful by itself. I f each new class definition must di­ rectly depend on at most one other class definition, we say the language uses single inheritance. If a new class can depend on more than one class we say the language supports multi­ ple inheritance. In single inheritance, direct combination of several classes is not possible. Extension is possible only by subclassing. Com­ bined, compound objects can only be created by storing instances of various classes as components of a single object-a technique that re­ quires a visible layer of structure to be interposed between the client program and the components. Multiple inheritance is a solution

34

to this problem. lf the classes are in independent domains-share no names for commensurate attri­ butes, either accidentally or delib­ erately-the resulting compound object has the union of all the com­ ponents of each superclass. If the classes are not independent, a means of handling conflicts is r·e­ quired. There are four approaches for addressing name conflicts: dis­ allow them, select among them, form a disjoint union, or form a composite union . The approach of disallowing conflicts is to signal an error if a name conflict occurs between com­ mensurate attributes. The approach of selecting among conflicts can be handled two ways. One is to require the user to specify choices for every case. The second is to use encapsulation: The specification of a class includes those attributes that must remain hidden and thus be automatically deselected. The approach of forming a dis­ joint union is to create a separate attribute for each same-named at­ tribute. Attributes in the composite will have to be disambiguated by some additional means beyond the normal names-perhaps by using a name that specifies the class con­ tributing the attribute. The approach of forming a com­ posite union is to create a single at­ tribute for each same-named attri­ bute by algorithmically resolving them. The resolution algorithm must be designed to reflect the es­ sential characteristics of the inheri­ tance graph topology, and the fea­ tures of the ancestor classes. Smalltalk-which supports only single inheritance-signals an error if the same-named instance variable is specified in a subclass. With disjoint unions, there are as many copies of the conflicting item as there are superclasses with an item by that name. C+ + uses this mechanism for member data ele­ ments. Only some of the named elements are visible in the C + + ' derived class, because C + + sup­ ports name encapsulation between

subclasses and superclasses. CLOS creates a single composite description for a slot from all the inherited slots of the same name. For some facets of slots, the resolu­ tion is to choose the one definition found in the most specific su­ perclass bearing such a slot. For other facets, it involves a u n ion of all the inherited definitions, and ultimately, the resolution step is open to end-user tailoring. The inheritance of methods and the ordering of methods in a combined method also depend on the speci­ ficity of the classes involved. For this reason, C LOS defines an algo­ rithm which constructs sets of linearizations on the inheritance graph, where each class has its own total precedence order-a unique linearization for each node in the inheritance hierarchy. See the sec­ tion "Determining the Class Prece­ dence List" in [3], and refer to [6] for a discussion of linearization al­ gorithms. Inheriting, Shadowing, and Enhancing Behavior

The phrase applicable to arguments, said of a method, is used in CLOS to refer to the situation in which actual arguments are instances, di­ rect or otherwise, of the classes specified for the parameters of the method. For example, the follow­ ing method is applicable to the ar­ guments (3,ABC) because 3 is an integer and ABO is a symbol: ( defmethod f ((i integer) (name symbol) ) . . .)

But the following method is not applicable because 3 is not a float: ( defmethod f ((i float) (name symbol ) ) . . .)

We speak of "the behavior of an object" to signify the set of methods that are applicable to the object, for all generic functions, even when that object is only one of several arguments that participate m

September 1 9 9 1 /Vol.34, No.9/COMMUNICATIONS OF THE ACM

; .. · ,·:-: ·· .

method selection. Method inheritance is also defined in terms of method applicability. There are two problems with enhancing behavior-contextual reference to behavior and guaran­ teeing behavioral congruence. When behavior is enhanced, there must be a way to refer to the preex­ isting behavior, to invoke it in a rea­ sonable place in the new behavior, and to guarantee that the overall semantics of the operation are pre­ served. As an example of behav­ ioral congruence, when + is de­ fined on a class, it is reasonable to expect that the method implements something recognizable as, and congruent to, addition. Note that behavioral congruence is a problem with shadowing as well. There is no way to guarantee semantic congruence, but contex­ tual reference to behavior can be handled. Reference may be made to the same operation defined on subclasses (such as by invoking inner in Beta [ I I ]), or to the same operation defined on superclasses (such as by sending the message to the pseudovariable super in Smalltalk). In CLOS, invoking the shadowed operation in the su­ perclasses is done by the special function call-next-method.

( defclass base-stream . . . ) ( defmethod open ( ( s base-stream) ) (pre-open s ) (basic-open s ) (post-open s ) ) ( defmethod pre-open ( ( s base-stream) ) nil ) ( defmethod basic-open ( ( s base-stream) ) ( os-open . . . ) ) (defmethod post-open ( ( s base-stream) ) nil) ( defclass abstract-buffer . . . ) ( defmethod pre-open ( ( x abstract-buffer) ) (unless (has-buffer-p x) (install-new-buffer x))) (defmethod post-open ( ( x abstract-buffer)) (fill-buffer (buffer x ) x ) ) ( defclass buffered-stream (base-stream abstract-buffe r) . . . )

Procedural Method combination

( defclass base-stream . . . ) ( defmethod open ( ( s base-stream) ) ( os-open . . . ) ) ( defclass abstract-buffer . . . ) ( defmethod open :before ( ( x abstract-buffer) ) (unless (has-buffer-p x) (install-new-buffer x ) ) )

Method combination by Roles

In C LOS, a method can be com­ posed from subpieces that are des­ ignated as playing different roles in the operation through a technique known as declarative method combina­ tion. The enhancement techniques of Beta and Smalltalk are simple cases of procedural method combina­ tion: Explicit calls are made to re­ lated behavior. Another technique for procedural method combina­ tion is for a basic class to have a method that calls other explicitly named methods, which will be de­ fined in derived classes. For exam­ ple, consider a simple stream­ opening protocol, shown in Figure 5. Notice that the method for open defined on base-stream provides a template for the operations on streams. The auxiliary methods

(defmethod open :after (( x abstract-buffer)) (fill-buffer (buffer x) x)) ( defclass buffered-stream (base-stream abstract-buffer) . . . )

oeclaratlve Method combination

and post-open have de­ fault definitions on base-stream, the base class, which do nothing. Declarative method combination is an abstraction based on this sort of procedural method combination. In this example code there are four methods-open, pre-open, basic­ open, and post-open. The main suboperation, basic-open, cannot be named open, since that name

pre-open

COMMUNICATIONS O F THE ACM/September 199! /Vol.34, No.9

refers to the whole combined oper­ ation. The other two names­ pre-open and post-open-are placeholders for actions before and after the main one, i.e., those pre­ paratory steps taken before the main part can be executed, and those subsequent clean-up actions performed afterward. There really is just one action-opening-and all other actions are auxiliary to it:

!5

they play particular roles. This con­ stellation of actions should have just one name, and the auxiliary names need only distinguish their roles. In declarative method combina­ tion, the role markers act like an orthogonal naming dimension. When a generic function is in­ voked, all applicable methods are gathered and sorted into roles. Then within roles, the methods are further sorted according to class specificity. An effective method is then constructed and executed, wherein each method plays its role. Because some method combina­ tions occur so often, they are de­ faultly defined and given names in CLOS. The most commonly used one is called standard method combi­ nation, which defines four method roles: primary methods for the main action; :before methods that are executed before the main action; :after methods that act after the main action; and : around methods that precede all other ac­ tions, and which optionally can in­ voke (via call-next-method) the sorted cluster of :before, :after, and primary methods. The example in Figure 5 could be coded using method combina­ tion in CLOS as shown in Figure 6. An important point to notice about this example is that the sev­ eral methods of differing roles did not all come from the same su­ perclass chains. The primary method is defined on base-stream and the auxiliary methods are de­ fined on abstract-buffer. Buffers and streams are independent, and when they are brought together to form the compound class bu:ffered­ stream, the independent methods are brought together to define a compound method. Although this

example does not show it, the :be­ and : after methods are often inherited from different classes. A mixin is a class designed to be used additively, not independently. Mixins provide auxiliary structure and behavior. The auxiliary behav­ ior can be in the form of auxiliary methods that are combined with the primary methods of the domi­ nant class, or it can be in the form of new primary methods. However, CLOS has no linguistic support for mixins, as Flavors does [ 1 3) . Such support would constrain the use of classes defined as mixins, or provide a means to hide names in a class so that, for example, slot names in mixin classes would not conflict with the slot names in the classes with which they are mixed. fore

Reflection

Reflection is the ability of a program to manipulate as data something representing the state of the pro­ gram during its own execution. There are two aspects of such ma­ nipulation: introspection and effectu­ ation. Introspection is a program's ability to observe and therefore rea­ son about its own state. Effectua­ tion is a program's ability to modify its own execution state or alter its own interpretation or meaning. Both aspects require a mechanism for encoding state as data. The pro­ vision for such an encoding is called reification. There are four dimensions on which to explore reflection : struc­ ture, program, process, and devel­ opment. Structure refers to the way programs are put together. In an object-oriented setting, structure is the class hierarchy. Program refers to the construction of code that ef­ fects behavior. Process refers to

how structure and program are in­ terpreted to produce running sys­ tems. Development refers to the support that such reification gives to the incremental change and de­ velopment of programs. Within each dimension there are three points: implicit, introspective, and effectual. When a quality is implicit, it is present in source code but is not represented as data in the language. When a quality is intro­ spective, it is a first-class object that can be analyzed by a program. When a quality is effectual, its rep­ resentation can be altered, causing its behavior to change. In some languages, like C + + , structure i s only implicit i n the source code. In these languages, source code is available for compil­ ers and environments to examine, but typically the compiler and the environment are separate, external. In other languages, like Smalltalk, CLOS and LOOPS [2], the class hierarchy can be altered and dy­ namically extended by the running program. Language systems can be im­ plicit, introspective, or effectual. I mplicit languages simply provide syntax and semantics for programs, and the compiler (or interpreter) and linker effect the semantics. In­ trospective languages provide a first-class representation for pro­ grams, and frequently they provide an operation such as FUNCTION in Lisp to convert from data to pro­ gram. Effectual languages provide something that resembles a metacir­ cular interpreter, which is an inter­ preter (or executor) for the system written in that very system itself. Altering or customizing parts of that interpreter changes the seman­ tics of programs.

Within each dimension there are three points: implicit, 36

Scprcmbcr 1991 /Vol.3•�, No.9/COMMUNICATIONS O F THE ACM

Lisp has traditionally supplied a means for programs to introspect, and to effect their own states albeit sometimes in a limited sense. Lisp programs are encoded as symbolic exjnessions- the original base of data types for Lisp-so a program can construct other programs and execute them, and a program can observe its own representation, and modify it during execution. Object-oriented programming offers an opportunity to migrate these notions from ad hoe mecha­ nisms (e.g., "hooks" added to EVAL) to more principled ones. The first step in this direction is to require that classes be first class­ that each class be represented by a data object that can be passed as an argument to functions, held in pro­ gram variables, and incorporated into data structures such as lists and the like. The second step is to re­ quire that each Lisp object be a di­ rect instance of some unique class. Thus, each class is (usually) an in­ stance of some other class (but there will be a fixed-point class that is an instance, at least indirectly, of itself). Classes whose direct in­ stances are themselves classes are called rnetaclasses. Generic functions and methods are also first class, and are thus in­ stances of classes. In fact, these classes form a network that pro­ vides introspection into the work­ ings of CLOS. The objects that de­ scribe the class of generic functions, methods, and method combina­ tions describe, at least to some ex­ tent, their structure and behavior. These classes and objects are re­ ferred to as rnetaobjecls. N ot all of these objects are metaclasses. For example, one metaobject is a class named standard-generic-func­ tion, whose instances are generic functions, not classes. Another metaobject is the function #'print­ object, which is a generic function and not a class.

Object-oriented languages sup­ port incrementally extendible or specializable systems. CLOS moves further in this direction first by presenting the implementation of CLOS as a C LOS program, and sec­ ond by supporting dynamic redefi­ nition of classes and objects while still preserving the identity of exist­ ing instances. The first step is a rnetaobject proto­ col, and the second is a software development protocol. Metaobject P rotocol

In CLOS, the details of inheritance, method combination, generic func­ tion application, slot access, in­ stance creation, instance initializa­ tion, class redefinition, and altering an instance to belong to a different class, are implemented as if by a CLOS program whose behavior can be observed (introspection) and al­ tered (effectuation), at least in prin­ ciple. By creating subclasses of metaob­ ject classes and adding methods to metaobject generic functions, stan­ dard behavior can be customized to a great degree. A particularly com­ mon customization of classes that differs from the standard ones is to change the way some local slots are to be stored-e.g., persistently in a database server rather than in com­ puter memory. To implement per­ sistent slots, a user-defined metaclass would shadow the stan­ dard methods for slot-value­ using-class, which is the metaob­ ject function that determines how slot storage is laid out in memory (or other areas). The metaobject protocol encom­ passes such things as the structure, representation, and allocation of classes, instances, generic functions, methods, and method combina­ tions; and the definition and mech­ anisms behind inheritance, generic function invocation, method dis­ patch, class precedence, method

applicability, method combination, and slots including slot access and slot inheritance. The exact mechanisms for metaobject programming are not part of the proposals for ANSI CLOS-but an informal, de facto standard is emerging out of the standardization process [ I O], and each CLOS implementation has at least some part of these mecha­ nisms. A key aspect of effectuation is that reflective capability not impose an excessive performance burden simply to provide for the possibility of effectuation. What is not used should not affect the cost of what is used, and common cases should retain the possibility of being opti­ mized. Even while supporting the development features described in the next subsection, some commer­ cial CLOS implementations have very good performance. By using the reflective capabilities of CLOS, one commercial group developed technology to eliminate the over­ head costs for CLOS's flexibility ( I ] . sottware Development

Different languages provide a vari­ ety of tools positioned along a spec­ trum for aiding software develop­ ment. At one end of the spectrum are languages like C+ + , in which the only tools are external develop­ ment environments. In the middle are languages like Smalltalk that provide residential development environments having access to every part of the language and its implementation. At the other end of the spectrum are languages like CLOS that provide linguistic mech­ anisms to support development. External development environ­ ments are not necessarily limited in power, but can provide incremental development and debugging capa­ bilities similar in power to residen­ tial environments [7]. Residential development env1-

introspective, and effectnal. COMMU NICATIONS OF THE ACM/September 1991 /Vol.34, No.9

ronments add the ability to use as libraries parts of the language and ·environment implementation. Linguistic support for develop­ ment can help with both incremen­ tal development and with delivery of applications. For example, CLOS supports a class redefinition proto­ col, a change-class protocol, and a mechanism to dump instances to a file and retrieve them . In addition, the metaobject protocol can be used to direct the analysis of application code, to provide flexibility during development, and to help achieve efficiency for delivery when that flexibility is no longer necessary. Software development environ­ ments can help solve linguistic problems. In CLOS a method may operate on several different classes, and the definition of the method cannot be defined textually near each of those classes on which it specializes. Furthermore, the meth­ ods of a generic function may be distributed over several different files, based on modularity issues arising out of the end application. Hence one could not expect them all to be defined in a textually com­ pact region. Environmental tools such as editors, browsers, source locators, and graphers can be used to present related classes, methods, and generic functions in textually meaningful ways. concluslon

CLOS and its merger with a func­ tional language has provided many lessons for the language designer and software developer. Its land­ scape can prove fruitful if exam­ ined carefully. During the brief tour of this landscape presented in this article, we have seen the vari­ ous aspects of CLOS, and have at­ tempted to draw connections be­ tween scattered parts of language design by connecting them through the ideas in CLOS. t3

Workshop,

1 989

OOPSLA

ings of OOPSLA ( 1 987). Also a spe­

2. Bobrow, D.G. and Stefik M . The

I. Bennett, J . , Dawes, J . , Hastings, R. Cleaning CLOS Applications with the MOP. Paper presented at the Second CLOS Users and Implementors

!8

cial issue of SIGPLAN Not. 22, 1 2 (Dec. 1 987).

Xerox Palo Alto

LOOPS Manual.

Research Center, 1 983.

3. Bobrow,

D.G.,

DeMichiel,

L.G.,

Gabriel, R.P., Keene, S., Kiczales, G. and Moon, D . A . The Common Lisp object system specification, Tech .

CR Categories and Subject Descrip­ tors: D.3.0 [Software]: Programming Languages-Genera l; D.3.2 [Software) :

Languages -Language

Programming

D.3.3

Pro­

Doc. 88-002R of X3J l 3 , J u ne 1 988.

Classifications;

Also in Special Issue of SIGPLAN

gramming Languages -Language Con­

NOT. 23 (Sept. 1 988) and Lisp and

structs

Symbolic Comput. Oan. 1 989).

4. Cardelli, L. and Wegner, P. On understanding types, data abstrac­ tion

and

polymorphism.

[Software) :

General Terms : Languages Additional Key Words and Phrases: Common Lisp Object System

Comput.

Surv. 1 7 (4), 1 985, pp. 47 1 -522.

5. Clocksin W.F. and Mellish, C.S. Pro­

About the Authors: RICHARD P. GABRIEL

is chief tech­

Ed.,

nical officer of Lucid, Inc., and a con­

6. Ducournau, R. and Habib, M . On

Stanford University. His research inter­

gramming

in

Third

Prolog,

sulting professor of computer science at

Springer-Verlag, 1 987. some algorithms for multiple inher­ itance in object-oriented program­ ming.

In

Proceedings

of ECOOP

1 987, the European Conference on

Programming,

Object-Oriented

Lecture Notes in Comput. Sci. 276, Springer-Verlag, 1 987.

7. Gabriel, R.P., Bourbaki, N . , Devin, M . , Dussud, P., Gray, D . and Sex­ ton, H . Foundation for a C + + pro­ gramming environment. In Proceed­ ings of C + + at Work (Sept. 1 990).

8. Goldberg,

A.

and

Robson,

D.

Smalltalk-80: The Language and its

Addison-Wesley,

Implementation.

Reading Mass., 1 983.

9. I ngalls, D . H . H . A simple technique for handling multiple polymorph­ ism. In Proceedings of OOPSLA 1 986. Also a special issue of SIGPLAN Not. 2 1 , 1 1 (Nov. 1 986).

10. Kiczales,

G.,

des

Rivieres,

J.

Bobrow, D.G. The Art of the Metaob­ ject Protocol, M I T Press, I 99 1 .

1 1 . Kristensen,

B.B.,

Madsen,

O.L.,

M !ll ller-Pedersen, B . and N ygaard, K. The BETA Programming Lan­ guage. Research Directions in Object­ Oriented

Bruce

Programming.

Shriver and

Peter Wegner, Eds.

ests include · programming languages, programming environments, and pro­ gramming systems.

JON L WHITE

is principal scientist at

Lucid, I nc., technical articles editor of the Lisp Pointers newsletter, and gen­ eral chair of the 1 992 ACM Conference on Lisp and Functional Programming. His research interests include program­ ming

languages,

object-oriented

sys­

tems, automated memory management (garbage

collection),

and

computer

Authors' Present Address:

Lucid, Inc.,

arithmetic. 707

Laurel Street, Menlo Park,

CA

94025.

DANIEL G. BOBROW is a research fel­ low in the System Sciences Laboratory at Xerox Palo Alto Research Center, and president of the American Association for Artificial Intelligence. His research interests

include

programming

lan­

guage design, knowledge representa­ tion, and automatic scientific and engi­ neering reasoning.

Authors' Present Address:

Xerox Palo

Alto Research Center, 3333 Coyote Hill Road, Palo Alto, CA 94304.

M IT Press, 1 987.

12. Steele J r . , G.L. Common Lisp the Lan­ guage,

Second

Ed.

Digital

Press,

1 990.

13. Symbolics, Inc. Symbolics Common Lisp-Language

Concepts,

Chapter

19 "Flavors," Symbolics, Inc., Bur­

References

Based Language Design. In Proceed­

(Oct.

1 989).

lington Mass., 1 988.

14. Ungar, D. and Smith, R. SELF: The power of simplicity. I n Proceedings of OOPSLA 1 987 (Dec. 1 987).

15. Wegner, P. Dimensions of Object-

Permission to copy without fee all or part of this material i s granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.

© ACM

0002 - 0782 / 9 1 /0900 - 028 $ 1 . 5 0

September 1991 /Vol.34, No.9/COMMUNICATIONS OF THE ACM

-

--=-

New Version!

Carnegie Mellon University

Software Engineering Institute

SEI Conference on

Software Eimineering

mul/SR@{Q) LISP Language Programming Environment

Education Presentation Titles

Building Soft Ware for Hard Physics Medium Size Proj ect Model: Variations on a Theme A Controlled Software Maintenance Project Models for Undergraduate Courses in Software Engineering The Establishment of an Appropriate Software Engineering Training Program Industrial Training for Software Engineers Software Engineering: Graduate-Level Courses for AFI Professional Continuing Education Computing Curricula 1 99 1 : Its Implications for Software Engineering Education

Compact: Runs in as little as 256K, & can handle 500 pages of code in just 640K! Cost Effective: Only $ 400 for both the interpreter and compiler! Fast: Fastest (by about 3 times) LISP available for PC compatibles! Easy: Expanded manual and interactive tutorial get you moving! Powerful: Handles industrial and commercial projects with ease. One time, flat fee runtime system available, too!

Teaching Project Management Bottom Up

If you need to write efficient Artificial Intelligence software and are looking for the best LISP available for PCs, try muLISP-90.

Seven Lessons to Teach Design

System Requirements: Personal

Design Evolution: I mplications for Academia and Industry

computer running MS-DOS, PC-DOS, or PS / 2 operating system. Minimum 256K

Computer Based Systems Engineering Teaching Styles for Software Engineering

Teaching Software Design in the Fresi'lman Year Teaching Software Engineering for Real-Time Design Industrial-Strength CASE Tools for Software Engineering Classes What We Have Learned About Software Engineering Expertise Instruction for Software Engineering Expertise Knowledge Elicitation for Software Engineering Expertise

For registration information contact-

For Your PC Compatible Computer

Helen E. Joyce (412) 268-6504

Chairperson Jim Tomayko Managing Asst. Barbara Mattis

of memory and one diskette drive.

YEsf Please send me more information today. •

Address City

I 'd like to know more about muLISP.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_______

Company Position

State

____

Zip

_ _ _ _

_ _ _ _ _ _ _ _ _ _ _ _ _ _ �

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

CIRCLE 64 ON READER SERVICE CARD

rt:-:1 � /�!rdi��!u����

© 1991 Soft Warehouse, Inc.

(808) 734-5801 after noon PST Handcmfted software/or the mind.

KENNETH H. SINCLAIR DAVID A. MOON ny computer program has a conceptual essence of data models, relationships among data, and algorithms, deriving from the specific domain addressed by the pro­ gram. This conceptual essence can be represented for execution by a computer system in many ways, using a variety of programming languages. The role of a pro­ gramming language and its supporting environment is to span the gap between the conceptual essence of a program and those concepts supported directly by the computer. The means of spanning this gap and the style in which concepts are expressed vary sharply among languages, as dictated by the philosophies that guide each language. The conceptual gap between programs and the computers that run them is growing as computer applications become more ambitious and software becomes more complex, while the concepts embodied in processor architec­ tures remain more or less constant. The principal tool software designers have to close this gap is abstraction-the synthesis of ideas into coherent new vocabularies with which to express more profound ideas. The philosophy of Lisp is to cultivate a high degree of abstraction. It accomplishes this by blurring the arbitrary boundaries between the various computational mechanisms supported by computers, and by decoupling the vocabulary used to describe an abstraction from the mechanisms used to implement it. Lisp is a h i ghly malleable language that adapts and extends

with new abstractions to describe a program's conceptual essence. This article discusses Lisp's rendition of this philosophy, particularly its mechanisms for abstraction, and its resulting strengths and weaknesses as a programming language, and suggests applications for which it is therefore best suited. How Lisp Reflects Its Philosophy

A programming language brings three mechanisms to bear against software complexity [1]: Primitive expressions-the basic elements of state and the operations used to

create and manipulate them, Means of combination-by which compound computational models are built

from simpler ones, and Means of abstraction-by which compound computational models can be

named and manipulated as units. An effective programming language must provide a means of abstraction that can describe the essence of a compound computational model, and hide any spurious complexities introduced by a particular choice of primitive expressions or means of combination. Lisp provides this means of abstrac­ tion, in conjunction with primitive expressions and means of combination introducing minimal spurious complexities. Its underlying model of data and execution subdues the artificial complexities of the computer, and its uniform, extensible syntax provides the means of abstraction to best express the con­ ceptual essence of any computational model. In Lisp, A l l Data Is Represented as Manifestly Typed Objects

All values in Lisp are objects, all objects have identity, and all objects have manifest type, meaning that an object's type can be determined independent of any external context. Lisp objects correspond to domain (real world) objects, mathematical entities such as numbers, data structures such as lists or trees, or computer system objects such as characters or files. The type of an object defines what operations can be performed on the object, including operations that modify and retrieve state. Types can be, and usually are,

COMMUNICATIONS OF THE ACM/Scplcmbcr 1991 /Vol.34, No.9

defined by the user. Variables in Lisp are fundamen­ tally different from variables in most other languages. Lisp variables do not intrinsically have types; objects have types. The value of a variable is an object. There can be more than one reference to a given object, and assignment does not copy, it creates a new reference to the same object. This preserves the identity of the object and enables side effects per­ formed on one reference to be observed through other references to the same object. In most other languages, data types are associated with variables, not with values, and assigning the value of one variable to another copies the object, possibly converts its type, and loses its identity. The Lisp data model hides awk­ ward, dangerous details of the underlying computer a rch itecture from the application program. For example: • In Lisp one never has to declare the type of a variable. In general, most functions do not need to know the exact types of the objects they manipulate. The fact that multiple implementations of a given con­ ceptual type might exist is. a hidden detail. However, a type declaration limiting the range of objects that can be the value of a given variable is sometimes used for documenta­ tion or optimization. • All objects can be members of col­ lections. In Lisp it is not necessary to resort to special types that can be members of collections, nor special collections that can only have members of a specific type. • The data model supports references between objects with natural, safe primitives of the language, instead of resorting to the m achine-level concept of memory addresses or pointers. • The Lisp data model includes automatic storage management, eliminating the difficult, time­ consuming, and error-prone task of tracking the objects in use and explicitly identifying objects that

41

are no longer needed. Garbage collection provides the illusion of an object-oriented memory of practically infinite size. The gar­ bage collector isolates objects that cannot affect further computa­ tion (the garbage), and makes the storage used to represent them

any type : integer, floating point, rational, or complex. Some pro­ gramming languages provide for such polymorphic operations (par­ ticularly mixed-mode arithmetic) using the technique of overloading, in which the language compiler uses type information available to it

available for reuse. Lisp's mani­

to genernte specialized code for the

fest typing provides the informa­ tion needed to discriminate gar­ bage from valuable objects.

particular call. Some languages ever. allow programmers to define their own overloaded functions. In Lisp, however, generic functions discriminate between their operand types at run time, using the type in formation manifest in the oper­ and values. Thus, a compound function that operates on its argu­ ments with generic functions is au­ tomatically generic itself. Example I shows how Lisp's generic func­ tions eliminate the need to replicate computational methods for each type of data to be manipulated. This model of data and execu­ tion has been in Lisp since its incep­ tion. In the past 1 5 years, Lisp has been extended with object-based programming and object-oriented programming techniques [4, 6]. Object-based programming means convenient user-defined types and user-defined generic functions. It provides data abstraction and the ability to organize a program around a collection of object types and prescriptions for operations on those objects. Object-oriented pro­ gramming adds inheritance of structure and behavior to this, pro­ viding the ability to construct pro­ grams from a toolkit of parts and to define desired behavior as a modi­ fication of existing behavior, rather than starting from scratch.

lisp's Execution Model B l u rs the Boundary Between State and Behavior

Lisp expresses all computation in terms of the application of func­ tions to objects. A function receives zero or more objects as arguments, performs a computation, and re­ turns zero or more objects as re­ sults. Some functions are primi­ tives, which may be executed directly by the underlying language system. Compound functions ex­ press a given computational method in terms of the application of other functions to the arguments or other accessible state. A function may be named and applied within itself or other functions, to build procedural abstractions as in all but the most primitive programming languages. Lisp functions are also objects in the Lisp data model, and can there­ fore be treated as any other value: they can be passed as arguments, returned as results, or stored in any data structure whatsoever. And, of course, their type is manifest and may be determined at any time. This treatment of functions as first­ class objects in the data model sup­ ports higher-order control struc­ tures and more flexible combina­ Lisp Uses a Simple, Extendable tion of computational methods that Syntax may be expressed in static composi­ Lisp uses a simple, uniform syntax tions. It also forms the basis for that can be extended to better im­ data-directed programming tech­ plement a particular abstraction niques, in which computational with a minimum of irrelevant verbi­ methods are directly associated age. Every expression is written as a left parenthesis, an operator, zero with data to obviate searching. Lisp functions can be generic, or more operands, and a right pa­ which means they operate on multi­ renthesis. An operand can be an ple types of objects. For example, atom, which is a constant or vari­ the + function adds numbers of able name, or it can be another ex-

42

pression. This syntax is identical for all expressions; Lisp makes no syn­ tactic distinctions based on : • the origin of a given operator; whether it is defined in a library, recognized specially by the com­ piler, or part of an application makes no d i fference, • the usage of an operator; combi­ national expressions, procedure invocations, data references, and declarative assertions all look the same, • the level of abstraction involved; a given operator might represent a machine primitive or a high­ level construct. The Lisp program syntax is identi­ cal to the syntax used to represent one of its primary data structures­ the list-and indeed lists are the internal data structures used to represent source programs. This allows Lisp's native data and execu­ tion models to be used as a macro language to manipulate and extend its syntax. Macros are typically used to establish an appropriate context around a computational method, or as a convenient way to express a common idiom. Occasionally, mac­ ros are used to implement alternate languages wholesale, or to intro­ duce new language constructs to Lisp itself. Example 2 shows how the Lisp syntax may be extended with macros to better describe an application domain. Strengths of Lisp

Well-designed programs are com­ posed of many smaller intercon­ nected modules, each of which may be designed, implemented, and tested apart from the complexity of the whole. Some modules directly reflect some aspect of the applica­ tion's conceptual essence, others serve supporting roles. In either case, the implementation of a given module requires a certain precise blend of state and behavior, the exact details of which should be hidden from its clients through the use of abstraction. Lisp's manifest data types, generic functions, and

September 1991 /Vol.34, No.9/COMMUNICATIONS OF THE ACM

treatment of functions as first class objects minimize artificial complex­ ity in the interfaces between mod­ ules, and its uniform syntax isolates interface definitions from any im­ plementation techniques. Lisp Encourages Evolutionary Software Development

The modularity inherent in most Lisp programs frees different parts of the program to be written with differing degrees of attention to detail. A Lisp program can be quickly prototyped with simplistic

implementations of its various ab­ stractions; as the program evolves and the abstractions prove their merit, the early implementations are discarded and rewritten. Fur­ thermore, different portions of the program can be refined to varying degrees depending on their im por­ tance and the usual trade-offs be­ tween cost, risk, performance, and so forth . Several highly functional Lisp environments have been cre­ ated specifically to support this evo­ lutionary style of software develop­ ment and maintenance [8, 9].

COMMU NICATIONS OF T H E ACM/September 1991 /Vol.34, No.9

Lisp Encourages a Less Im perative Style of Progra m m i ng

Most contemporary computer pro­ grams are written in an imperative style, detailing the steps to be fol­ lowed in implementing any given procedure. At very high levels of abstraction, however, the character of a program becomes less impera­ tive and more declarative; the ab­ stractions coalesce to form a new language in which intent can be specified without reference to pro­ cedure. Indeed, a common tech­ nique for application development

43

in Lisp is to invent a high-level lan­ guage to describe the application domain, implement it using exten­ sions to Lisp's syntax and semantics, and then describe the bulk of the application in that language. Occa­ sionally, such embedded languages

take the form of formally declara­ tive languages, using techniques such as logic programming. Lisp Encourages the Development of Reusable Software

Lisp's generic functions and mani-

fest data types allow existing soft­ ware to be reused or extended for different purposes. Lisp;s abstrac­ tion capabilities and automatic stor­ age management allow the defini­ tion of simple interfaces between modules, free of implementation details. Often, Lisp applications take the form of a veneer of user­ interface or other specific capability layered on top of a large generic library. The same library is incor­ porated in other related applica­ tions. Some Lisp dialects, such as Com­ mon Lisp, provide a large library of data structures and algorithms use­ ful to many applications. M uch of the variation between Lisp dialects is variation in the scope and content of this library [3, 7]. Lisp Evolves to Meet New Demands

The Lisp language of the 1 990s is quite different from the Lisp lan­ guage of the 1 950s. The language has been standardized and refined through competitive and coopera­ tive processes similar to those of other languages; the result is that high-performance, robust imple­ mentations of compatible Lisp dia­ lects are available for a broad spec­ trum of computers. Beyond these developments, however, the lan­ guage itself has evolved, incorpo­ rating semantic refinements such as lexical scoping, and extensions such as the obj ect-oriented program­ ming frameworks. The evolution of Lisp is largely a result of the experimentation of its user community. Lisp's manifest data types and uniform syntax fos­ ter extensions both large and small, many of which survive the test of time to become part of the lan­ guage itself. weaknesses of Lisp

The syntactic and semantic devices that facilitate abstraction in Lisp can also obscure performance problems at the application level. The cost of any given construct is not manifest; it is impossible to tell

44

September 1991 /Vol.34, No.9/COMMUNICATIONS OF THE ACM

pert this is exploratory program­ ming, but for the beginner this can be "programming without think­ ing" that produces poorly orga­ nized programs. Current Lisp sys­ tems opt for maximum freedom and make little attempt to enforce good, modular, programming practice. Successful use of Lisp too often depends on who one's teacher was.

by looking at an expression whether it is a machine primitive or a compound operation, or whether its complexity is 0( I ) or O(N2) or higher. Understanding the perfor­ mance implications of a Lisp pro­ gram requires understanding the program in a deeper way, and at a lower level of abstraction, than sim­ ply understanding what a Lisp pro­ gram does. This fact often com­ bines with inadequate metering tools and training to produce sig­ nificant inefficiencies in otherwise well-implemented software. On the other hand, better abstraction can also improve efficiency by fostering better algorithms. Most modern Lisp implementa­ tions are based on production qual­ ity compilers capable of exploiting the underlying processor architec­ ture as well as compilers for any

Some of the evolutionary changes in the Lisp language and its usage, particularly those introduced over the last decade, have not been pro­ mulgated throughout the user community. This is a phenomenon common to many older program­ ming languages and indeed to some other engineering disciplines. Ex­

other language. The performance

acerbati n g the problem are some

problems incurred by the original Lisp interpreters are no longer an issue.

Lisp textbooks that present the lan­ guage as it was defined and applied earlier in its life. Many program­ mers are not comfortable with the high degree of abstraction found in good Lisp programs.

Lisp I m plementations have a History of Poor Interoperability

The technical differences between Lisp's manifest typing and the com­ pile-time-type checking prevalent in other languages have led to poor interoperability between Lisp and other languages and environments. However, increased investment in interoperability over the past few years has yielded good results in the areas of user interface and net­ working. Products are also available that support good general integra­ tion between Lisp and other lan­ guages. However this area has not yet been standardized. Lisp Does Not E nforce Good Progra m ming Practices

Lisp provides a broad palette of data structures, algorithms, and program-structuring techniques. There are often several ways to ac­ complish a task-an asset in the hands of an expert programmer, but overwhelming to the beginner. I ncremental development allows coding to begin before the whole program is designed. For the ex-

Obsolete and Undisciplined Practices Persist

conclusion

The conceptual gap between pro­ grams and the computers that run them is growing as computer appli­ cations become more ambitious and software becomes more complex. To span this gap, an effective pro­ gramming language must provide a means of abstraction that can de­ scribe the essence of a compound computational model, hiding any spurious complexities introduced by a particular choice of primitive expressions or means of combina­ tion. Lisp provides such means of abstraction. I ts manifestly typed data model subdues the artificial complexities of the computer. Its uniform syntax, which makes no distinctions based on the origin, usage, or implementation of a given operator, provides the information hiding needed to effectively define abstract interfaces. These capabili­ ties combine to make Lisp a highly malleable language that adapts and extends with new abstractions

COMMUNICATIONS OF THE ACM/September 1991 /Vol.34, No.9

suited to the task at hand. Distinctly different philosophies are possible. Consider these simpli­ fied statements of the philosophies of a few other programming lan­ guages: expedites the construction and maintenance of enormous real-time systems by large organi­ zations. • A P L offers a programmable desk calculator for array-orient�d computations using familiar mathematical notation. • C provides direct access to com­ puter hardware in a portable fashion and strives for highly predictable performance. • HyperTaik empowers inexperi­ enced programmers to quickly construct or customize interactive applications.

•

Ada

A programming language best serves a software project when the language's strengths and philoso­ phy closely match the needs of the project. Lisp's primitive mecha­ nisms and abstraction techniques support the evolutionary develop­ ment and refinement of modular, reusable software, making Lisp particularly well suited for applica­ tions characterized by: • Uncertain or continually evolving functional requirements; • Very complex or ground-break­ ing domains, where simply de­ scribing the conceptual essence of the application is a major chal­ lenge; and • Low-to-medium deployment vol­ ume, where· the development process dominates the economic considerations of the project. Lisp is by no means the solution to all programming problems. The high degree of abstraction obscures implementation details, allowing inefficient programming to pass unnoticed. Abstraction is often abused by inexperienced program­ mers, but current Lisp systems make little attempt to enforce good programming practices. Some situ­ ations for which these weaknesses make Lisp less suitable than other

45

languages include: • Applications of computers that require careful exploitation of much of the complexities and constraints of a given computer system; • Projects of a hundred or more p rogrammer s that require very careful control over the program­ mers and their mutual interac­ tions. The exciting, path-breaking ap­ plications of the early 1 980s were written in assembly language, be­ cause they had to work on small, slow machines and what they did was pretty simple (word processing, spreadsheets, video games). The exotmg, path-breaking applica­ tions of the late 1 980s were written in C and other higher-level lan­ guages, because they were bigger, more complex, and needed to be written in a language that sheltered the programmer from more irrele­ vant details. At the same time, the hardware evolved to the point where such languages became prac­ tical. Each generation of application is more complex than the previous generation, and the time available for its development is shorter. Sim­ ply describing the conceptual es­ sence of the next generation of applications will be a major chal­ lenge, and will place a premium on the language's abstraction capabil­ ity. H and-crafting software at low levels of abstraction will be a luxury appropriate only for carefully se­ lected portions of the program. These trends suggest the excit­ ing, path-breaking applications of the 1 990s will be written wholly or partially in Lisp. That a program­ ming language invented in the 1 950s has something important to contribute to the applications of the 1 990s is a tribute to the language's flexibility and capacity for evolu­ tion . 13 References 1. Abelson, H . and Sussman, G.J. Struc­ ture and Interpretation of Computer Pro­ grams. The M I T Press, Cambridge,

46

(Aug. 1 977), 564-576.

Mass., 1 985.

2. Brooks, F.P. Jr. No silver bullet: Es­ sence and accidents of software engi­

6. Moon, D.A. The Common Lisp ob­ ject-oriented programming language

neering. IEEE Comput. (Apr. 1 987), 1 0-20.

3. Haynes, C.T. I EEE Standard for the scheme

programming

I EEE Std

1 1 78- 1 990,

language, Institute of

Electrical and Electronic Engineers, I nc., N . Y . , N . Y., 1 99 1 . in

Common

Wesley, Reading, Mass., 1 988.

5. Liskov, B . et al. Abstraction mecha­

Concepts,

Applications.

ACM

7. Steele, G.L. Jr. Common Lisp: the Lan­ guage. Digital Press, Bedford, Mass.,

1 990.

8. Teitelman, W. and Masinter, L. The l n terlisp programming experience.

Addison­

Lisp.

Object-Oriented and

Press, N .Y., N .Y., 1 989, pp 49-78.

4. Keene, S.E. Object-Oriented Program­ ming

standard. Databases,

IEEE Comput. (Apr. 1 983).

9. Walker, J . H . et al. The Symbolics Genera programming environment. IEEE Softw. (Nov. 1 987), 36-44.

nisms in C L U . Commun. ACM 20, 8

The Meta l system ------- onve•

S

iemens Nixdorf Informa­ tion Systems has created a machine

translation

GaJek .. .----------... •

sys­

now processed by the deformattin g programs.

tem called Metal that sup­

ports the following

The text in its native file format is These

separate

textual

from formatti ng information which

language pairs:

is saved in a formatting template.

German- English; English -German; Ger­

The textua l information is then sepa­

man-Spanish;

French -Dutch;

Dutch­

French. (Work on other language pairs is u nderway.l

•

The system is cu rrently deployed in a

rated into translation u n its. The file with the text to be translated is processed by the preanalvze mod­ ule running on the Lisp server which

scans the text for lexical ite ms that

network configuration consisting of a U n ix m u ltiuser system networked to a

are not contained in the lexico n . The

special-pu rpose Lisp machine as trans­

user will then provide the missing

lation server. Implementations of the

terms on the Lisp server, using the

server component o n general-purpose U n ix workstations are cu rrently under investigation.

interactive coding tool tntercoder. •

The Lisp appl ication consists of ap­ proximately 1 00K l ines of code Lisp

an

extensive

which

operates

as

a

user receives a notification when the text has been translated and sent

database of grammar

guage and the generation of the ap­

translation,

batch process on the Lisp server. The

code, extensive lexical databases, and

rules for ana lysis of the sou rce lan­

The file can then be subm itted for

•

propriate target language structu res.

back to the U n ix machine. The user can now postedit the text file, using the Metal editor M E D . This operation is typically performed at

The Metal system provides automated

this stage because the textfile con­

support for the translation process. Its

tains all the information that is rele­

translation methods typically proceed •

in the following steps: •

Acq u iring the text. which must be made available to the U n ix system via file transfer from another machine, network

•

access,

optical

character

reader. or an editor. The user then assigns certa in param­ eters to the text. such as language

vant for the postediting process. The text is then reformatted. The textual information is merged back into the formatting template to gen­ erate a translated text in the native file format of the relevant text sys­ tem. This text now contains the same logical and layout structure as the input document.

d i rection. priority of the translation job, tech nical subject a reas or which

The Lisp Advantage

Lisp server to translate the text.

The properties that set Lisp apart from

etc . . . .

the more traditional prog ram ming Ian-

September 1991 /Vol.34, No.9/COMMUNICATIONS OF T H E ACM

management and helpful software de­

CR Categories and Subject Descrip­ tors: D. 1 .5 [Programming Techniques]:

About the Authors: KENNETH H. SINCLAIR

Object-oriented

D.2.6

of the technical staff at Object Design,

dress:

Programming

Inc. His research interests include ad­ ' va nced storage management techniques

bridge, MA 02 1 42 , moon@cambridge.

Programming;

[Software Engineering]:

Environments-interactive; D.2.m

ware

Engineering]:

Miscellaneous­

rapid /1rototyping; D . 3 . 2

Languages]:

[Programming

Language Classifications­

extensible language; D.3.3

Languages]:

[Soft­

[Programming

Language Constructs and

Features

General Terms: Languages Additional Key Words and Phrases:

is a member

and object-oriented databases.

Author's

Object Design, One

Present Address:

New England Executive Park, Burling­ ton, MA 0 1 803, [email protected].

DAVID A. MOON is tist

at

Apple

a consulting scien­

Computer's

Advanced

Technology Group, where he works on

Abstraction, automatic storage manage­

advanced dynamic languages and ob­

ment, evolutionary software develop­

ject-based systems. His other research

ment, garbage collection, Lisp

interests

include

automatic

velopment tools.

Author's Present Ad­

238 Main St., Suite 20 I , Cam­

apple.com.

Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.

storage

© ACM

0002-0782/91/0900-040 $1.50

guages have been the rationale behind

The primary consumer of data stor­

deallocation of storage is remin iscent

our decision to use Lisp as an imple­

age in the Metal appl ication is the pars­

of the techniques necessary in sta n ­

mentation language. Some of these

ing

d a r d prog ramming languages. The Lisp

features include the following:

guage input is syntactica lly analyzed.

language offers an advantage, how­

Since there is a great amount of local

ever: these optimizations can be imple­

ambiguity in natural-language analysis,

mented gradually once the system

this process is essentially nondeter­ min istic. This storage behavior of allo­

behavior is fully im plemented therefore well understood.

Programs are Data: Lisp lends itself par­ ticularly well to applications in which code is constructed a nd manipu lated by programs. Lin g uists use a specia l ­ pu rpose prog ra mming

language for

grammar rules. This language allows the grammar writer to express the in­ structions and control and iteration constructs that are appropriate for the appl ication in a straig htforward way. The rule texts are translated into or­ dinary Lisp code by the rule compiler. The Lisp compiler then compiles them into efficient machine code. The rule compiler also performs a variety of application-specific operations on the rule text, including warnings for obso­ lete usage, code instrumentation for metering, traci ng, stepping and de­ bugging, and program optimization.

process. where the sou rce lan­

cating and dea llocating temporary syn­ tactic structures varies nonpredictably with the complexity of the i n put. Be­ cause prog rammers do not have to worry about providing explicit control for the storage behavior. they have been able to opti mize the algorithms for g u id i ng the parsing process to a great degree. These temporary structures a re also very short-lived. Therefore. they are handled efficiently by the ephemeral or generation-scavenging garbage collec­ tion mechanism su pported by current Lisp

im plementations.

These

ap­

proaches avoid subjecting the com­ plete Lisp add ress space to regular gar­

Large Address Space: Natural-language

bage

programs typically require a large ad­

freq uent and uni ntrusive collections of

dress space for storing the static and

the recently active portion of the ad­

dynamic data that are used. Lisp sys­

dress space. Since these areas are likely

tems on Lisp machines su pport large

to be i n physical memory, each collec­

address space appl ications very effi ­

tion phase will be very efficient.

ciently. This makes it possible to store

To

collections

maximize

by

the

performing

efficiency

of

a l l static data-including rule texts. rule

ephemeral or generation-scavenging

programs. lexical databases in virtual

garbage collection. the program main­

memory-thereby avoiding the soft­

tains a pool of commonly used re­

ware complexity of external or com­

sources. These contain list cells of vari­

pacted data representation and data­

ous

base management. Storage

Management:

that

are

used

often

to

represent core data structures such as Lisp

systems

offer automatic allocation and recla­ mation of data storage. This relieves the application progra mmer from i m ­ plementing highly error-prone storage management routines.

sizes

syntactic features and values and syn­ tactic tree structures. Since text is translated sentence by sentence, these temporary pools can be reset after

and

User Interfaces: Metal offers a very sophisticated

user interface for the

coding of lexical entries as part of the Metal syste m . This a llows nonexpert users to augment the lexical databases without requiring expert knowledge. As part of the i n - house development environment. there is a collection of programs that aid the linguist in the development of the linguistic data­ bases. These include user interfaces for tracing and stepping g ra m m a r rules. examining the current state of the sys­ tem for debugging, special rule and lexicon editors, database maintenance tools for version control and config u ­ ration and

management,

di rect

g raphic display

manipu lation for syntax

trees. nodes. and featu res. These advanced tools benefit from the high-level user interface su pport available in Common Lisp. They a re now im plemented

in Symbolics's Genera.

making extensive use of the mixed­ mode command- and

presentation­

based user interface paradig m . () OLIVER GAJEK is project manager for solt­ ware development at Siemens N ixdorf Infor­ mation Systeme AG in Munich, Germany. His cu rrent research i nterests revolve around natural-language processing. Present Ad· dress: Siemens Nixdorf lnformationssys­ teme AG, Otto-Hahn-Ring 6, W-8000 Munich 83, Germany.

every sentence. Of course, the explicit al location and

COMMUNICATIONS OF THE ACM/September 1991 /Vol.31�, No.9

Unix is a registered trademark of UNIX Sys­ tem Laboratories. Inc.

47

D. KEVIN LAYER CHRIS RICHARDSON isp was designed by John McCarthy and implemented in the late 1950s at MIT Designed to manipulate symbolic rather than numeric data, Lisp became very popular with the research community, especially in the fields of artificial intelligence and computer-aided design. Programming in Lisp includes the following benefits: •

Lisp provides an interactive program development environment; • Lisp allows incremental compilation; • Lisp provides automatic memory management; and • Lisp is an extensible language, allowing application­ specific customization. Over the past 30 years a variety of Lisp dialects have been developed, including MacLisp [22], ZetaLisp [36], Franz Lisp [10], Portable Standard Lisp [14] and InterLisp [34] to mention just a few. The latest dialect of Lisp­ Common Lisp [31]-is in the process of being standardized by the ANSI sub­ committee X3J13. (The standard has gone through many stages of review and is now being written in specification form.) Common Lisp is very dif­ ferent from the original version of Lisp and is a rich, sophisticated language providing functional, imperative, and object-oriented programming. Lisp was originally implemented on an IBM 709. The first high­ performance Lisp implementation was MacLisp on a PDP-10 [30] with special-purpose Lisp machines developed during the 1970s at MIT and Xerox PARC to follow. Lisp machines provide hardware support for Lisp and can run large applications effectively. They became commercially available during the late 1970s and early 1980s and offered high-productivity programming environments which are unsurpassed in terms of their richness and sophistica­ tion even today. The mid-1980s saw the development of high-performance Lisp systems on stock hardware, and today Lisp has been implemented effi­ ciently on workstations, personal computers and mainframes. This article describes the features that can be found in a modern Com­ mon Lisp system-including programming environments, object-oriented language extensions, integration with programs written in other langauges, and a method for delivery of applications written in Lisp. Additionally, this article outlines some of the possible future developments of Lisp which include: • programming environments on general-purpose hardware that surpass those on Lisp Machines; • Lisp compilers that further exploit efficient compilation strategies for RISC processors; • garbage collection schemes that will benefit from hardware support for fast user-accessible traps; • a pioneering role for Lisp in object-oriented programming design due to the flexibility and extensibility of Common Lisp Object System (CLOS); • delivery strategies in which Lisp applications can be deployed on small­ memory machines; • even tighter integration between C and Lisp, allowing programmers to write and debug C programs in the Lisp environment more easily and, more important, making it easier to use Lisp in a predominantly non­ Lisp-based environment; • continued development of window systems and graphical user interfaces, especially in the area of integration with the window toolkits now becom­ ing available. The Lisp Programming Environment

Traditionally, a Lisp system consists of both an implementation of the

COMMUNICATIONS OF THE ACM/September 1991 /Vol.34, No.9

language and an interactive program development environment. Pro­ grams are written by extending the system with definitions of new fimc­ tions and other program parts. The basic method of in teraction is through a read-eval-print loop, com­ monly called a top level, that reads user input and converts it into a Lisp expression, evaluates the expression, then prints the result of the evalua­ tion. By using the top level, program­ mers can evaluate expressions that create new definitions, and then evaluate expressions that use those definitions. Since Lisp is interactive, program development is not slowed by the edit-compile-link-run cycle typical of conventional languages. Redefining a function has an immediate effect. Since there is no notion of a main program, individual functions can be tested by ru nning them without hav­ ing to write a test driver. In most Lisp systems, interpreted and compiled definitions can be freely mixed. In addition to enabling programmers to evaluate expressions, the top level typically contains special commands to make the task of interacting with Lisp easier. For example, there are commands to retrieve previous com­ mands and to interface with the operating system. The top level also provides a debugger. Lisp has a unique debugging environment because of the interac­ tive nature of the language, the existence of dynamic typing, and the language support for error handling. The C o m m o n Lisp C o ndition System provides facilities for signal­ ing errors and for establishing error handlers and restart points within the program. In Common Lisp, an error is signaled by calling the function error with arguments describing the error. This function searches for error handlers, which have dynamic scope, and if none are found it recur­ sively invokes the top level. Within the top level, the programmer can use debugger commands to examine and modify the state of the program. These commands can print the stack of active function call frames, allow access to lexical variables, change the

49

values of lexical variables, abort the execution of the program, and return to the original top level or one created by a previous error. A valuable part of the Lisp de­ bugging environment is the ability to continue from errors during program execution. Debuggers typically provide commands to: • restart arbitrary functions on the run-time stack, possibly with dif­ ferent arguments. For example, from within the debugger, pro­ grammers can redefine the func­ tion containing the error and then restart the call to that func­ tion. • return a value from a call to a function to provide the illusion that the function had returned normally. This might occur after the programmer determines the correct value interactively. • invoke restarts, i.e., continuation points, specified by the program itself. I f a program has estab­ lished restarts, then the debugger presents them to the program­ mer. This provides programmers with a convenient way to resume execution of a program. This facility for resuming execution

after an error has occurred or re­ turning from arbitrary functions is an extremely useful tool during the debugging of a program, and can save the programmer a significant amount of time (for example, the time spent re-running the program to reproduce the same conditions under which the failure occurred). In fact, the situation can be much worse with conventional languages­ sometimes all there is to examine is a memory dump of the program at the point of failure. Other typical Lisp debugging tools include: • a trace facility that enables pro­ grammers to temporarily modify a function definition by execut­ ing code on entry to and on exit f from the function. Common uses of tracing include printing out argument and return values, and set ting conditional breakpoints; • the ability to invoke the debugger when a particular invocation of a function returns; • a stepper, which allows the exe­ cution of programs, one form at a time, so that arbitrary forms can be evaluated during the execu­ tion of a program; and • an inspector that enables pro-

In most Lisp systems, interpreted

grammers to examine and mod­ ify data structures created by their program. While debugging environments vary from implementation to im­ plementation, affected particularly by whether a window system is available, the common thread is the dynamic nature in which Lisp pro­ grams are put together. Also important to the program development environment are tools that track the static program struc­ ture. There are three main aspects to this : source file recording, cross referencing and dependency main­ tenance. Source file recording maintains a database of the loca­ tions of program parts. A similar facility is the cross referencer, which maintains a database of the usage of functions and variables within a program. Programmers can then query these databases to find out about the structure of their programs. Dependency mainte­ nance facilities allow programmers to define systems that are sets of files and dependencies between the files that determine order of compila­ tion and loading. Currently, the smallest unit of compilation and loading is a file; but in the future, more finely grained dependency analysis will allow the unit to be in­ dividual program parts, such as functions or macros. While programmers can use the top level to construct programs, it is usually more convenient to use an editor. Lisp program development environments typically use either a structure editor or a text editor. A structure editor manipulates the underlying in-memory data struc­ tures and displays a nicely format­ ted, printed representation. A mechanism is provided for generat­ ing text files which are used for long-term storage and for commu­ nication. Xerox Lisp machines [34]

and uompiled definitions 50

September 1991 /Vol.34, No.9/COMMUNICATIONS OF THE ACM

use structure editors. Most other Lisp programming environments provide a text editor, typically the Emacs programmable editor [29] or some derivative. Emacs has a thorough knowledge of Lisp syntax and provides a set of commands oriented toward Lisp. Some programming environments, such as the one on the Symbolics Lisp Machine [35], have an in-Lisp implementation of Emacs. In other programming environments, such as Allegro Common Lisp [ 1 1 ] , Lisp and Emacs run as separate pro­ cesses using high-bandwidth inter­ process communication mecha­ nisms. When Emacs and Lisp are closely integrated, Emacs can query the Lisp environment and Lisp can it­ self process the contents of Emacs buffers. For example, within the edito1· programmers can: •

query the Lisp system to obtain argument list information or the documentation for a function; • verify or complete the names of symbols; • evaluate or compile the defini­ tions in all or part of an editor buffer; • evaluate, compile, or list the pro­ gram parts which have changed with respect to the Lisp environ­ ment during the normal course of editing; • find the source code· of a pro­ gram part; and •

find the source code for each of the callers of a particular func­ tion.

Programming productivity is further enhanced by window-based interfaces. Facilities provided by such an interface include: •

browsers for graphically display­ ing some aspects of program structure such as a call graph or a class hierarchy. Clicking the

mouse on a node in a graph will typically perform an operation on the program part that it repre­ sents, such as displaying the source code in an editor window; • graphical time and space profil­ ers that display the dynamic call graph annotated with profiling information; • tools for displaying and modify­ ing data structures; and • windowized versions of the de­ bugger and the top level. The following features are typi­ cally found only on Lisp machines, but during the 1 990s will be imple­ mented on stock-general-pur­ pose-hardware. Source-level debugging. This allows the close association of the execut­ able representation of the program with source text, which enables the state of the program to be p1·e­ sented in terms of the original source program. An example of this assoc1at1on is highlighting source code fragments from within the debugger to show the location of an error. Furthermore, from within the editor, programmers can set breakpoints at specific locations in a function and can evaluate ex­ pressions in an appropriate con­ text. Context and mouse-sensitive input. The Symbolics Genera program­ ming environment makes use of the features in the underlying window­ ing systems that enable program­ mers to manipulate objects by mousing on their printed represen­ tation. For example, objects can be inspected or described or incorpo­ rated into new expressions. The Common Lisp I nterface Manager (CU M ) [26], described later, pro­ vides many of the features of the Symbolics window system on stock hardware and enables stock hard­ ware environments to have similar user interfaces.

uan be freely mixed. COMMUNICATIONS OF THE ACM/September 1991 /Vol.34, No.9

Watchpoints. Some conventional language debuggers and Lisp ma­ chines allow a particular memory location to be monitored and notifi­ cation given when the location is changed. ln Lisp, the availability of hardware and operating-system support on general-purpose ma­ chines will allow Lisp systems to offer this capability without incur­ ring a significant loss in perfor­ mance. In fact, the nature of Lisp would suggest there are other quantities beside memory locations that could be watched: the value of a variable for both read and write accesses, the property list of a sym­ bol, and activity on a particular I/O stream. The ability to watch these various quantities would be a very useful debugging tool. Issues in Implementing Lisp Efficiently on Stock Hardware

High-performance Lisp on stock hardware requires efficient imple­ mentation of dynamic typing, over­ loaded functions and garbage col­ lection. Here we describe how dynamic typing and function overloading can be implemented efficiently and show that some hardware support could increase performance signifi­ cantly in some situations. We then describe strategies for garbage col­ lection on stock hardware and dis­ cuss how that can also benefit from minimal hardware support. Lisp is a dynamically typed lan­ guage. Types are associated with values rather than with variables. Additionally, many of the functions in Lisp are overloaded. For instance, the function + can accept as argu­ ments any combination of small in­ tegers, large integers, single-floats, double-floats, ratios, and complex numbers. U nlike statically typed languages where the resolution of overloading takes place at compile time, in Lisp it occurs at run time. On stock hardware, dynamic typ­ ing can be eliminated in the pres­ ence of declarations that tell the compiler about the types of variable values, expression results and func­ tion signatures. These declarations

51

take the form of a promise to the compiler that these quantities will be of a particular type, and when possible this type information is propagated from the use of such declarations. Since Lisp machines provide hardware support for Lisp, compi­ lation is relatively straightforward: the instruction set closely matches the language, and type checking and dispatching are supported in hardware and microcode. For ex­ ample, a call to the same generic function + is compiled to a ma­ chine instruction that uses a combi­ nation of hardware and microcode to efficiently dispatch to the correct code based on the types of its argu­ ments. In addition, Lisp machines have a stack architecture, so regis­ ter allocation is not an issue. In contrast, stock hardware Lisp compilers have to perform efficient register allocation and must emit machine instructions to perform type checking and dispatching when declarations are not present. This means that a call to the function + compiles into many machine instructions. The situation is made worse because for effi­ ciency the case where + is called with small integers is usually han­ dled in line and the generalized version is only called for non-small­ integer arguments. For example, on the SPARC processor [32], a call to + with no type information given could easily expand to 1 2 machine instructions to perform the addition. The resulting code runs quite fast, but is much less compact than its Lisp machine counterpart. However, when both arguments and the result of a call to the function + are declared to be small integers, the resulting SPARC machine code is one machine in­ struction. Stock hardware Lisp compilers use state-of-the-art compiler tech­ nology in instruction scheduling and register allocation. Such com­ pilers can generate code on RISC­ based workstations that competes favorably with code generated by compilers for conventional Ian-

52

guages such as C. While Lisp runs well on stock hardware today, further hardware support can improve its perfor­ mance. The SPARC chip already provides some support for Lisp in the form of tagged add and sub­ tract instructions. The SPARC tagged add instruction combines into one instruction the test for whether both arguments are of the Lisp data type small integer and the computation of the sum of the two values. The instruction can either trap if one of the operands is not a small integer, or merely set a flag. This reduces our 1 2 instructions needed to implement + to about 9 machine instructions. If the argu­ ments are both small integers (the typical case) only 2 of the 9 instruc­ tions are executed. Additionally, Johnson [ 1 6] has shown that many RISC architec­ tures have the potential for further hardware assistance for Lisp at a very low design and implementa­ tion cost. If fast user accessible traps on RISC hardware existed, then various operations could be implemented in fewer instructions by trapping when an unusual con­ dition is detected. For example, expensive type checking on arith­ metic operations, whose operands are very often integers [28], can be eliminated if fast traps are taken when the unusual condition is the operand is not an integer. Therefore, the tagged add instruction could invoke a trap handler making a sin­ gle SPARC instruction do either the integer addition or trap to perform the generic addition. The code would be both fast and safe. Johnson estimates the cost in additional CPU logic of implement­ ing fast traps is only about 1 .6% in the case of SPARC, while the in­ crease in performance for some Lisp programs could be as much as 35%. Another technique to be ex­ ploited is interprocedural compiler optimization, where knowledge of the properties of a function, such as argument and result type, are used across function boundaries. Cur-

rent compilers use global and lexi­ cal declaration to optimize the allo­ cation and access of variables within a function. Information such as the declared types of a function's argu­ ments could be used to efficiently pass the arguments to the function -allowing, for example, stack allo­ cation rather than heap allocation for certain types of arguments and resulting in better locality of refer­ ence. Interprocedural optimization in Lisp is more difficult than in other languages because Lisp allows any function to be redefined at any time. However, there are many applications where increased per­ formance at the expense of ease of redefinition would be worthwhile. It should also be possible for the program development environ­ ment to keep track of where as­ sumptions about a function's prop­ erties were made and to force recompilation of any callers when redefinition violates the assump­ tions. Garbage Collectlon

Automatic storage management has always differentiated Lisp from conventional static languages. All Lisp systems contain a garbage col­ lector that provides automatic memory management allowing the reuse of memory occupied by ob­ jects that are no longer accessible. Two common sources of program­ ming errors in conventional lan­ guages where dynamically allocated objects must be explicitly freed are: dangling references (an object is freed when it should not be) and storage leaks (an object is not freed when it should be). Automatic memory management greatly sim­ plifies code that manipulates com­ plex data structures and ensures that neither of these two errors can occur. Large sophisticated Lisp applica­ tions often have a process virtual memory size larger than the physi­ cal memory of the machine on which they run. Consequently, it is important that the memory refer­ ences performed during the execu­ tion of these programs have good

September 1991/Vol.34, No.9/COMMUNICATIONS OF THE ACM

locality of reference. Since no Lisp implementation wants to preempt an interactive program with a gar­ bage collection, the duration of a garbage collection must also be short. A variety of garbage collection algorithms have been developed and the two most important are copying and mark-and-sweep. There are two types of copying gar­ bage collectors: stop-and-copy (where the execution of the pro­ gram is suspended while garbage collection occurs) and incremental copying [6] (where the executing of garbage collector and the program are interleaved). Both copying and mark-and-sweep techniques deter­ mine the set of objects that are ac­ cessible by the program by tracing pointers starting from a set of roots, or known live objects. Modern Lisp systems use either of the above techniques or a combi­ nation of both. In addition, many Lisp systems are further refined to use generation-based garbage col­ lection [20], since empirical studies have shown that most objects have either very short or long lifetimes. Furthermore, generational garbage collection works by grouping ob­ jects according to their age (i.e. , how many garbage collections they have survived). The groups are really memory pools called genera­ tions. Collection within a genera­ tion is usually either mark-and­ sweep or stop-and-copy. Objects are allocated in the first generation and are promoted to the next­ higher generation when they sur­ vive some number of garbage col­ lections. Often, only the first, smaller, generation is automatically collected, and hence garbage collec­ tions are short and well behaved. When a generation is garbage collected, the set of roots include those objects in older generations that contain pointers into the newer generation. Intergenerational ref­ erences must be updated if garbage collection moves an object, as hap­ pens with stop-and-copy and some mark-and-sweep garbage collec­ tors. Consequently, generation gar-

bage collection requires that refer­ ences from an object in an old generation to an object in newer generation be recorded. This re­ quires that every write into the heap be checked. On a Lisp ma­ chine this write barrier, as it is called, is implemented efficiently in hard­ ware. On stock hardware this check is done in software, which adds an execution time overhead and in­ creases the size of the code. Fortu­ nately for the majority of applica­ tions, the frequency of stores is such that overhead of this check is typically 1 0% [23] . Stock hardware Lisps use gener­ ational versions of mark-and-sweep or stop-and-copy, and Zorn [37] has shown the performance of both styles to be quite similar. In con­ trast, Lisp Machines use the far more efficient technique of incre­ mental copying. However, it re­ quires that every reference to the heap by the program is checked (this is called a read barrier) to see whether it is an out-of-date refer­ ence to an object that has been moved. On Lisp machines, this read barrier is implemented in hardware and microcode. Additionally, some Lisp machines use a read barrier to separate live-but-unused objects from objects that are actively being referenced by the program, and greatly improving the locality of reference for data being used [9] . Without the fast trap discussed earlier, the incremental garbage collection technique cannot be used on stock hardware because a soft­ ware read barrier would impose an unacceptably high overhead (ap­ proximately 50%) to running pro­ grams. On stock hardware, imple­ menting a read barrier requires support from the virtual memory system to trap on memory accesses [3], and fast traps [ 1 7] to make it efficient. The hardware modifications proposed by Johnson will benefit not only Lisp, but also full imple­ mentations of IEEE floating-point and any program that needs traps to be fast. Anderson [ l ] also con­ cluded that general-purpose work-

COMMUNICATIONS OF THE ACM/September 1991 /Vol.34, No.9

station performance would be im­ proved by faster traps. Broad benefits in Lisp and other lan­ guages, coupled with small imple­ mentation cost, lead us to believe the hardware modifications for fast traps will eventually show up in general-purpose RISC processors. Object-Oriented Programming

Object-oriented programming has been accepted as a mainstream method of program development. While Smalltalk [ 1 3] was the first object-oriented system to be widely used, early dialects of Lisp also sup­ ported object-oriented program­ ming. Two early Lisp-based object­ oriented programming systems were Flavors, developed at M IT [8], and Loops, developed at Xerox PARC. Loops and Flavors allow programmers to define classes and methods and both attempt to unify object-oriented and functional pro­ gramming while extending Lisp to support message passing. As in Smalltalk, methods are invoked by sending a message to an instance of a class by using a send primitive. Fla­ vors and Loops have always sup­ ported multiple inheritance-a characteristic only recently added to Smalltalk. An important feature of Loops is the ability of programs to manipulate classes and methods as data. In recent versions of Fla­ vors, message sending was replaced by generic functions, which are a form of overloading. Flavors has been implemented efficiently on both Lisp machines and stock hard­ ware and has been in wide use for many years. The latest object-oriented exten­ sion to Lisp is CLOS [7], which is the culmination of many years of research and experience in object­ oriented programming use and design and draws heavily from Fla­ vors and Loops. Furthermore, it attempts to integrate the Common Lisp type system with classes. The components of a CLOS program­ classes, generic functions and methods (the so-called meta-ob­ jects)-are themselves instances of classes. That is, every class is an in-

5!

Tree shaking eliminates what stance of some metaclass. CLOS provides a metaobject protocol that programmers use to extend CLOS by defining new metaclasses and methods specialized on them. The metaobject protocol makes CLOS an ideal tool for exploration of new ideas in object-oriented pro­ gramming. C/Lisp Integration

Each computer language has its advantages and disadvantages, and no single language is right for the implementation of all applications. C is popular due to its wide avail­ ability (being the implementation language of the popular Unix op­ eration system), and C's low-level orientation has won over a large number of assembler language pro­ grammers. In order to be usable in a computing environment that is dominated by non-Lisp languages, it is vital that Lisp programmers can access non-Lisp-based resources such as libraries and operating sys­ tem interfaces. To this end, the in­ tegration provided on Lisp ma­ chines allows remote procedure calls from Lisp to programs on ar­ bitrary hosts, as well as compilers for languages other than Lisp. I n contrast, Lisp systems o n stock hardware typically provide a foreign function interface that allows for­ eign code to be dynamically loaded and linked into the Lisp system. This enables Lisp applications to call user-written and library foreign routines and access data that was created for foreign functions, and enables foreign functions to access data created by Lisp and to call ar­ bitrary Lisp functions. But there is much work to be done to make the use of foreign code as natural as native Lisp code. Among the ideas for improving the interface are: • allowing foreign code to be de­ bugged within Lisp. Once foreign code is loaded into the Lisp envi-

54

ronment, there should be an easy way to debug both the foreign and Lisp code. Typical C debug­ gers, such as dbx and gdb, do not understand the structure of Lisp, and most Lisp debuggers do not understand C. While it would be hard to get C debuggers to un­ derstand Lisp, it would be quite straightforward to get Lisp de­ buggers to understand C. • being able to debug within Lisp multiply threaded foreign code. As threads, or lightweight pro­ cesses, become more available and popular, their use will need to be integrated into current Lisp environments containing their own thread implementations. An interface to programming in a environment multithreaded needs to be developed as these foreign libraries become more common. • allowing better sharing of data between Lisp and C. Many Lisp implementations on stock hard­ ware already have support for the sharing of data structures be­ tween Lisp and C. To make com­ plex applications useful in the Lisp environment, however, a much more seamless integration must be achieved. For example, garbage collectors often move objects, and that can be trouble­ some in the presence of C func­ tions which expect data not to move and so cache pointers to objects. This is fine for many types of applications and development. However, compilers for conven­ tional languages produce object modules of a compatible format and share a common calling con­ vention. These modules can be linked together to form a single executable program, making mixed-language programming straightforward. Lisp compilers of the past have not produced object

modules that can be linked in this way, thus Lisp does not fit the nor­ mal program construction model. We expect this will change in the future, enabling Lisp to be used easily in non-Lisp centered soft­ ware projects. To this end, some Lisp programs will be statically compiled and linked with libraries that contain the functionality to perform Lisp-based operations. We have already seen object file for­ mats such as ELF [4], which sup­ port run-time initialization on a per-module basis. This run-time initialization of data is necessary for building certain Lisp data struc­ tures which reference data from other modules. However, it may even be possible with the sacrifice of some Lisp semantics to compile programs into a static form that is equivalent to C. Lisp as an Extension Language

Many readers may already be fa­ miliar with Lisp not as a program­ ming language, but as an extension language. For years Emacs-like edi­ tors have used Lisp as the customi­ zation language with great success. Two notable non-Lisp applications that use Lisp as an extension lan­ guage are Interleaf (a document­ processing system) and AutoCAD (a computer-aided design pro­ gram). Emacs is a particularly interest­ ing case of an application choosing Lisp as its extension language since it is used so widely among non-Lisp programmers. Even nonprogram­ mers quickly learn the syntax for Lisp as they customize their Emacs environment. One reason Lisp is ideally suited to be an extension language is the dynamic nature of the Lisp envi­ ronment-extension implies the ability to augment standard capa­ bilities, and Lisp resolves references to functions at run time, making it ideal for this. Second, since Lisp has

September 1991 /Vol.34, No.9/COMMUNICATIONS OF THE ACM

is not needed in a statiu fashion. very simple syntax, a parser is quite simple to write. Third, it is quite easy to write an interpreter for a simplified Lisp dialect. The future will see the develop­ ment of increasingly more com­ plex, extensible, and customizable applications, increasing the use of Lisp as an extension language. Cur­ rently, each embedded Lisp is an ad-hoe program often written with little thought toward the emerging Common Lisp standard. If applica­ tion writers wish to purchase the embedded Lisp portion from a Lisp vendor, the Lisp vendors will have to provide an embedded delivery system that can be separated from

never used are never loaded into memory. Selective loading im­ proves locality of reference because the layout of functions in memory is determined by the order in which the functions are called. Selective loading is easy to use because it is fully automatic. To minimize start­ up time, one can train the applica­ tion by using it in a typical way to cause the necessary functions to be loaded ; the image can then be writ­ ten to disk. When selective loading

Future work includes providing the ability to analyze Lisp programs and generate code that is more static and contains less of the dynamic nature of Lisp. By the very nature of delivery, many of the benefits of this dynamic nature will not even be missed. Increased debugging abil­ ity, for example, is all but wasted in most delivery situations. There will be applications, however, that need some of this dynamic nature and additional solutions for those appli­

the fu l l development environment

is used, the whole of' the Common

cations must be designed as wel l .

of Lisp. This embedded portion will necessarily be a subset of Com­ mon Lisp and it might be a user­ configurable subset instead of one chosen by the Lisp vendors them­ selves. Next, we discuss some tech­ niques to overcome this problem.

Lisp language and development environment remains available. While some current systems al­ ready selectively load functions and their associated data, in the future Lisp will also be able to selectively load much more of the data, fur­ ther reducing image sizes. In contrast, tree shaking uses the approach of eliminating-shaking out-what is not needed in a static fashion. Programmers specify the requirements of their application and the unneeded parts of the Lisp system are removed using their de­ tailed knowledge of the application. The disadvantages of tree shaking are that it requires programmer intervention and that a function which is shaken out cannot be easily restored. A third technique is to reorga­ nize the layout of code and data to improve the locality of reference and thus reduce the real memory requirements of the program and ease the burden on the virtual memory manager of the operating system. Courts [9] has already shown this to significantly improve garbage collection performance, and its expected locality of refer­ ence [2] will improve run-time per­ formance of Lisp programs.

Delivery

Lisp systems are traditionally large because they contain a develop­ ment environment and every func­ tion in the language regardless of whether it is used by the applica­ tion. In contrast, conventional lan­ guage applications are linked selec­ tively with the necessary library modules. Selective linking cannot be done for Lisp because the set of functions callable by an application cannot be determined from a static analysis, except in special cases. Various techniques for reducing the size of the Lisp image have been developed including selective load­ ing, tree shaking and reorganiza­ tion. Selective loading arranges that a function object and its associated data reside in a file on disk until the first time it is used, at which point the function is loaded into memory. This technique reduces memory usage because functions that are

COMMUNICATIONS OF THE ACM/September 1991 /Vol.3·1', No.9

Windowing

Much of the early window system research was done in Lisp on Lisp machines. Furthermore, some of the earliest commercially available windowized user interfaces were on Lisp machines. Later versions of the Lisp machine windowing sys­ tem, developed during the mid­ I 980s, contain a component called the presentation substrate [2 1 ] that automatically maintains the seman­ tic links between the visual-graph­ ical or textual-representation of objects and the corresponding Lisp object. Whenever an object is ac­ ceptable as input, its visual repre­ sentation can be selected by using the mouse. For example, if a pro­ gram is prompting for a filename, only the visible filenames in the window are mouse sensitive while other objects are not. This enabled programmers to construct sophisti­ cated user interfaces. The past five or six years have seen the widespread availability and standardization of windowing sys­ tems on stock hardware. The X Window system is among those having had the largest impact. Oth­ ers, including the postscript-based NeWS and NeXTstep systems also

55

have their supporters. There has been a good deal of experimentation with window sys­ tems written in Lisp. CLX [27) is perhaps the most successful and the lowest-level interface to X, on top of which are built several other high-level window systems such as Common Windows [ 1 2 ] , CLU E [ 1 8) , and CLIO [ 1 9) . C L X i s not a linkage t o the C ver­ sion of Xlib (the library interface to writing X-based applications), but it is entirely written in Lisp, using native data structures and I/O. Its performance is nearly that of its Xlib counterpart, and it fits more naturally into the Lisp environment than would a foreign function in­ terface to Xlib in Lisp. Some of the abstractions and idioms are differ­ ent than what they are in Xlib but they fit the model of Lisp and the programmer's expectation with much better success. CLX is a rather low-level tool, and because many people prefer to program at a much higher level, a variety of different window systems were written on top of it including the following: • Common Windows, which has its roots in the Xerox Lisp machine windowing system, is a simple but effective windowing system that is becoming somewhat outdated. • CLUE is essentially a translation of the X I ntrinsics into the do­ main of Common Lisp and CLX. It provides a Lisp-style frame­ work for building user interfaces. Layered on top of CLUE is CLIO, which provides a set of look-and-feel independent CLOS classes representing standard user interface components such as buttons and scroll bars. Cui·­ rently, a CLIO implementation of Open Look [33) is available. • Garnet [25) is a collection of tools for creating graphical, interactive user interfaces. Garnet uses a va­ riety of novel techniques for gen­ erating graphical output and handling input. Since the first window systems for

56

use by Lisp programmers were originally done on Lisp machines, the trend has been to implement windowing software entirely in Lisp. U ntil recently this was justifia­ ble because Lisp-based windowing was more sophisticated than that available in mainstream languages. However, sophisticated C-based toolkits, such as Motif and Open Look are now becoming widely available. These toolkits provide a large number of widgets, each with a well thought out and clearly speci­ fied appearance, and conformance with their look and feel has become an important issue. Rather than attempting to dupli­ cate the effort of a great many C programmers, Lisp programmers are now ' starting to utilize these toolkits in Lisp applications through foreign-function inter­ faces. CLM [5] is an example of a Lisp-Motif interface which uses the network server approach. Another example of a foreign toolkit inter­ face is LispView [24]. An emerging standard in the area of window systems for Lisp programmers is the Common Lisp I nterface Manager (CLIM), which provides a set of high-level tools for constructing user interfaces that are independent of the underlying window system and toolkit and thus enables programmers to write highly portable code. CLIM pro­ vides many facilities of the Sym­ bolics window system, including a presentation substrate and tools for formatting output. I n addition, it provides a set of abstract gadgets that are mapped into the actual gadgets provided by the underlying window system. CLIM runs on a variety of window systems includ­ ing X windows, Dynamic Windows, Presentation Manager and Quick­ Draw. It is planned that CLIM will interface to a variety of toolkits in­ cluding Motif and Open Look. conclusions

Lisp has come a long way from being just a list-processing lan­ guage. The Common Lisp lan­ guage supports a rich set of data

types and multiple programming paradigms: functional, imperative, and object oriented. It is a language that is unsurpassed for inexpensive, rapid development ofapplications­ Lisp is most often the choice for prototyping complex systems, for implementing complex and evolv­ ing systems, or for implementing partially formed ideas of the pro­ grammer or researcher. Early barriers to the use of Lisp (e.g., lack of a compiler) have been removed, though there are others still needing removal. Delivery. Lisp delivery techniques are just now available, and it should be possible to produce very com­ pact Lisp applications in the future; Hardware support for languages. With little additional hardware as­ sistance from RISC processors, gar­ bage collection and generic arith­ metic will have less overhead than with current general-purpose hard­ ware; Foreign language integration. Tighter integration of Lisp and C will permit mixed language devel­ opment in the large class of applica­ tion that could benefit from partial Lisp implementation. The completion of this work will make Lisp not only the most ad­ vanced programming environment but also a viable delivery vehicle on plentiful, small machines. Lisp has already shown itself to be a pioneer in object-oriented programming. Because of the flexibility and exten­ sibility of CLOS, the use of Lisp will continue to foster the search for the object-oriented system of the fu­ ture. The future of Lisp includes pro­ gramming environments that are more powerful than the ones cur­ rently available on either general­ purpose or Lisp machines. Un­ doubtedly, part of the environment will be the research and develop­ ment of graphical user interfaces, including the use of foreign tool­ kits. Not only will Lisp continue to survive the decades, but it will be­ come the choice of more program­ mers in the coming years. t3

September 1991 /Vol.34, No.9/COMMUNICATIONS OF THE ACM

References

( N ice,

Graphical User Interface Functional

17. Johnson, D. The case for a read

34. Teitelman, W. et. al. InterLisp Refer­

Functional

1. Anderson et al. The interaction of architecture and operating system design. In Proceedings of the Fourth

barrier.

U npublished.

International Conference on Architec­

struments

tural Support for Programming Lan­

75265.

guages and Operating Systems ( 1 99 1 ) .

2. Andre, D . L . Paging i n Lisp pro­ Maryland, 1 986.

MS

369,

Texas

Dallas,

In­ Tex.

18. Kimbrough, K. and Oren, L. Com­ mon Lisp User Interface Environment.

grams. Master's thesis, University of

3. Appel, W. and Li, K. Virtual mem­

Programming

France).

Texas Instruments I nc., July, 1 990.

19. Kimbrough, K . , McBride, S. and Greninger, L. Common Lisp Interac­

Specification. Addison-Wesley. ence Manual, Xerox Palo Alto Re­

search

Center,

Palo,

Alto,

35. Walker, J. et al. The Symbolics Ge­ nera

programming

environment.

IEEE Softw., (Nov. 1 987), 36-45.

36. Weinreb, D . and Moon, D. LISP Machine Manual, Fourth Ed., M I T

ory primitives for user programs.

tive Objects. Texas Instruments Inc.,

In Proceedings of the Fourth Interna­

Artificial

J uly, 1 990.

Cambridge, Mass., July I 98 1 .

tional Conference on Architectural Sup­ port for Programming Languages and

20. Lieberman, H. and Hewitt, C. A real-time garbage collector based on

Operating Systems ( I 99 1 ) .

4 . AT&T U N I X System V Release 4 Reference Manual, 1 990.

5. Babatz, R. et al. CLM-A language binding

for

Common

Lisp

manager based on application se­ mantics. In Proceedings of the ACM

search Center for Computer Sci­

face Software and Technology ( 1 989),

6. Baker, H. List processing in real time on a serial computer. Commun. ACM 2 I , 4 (Apr. 1 978), 280-294.

7. Bobrow, D.G., DiMichiel, G., Ga­

pp. 1 4 1 - 148.

22. Moon, D . A . MacLisp Reference Man­ ual, Revision 0, M IT, Project MAC, Cambridge, Mass. (Apr. 1 974).

23. Moon, D.A. Garbage collection in a large Lisp system. In Proceedings of

briel, R.P., Keene, S.E., Kiczales, G.

ACM Symposium on Lisp and Func­

and Moon, D.A. Common Lisp ob­

tional Programming (Austin,

ject system specification. Lisp and

1 984), pp. 235-246.

Symbolic Comput. I, 245-394.

8. Cannon, H . J . Flavors: A Non-Hier­ archical Approach to Object-Oriented Programming. 1 982.

9. Courts, R. I mproving locality of

Tex.

24. Muller, H. LispView: Using Com­ mon Lisp and CLOS to hide a C toolkit. Lisp Pointers 4, I , ( 1 99 1 ) . 25. Myers, B.A. The Garnet Toolkit Refer­ ence Manuals: Support for Highly­

reference in a garbage-collecting

Interactive, Graphical User Interfaces

memory management system. Com­

in Lisp, Carnegie Mellon University,

mun. ACM 3 I, 9 (Sept. 1 988), 1 1 28-

C M U-CS-90- 1 1 7 , Mar. 1 990.

1 1 38.

10. Foderaro, J . K . , Sklower, K . L. and

26. Rao, R., York, W. and Doughty, D .

Layer, K. The Franz Lisp Manual. University of California at Berke­ ley, Calif., 1 984.

1 1 . Franz Inc. Allegro Common Lisp User Guide, Release 3.0, June 1 988. Manual, 1 990.

13. Goldberg,

A.

and

Robson,

Implementation.

Reading, Mass. 1 983.

14. Criss, M . L. , Benson, E. PCL: A portable LISP system. In Proceedings

Lisp

rial, Aug. 29, 1 990.

Feb.

1 988.

Features;

windowing systems.

General Terms: Languages Additional Key Words and Phrases: Common Lisp

About the Authors: D. KEVIN LAYER is manager/technical staff member and co-founder of Franz I ncorporated where he manages and works on Common Lisp and its pro­ gram development environment. interests

include

Lisp

His

programming

environments and efficient implemen­ tation of Lisp on stock hardware. is a technical

where he manages and works on pro­ gram development environment and window system projects. His interests include object-oriented programming, Lisp programming environments, win­ dow systems, and Lisp implementation techniques.

Rep. CSL-TR-88-35 1 .

1 995

3 1 . Steele J r . , G . L . Common Lisp, The Language, Second Ed., Digital Press,

1 990.

32. Sun

M icrosystems,

Inc.

The

SPARC'" Architecture Manual, Revi­

sion 50 of Aug. 8, 1 987.

33. Sun M icrosystems, Inc. Open Look:

COMMUNICATIONS OF THE ACM/September 1991 /Vol.34, No.9

and

Authors' Present Address:

CP-20 1 2 , 1 97 7 .

Lisp systems. In Proceedings of the

Constructs

[Programming Languages]: Proc­ essors; H .5.2 [Information Interfaces and Presentation]: User interfaces­

Also appeared as Stanford Tech .

MACSYMA User's Conference, NASA

16. Johnson, D . Trap architectures for I 990 ACM Conference on Lisp and

U niversity,

dissertation,

MacLisp. In Proceedings of the 1 977

Common Lisp I nterface Manager, Version I, Release 0.9, User Tuto­

Ph.D.

29. Stallman, R. GNU Emacs Manual. 30. Steele J r . , G.L. Fast arithmetic in

and Functional Programming (Aug.

1 98 2 ) . 15. International L i s p Associated, Inc.

system.

Stanford

of the I 982 ACM Symposium on Lisp

Language D.3.4

CHRIS RICHARDSON

28. Shaw, R. Empirical analysis of a

Addison-Wesley,

Environments- interac­

[Programming Languages]:

staff member of Franz I ncorporated,

( 1 99 I ) .

Smalltalk-80: the Language and its

Programming tive; D.3.3

interface manager. Lisp Pointers 4, 1 ,

2 7 . Scheifler, R.W. e t a l . CLX-Common Lisp X Interface, Release 4 Uan.

D.

(Nice, France).

CR Categories and Subject Descrip­ tors: D.2.6. [Software Engineering) :

A guided tour of t h e Common Lisp

1 990).

1 2. Franz Inc. The Common Windows

Mark-and­

on Lisp and Functional Programming

2 1 . McKay, S. et al. A presentation

Federal

Comparing

sweep and Stop-and-copy. I n Pro­ ceedings of the 1 990 ACM Conference

SIGGRAPH Symposium on User Inter­

1,

B.

Laboratory

the lifetimes of objects. Commun.

and

Republic of Germany.

37. Zorn,

I ntelligence

ACM 26, 6, U une 1 983), 4 1 9-429.

OSF/Motif, German National Re­ ence, Sankt Augustin

Calif.

1 978.

University

94704,

Ave.,

Franz Inc.,

Berkeley,

[email protected],

CA

cer@franz.

corn.

Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.

© ACM

0002-0782/91/0900-048 $1.50

57

C L I M : The c o m m o n Lisp I nte rface M a n a g e r ------ Scott McKay -----------------....

T

objects.

CUM

supports

The prog ram mer also defines com­

he essence of an apr:ilica­

application ' s

tion is a set of objects and a

transcript windows via an output re­

mands for the appl ication operations

set of operations on those

cording facility that automatically re­

that are accessible from the user inter­ face. A command is specified in terms

objects. The essence of the

members all of the output performed

behavior of an application's user inter­

upon a stream in a device-independent

of the presentation types of each of its

face is similar to Lisp's read-eva/-print

fashion. thus relieving the appl ication

operands, plus a small body of code

loop: the user specifies what he or she

programmer from the need to per­

requesting the appl ication to perform

wants to do (perhaps via a menu or a

form this task. Other facilities such as

the corresponding operatio n . What is

dialog or a d i rect man ipulation), the

automated table, graph, menu, and

not specified in a command is the way

application

performs the operation.

dialog formatting are layered on top of

in which a user enters the command;

and then the result of that operation is

output recording . C U M also provides

com mands can be entered via menus,

displayed. The Common Lisp Interface

application-bu ilding facilities such as a

dialogs, command lines. or d i rect ma­

Manager ( C U M ) is a system for con­

command processor. context-sensitive

nipulations.

structing portable user interfaces in a

help

layout of

When an application asks CUM for

way that d i rectly connects the objects

appl ication frames. and access to the

i n put of a particu lar type (using the ac­

and

documentation,

and operations of an application to the

gadgets provided by toolkits such as

cept operator), all presentations in any

objects of its user i nterface.

Motif and OpenLook.

transcript window whose type is equal to or a su btype of the requested type

Using C U M , programmers describe

A unique and im porta nt part of C U M

the user interface of an application in a

is t h e presentation facility (not t o be

are eligible as input. No other presen­

high -level language that is indepen­

confused with the Presentation M a n ­

tations are eligible. CUM highlights eli­

dent of any particu lar window sub­

a g e n , which remembers n o t o n l y the

gible objects when the user points at

strate. The language is decla rative in

output done to a stream but also the

them with the mouse. This context­

nature. in that the prog rammer indi­

underlying application object it repre­

based selectivity and highlighting pro­

cates his or her intent and C U M hides

sents and the presentation type associ­

vides feedback to assist the user in de­

the exact details of how the tasks are

ated with the output.

termining what user interface entities

performed. C U M relieves the program­

types are an extension of the Common

are selectable at any point in time. The

mer from having to program at the

Lisp Object System (CLOS) that provide

coupling Qf present and accept via

level of handling events. such as mouse

b arameterized types and a n u m ber of generic functions to su pport interac­

presentation types means that all out­

motion and button presses (although it is possible to handle such events d i ­

tion with users. such as methods for

later a s i n put.

Presentation

put done by an appl ication is available

rectly if necessary). L i s p uniquely pro­

reading i n put from or presenting out­

vides the ability to create such a high­

put to the user. Since presentation

make presentations eligible as input is

level lang uage. Macros and lexical clo­

types are an extension of CLOS classes.

the

su res are used to im plement C U M ' s

one presentation type may be defined

objects having one presentation type

Another means translator.

CUM

provides to

Tra nslators

"coerce"

facilities without imposing undue con­

as a subtype of one or more other ,

into objects of another presentation

straints upon the structure of the ap­

types in the usual way, sharing the

type. A translator can be thought of a s

basic cha racteristics of its su pertype(s),

a method that specializes i n t h e pre­

CUM provides a n u mber of basic fa­

while specializing other aspects of its

sentation type of one presentation and

cilities: a geometry model, affi ne trans­

behavior. A prog rammer creates a pre­

a gesture (such as clicking the left- hand

formations.

sentation

plication code.

text

(including

m u ltiple

by

invoking

the present

mouse button), and returns an object

fonts), graph ics (including a sophisti­

operator. which takes an appl ication

of

cated color i n king modeD, an extended

object and a presentation type, pro­

translated object. as its result. Since the

110 stream model that includes event

duces some output on a specified

object representing the invocation of a

stream. and associates the displayed

command has a presentation type (the

device (such as a mouse), and window

representation with the object and the

command type), translators can be

management.

Rather

presentation type.

im plementing

all

management, su pport for a pointing than

d i rectly

another

presentation

type,

the

used to provide a mapping from dis­ played application objects and gestures

of these facilities.

When building an application in C U M ,

C U M instead uses the services provided

t h e programmer defines presentation

by the native window system, such as X

types for the application objects partic­

As a n exa mple, consider a simple

Windows or M icrosoft Windows.

ipating in the user interface by defi ning

electrical computer-aided design (CADl

to commands.

Applications written using CUM are

present and accept methods that

application. The basic object type is de­

usually structured to include one or

describe the appearance of the appli­

vice, which has su btypes transistor

more scrolling transcript windows that

cation objects in the user interface. and

and resistor; these three types have

display a visual representation of the

how the appl ication objects are input.

corresponding presentation types. The

58

September 1991 /Vol.34, No.9/COMMUNICATIONS OF THE ACM

presentation types for transistors and

a menu bar in the application with a Set

on the inheritance mechanisms already

resistors define present methods that

Resistance button in it; if the user se­

found in C LOS, prog rammers have a

draw each device. There are operations

lects that command from the menu

fa miliar framework for declaring the

in the application for moving devices

bar, the only eligible presentations will

relationships

and

be resistors, and only they will be high­

objects and operations.

changing

their

properties

The

among

the

application Finally (and

move-device operator applies to a l l

lig hted as the user waves the mouse

possibly most profoundly), since the

devices, t h u s there is a Move Device

over the application ' s display pane

objects and commands in the user in­

command o n all objects whose presen­

There are several advantages to be

terface are built d i rectly on the objects

tation type is device. The set-resist­

gained from using presentation types

and operations in the application, user

ance operator appl ies only to resistors,

instead

and

interface consistency becomes a by­

so there is a Set Resistance command

gadget-based

of constructing

product of the appl ication's structure

only on resistor objects There is a

user

the

rather than an a rtifact of graphic de­

translator that translates from objects

event-driven style of interface tends to

sig n . Such consistency provides a user

of type device to the Move Device

be written in an im perative style, C U M

interface that can be more easily u n ­

command when the user clicks the left

allows t h e prog rammer t o u s e a declar­

derstood by t h e end-user o f the a p p l i ­

button of the mouse on a device. If the

ative style that often better expresses

user waves the mouse over any device

the progra m mer's intent. Second, be­

while the CAD application is waiting for

cause the presentation type system

of

the

usual

style

interfaces.

First,

eventwhereas

a command, C U M will ind icate that the

brings the application objects out to

device is eligible as input by highlight­

the user interface, the code imple­

ing it. Furthermore, if the programmer

menting the user interface can be writ­

included a documentation pane in the

ten in a style consistent with the rest of

application, CUM will display docu men­

the appl ication, rather than in a style

tation that indicates clicking the left

i m posed by the conventions of a par­

mouse button will perform the Move Device com m a n d . There might also be

ticular window substrate. Also, since the presentation type system is based

cation s i n c e t h e user interface directly

reflects the state of the appl ication. [3 SCOTT MCKAY is a consulting member of the technical staff of Symbolics, Inc. His current research interests include advanced soft­ ware development tools and environments. next-generation user interface tools, and vis­ ual programming languages. Author's Pres­ ent Address: Symbolics, Inc., 8 New England Executive Park, Burlington, M A 0 1 803, swm@ riverside.scrc.svmbolics.com.

LisDVi ew: Leverag e T h rough I nteg rat i o n ------ Hans Muller ------

A

lthough

Lisp

was

the

scrollbar, we have focused on layering

host for many of the

a

clean

object-oriented

application

first graphical user inter­

programmer interface (APll on top of

face ( G U i l packages, pop­

an existing C platform.

function defi nition such as extern XChangeGC(Display *dpy, GC gc, unsigned long mask, XGCValues

u la r activity in this area has sh ifted to

LispView also works well with the

more prim itive but widely used lan­

OpenWindows Developer's G u ide mev­

guages such as c and C+ +. One expla­

g u idel

nation for this sh ift is that while Lisp's

create and mod ify LispView applica­

strength i n rapid prototyping and de­

tions interactively, only resorting to

( def-foreign-function (XChangeGC

velopment led to the i n itial progress, it

Lisp code to define actions for buttons

( :return-type :null)

also tended to inspire an i m perialist

and menu items, etc. Figure 1 shows a

attitude:

LispView Devg uide session in progress.

applications

were

often

Using

Devg uide,

developers

crafted exclusively in Lisp, even when

It turns out that many other people

part of the application could make use

have toyed with the idea of connecting

*values);

using the Lucid Common Lisp foreign interface extensions, would be:

( : name "_XChangeGC" ) ) ( dpy ( :pointer Display ) ) ( g c GC) (mask unsigned-long)

libra ry. We believe the ideal way to con­

Lisp to c libraries such as Xlibl41 and

(values ( :pointer XGCvalues ) ) )

XViewl21, but most have been discour­

struct

of a n existing conventional language package

aged by the task of building the foreign

This sort o f thing i s easily generated by

today is to integrate proven C libraries

interface 151-the Lisp definitions that

hand for small libraries. Unfortunately,

with an object-oriented

precisely characterize the functions,

libraries like XView and

types, and other definitions the li brary

about a

a

Commonlisp

GUI

Lisp fra me­

work.

thousand

Xlib conta i n

definitions each.

Lisp GUI package,

contains. Most of the work in defi ning a

Hand translation on this scale is both

LispView 131, takes this approach: we

Lisp interface involves translating the

mind n u m bing and error prone.

have taken advantage of sta ndard C

definitions from a C include or header

We solved the problem by writing a

toolkit and window system libraries.

file into the appropriate Lisp syntax. For

short Lisp program that transforms C

Rather than trying to build a better

example, the foreign interface for a C

header files into a Lisp foreign inter-

Sun's

Common

COMMUNICATIONS OF THE ACM/September 1991 /Vol.34, No.9

59

Devgulde: Text Fields Text Fields:

�1j �

Octahedron

d 1_ l_ � l_ tex_ ttie _ _ _ _ _

1;

Name: Label: Label Is: Location: Field Type:

Base Window

Text Field:

I Text IGlyph Filename I I Left I Above I X:

�

Y: 32

IAlphanumeric I Numeric I

Ri!ngo: Min : _

Field Length : Stored Leng1h: Operation:

.... . . .. .........; C]

textfield 1

_ B _

Max : _

��------J.::===========:_---,

e_ er'_ ld nWlndo= s= De= velo p_ :::; ::::;: ;::= Ope · '---;::::::: _ -_,_ _ Gu •_ w= :: = : ::;-;;=.=::::;----;: " ==: :::: ri --;:@) _ _ so rRead-w rite

:= ;--;::;:

=::;-

I Build I Test I

Notify Handler : ----! Event Handler: ----!

� times by 2...__ �

( Rotate)

Pointer:

X:

O

Y:

O

:label "Example Base Window") )

All the initial values of the base­

A LlspVlew/XGL Appllcatlon

window can be changed dynamically

Running on openWlndows

with setf methods. For example, to change the label:

recog nize 95% of the definitions that appear in header files; the remainder were flagged and then translated by hand.1

"Sample Example Base Window" )

LispView takes advantage of many of tures that are unique to CLOS (e.g . , method

tation of LispView. Using them di rectly

methodsl.

�

combination

and

multi­

requires some special care: one must

Method combination is used to i m ­

consider how the Lisp garbage collec­

plement a two-stage object-creation

tor will interact with data shared by Lisp

framework: objects are initialized ( i . e . ,

and C , the i mpact of the preemptive

their slots a re filled i n l and then real­

function match-event. If a matching interest is found, then LispView applies the generic function receive-event to the

window,

the

i nterest,

the

Sim ple applications usually create a u nique i nterest subclass and then just specialize the second a rg u ment. For exa mple: ( defclass sld ( mouse-interest) ( ) ( :default-initargs : event-spec '( ( :shift) ( :left; :down ) ) ) ) ( defmethod deliver-event

ized-the window system resou rces

(window (i sld) e )

that the object represents are created .

(draw-string window (mouse-event-x e )

data to c functions. Instead of burden­

Applications can use : around, :before,

ing appl ication developers with these

and :after methods to insert code at

constraints, we built a Common Lisp

any point in this sequence. M u ltimethods

and

g uments.

Lisp scheduler on nonreentrant C code,

Object System (CLOS) [1] API that pro­

%

windows interest list, using the generic

and the i m plications of passing bad

vided a "firewall" between Lisp and the

300

ceive-event on any n umber of the ar­

( setf (label my-winrl.ow)

were the basis for the first implemen­

o

( Create New Object '