Software Innovations for the Texas Instruments Explorer Computer

HARRY R. TENNANT, MEMBER, IEEE, ROGER R. BATE, MEMBER, IE EE, STEPHEN M. COREY, LAWRENCE DAVIS, PAUL KLINE, LAMOTT G. OREN, MALIPATLOLA RAJINIKANTH, RICHARD SAENZ, DANIEL STENGER, MEMBER, IEEE, AND CRAIG W. THOMPSON

Invited Paper

Explorer is a LISP Machine from Texas Instruments. Its software starts with a vast body of software developed at MIT. Texas Instru­ ments has stabilized that software and added more packages and utilities. Th is paper describes certain innovations in Texas Instru­ ment's software for the Explorer. Tl's software innovations were in two areas: increasing the learn­ ability of this sophisticated system and adding software compo­ nents as an aid to prototypers and software developers. Learning aid innovations are embodied in Suggestions Menus and the Uni­ versal Command Loop. Software component innovations are em­ bodied in the Universal Command Loop, the Graphics Window System and Graphics Editor, the Relational Table Manager, and the Menu-Based Natural Language Interface. The innovations repre­ sented are of two kinds: innovations in concept (Suggestions Menus, Universal Command Loop, and Menu-Based Natural Language In­ terface) and innovations in design (Graphics Window System, Rela­ tional Table Manager).

I. INTRODUCTION Fig. 1. Th e Texas Instruments Explorer computer is de­ signed for creating and running LISP software. The hardware The Texas Instruments Explorer computer is a high-capa­ features a large high-resolution bit-mapped display, a mouse bility personal computer. It is intended for rapid proto­ pointing device, and a keyboard with many special keys. typing and development of software by expert programmers software that was conceived and developed at Tex as Instru­ and for other interactive applications such as VLSI design, ments for the Explorer. command, and control systems and artificial intelligence Tl's software extensions for the Explorer were made in applications. Explorer, as shown in Fig. 1, has a large high­ two categori es: 1) learning aids to enable users to acquire resolution bit-mapped display, a mouse pointing device, and maintain mastery over significant portions of this large and a keyboard with many special keys in addition to the system (e.g., there are over 10000 functions in the syste m) usual keys of a computer keyboard. It is an unusual com­ and 2) component software which programmers can in­ puter for several reasons, two of which are that 1) all the tegrate into their own applications, thus reducing develop­ software on the Explorer is w ritten in LISP and 2) there is a ment time and increasing the quality and effectiveness of great deal of software available on the machine (20 to 40 software prototypes. Mbytes), most of which is devoted to software develop­ The approaches taken by programmers using LISP Ma­ ment and interactive systems. chines are often strikingly different from the approaches The Explorer is based on the LISP Machine designed at they had used before. We give two examples taken from MIT [1), [2), and a large part of the software on it was first the experience of researchers in the Texas Instruments written at MIT [3], [4). This paper will describe the novel Computer Science Laboratory.

Manuscript received january 22, 1985; revised May 15, 1985. A. "This Is Exa ctly What I Want" The authors are with the Computer Science Laboratory, Central The Equipment Croup of Texas Instruments (EC), the Research laboratories, Texas Instruments, Inc., Dallas, TX 75266, USA. division that makes military products, had been talking with

0018-9219/85/1 200-1771$01 00 ©1 985 IEEE

PROCEEDINGS OF THE I EEE, VOL. 73, NO. 12, D EC EMBER 1985 1771 a customer about a large command and control system. The The natural language-graphical interface-database dem­ customer was requiring a natural language interface to a onstration was possible to construct in such a short time for database, a technology which the EG did not have at the two reasons: we had many of the large components needed time. They contacted us in the Computer Science labora­ for it and the development environment allowed us to tory of Tl (CSL) to help them w ith the natural language readily stick the pieces together. Most of the programming interface. EG described the problem to CSL, and we set up environment features came from the work of the LI SP an appointment for a demonstration of our natural lan­ Machine implementors at M IT. The component software guage interface capabi lity for the next day. used for this demonstration, the graphics window system, Th e request was for a natural language interface, but the the graphics editor, the relational database, the natural problem seemed amenable to a spatial interface to a data­ language interface, and the natural language interface gen­ base as well. One of the researchers spent a couple of erator, were all software components deve loped at Tl, which hours w ith the graphics editor creating a demonstration of w ill be described below. database access through a graphical interface. The next day, the people from EG were interested in both the graphics B. Debugging an Algorithm Visually and the natural language, and w ith their knowledge of the domain and our knowledge of the technologies, we worked A new member of CSL, previously a Pasca l and Fortran out an integration of the two approaches. EG built a data­ programmer, was assigned to learn to use LI SP Machines. base that w as realistic for the domain, we generated a He decided to learn by implementing a new approach to natural language front-end to that database. two-dimensional bin-packing. The most complicated part O ne of the uses of the system was to locate airports and of the system he wrote was a routine that would take a list fuel depots. The database recorded the latitude and longi­ of rectangles to be packed in a space and pack them there, tude coordinates of these items. O ne way to query the in list order. There were two requirements on that routine: database was to ask for all airports between, say, 41° and it needed to be fast, and it needed to produce a relative ly 43° North latitude and between 47 ° and 47.356° West dense packing. Routines that were clever enough to pro­ longitude. By integrating our graphics w indow system with duce good packings tended to take a good deal of time, the natural language capability, a map would pop up when and fast routines tended to produce bad packings. The the user needed to specify a location. He could then programmer compared several packing algorithms, search­ o utline the region of interest on the map with his mouse (a ing for one that would strike a balance between these two pointing device). Th e latitude and longitude coordinates of goals. the box would then be inserted textually into the natural Early on, the programmer decided to display the packing language query. Hence, the demonstration used graphical process as it placed the rectangles, and this decision turned query where appropriate and t extual (i.e., natural language) out to be a good one. Using the object-oriented program­ query where appropriate, even within the scope of one ming style, he created a graphical display aid in an afternoon. question. The results of database queries could also be He elaborated and refined it over the next two afternoons, displayed either graphically (e.g., the requested airports so that it showed the movement of the rectangles as they would appear on a map) or in tabular form. w ere being packed, in animated fashion. Th e effect as Two weeks from the time of the original contact be­ recta ngles moved along the edge of the packed area to tween EG and the customer, the customer was in the lab in their final positions and others slid in beside was " just like CSL personally using the demonstration system. He liked it. real life." The nature of the various packing routines could He gave us one of our best recommendations, " This system be grasped immediately by eye, w hereas it would have is so easy, I'd let a general use it." He also said, while he taken hours with printout. was using the demonstration system, " This is exactly what 1 In another five afternoons, he tried out twelve variations want," a nice thing to hear before the proposal had been on his packing algorithms, each suggested by the behavior w ritten. (TI got the contract.) of the ones preceding. At one point, he was working on

Fig. 2. Partial results of a bin-packing algorithm. The algorithm maximized contact wi th the walls of the packing area, so we find the center being left open. The programmer did not appreciate this consequence of the algorithm until he saw it happen with graphical debugging tools.

1772 PROCEEDINGS O F THE IEEE , VO L. 73, N O . 12, DECEMBER 1985 algorithms that moved each new rectangle around the A. The Need for Learning A ids existing "skyline" of packed rectangles, finding the place­ The LI SP M achine, as developed at M IT, is a magnificent ment that max imized the length of its perimeter in contact workstation for a highly skilled programmer, an expert user w ith the rectangles already placed. Th e w all s of the packing of the machine. A great number of commands are available area were counted in computing the perimeter length con­ through single keystroke invocation, maximizing the rate of tacting the existing structure, and this led to an interesting flow of commands from the use r into the machine. Several problem. additional control keys have been added to the keyboard In the programmer's first implementation of this family of for th is purpose. In addition to "shift" and "control" keys algorithms, the packings produced contained more empty for invoking characters on standard computer keyboards, space than expected in their central regi on. To find out the LI SP Machines also have " meta," " hyper," "super," and w hy, he turned on the animated display. Fi g. 2 shows the "symbol." These can be used together as in the single st ate of such a packing w hen it was roughly one-quarter character, meta-hyper-s uper-A. In addition, there are speoal completed. Because the algorithm maximized contact with prefix keys (" system," " terminal," " network") that se nd the the walls of the packing area, the initial rectangles pl aced subsequent keystroke to the appropriate subsystem of the w ere moving to the three corners, and the packing was machine. One result is that a highly skilled user can be gradually grow ing outward from them. (In this version of extraordinarily productive on a LISP M achine. Another re­ the algorithm, the lower right corner was kept open, to sult is that new users had a lot to learn before they were allow new rectangles a way into the packing area.) He ve ry productive at all. changed the routine so that only the left and top walls O ur vision of Explorer at Tl was that it should support the counted in computing edge contact. The graphic displays expert user just as the MIT system supports him. However, that resulted were like Fig. 3. The packing grew from the we were very concerned w ith the difficulties that new or upper lett corner, as he had intended. infreq uent users would experience in learning and remem­ In the programmer's view, this was the most striking beri ng the protocols for operating the machine. We were feature of his LISP Machine experience. Debugging packing also concerned about the users beyond the programmers. A algorithms by eye led him to the results he wanted in days; programmer might be programming on an Explorer in order w ith the techniques he had been accustomed to usmg, to build a workstation for a VLSI designer, for example. We arriving at the same stage would have required many weeks wanted to make it eas ier for the programmer to learn to use of work. Th e graphics capability of the LI SP Machine is the machine. We also wanted to provide software for th at highly integrated w ith the rest of the LISP computing en­ progra mmer to incorporate into his system to .make his VLSI vironment, enabling the ready application of graphical tech­ des igner's workstation eas ier for the VLSI des1gner to use. niques like this to software development. In order to accomplish these goals, we addressed the questi ons of taking a user along the transition from novice II. Tl SOFTWARE FO R TH E EX PLO RER to expert, an d of providing mnemonics for powerful but infrequently used capabiliti es of the computer. Two ap­ A great deal of work has been directed at the software on proaches contributed to our solution, Suggest1on the Explorer. The software from M IT was impressive in its M~ nu s and the Universal Command Loop. These w ill be descnbed extent and capability. It did suffer from a lot of bugs, however, and there were problems of configuration control: in detail below. the source code did not always match what was running on the machine. Much of the software effort at Tl was directed B. The Benefits of Component Software at stabilizing the ex isting software and getting it under control. As illustrated in the examples above, a common use for Th e primary software innovations came in the extensions LI SP Machines is for prototyping software systems, espe­ to the M IT software for the Explorer. These extensions came cially interactive systems. In building a prototype, a pro­ either as learning ai ds or component software. grammer's goal is to get a rough version of the system

