{Begin SubSec Introduction}
{Title Introduction}
{Text
Four distinct paradigms of programming available in the computer science community today are oriented around procedures, objects, data access and rules. Usually these paradigms are embedded in different languages. LOOPS is designed to incorporate all of them within the Interlisp programming environment, to allow users to choose the style of programming which best suits their application.
{it Procedure Oriented Programming:} Lisp is a procedure oriented language; the procedure oriented paradigm is the dominant one provided in most programming languages today. Two separate kinds of entities are distinguished: procedures and data. Procedures are active and data are passive. The ability to compose procedures out of instructions and to invoke them is central to organizing programs using these languages. This is a major source of leverage in synthesizing programs. Side effects happen when separate procedures share a data structure and change parts of it independently.
{it Object Oriented Programming:} This paradigm was pioneered by Smalltalk, and has its roots in SIMULA and in the concept of data abstraction. In contrast with the procedure-oriented paradigm, programs are not primarily partitioned into procedures and separate data. Rather, a program is organized around entities called objects that have aspects of both procedures and data. Objects have local procedures (methods) and local data (variables). All of the action in these languages comes from sending messages between objects. Objects provide local interpretation of the message form.
The object-oriented paradigm is well suited to applications where the description of entities is simplified by the use of uniform protocols. For example in a graphics application, windows, lines and composite structures could be represented as objects that respond to a uniform set of messages (i.e., {lisp Display}, {lisp Move}, and {lisp Erase}). An important feature of these languages is an inheritance network, which makes it convenient to define objects which are {it almost like} other objects. This works together with the use of uniform protocols because specialized objects usually share the protocols of their super classes.
{it Data Oriented Programming:} In both of the previous paradigms, the invocation of procedures (either by direct procedure call or by message sending) is convenient for creating a description of a single process. In the data-oriented programming, action is potentially triggered when data are accessed. Data oriented programming makes use of long term storage of objects with implicit links from structures to actions.
Data oriented programming is appropriate for interfacing between nearly independent processes. A good example of this is the construction of a viewer for an independent traffic simulation process. The viewer provides a visual display of the changing traffic simulation process without affecting the code for the simulation. This independence means that the two processes can be written and understood separately. It means that the interactions between them can often be controlled without changing them.
{it Rule Oriented Programming:} In rule oriented programming, the behavior of the system is determined by sets of condition-action pairs. These {it RuleSets} play the same role as subroutines in the procedure oriented metaphor. Within a RuleSet, invocation of rules is guided largely by patterns in the data. In the typical case, rules correspond to nearly-independent patterns in the data. The rule-oriented approach is convenient for describing flexible responses to a wide range of events characterized by the structure of the data.
Our experience suggests that programs are easier to build in a language when there is an available paradigm that matches the structure of the problem. A variety of programming paradigms gives breadth to a programming language. The paradigms described here offer distinct ways of partitioning the organization of a program, as well as distinct ways of viewing the significance of side effects. LOOPS provides all these paradigms within the Interlisp environment [Xerox83]. In principle, the data-oriented programming can be used with either the object-oriented or the procedure-oriented paradigms. In LOOPS, we have combined it only with variables in the object-oriented metaphor.
{it Summary:} LOOPS adds data, object, and rule oriented programming to Interlisp. In object oriented programming, behavior is determined by responses of instances of classes to messages sent between these objects, with no direct access to the internal structure of an object. This approach makes it convenient to define program interfaces in terms of message protocols. LOOPS provides:
{Begin Unnumberedlist}
{Item inheritance of instance behavior and structure from multiple super classes}
{Item user extendible property list descriptions of classes, their variables, and their methods}
{Item composite objects - templates for related objects that are instantiated as a group.}
{End Unnumberedlist}
Data oriented programming is a dual of object oriented programming, where behavior can occur as a side effect of direct access to (permanent) object state. This makes it easy to write programs which monitor the behavior of other programs. LOOPS provides:
{Begin Unnumberedlist}
{Item active values for object variables which can cause a procedure invocation on setting or fetching}
{Item integration with facilities for long term storage of objects in shared knowledge bases}
{Item support for incremental updates (layers), and the representation of multiple alternatives.}
{End Unnumberedlist}
Rule oriented programming is an alternative to programming in LISP. Programs in this paradigm are organized around recursively composable sets of pattern-action rules for use in expert system design. Rules make it convenient for describing flexible responses to a wide range of events. LOOPS provides:
{Begin Unnumberedlist}
{Item a concise syntax for pattern matching and rule set construction}
{Item use of objects as working memory for rule sets}
{Item primitives for executing, stepping and suspending tasks based on ruleSets}
{Item compilation of ruleSets into Lisp code for efficient execution}
{End Unnumberedlist}
LOOPS is integrated into Interlisp. LOOPS provides:
{Begin Unnumberedlist}
{Item classes and instances as Interlisp file objects}
{Item pseudoClasses to field messages to standard Interlisp datatypes}
{End Unnumberedlist}
This manual is intended as the primary documentation for users of LOOPS. It describes the concepts and the programming facilities, and gives examples and scenarios for using LOOPS.
{Begin SubSec Intellectual Precursors}
{Title Intellectual Precursors}
{Text
LOOPS grew out of our research in a knowledge representation language (called Lore) for use in a project to create an {it expert assistant} for designers of integrated digital systems. Along the way, we discovered that we needed to experiment with alternative versions of the representation language. A core of features was identified that we wanted to keep constant in our experiments. This core became a data and object-oriented programming system with many features not found in other available systems. Many of the features (e.g., active values, data bases, and composite objects) were motivated by the needs of our project, but we they would be useful for many other applications. LOOPS has been sufficiently useful and general that we decided to make it available outside of our group.
The design of LOOPS owes an intellectual debt to a number of other systems, including:
(1) Smalltalk ([Goldberg82], [Goldberg81], [Ingalls78]), which has pioneered many of the concepts of object-oriented programming.
(2) Flavors [Cannon82], which supports this style of programming in the MIT Lisp Machine environment and which confronted non-hierarchical inheritance.
(3) PIE [Goldstein80], which provided facilities for incremental, sharable data bases.
(4) KRL [Bobrow77], which explored many issues in the design of frame-based knowledge representation languages and which provoked much additional work in this area.
(5) UNITS [Stefik79], which provided a substantial testbed for experiments in problem solving that have guided our decisions about the importance of several language features.
(6) EMYCIN [VanMelle80] which showed the power of rule oriented programming for building expert systems.
While all of these languages provided ideas, none of them was quite right for our current needs. For example, Smalltalk supports only hierarchical inheritance and does not have a layered data base, active values, or property lists on variables. PIE and KRL are not easily supportable or extendable. Flavors does not run on the machines available to us.{note Is this all you can say about the limitations of Flavors? --- jonl} UNITS was the closest existing language to our needs, but we wanted to change many of its features. Since we have compared these languages and traced the intellectual history elsewhere [Bobrow82], we will not pursue that further in this document.
In designing LOOPS, we wanted a general inheritance mechanism, a way of attaching access-triggered procedures to variables, a way of instantiating composite objects recursively, and a way of creating permanent databases of objects that can be shared and updated incrementally.
In tension with the desire for extensive language features was a desire to keep LOOPS small so that it would be easy to understand and to implement. To this end we have tried to create a small repertoire of powerful features that work well together.
}{End SubSec Intellectual Precursors}
{Begin SubSec Acknowledgments}
{Title Acknowledgments}
{Text
{it from the LOOPS Manual:}
Thanks to Alan Bell, Harry Barrow, Harold Brown, Gordon Foyster, Phil Gerring and Gordon Novak, Chris Tong, Schlomo Weiss, Terry Winograd and the other members of the KBVLSI project (past and present) for bug reports and suggestions, and for enduring the wait for it to mature into existence while so many things have been pressing. Special thanks to Johan de Kleer for extensive discussions of design issues, and to Richard Fikes, Adele Goldberg, Danny Hillis, Dan Ingalls, and Gordon Novak for comments on earlier drafts of this manuscript. We are grateful to Larry Masinter and Bill Van Melle for help on the integration of LOOPS with Lisp, and to the Interlisp-D group for unfailing support and encouragement. Thanks also to Lynn Conway for encouraging this work and to the Xerox Corporation for providing the intellectual and computing environments in which it could be done.
{it from the Rules Manual:}
Special thanks to Danny Berlin and Lynn Conway for many suggestions and for the patience it takes to be the first real users of something new. Sanjay Mittal and Terry Winograd offered helpful criticisms and advice on the documentation and concepts of the rule language. Larry Masinter and Bill van Melle have provided substantial support in the entire Loops enterprise with Interlisp-D. Thanks to the Xerox Corporation and George Pake of Xerox PARC for providing the stimulating environment and computational facilities that made this work possible.
}{End SubSec Acknowledgments}
{Begin SubSec References}
{Title References}
{Text
[Aiello81] Aiello, N., Bock, C., Nii, H. P., White, W. C., {it AGE Reference Manual}. Technical Report, Heuristic Programming Project, Computer Science Department, Stanford University, October 1981.
[Bobrow82] Bobrow, D. G., & Stefik, M. J. Introducing new programming metaphors to LISP. (submitted to {it Communications of the Association for Computing Machinery}).
[Bobrow80] Bobrow, D. G., & Goldstein, I. P. Representing design alternatives. {it Proceedings of the AISB Conference}, Amsterdam, 1980.
[Bobrow77a] Bobrow, D. G., & Winograd, T. An overview of KRL, a knowledge representation language, {it Cognitive Science} 1:1, 1977, pp 3-46.
[Bobrow77b] Bobrow, D. G., & Winograd, T. Experience with KRL-0, one cycle of a knowledge representation language, {it Proceedings of the Fifth International Joint Conference on Artificial Intelligence}, Cambridge, Mass. August, 1977, pp 213-222.
[Cannon82] Cannon, H. I. Flavors: a non-hierarchical approach to object-oriented programming, {it personal communication}, 1982.
[Consumers80] Anon, Washing Machines. {it Consumer Reports}, November 1980, pp. 679-684.
[Erman81] Erman, L. D., London, P. E., Fickas, S. F. The design and an example use of Hearsay-III. {it Proceedings of the Seventh International Joint Conference on Artificial Intelligence}, August 1981, pp. 409-415.
[Fain81] Fain, J., Gorlin, D., Hayes-Roth, F., Rosenschein, S., Sowizral, H., Waterman, D. {it The ROSIE Reference Manual}, Rand Note N-1647-ARPA, Rand Corporation, December 1981.
[Feigenbaum78] Feigenbaum, E. A., The art of artificial intelligence: themes and case studies of knowledge engineering, {it AFIPS Conference Proceedings} 47 National Computer Conference, 1978, pp. 227--240.
[Forgy81] Forgy, C. L. {it OPS5 User's Manual}. Technical Report CMU-CS-81-135. Department of Computer Science, Carnegie-Mellon University, Pittsburgh, Pennsylvania, July 1981.
[Goldberg82] Goldberg, A., Robson, D., Ingalls, D. {it Smalltalk-80: The language and its implementation}. Reading, Massachusetts: Addison-Wesley (in press).
[Goldberg81] Goldberg, A. Introducing the Smalltalk-80 System, {it Byte} 6:8, August 1981.
[Goldstein80] Goldstein, I. P., & Bobrow, D. G. Extending object oriented programming in Smalltalk. {it Proceedings of the Lisp Conference}, Stanford University, 1980.
[Ingalls78] Ingalls, D. H. The Smalltalk-76 programming system: design and implementation. {it Conference Record of the Fifth Annual ACM Symposium on Principles of Programming Languages}, Tucson, Arizona, January 1978, pp 9-16.
[Maytag] Anon. {it Operating Instructions for Model A510}. Printed by the Maytag Company, Newton Iowa 50208.
[Stefik82] Stefik, M., Aikins,5 J., Balzer, R., Benoit, J., Birnbaum, L., Hayes-Roth, F., Sacerdoti, E. The organization of expert systems: a tutorial. {it Artificial Intelligence}, 18:2, March 1982, pp. 135-173.
[Stefik79] Stefik, M. An examination of a frame-structured representation system. {it Proceedings of the Sixth International Joint Conference on Artificial Intelligence}, Tokyo, Japan, August 1979, pp. 845-852.
[VanMelle80] Emycin ... To be filled in
[Weinreb81] Weinreb, D., & Moon, D. {it Lisp Machine Manual}, Massachusetts Institute of Technology, 1981
[Xerox83] {it Interlisp Reference Manual}, Xerox Palo Alto Research Center, October, 1983.
}{End SubSec References}
}{End SubSec Introduction}