fig. 3. Modifying the bi n-packing algorithm caused the packing to grow out from the upper left corner as intended.

TENNANT et al.: INNOVATIONS FO R TH E Tl EXPLORER COMPUTER 1773 working as quickly as possible. He wants to actually see it, high productivity). Having the co mmands available in menus and thereby understand the concept of the eventual sys­ exposes new users to the extent of the command set and tem. There is little use of working on the fine details of the encourages experimentation. The transit ion to single key­ most efficient algorithms for a system if the overal l concept stroke commands is also assisted by temporarily flashing the for the system is flawed. The goal of rapid prototyping is to keystroke equivalent of a se lected menu command at the be able to see, through a prototype, the overall system as location of the cursor (where the user's attention is focused) quickly as possible. With the prototype as a focal point, the when a menu selection is made. overall design can be assessed, modified, rejected, or con­ Fig. 4 illustrates w hat the Explorer screen looks like w ith firmed. Work beyond the prototype is then generally in­ Suggestions M enus turned on. The LISP Listener window, volved with implementing the system more efficiently. Put which would ordinarily extend all the way to the right edge simply, the purpose of a prototype is as a communication of the screen, has been sh run ken to allow room for the four device between programmer and customer: to insure that individual menus that comprise Suggestions to appear in a the finished program that w ill eventually be delivered will column along that edge. A LISP listener is typically invoked solve the problem that th e customer needed to have solved. when a user wishes to type LISP expressions for evaluation If prototypi ng is to be rap id, which means more rapid by the interpreter. In Fig. 4, the user has typed the expres­ than a full implementation of the desired system, it must be sion (print-herald), and the evaluation of that function simpler. One of the simplest, fastest ways of w riting soft­ causes a description of some of the loaded utilities to be ware is not to write it at all, but to use some existing printed out immediately below the type-in. software. The component software that runs on the Ex­ There are a number of commands ava ilabl e in a LI SP plorer is part of the software library available to pro­ Listener that allow users to correct their typing mistakes, grammers for their prototypes. A programmer may choose req uest documentation of the items they have typed, ask to use the RTMS database component, for example, when the system to complete the item that is being typed, etc. prototyping a VlSI designer's workstation. Whether or not These commands are normally invoked by the user through he chooses to implement his own database system for the the use of keystroke commands such as control-y, which delivered workstation, he had the advantage of a working, inserts the most recently deleted characters before the usable database system from the beginning of his program­ cursor, just as if the user had typed them in again. ming effort. When Suggestions Menus are turned on, however, the Several software components will be discussed in this user has the option of executing those same commands paper, including the Universal Command Loop (UCL), the from the menus instead. In Fig. 4, the user has the mouse Graphics Window System (GWIN), the Graphics Editor pointing to the Suggestions Menu item " Retrieve Last Ki ll" (GED), the Relational Table Management System (RTMS), which is boxed to show that clicks of mouse buttons w ill and the Menu-Based Natural language System (NlMenu). be interpreted as applying to that item. Addi tional informa­ Other software components were implemented at Tl for tion about that command is displayed in the mouse docu­ the Explorer, but will not be described below, such as the mentation lines, which are shown in reverse video at the Tree Editor, the Glossary utility, Grasper [5] (a semantic bottom of the screen. Shown there are the first line of the network system), and PROLOG [6], [7] (a logic programming documentation for this command, an indication that there language). is more than one line of documentation available, and the keystroke equivalent of this menu item. The Suggestions Menus interface provides menus of LI SP Ill. LEARNING A IDS listener commands in order to acquaint new users with their options and to provide a route through which they A. Suggestions Menus can painlessly acquire the keystroke seq uences that will The LISP Machine environment, as designed at MIT is permit them to most effi cien tly interact w ith the LI SP intended to maximize the productivity of expert users. To Listener utility. Besides promoting more efficient interac­ th is end, user interaction centers on minimal command tion, Suggestions Menus also assist users who find them­ strings (generally single key strokes like control-meta-f) to selves in situations that they are not prepared to cope with invoke one of a large number of commands. For example, on their own. the ZMACS text editor alone has over 700 commands, most Fig. 5 shows an example in which the Suggestions Menus of w hich are invocable through single keystrokes. The abil­ automatically change to assist a user who has run into ity to invoke powerful operations through single keystrokes difficulties. Th e user has misspelled the function PRINT in provides expert users with a very responsive programming the newly defined function FOO. Evaluating FOO causes an environment. Unfortunately, this keystroke operation can error, and the user has no choice but to try to cope with a provide difficulties for new users-they frequently are un­ d ifferent command interpreter, the Error Handler. To assist aware of options open to them and have trouble remem­ the user, the Suggestions Menus have also changed to re­ bering which keystrokes invoke which operations. place the LISP Listener commands with Error Handler com­ We have add ressed the learning problem for the Explorer mands. Suggestions Menus tracks context changes in order by developing a dynamic menu-based interface call ed to provide the user w ith a set of legal commands w henever Suggestions Menus. Keystroke operation is important to possible. Th e goal is to ensure that the user is never at a retain for expert users. Instead of replacing single keystroke total loss without any idea of commands to try. commands, we have augmented the interface to allow 1) Suggestions for the Debugger: The power of the mixing keystroke commands with menu operations, with Explorer programming environment is greatly enhanced by attention given to providing a path from novice operation the powerful debugging facilities provided by its Error Han­ (menus, easy to learn) to expert operation (singl e keystrokes, dler utilities. Unfortunately, our observations of users with

1774 PROCEED INGS OF TI~E IE EE, VOL. 73, NO. 12, DECEMBER 1985 (print herald ) Lisp: TI Chaparral System, band 1 of Godz illa. (Ford Entoce ) Li s t Me nus 2948K phys oca l memory, 32639K v orlual memory. He lp Ex perimental FORD 1.8 Ex perimental Lo cal - Fole 2.9 Menu To ol s Ex per imenta l FILE- Server 19.9 Li s p S u gges t ion ~ Expe rime nta l Un iversal Command Loop 5 .9 Sug g e s t ion ~ Menus Off Experimental UCL System Interfaces 2 .9 Expe rimental Glossary 1.e Basic M ~nn Experimental Sugges toons 5 .12 [xperimen t a l Grapho c s Wondow 2. e C l e~r Screen Experimental Grapho cs Editor 2. 9 S t ar t Input Over Exper imental Tree Drawing Ut iloty 1.0 Forwltrd Exper ime ntal NLMenu 12 .9 Bac k.., ard Experimental Re l at iona l Table Management Syst em 23 .9 For ... a f"d L.l ord Exper imental NLMenu- RT MS- lnterface 3.9 Back ~o~ a rd L.lord Experimental Gras per 1.9 Beglnnjng o f l • nP Mic rocode 163 End o f L•ne ~ I _ DALLAS _ NORTH_BUILD I NG Godz illa , with assoc oated mach ine LAM!. Rubout Last Char ,,rL De l e t e Charac t Pr > Retr1eve Input Typed ' letrieye La5 t Ko I 0

L1s p Lls t ener 2 L:Execute Command M:Show Keystroke R:Command Documentation Rl:System Menu Take the most recently l

TENNANT et a /.: INNOVATIO N S FO R T HE T l EXPLORER COM PUTER 1775 Error H andlQr: > ldefun foo () (prnt "Greet ings ")) Abort ~c oo Li s t Henu5 > (fool He lp >>TRAP 11e22. !TRANS- TRAP) Pro ceed Type5 The function PRNT i s unde fi ned . ~i nd o ~ Error Handl ~ r ~ h il e in the function Sl: EVAL 1 ~BL OCK ~ S l: EVAL l Menu Tools

lr-00: Bas i c Error Dandier M enu

Using 2etali s p syntax a nd s emant1cs and base te in package US ER. Eva l & Lisp For" S hort Back tr ~ce omma nds ava1lable for thi s particular e rror: Fu I I Backtrace Re tur n A Val u e Super-A, ck ~ up er - C : Edi t Fran e Func tion Super- 0, ~ : Re turn to L i s p L i s t e ner t op leve l. Search ~up er-E : Re start process L i sp Listener 2. Bug Report j->uper-F : Reset a n d arrest process Lisp Li s tener 2. Repeat Error Message ~

Li s p Li s t ener 2 L:Execute Command M:Show Keystroke R:Command Documentation R2.:System Menu Which function called this one keystroke: Controi-N USER: t ,PUii(l~r" rl Fig. 5. The contents of the Suggestions Menus change as the state of the interaction changes. The user has attempted to evaluate an undefined function, PRNT, which caused an erro r. The Suggestions Menus now show options that are relevant to the Error Handler.

The M enu Search option is related (but not identical) to did not have the luxury of pre-dati ng the software, and the ZMACS Apropos capability in which the user is shown have unashamedly tacked on an interface after the fact. the set of ZMACS commands w hose names contain a However, the different goals of the Expl orer and the Star specified string of characters. One drawback of the Apropos dictate different interface needs, and the Explorer interface command is that the display of commands containing the might not be at as much of a disadvantage as it would string of interest disappears as soon as a key is struck. appear at first. As a machine intended for software develop­ Another drawback is that only the first line of documen­ ment, the Explorer programming utilities can be viewed as a tation is shown in the display. The combined result is that it source of examples, as well as a programming environment. may not be obvious which ZMACS command out of a It is clear that the originators of the M IT LI SP Machine fami ly of related commands is actually the one desired. If software were experimenting with different styles of user the users do not guess correctly, they often find themse lves interfaces when they developed the various programming issuing the sa me Apropos command over and over again, utilities. Each different style of user interface provides a trying out a different command after each display. concrete example that software developers could choose to The Suggestions Menus interface overcomes these imitate in their own programs. From this point of view, a drawbacks of Apropos by giving the user the option of diverse set of interfaces is an advantage. Perhaps the most forming a menu of the commands that Apropos finds in its va luable feature of the Suggestions Menus interface is that search. M enus created in this way behave just like any other by overlayi ng an optional interface on top of the original Suggestions M enu. Items are executed in the usual way, interface it provides the consistency that new users appreci­ and as is shown in Fig. 7, documentation is al so obtained ate without destroying the underl ying diversity that serves for them in the usual way. In thi s case, the documentation as a source of examples. features of ZMACS and the capabilities of Suggestions Menus are combined to the advantage of the users. B. Universal Command Loop 3) Retrofitting an Interface: Th e developers of the Xerox Star [9] argue persuasively that the user interface should be The Universal Command Loop (UCL) is a software com­ designed before the software is written rather than being ponent developed for the Explorer designed to make user tacked on afterward s. In the case of Suggestions Menus, we interaction with application packages powerful, consistent,

1776 PROCEEDINGS OF TH E IEEE, VOL. 73. NO . 12, D ECEMBER 1 98S Zmacs: list Me nus Menu Tools

Find Co""ands Li s p Suggest ions Undo lncl uding the keystrokes lll the "' Fonts & Case MENU

EXAMINE FONTS List Fonts tnenu:s n1.a.kes it. ea.s1er to detect Di s play Font

MODIFY SUFFER DEFAULTS Electric Font Loc k Mo Set Fonts Repars e Attribut e Li s patterns. Update Attribute Li s t

C H ANGE FONTS CTRL - j Change Charact META - j Change ~ord CTRL - J Change Region META-J Change in Regi CTRL - META-j Chnge Def

[ ~ho s~e SYSTEM F ]

CHANG£ W O RD C'A~£ METR-e Uppercas e Init META-u Uppercase ~ ord META - l L o~erca s e ~ord

C li:ANGE REGION CASE Lisp Uppercase Region Li s p Lo u e rca se Re g ion

2 MA CS (LISP l " I newbuffer Font: A ([MOLD)

l:Move point, L2:Move to point, M:Mark thing, M2:Save/Kiii/Vank, R:Menu, R2:System menu.

01 /08/85 89 :47:56 TALAR IS USEP.: • r.o: .JO HNSOt-1: SPELLllCT~3 4:??. 78280 Fig. 6. The " Fonts & Case Menu" is one of over 20 menus available for the ZMACS text editor. ZMACS is highly functional, including ove r 700 commands. Suggestions exposes the use r to the range of these commands.

and easy to learn. It is intended to help users learn the invocation through a system-initiated device such as menu capabilities and commands of a system, to help make the selection. Th e menus reveal what can be done. transition from novice to expert, and to help users relearn • Whenever possible, user interfaces should appear con­ the capabilities and commands that have been forgotten sistent from one application to the next. through a period of disuse. Since this component has been • Expert users should have access to large numbers of applied to some of the Explorer systems, it qualifi es to be commands. considered both as a learning aid and a software compo­ • With large command sets, menus become unwieldy, so nent. user-initiated command invocation is preferable for~ expert 1) Ease of Learning and Ease of Use: In our work on users over system-initiated invocation. user interfaces, we held several assumptions about what • User-initiated invocation is done most efficiently by made a system easy to learn and easy to use. minimizing keystrokes, so single keystroke commands are preferable for the users who remember them than longer, • If one is to use the system effectively, he must have an more mnemonic command names. understanding of the effects of operations he is invoking. • Highly skilled expert users forget commands and ven­ One cannot effectively use a statistics package, for example, ture into parts of systems where they are unskilled, so they until one understands the meaning of the results, and how need to be able to be treated as novice users by the system. the results depend upon the operations and parameters set Also, different users reach different plateaus of mastery. by the user. • For new users, a small set of commands is preferable to In summary of the above assumptions, users differ, users a large set. A small set is more readily mastered, which gives change, and no one style of interaction is the " right" one. the user a good feeling about the system as a tool of his. Of The novelty of the UCL is that it accommodates all of the course, the small set of commands must be adequate for users implied by the above assumptions, from novices doing useful work. through experts. • The command set should be self-evident for new users. 2) Supply Cabinet Metaphor: The UCL implements a A common method for doing this is to provide command new metaphor of user interaction which we call the Supply

TENNANT e t a/. : INNOVATIO N S FO R T HE T l EXPLORER COMPUTER 1777 Z macs: Li s t Menus Me nu Too l s

F i nd Co ,,ands l isp Su gge s tions Undo

Ap r opos P aragraph. M E N U A n1_enu ts created cotntnancls all !Sort Paragraphs! F i I I Paragr aph Mark Paragr aph Bac k ~ a r d Parag r aph ..who se name includes the string Forua rd Paragraph

" paragraph" .

ZMAC S (LISP) M f newbuffer Font: A ( CM OLO)

L:Execute Command M:Show Keystroke R:Command Documentation Rl:System Menu Sort the region alphabctioally by paragraphs

01/07, 25 15 :55: 55 KLI IE LI SER : Fig. 7. The documentation features of ZMACS, such as Apropos, allow the user to query the list of commands. Thi s capability has been combined with Suggestions to subsequently apply the commands through menu selection.

Cabinet of Commands Metaphor. When a new user starts is selected, the user could be notified of others which interaction, the interface he sees corresponds with the might al so be of interest. Finally, the transition from supply assumptions for novices: a small set of commands which cabinet to active command is an opportunity for the system are avai lable through menus. The expectation is that an to maintain a simple model of w hat the user knows about initial simple command set is easi ly mastered. The user also the system. is protected from inadvertently activati ng a seriously harm­ Fig. 8 shows a screen image of the supply cabinet meta­ ful command. phor in use. The user is browsing through commands for Th e user also has avai lable to him a supply cabinet that the graphics editor (which is described below). He has holds a library of commands. When a user wants to expand elected to modify the status of the Line Mode command the capability of the user interface, he goes to the supply (which allows creating lines through the graphics editor). A cabinet, perh aps browsing through what is there, or search­ menu has popped up in the center of the screen, giving him ing for a specific kind of command. He can select com­ an opportunity to bring the command into his environment mands to be activated, which brings them out of the supply or take it out, change the command name (for type-in cabinet, and install them in his working environment. The entry), change key bindings, change the shape of the cursor user can thus build up a command-rich interface, but only when the command is invoked, change the li st of menus it if he chooses to do so. The command set, in terms of what will appear in, and so on. is active and what is not, is entirely under his control. 3) Flexibility Through a Database of Commands: The The supply cabinet metaphor offers other opportunities supply cabinet holds several pieces of information on each for helping the user understand the system (a lthough the command: the command name for keyboard entry, short following have not yet been implemented in the UCL). and long forms of documentation, what menus the com­ When a command in the supply cabinet is se lected to be mand should appear in, and the special keystrokes that will moved into the user's environment, a tutorial could be invoke the command. Th e supply cabinet is implemented invoked (or available) on its use. Th ere might also be as an interface to a command database. collections of related commands that, when one of the set The UCL command database al so serves the goal of

1778 PROCEEDINGS OF THE IEEE. VOL. 73, NO. 12. D ECEMBER 1'l85 TOJI

COtltiAIID TABLE : COMMAim IIAtiE ASSJGtiED hEVSTROr.E DESCRIPTIOH Arc Mode Meta- A Begln USlng •rouse t o or.~ ~· <'II"CS C1rcle Mode 11eto!!-C 8eg1n us1ng rouse to dro1.• c i r-cles Clear BacKground Plcture Cont··ol-Meta-Clear-lnput Delete the current backqround p1cwre 'r·o•• t M dlSDlay Clo?ar Ptcture Cl ea.... -tnput Delete all ObJects 111 t he foregr our,d ptcture Copy ObJeCtS Mode ~leta - E Cop~ selected obJects f ro" oo1nt to oo 1nt u1th Mouse Crosshalr On/ Qff Control -H COI"'plel'lent crosshoir· cursor settlf)Q Def lnE Present at wn super-J Define a r~ ultl-ftle present ation - Def 1ne S•JbP lC tur~ Meta-G ,---~(:":'L"':'in-e--:M:-:o-d-:e....,.) --.,ted group of ob,1 ects 1nto ·• subp1ctur·e Delete ObJects M~de Me t a- D .. cts for~ d E' 1 et t on .n• th r1ouse Dlsplay Presentat1on Super- Y rent pr·esent at ton f 11 es tn seQuence Dr·ag Mo•Je t1ode Co,trol -Het

Mouse ngl1t t hree H;rpo;:r-Suoer-H L 1 st Commands cursor nqht t hree pl ~els/gr i d-powts Mouse r 1ght t.ro Super·-HMd-n Scroll Uo cursor ngl1t t uo p l ~ ~lS/g r id-pJlnts t1ouse up one Hype,~ - H,nd-up Sc,-o l l Do~·m cursor uo one p1:--:el /gr 1d-po1nt 11ouse up tl1 r~e Hyper·- Super·- H cursor IJP t 1·1ree '11:-·e 1S/g f~ ld- poli'H;: s 1·1ouse up tuo Super·-Yand-up Too of Drsplay cur'sor up t•Jo pn:els/grid-polnts 1 Move ODJec ts tlode Meta-M Bottom of Crrsola}' ed ObJeCts fro" point to poH>t ''ith Muse Next P1cture Contr· ol - 11eta-.....___ .,. E_x_•.,.t-====~ pictur£ on pv;tur·e 11st ~l ,;re Below Co rnrn.ultl Edi tor Flip the activeness of this command. Key assignments: none

01(04(_85__ 12 .:_44 : 38 TEHNRN T Fig. 8. The supply cabinet mataphor allows the user to browse through a collection of commands. The com mands can be activated and deactivated at the user's discretion, giving him control over the commands in his environment. A command supply cabinet is shown here for the graphics editor. consistency between applications. Because all the com­ IV. COMPONENT SOFTWARE mands and their means for invocation are in a database, the entire UCL mechanism can be readily applied to a new A The Graphics Window System application by just changing the contents of the database. This had additional implications in the features that can be The user interacts with the di splay through windows included in the UCL mechanism, and thereby ca n be auto­ (rectangular regions of the screen which behave as virtual matically gained by any application that uses the UCL. terminals). Th e windows as built at M IT are implemented in These include multiple command en try modes available for the object-oriented sublanguage, Flavors [4], which allows a each command (menus, si ngl e keystroke commands, and variety of t ypes of windows to be readily constructed. The command name entry), command macros, and several forms M IT software includes a large number of w indow types: of help on each command. Final ly, UCL supports inheri­ text windows, a variety of menu windows, and many kinds tance of commands from one system to another. If, for of windows specific to applications and subsystems. The example, the user can list his directory or type a file at the MIT software also included graphics primitives for drawing top level of a system, why not enable him to have these to windows. The Graphics Window system (GWIN) is an capabilities plus additional ones (assuming there is no con­ extension to the LISP Machine window system for the flict) when one moves into an application? The UCL allows Explorer. GWIN is novel among graphics window systems in commands to be inherited in this way. that its desi gn allows ready extension of the set of graphical Most of the features that the UCL implements are found types that it manipulates. in the [8] and ZMACS text editors. The contribution A program can draw lines, arcs, etc., on any window on a of UCL has been to abstract what was coded into ZMACS, LI SP Machine, but a GWIN window maintains an internal implement it as a command-database-driven utility, which representation of the graph ics objects that are displayed on enabled the supply cabinet metaphor, and make the package the window. The internal represen tation allows ready ma­ available for use with other applications. nipulation of graphics objects, including the abi lity to inter-

TENNANT e ta/,: INNOVATIO NS FO R THE Tl EXPLO RER COMPUTER 1779 actively select graphics objects with the mouse for manipu­ cod e that displays triangles and gene rates the image on the lation. screen. A GWIN window is a view of two-dimensional graphics In contrast with conventional approaches, each item on objects on an infinite drawing surface, some fraction of the display list of a GWIN w indow is an object, and a which can be visible through the window. The window can program communicates with these objects through message be panned over the drawing surface, and can zoom in or pass ing. All of the graphics objects respond to a minimal set out indefinitely on the drawing surface . When zooming on of messages such as draw , move, scal e, and distance-from­ a picture, all elements are scaled appropriately for the a-point. Each graphics object is able to respond ap­ zoom. propriately to these messages. Several types of primitive graphics objects are supported The advantage of graphics entities being objects which under GWIN including rectangle, triangle, arc, circle, line, are manipulated through message passing is that the set of spline, poly-line (broken line), text, and bit-pattern. Com­ entities known to GWIN is easily extensible. If one wanted pound objects may be hierarchically composed of simpl er to add to the object types, one only needs to define a new ones, so that one may operate with the primitives ap­ object that can respond to the predefined set of graphics propriate for a specific application, such as symbols for object messages. With a conventional system, a new graph­ resistors, capacitors, wires, power supplies, and amplifiers. ics entity would require modification of the code for draw­ The novel contribution of GWIN is in its object-oriented ing entities, a modification of the code for moving entities, approach, and the facility for extensibility that this allows. and so on. In other words, the conventional approach Many graphics systems (10], (11] have been built that main­ requires code modification while the object-oriented ap­ tain an internal model of the graphical entities that appear proach of GWIN requires only that a new object respond to on the screen. They typically maintain a display list of these the set of required messages. entities. When the window is to be redisplayed, the display B. The Graphics Editor list is scanned. Each item on the list, a primitive graphical entity, is displayed. If, for example, the entity is a triangle The Graphics Editor (GED) was written as a means to primitive, the display routine branches to that portion of interactively compose and manipulate GWIN graphical ob-

0l / 0q/ 85 12 : 37 : 43 t.e!-lt•oard IJSI:P. ; Choose - 'Jq : ~'" U D : f TENHP.NT ll.BLAPIS . QtiS 2?034 Fig. 9. Interacti on with the graph ics ed itor, G ED, is shown. The user has popped up a window through which the para meters of one of the rectangle objects can be edi ted.

1780 PROCEEDINGS O F TH E I EEE . VOL. 73. NO. 12. D EC EM BER 1985 Copy Clear Circle Delete Clear Background line Drag-Copy Find Paint Drag-Move Insert Kill or Save ~X Edit Parameters Kill List/Select Rectangle Exit Kill or Save load Undefine Ruler Move List Modify Spline Restore User Status Next Restore Text Rev ert Picture Status Previous Save Triangle Revert User Status Read Background Save User Status Redraw Scale Reorder Status Revert Undo

Grid set to Yes Grid set to No , .,- - h l'S 1t1r I Begin using mouse to draw polylines Key assignments: Meta-W

USE R: Me ~u choose _, '.!4 , \I~U D· rTEiiNRNTllBLARI S. QI·IS 1'?65 Fig. 10. Interaction with the graphics editor is mediated by the Universal Command Loop (UCL). UCL allows commands to be entered in several ways. The pop-up menu of active commands shown here is one way. Other ways include smaller, more specialized menus, typing in command names, and invocation through single keystrokes.

jects. A program can be written to create and move graph­ C Relational Table Management System ics objects in a GWIN window, but GED gives the user a means for directly manipulating GWIN graphics objects Database management being important in such a wide interactively. GED was originally implemented for use in range of applications, it was clear that a database manage­ debugging GWIN, but has proved indispensable in its own ment system would be an important component for pro­ right for composing pictures for hard-copy output or for totyping on the Explorer. Some unique problems and op­ composing pictures for use with other interactive applica­ portunities arose in the context of building a database tions. management capability in a LISP environment. Our ap­ GED is implemented using the Universal Command Loop proach resulted in the Relational Table Management System (UCL), and served as a testing ground for the ideas of UCL. (RTMS). RTMS is unusual primarily in that it can hold any Fig. 9 shows an image of an Explorer screen using GED. The sort of LISP object as a data element, the data are manipula­ user has popped up a window allowing the parameters of ble either through the query language or independent of one of the rectangle objects to be edited (it is the largest RTMS. In addition, the query language is extensible. rectangle). The user has widened the border of the rectan­ RTMS implements most standard relational database ca­ gle. Fig. 10 shows the outer rectangle with its enlarged pabilities. Data definition functions define, rename, or de­ border. It also shows a pop-up menu showing all the active stroy databases, relations, views, attributes, or secondary GED commands. Command selection from this menu is one indices. There is no restriction on relation degree or cardi­ of several methods of command invocation (using UCL) in nality. A relational algebra includes operators RETRIEVE the graphics editor. Users may also specify commands (select and project), JOIN, UNION, DIFFERENCE, and INTERSEC­ through smaller menus of command clusters, selected from TION as well as operators INSERT, DELETE , MODIFY, GRANT, and the menu bar at the top of the display. Finally, most REVOKE. Certain basic features of most relational databases commands have single keystroke equiva lents for rapid invo­ are not present in today's RTMS: full secure protection cation by skilled users. cannot be supported on data resident on ; no

TENNANT eta/., INNOVATIO N S FO R THE Tl EXPLORER COMPUTER 1781 1 locking scheme protects concurrent access by multiple users (retrieve from 1 EMPL0YEES into MY-EM P LOYEES or processes; finally, tables must be in virtual space to be where {AN D (GT age 30) operated on. These restrictions will be lifted as RTMS ma­ {OR {GT salary SOK) {KEEP-TUPLEP)))) tures and, while the system is not at present a full DBMS, it is nevertheless useful. / In another example, a user uses a functional definition of a v Of interest in this section is how the LI SP environment database key to specify a join over two tables where differ­ affected the design of RTMS. The LISP Machine environ­ ent representations of the same conceptual entities are ment is a one-language, single-use r environment. Any pro­ maintained. cess ca n browse any data structures within virtual memory (join ' R1 and ' R2 and so there is no enforced hardware or operating system w here (EQ (make-julian-date r1.mo r1.day r1.yr) protection. LI SP users routinely build co mplicated data r2.jdate)) structures from several primitives including atoms, lists, arrays, flavors, etc. LISP users depend on garbage collection In a final example, a user wants to " find the interstate and compaction to manage memory for these complex highw ays in Texas that go through Dallas." To do this, he objects and so the detailed layout of these complex objects might join the relations HIGHWAY (name, type, graphics­ on disk pages is left to the system. subpicture, · · · ) and CITY (name, population, graphics-sub­ Conventional database management systems (DBMS) picture) using an application-dependent join predicate (e.g., INGRES [12], SQL [1 3]) provide the sa me sort of func­ GRAPH ICS-INTERSECTP which returns true if two graphics enti­ tionality as described for RTMS but usually in an environ­ ties intersect. In the literature on conventional databases, m"ent w here the only primitive data types are character only (14] discusses implementations of re lated work on strings, numbers, and dates. In conventional database abstract indices. management systems, the only functionality available is Traditional databases maintain an " inside- outside" dis­ contained in the data manipulation language and interfaces tinction. Ei ther data are managed by the database or they to host languages which are frequently awkward to use. In are outside of database control. If an application maintains conventional DBMSs, secure programs can guarantee pro­ its own data but needs some database operations on it, in tection. Further, much attention is spent in matching record traditional databases, the data must be copied into the and index structure to page layout to minimize disk access database, operated on, and recopied to the application. emphasizing efficiency at the expense of functionality. Because there is no hardware protection on a LISP Machine, .1 In a LISP environment, users would find a relational this distinction breaks down for the LISP Machine database. database management system less useful if it failed to A user can browse through any data structures including provide support for LI SP data types . Hence, RTMS allows those managed by the database. One of the RTMS goals any domains that users want to define. Users can define was to turn this problem to advantage and allow the data­ domain-dependent functions for validating the data type of base to use user-defined structures. domain elements inserted into relations, for domain-depen­ In RTMS, tuple structures and table storage structures can dent partial ordering functions (e.g., GREAT ER-THAN-IN­ be user-defined using accessor functions. RTMS comes with LENGTH). Default domains are also supported to allow users a predefined collection of useful !tuple implementations to ignore the details of domain definition in simple applica­ including tuples implemented as linked lists, structures, and tions. Any type of data object may be stored in a rel ation flavor instances. In addition, RTMS provides a predefined including pointers, lists, flavor instances, arrays, variables, collection of storage structures including balanced tree, file names, relation names, graphical objects, and large hash, and heap, useful for building indices. A user can amounts of text. In the pure relational model, components specify the tuple implementation and storage structure of relations are atomic, but RTMS recognizes the atomicity when defining a relation. In addition, RTMS provides an is application dependent. RTMS does not enforce artificial operation ca lled ATTACH-RELATION, which allows a user­ restrictions requiring flattening complex data structures. defined data structu re that matches one of the tuple imple­ I The LI SP environment is a one-language environment. mentation- storage structure implementations to be grafted Th e relational algebra of RTMS is implemented with LI SP into RTMS as a database relation without recopying, thus functions so it is easy to embed in LISP programs. The allowing a user easy access to RTMS query functionality ability to embed database ca lls in programs in a one-lan­ incl uding the ability to build other indices on the data guage environment makes passing parameters between the structure to provide al ternative access paths. A correspond­ database operators and other LISP functions straightfor­ ing DETACH-RELATION operation allows a user to remove a ward, requiring no specialized mechanism. Within RTMS, database structure from the database without destroying it. names of databases, relations, and attributes follow the An application of these capabilities is to facilitate the build­ same rules as do names of LI SP variables. In addition, it is ing of a REL ATION-MIXIN which adds to a LISP Flavor the natural to allow LI SP predicates in the WHERE clause of ability to manage and access instances of the Flavor and RETR IE VE statements and as the predicate in th eta JO INS. For perform set operations on them. instance, if a user defines a predicate KEE P-TUPLEP which The added flexibility offered by RTMS must be accompa­ displays a tuple and allows him to mouse KEEP TUPLE or nied by a concern for efficiency. Two optimization prob­ REJECT TUPLE choices, then he can include KEEP-TUPLEP at the lems occur when users are given ready access to LI SP. First, end of a WHERE clause s-ex pression, allowing him to se lect in operators like RETRI EV E and JOIN, allowing user-defined or reject most tuples automatically based on the first part of functions, can hide from the opportunity to use defined the WHERE clause and manually select from the remaining indices making it necessary to loop through all tuples in a tuples as in: relation executing the user-defined function. For instance,

1782 PROCEEDINGS O F THE IEEE . VOL. 73, NO. 12. DECEMBER 1985 in the query (RETRIEVE from 'R where (EQUSTRINGLENGTH A terns, it correctly interprets 100 percent of the utterances 10)), if the EQUSTRINGLENGTH predicate is not registered with entered by users. It also enables mixing natural language RTMS, the EQUSTRINGLENGTH predicate must be executed input w ith other input modalities such as graphics. Finally, for each tuple in R. When the user is working with personal it requires fewer resources to run and can be quickly sized databases or when he has a new need unsupported tailored to new applications. by current RTMS functionality, this solution is acceptable. Watt [15] defined a " habitable" sublanguage as " one in But a framework for adm itting optimization hints to RTMS which users can express themselves without straying over can allow the system to retain the ability to optimize while the language boundaries into unallowed sentences." Codd allowing extra flexibility. The way RTMS handles these hints [16] pointed out the "semantic overshoot" problem, that is .to provide an optimization handler for user-defined func­ many user queries overreach the coverage of the system, tions, so that AND, OR, EQ, GT, LT , and other commonly used asking reasonable questions that the system semantics can­ functions are supported. To plan how the RETRIEVE will be not handle. Si milar syntactic and lexical overshoot problems implemented, RTMS interprets the WHERE clause as long as occur, when the user employs grammatical constructions it is not blocked by user-defined functions. Thus in a WHERE and words that the system does not cover. clause sim ilar to one in a previous example, "Undersh oot" problems occur as well. Tennant [17] found that users of the PLANES natural language interface devel­ (AND (L T age 40) (OR (GT age 30) (KEEP-TUPLEP)))) oped negative expectations concerning what the linguistic if an ordered index on AGE exists, only tuples corresponding and semantic coverage of the system was, and so they did to employees under 40 years old need be considered, all not ask more complex queries, many of which could be tuples between 30 and 40 must be returned, and KEEP-TUP LE P handled by PLANES. must be executed on all remaining tuples. The optimization Focusing on the goal of habitability, we conceived of a capability is extensible; users can register a definition for new sort of natural language interface based on combining (opt-sto) - (opt-fn) with RTMS to inform RTMS of the menus w ith a grammar-driven control structure. Menu­ opportunity to use a supported storage structure in imple­ based natural language interfaces [1 8]- [20] guide a user in menting a new function, as when one defines OPT-TREE­ the completion of a query and constrain him to a limited STRINGLENGTH to tell RTMS to use a TREE structured index but expressive natural language subset. The basic idea is ordered by string length to locate strings of lengtr 10 in the that instead of typing natural language in an unconstrained example above. way, a user selects words and phrases from a conste llation In sum, the interesting contribution of RTMS is to make of menus to construct a sentence. A semantically con­ the functionality of a relational database more easily strained grammar drives the menu display, dynamically de­ extendable by the user and to be well integrated with the termining which menus should be active and what the Explorer environment. Often increased functionality is paid contents of the menus should be. In this way, a user's input for by decreased efficiency. Proponents of the conventional is guaranteed to be both grammatically understood and relational model claim that the physical tree structures of a semantical ly meaningful to the system. The approach has hierarchical data model can be implemented at the storage the advantage that all inputs to the system are understood, level w hile still giving users a logicall y independent tabular thus giving a 0-percent fa ilure rate. view of the data. Tot;rk-e-f~o~l-1-advantage of the hierarchical Fig. 11 shows a sample NLMenu screen interfacing to a storage, a user would have to restrict himself to just the small database (from (21]) consisting of three tables PART physically supported join or index paths. Yet, the extra (PART#, NAME, COLOR, WEIGHT, CITY), SUPPLIER (SUPPLIER# , flexibility of requesting logically meaningful searches over NAME, STATUS, CITY), and SHI PMENT (PART#, SUPPLIER#, QUAN­ unsupported paths is the central strength of the relational TITY). The user constructs a natural language query (in this model. In RTMS, the ability to add user-defined domains, case, in English) in the sentence window, the central empty search predicates, and indices makes RTMS more useful in a window in the figure. The query is constructed from con­ LI SP environment. A user seeking efficiency can restrict stituents that he selects from the active menus above. himself to supported data types, search predicates, and Menus with white backgrounds are active. Other menus are access paths. A user seeking flexibility can more easily drop temporarily inactive. The grammar of the SUPPLI ER-PARTS into LISP to build more complicated search strategies. If interface controls which lexical items are reachable from those search strategies are important for his application, he the current sentence fragment and paints w indows " active" has a route to add a more efficient implementation to if they contain legal next choices (narrowing the choices RTMS. We expect to be able to use these hooks to define accordingly) making other windows " inactive." new implementation types that remove the restriction that An example iII ustrates the idea. The user selects " Find" relations must be in real memory, without affecting RTMS. from the active menu in Fig. 11. "Find" appears in the sentence window in Fig. 12. He then sel ects " parts" from the active "nouns" menu. The sen tence now reads " Find parts." This is a complete sentence, understandable to the D. Menu-Based Natural Language Understanding system, so the system presents the "Execute" option in the Many software prototypes require users to interact with " system commands" window just above the "sentence" complex systems. One of the component software packages window. The user may execute the query as it stands or on the Explorer is a natural language processing interface. It continue to qualify it. He elects to execute it and the result can serve as a highly expressive yet easy to use front-end to is shown in Fig. 13. He then decides to incrementally a w ide variety of applications. It is novel in that, while it modify the query. He chooses "whose color is" and then provides the same coverage as other natural language sys- " ( specific colors)" to specify actual database values. A

TENNANT eta/.: INNOVATIONS FO R THE Tl EXPLORER COMPUTE'R 1783 the number of for of and or ( ) by the average the total

Exit System

N1 M enu D1sp 1ay ~llnd o'• P11rts And Supp 1 i er s Er:C -c f -cutput

Fig. 11. An NLMenu interface to a database is used to construct question in Engl ish from words and phrases selected from the menus. The NLMenu system has the same expressive power as conventional natural language systems, yet 100 percent of the questions entered will be understood. special window, cal led an " interaction expert," pops up and the structure of the domain object s, as well as their with specific colors in it as shown in Fig. 14. The user names and intended semantic interrelationships. Conven­ selects "blue" and " red." The COLOR pop-up menu shown tional Nlls take the opposite approach and burden the is an example of one so rt of expert. Experts provide a system with this sort of knowledge, allowing the user a specialized hook for placi ng functions that support the user natural or at least familiar mode of communication, English, in specifying a database value. The user can go on to add at the expense of the ease-of-use problems described earlier. other qualifications to his query, he can save it and enter a The NLMenu approach offers an attractive middle ground different query, later retrieving his old query. for guiding the user to use a limited language, a language The NLM enu guided approach restricts the user to the that ca n be carefully engineered to allow natural language defined language in just the right way, so that he beco mes expre ss iveness and still reflect the system's capabilities. aware of the full extent of the language but can not go 1) Building and Maintaining Usable NLMenu Interfaces: beyond it. Learn ing time is greatly reduced si nce it takes no We approached the problem of building and maintaining experi ence to begin to state legal se ntences in a new usabl e menu-based natural language interfaces from two limited language. directions. We reasoned that, in the general case, menu­ NLM enu capitalizes on the user's ability to meet the based natural language interfaces would need to be wri tten system part way by restricting him to a limited language manually by a lingui stical ly trained interface designer but that covers an application, and so provides a path for the that in some important special cases, like natural language user to understand the coverage of the system. Conve n­ interfaces to databases, interfaces could be generated auto­ tional formal query languages and conventional natural matically. To support the manual design of interfaces, we language interfaces (Nlls) both ignore the use r's ability to provided functions that check the well-formed ness of meet the system half way. Conventional formal query lan­ grammar rules and lexical entries, that identify grammar guages tend to burden the user w ith knowing the details of nonterminals and lexical entries not reachable from the the system, including the syntax and se mantics of queri es grammar's root, that generate sets of sa mple se ntences, that

1784 PROCEEDINGS Of THE IEE E. VOL. 71 NO 1 ? nFIFMRFR 1QA ~ puts shipments narne part# supplier # status weight quantity

Play Input

l 1•1enu Di spla~ ~1 nd ou Pa1'ts And Suppl ier·s E nd -¢j -retput

Fig. 12. The user is building a question with NLMenu. He has selected " Find" by pointing at it w ith the mouse. " Find" is written in the question window. display parse trees, and that aid in partitioning the lex icon available. As a result, end-users could then build their own into separate w indows. These tools made designing and interfaces quickly for low cost. debugging hand-written grammars much easier. They were To date, about fifteen interfaces have been built usi ng intended for users with special applications w here it was the interface generator, many in a few hours. Sample inter­ cost effective to build interfaces by hand [22], [23]. face SCreens to a RESTAURANT DATABASE and a BASEBA LL STA ­ Much natural language research has been ai med at the TI STICS database are show n in Figs. 15 and 16. References important special case of natural language interfaces that [20], and [25] provide other sample interfaces, more detail s faci litate database retrieval. An important research area has on interface generation, and menu-based acquisition di­ involved transportability of Nlls to new applications and to alogue that allows users to build domai n specifications. By different target database management systems. If natural virtue of the menu-drive n approach, automatical ly gener­ language interfaces to new applications cannot be built ated interfaces are immediately usable without the long cheaply, then natural language w ill not be used widely lexica l tuning phase needed for 'conventional natural lan­ except for important applications. For conventional trans­ guage interfaces. New use rs, even those naive about the portable natural language interfaces, the current state of the coverage of a given database, appear to have little trouble art is that bare-bones interfaces to new applications can be generating interesting queries. generated quickly but that an expensive empirical tuning 2) Limitations of M enu-Based Natural Language: Menu­ phase is needed to discover all the many ways a user w ill based natural language understanding has some inherent refer to domain entities. For Intellect interfaces, for exam­ limitations, inherited from grammars and from menus. For ple, such a tuning phase ca n require two man-months of a instance, the " weak bridge" problem occurs w hen the trained interface des igner's time [24]. We reasoned that, if amount of context available in displayed menu items is not an interface generator for menu-based natural language eno ugh for the user to know where a particular selection interfaces to a database could be built, automati cally gener­ will lead. Similarly, the " big menu" problem occurs when ated interfaces would immediately be usable without the the user has trouble locating or discriminating between long and expensive lexical tuning phase. This is possible menu items w hen many sentence co mpletions are avail­ because the menus would limit the user to the sublanguage able. Careful design of th e NLMenu grammar can forestall

TENNANT et a/.: INNO VATIONS FO R THE Tl EXP LORER COMPUTER 1785 these problems, but interface designers need to be aware of We f eel that computing environments like that on the these sorts of problems. Even with these limitations, large Explorer represent a new class of capability in interactive and complex but still usable applications can be built. C. W . computing which is highly functional and can significantly Thompson [26] extends the NLM enu prototype to accom­ enhance user productivity. At the same time, the high modate the ACCAT Blue Fi le describing naval ships, a large functionality poses a challenge: to prese nt that range of command and control database comprised of fourteen rela­ functionality to a wider class of users. While the designers tions w ith over 70 unique attributes. of many computing systems have elected to build sim­ plified computing environments that can be quickly mas­ v. CoNCLUSIONS tered, the Explorer environment is one that, with time taken to become proficient, can provide the user w ith the tools This paper has described a collection of software innova­ and materials necessary to become truly proficient at the tions from Texas Instruments that have become embodied craft of computer programming. We see the future of the in the Explorer computing environment. We have enhanced Explorer environment as one of continuous improvement in this environment in two ways. We have made the vast the learnability and usability of this sophisticated, produc­ range of capabilities of t he LI SP Machine environment more tive environment, while at the same time of continuous access ible to nonexpert users through Suggestions Menus enhancement of its scope. and the command supply cab inet metaphor, implemented as the Unive rsal Command Loop. W e have also added to APPENDIX I the component software available in the Explorer environ­ ment by providing the Universal Command Loop, the LI SP M ACHINES Graphics Window System and Graph ics Editor, the Rela­ A. Why LISP? tional T.able Management System, and the Menu-Based Natural Language Interface. The innovations represe nted by LISP is an old computer language, having been intro­ these systems show innovations in both concept (Sugges­ duced in its primitive form by j ohn McCarthy in 1960 [27]. tions Menus, Universal Command Loop, Menu-Based Natu­ Since t hen it has evolved by additions and extensions as ral Language Interface) and design (Graphics Window Sys­ people have applied it to a wide range of problems. There tem, Relational Table Management System). have been two major evolutions: the path that lead to

[ I - - ' I ~ •• - Corn'lands - Nouns - Experts Find Draw suppliers parts whose pa.rt name is Attributes whose part part# is weight a bar chart whose part weight is quantity a line graph a pie chart which are supplied by city a histogr.m a scatter plot name p•rU' supplier I status Col'lparisons between greater than less than greater than or equal to less tflan or equal to equal to ~nnector;

I . Pl.')' Input . I F 1nd parts

'

till1: rtL~I Eii U Cdr d1nal1ty: 5. PJ;J5 IIArtE: CAI1 COLOR : BLUE WEIGHT: 12. Cl T'i: PARIS

PAPT~: PR 4 NAME: SCP. E~I COLOR: P.ED I-lElGHT : 14. Cl Ti': LOIWON

PART ~: P~3 NAME: SCREI-I COLOR: BLUE I-lE lGH T: P. Cl T'l: ROME

PARTn: P~2 NAME: BOLT COLOR: GPEEtl I-lElGHT: 17. CI T'/ : PARIS

PART~: P~l NANE: IIUT COLOR : RED I-lElGHT: 12. Ci Ti': LOIIDOtl

Execut1on coMpleted. ,enu Di splO!J I.J l ndor,r Parts And Suppl i er·s

Fig. 13. Th e user has built the question " Find parts" and eva luated it. The result is shown in the window at the bottom of the screen.

1786 PROCEEDINGS O F THE IEEE, VOL. 73. N O. 12, DECEMBER 1985 COLOR values :

Do It D

Connectors the number of for of and or ( ) by the average the tota.l

P"5 NAME: CAM COLOR: BLU E WEI GH T : 12 . CITY : PARIS

P"4 IIAOI:':: SCREW COLOR: RED WEI GHT: 14. CIT '.' : LONDOH

P"3 IIAME: SCRE>I COLOP : BLUE WEIGHT: 17. CITY: ROME

P~2 lmtiE: BOLT COLOR : GREEH •lEI GHT: 17 . CITY: PARIS

PO! NAME: I~UT COLOR: RED WE I GHT : 12. C I TV: LO~IDON

E>

HlM~?nu Di splay IJ1ndow Ports And Suppllei"'S

Fig. 14. The user is refining his question by adding further qualification to it. This figure illustrates that a special kind of window pops up to allow entry of specific database values, in this case the colors of parts. These special windows, called " interaction experts," allow mixing natural language interaction with other kinds such as graphical interaction. lnterLISP [28] and the "other LISPs," many derived from ing commercial support. Th ey are: the facilities of the work at MIT. The lnterLI SP evolution was virtually stopped language, and the advent of co mputer architectures w hi ch by standardization in the mid-1970s, so that it could be support LISP efficiently. used in a production role, while the evolution of other LISP allows the programmer to delay (or sometimes dialects continued in research environments, most becom­ ignore) many implementation details, making the job of ing ever more complex, and with increasingly many splinter prototyping proceed more quickly [30]. For exa mple, LI SP dialects. In an attempt to bring order out of the chaotic LISP handles heap-allocated memory management for the pro­ situation, a group of users organized a standardization ef­ grammer. Also, LI SP is dynamically typed, mea ning that the fort, which culminated in the definition of Common LI SP user need not declare the data types of va ri ables prior to [29]. This effort tri ed to capture the improvements which use. Data typing is done by the LI SP syst em at run time. had been made by the research efforts since the standardi­ Once a prototype has been completed, however, many zation of lnterLISP, while bringing about a measure of dialects of LISP allow data-type declarations to increase consistency w hich would make possible the use of the new efficiency. LI SP maintains a database facility, of sorts, in the language in a production environment. runtime environment. Every symbol can have a set of prop­ LI SP has beer) the language of choice for artificial intelli­ erties associated with it, which can include flags, data gence research since its introduction. It has also been used structures, or code. Finally, LISP includes a function, ca lled for developing powerful mathematical tools, such as Mac­ EVAL, w hich indicates that a data structure should be inter­ syma, a symbolic mathematic system, w hich can perform pret ed as code and eva luated. This allows for databases of algebraic manipulations, formal differentiation and integra­ code (as opposed to databases of data), w hi ch leads to tion, and algebrai c simplification. It is now being used for a novel programming paradigms. It also allows for programs w idening spectrum of applications in number theory, w hich compose or modify other programs, which programs database queri es, computer and digital circuit simulation, can then be evaluated. Th is is especially useful in automati­ mathematical logic, and expert systems. cally appending debuggi ng an notations to code, then auto­ There are two primary reasons why LI SP, which has per­ matica lly removing the annotations. sisted so long in research environments, is suddenly enjoy- The powerful symbolic manipulation faci lities and the

TENNANT et al.: INNOVATIONS FOR THE Tl EXPLORER COMPUTER 1787 and draw a map of them the number of tor o f and

NlMen u Displ ay Window Aus tin Re staurants

Fig. 15. An NLMenu interface to a restaurant database. For some applications, NLMenu interfaces can be automatical ly generated from a description of the database. This interface was automatically generated. extensibility of the language have made it possible to pro­ dispatching to the right code function for the type of data vide powerful programming tools including graphic displays to be processed. For example, addition of numbers is effi ­ w hich greatly improve the productivity of programmers. ciently and re liably executed because tags dist inguish single­ Program debuggers and analyzers are available to help in precision integers, floating-point numbers, and multiple­ testing of programs. precision integer. In other machines, errors could be made The above capabilities of the language LI SP and its imple­ if the wrong operator is coded in the program for the type mentation systems have made it attractive to a growing of data encountered. This kind of error is not possible in a number of people who have to solve complex problems. LISP Machine program, because of the built-in type check­ Th e language w ill continue to evolve by extensions to ing. accommodate ever more compl ex problems. The tagged word also prevents inappropri ate use of pointers and functions. It permits the collection and return to use of inaccessible data structures (garbage collection) in B. Advantages of LISP Machines over a safe and automatic manner. The dangling pointer problem Conventional Machines (a pointer that does not point to a data structure, as ex­ The LI SP Machine architecture has an instruction set pected) so common in other languages and architectures which facilitates running LISP efficiently and reliably. Many cannot occur. of its features are aimed at providing a superb environment The LISP Machine architecture has special hardware for for programming in LISP, although some are useful for handling stacks and stack frames which permit efficient programming in other languages. function ca lling. In addition, the hardware helps the debug­ In each word in the LI SP Machine there is a field called ging tools to do their job by providing access to the current the tag, w hich identifies the kind of information which is stack of frames, so that the full current state of the machine contained in the word. The tagged word permits rapid is readily available. This capability has resulted in a suite of checking of the type of object represe nted and fast circuitry debugging tools whose power is unmatched in any other (e.g., a barrel shifter and dispatch memory) permi ts rapid environment.

1788 PllllrHniN(;<; ()F THF I FH vn1 7< N n 1? nFr FMRFil 1QRt; ... - ~ .. COMMd nilS Nouns Ex erts Mod1f1ers Find Draw batters pitchers whose batter name is Delete Insert teams whose batter league is "'A ,..t t'"r-l"'b-u""t_e_s----~ whose batter team Is whose pitcher name Is btttlng average a bar chtM whose pitcher league Is games played a lkle graph a pie chart whose pitcher team Is at bats a histogram a scatter plot whose team name is ~~: a surface graph whose team league Is whose individual batting average Is doubles whose batter games played Is triples whose batter at bus Is homet"uns whose batter runs is RBIS Con arlsons whose batter hits is steals whose batter doubles: is wins between whose batter triples is losSes greuer than whose batter homeruns Is ERA less than whose batter RBis Is gam2>: pitched greater thin or equal to whose batter steals is less than or equal to complete games whose pitcher w ins is innings pitched equal to whose pitcher tosses is hits given up whose pitcher EllA is walks an d or whose pitcher games pitc hed is strikeouts whose pitcher complete games is shutouts whose pitc her innings pitched is saves whose pitcher hits given up is

I. . I

(NL/·1: DRR>I ' :GRAPH-TYPE 'IIL/1 : BAR-CHART ': TI TL E ! ClUOT E "BAR CHART OF THE DOUBLES AND TRIPLES A ~ID HOME RUNS BY NAME FOP BATTEF~S WHOSE IIIDI',IIDUAL BATTING A'JER AGE IS GREA ER THAll 0 . 27 ") ':OPTIONS ' tilL ' : RELAT I Otl ' IILN:BATTER ' : ~IHEP.E - CLAUSE ' ( ' HLM: AJERAGE B.2? ) I: ;:- All R 'Hltl: I·IAME lll'

Fig. 16. An automatically generated NLMenu interface to a baseball statistics database.

Many of the debugging tools are implemented as objects (flavors) and windows are assisted by hardware processes, which can run side by side with the process features and the high quality of the display graphics. being debugged. O n the LI SP Machine, the Debugger (for examining the dynamic state of a program), the Inspector (for examining the state of complex data structures), and REFERENCES Peek (for examining the state of active processes) have full access to the state of the process being debugged. In (1] A. Bawden, R. D. Greenblatt, J. Holloway, T. F. Knight, Jr. , addition, the programmer, at a break, has the full capability D. A. Moon and D. L. Wei nreb, " The LISP Machine," in P. H. to cause evaluation of LISP forms in the current environ­ Winston and R. H. Brown, Eds., Artificial Intelligence: An MIT Perspective Volume 2. Cambridge, MA: MIT Press, 1979, pp. ment of the debugged process. In this way he can examine 345-374. the state, and he ca n summon the full power of other tools, [2] R. D. Greenblatt, T. F. Kn igh t, Jr., J. Holloway, David. A. such as the Editor, to help examine pertinent source code, Moon, and D. L. We inreb, " The LISP Machine," in D. R. t he current values of all variables, and anything else in the Barstow, H. E. Shrobe, and E. Sandewall, Eds., Interactive Programming Environments. New York: McGraw-Hill, 1984, machine he w ishes. All of this can be accomplished without pp. 326-352. disturbing the possibility of res uming the debugged process [3] D. A. Moon, R. M. Stallman, and D. L. Weinreb, The LISP at the point t he break occurred. Machine Manual. Cambridge, MA: MIT Press, 1983. The programming environment on the LISP Machine is (4] R. M. Stallman, D. L. Weinreb, and D. A. Moon, LISP Machine the most powerful one existing. This has happened because Window System Manual. Cambridge, MA: MIT Press, 1983. [5] R. Wall, " Industrial strength knowledge representation," in the nature of LISP and the flexibility of the architecture has Proc. 3rd Annual Phoenix Conf. on Computers and Com­ made possible the writing of debugging tools of immense munications (Phoenix, AZ, Ma r. 1984), pp. 6- 10. complexity and power. The whole LI SP system is written in (6] A. Srivastava, " Techniques tor improving the efficiency of LI SP, and is thereby accessible to the programmer, unlike PROLOG interpreters" (submitted to the 1985 Symp. on Logic the situation prevailing in most other systems which are Programming). [7] __ , " Implementing PROLOG on the LI SP Machines," totally inaccessible to the ordinary programmer. Texas Instruments Comput. Sci. Lab. Tech. Rep., 84-19. In addition, ex tensions to the language which provide [8] R. M. Stallman, " EMACS: The extensible, customizable, and higher forms of data and procedural abstractions, such as self-documenting display editor," in D. R. Barstow, H. E.

TENNANT e l a/.: INNOVATIONS FOR THE Tl EXPLORER COMPUTER 1789 Shrobe, and E. Sandewall, Eds., Interactive Programming En­ guage understand ing," in Proc. Conf. on Human Factors in vironments. New York: McGraw-Hi ll, 1984. Computing Systems (Boston, MA, Dec. 1983). [9] D. C. Smith, C. lrby, R. Kimball, B. Verplank, and E. Harslem, [20] C. W. Thompson, H. R. Tennant, K. M. Ross, and R. M. Saenz, " Designing the STAR user interface," BYTE, vol. 7, no. 4, pp. " Building usable menu-based natural language interfaces to 242-282, Apr. 1982. databases," in Proc. 9th Very Large Databases Con f. (Florence, [10] W. M. Newman and R. F. Sproull, Principles of Interactive Italy, Oct., 1983). Computer Graphics, 2nd ed. New York: McGraw-Hill, 1979. [21] C. J_ Date, An Introduction to Database Systems. Volume I. [11] ]. D. Fol ey and A. Van Dam, Fundamentals of Interactive Menlo Park, CA: Addison-Wesley, 1982. Computer Graphics. Reading, MA: Addison-Wesley, 1982. [22] C. W. Thompso n and K. Ross, "A toolkit for building NLMenu [1 2] M. Stonebraker, E. Wong, P. Kre ps, and G. Held, " The desi gn interfaces," CSL Tech. Rep., 83-04, Apr. 1983. and implementation of INGRES," ACM Trans. Database Syst., [23] User' s Guide: Natura/Link Toolkit, part no. 2240316-0001A, vol. 1, no. 3, pp. 189- 222, Sept. 1976. Apr. 1984. [13] M. M. Astrahan, M. W. Blasgen, D. D. Chamberlin, K. P. [24] A. Suding, " The user's perspecti ve," in N. Sonheimer, Ed., Eswaran, ]. N. Gray, P. P. Griffiths, W. F. King, R. A. Lori e, P. R. Tutorial on Natural Language Interfaces, Conference on Ap­ Mcjones, J. W. Mehl, G. R. Putzolu, I. l. Tra iger, B. W. Wade, plied Natural Language Processing, Santa Monica, CA, 1983. and V. Watson, "System R: Relational approach to database [25] C. W. Thompson, and S. Marti n, " Using a menu-based natural manage ment," ACM Trans. Database Syst. , vol. 1, no. 2, pp. language interface to request spatial and gra phical database 97- 137, june 1976. queries," in p reparation. (14] M. Stone braker, B. Rubenstein, and A. Guttman, " Application [26] C. W. Thompson, " Using menu-based natural language un­ of abstract data types and abstract indices to CAD databases," derstanding to avoid problems associated with trad itional in Proc. Database Week: Engineering Design Applications natural language interfaces to databases," Ph.D. dissertation, (San jose, CA, May 23-26, 1983), pp. 107-114. Dep. Comput. Sci. Univ. o f Texas, Austin, May, 1984. [15] W. C. Watt, " Habitability," Amer. Documentation, july, 1%8. [27] J. McCarthy, " Recursive functions of symbolic exp ressions and [16] E. F. Codd , " How about recently?" in B. Schneiderman, Ed., their computations by machines, Part 1," Commun. Assoc. Databases: Improving Usability and Responsiveness. New Comput. Mach., vel. 3, no. 4, pp. 184-194, Apr. 1960. York: Academic Press, 1978. (28] W. Teitel man, INTERLJSP Reference Manual. Palo Alto, CA: [17] H. R. Tennant, " Evaluation of NL processors," Ph.D. disserta­ Xerox Corp., 1975. tion, Dep. Comput. Sci. Univ. of Illinois, Urbana, Nov. 1980. [29] G. l. Steele, Jr., Common LISP, The Language. Burli ngton, (18] H. R. Tennant, K. M. Ross, R. M. Saenz, C. W. Thompson, and VT: Digital Press, 1984. ]. R. Miller, " Menu-based natural language understanding," in [30] B. A. Sheil, " Power tools for programmers," in D. R. Barstow, Proceedings 21st ACL (MIT, June 1983). H . E. Shrobe, and E. Sandewall, Eds., Interactive Programming [19] H. R. Tennant, K. M. Ross, and C. W. Thompson, "Usable Environments. New York: McGraw-Hill , 1984, p p. 19- 30. natural language interfaces through menu-based natural ian-

1790 PROCEEDINGS OF THE IEEE, VOL. 73, NO. 12, DECEMBER 1985