Brian Foote

Department of Computer Science

University of Illinois at Urbana-Champaign

1304 W. Springfield

Urbana, IL 61801 USA

(217) 328-3523

[email protected]

August 1992

The marriage of reflection with object-oriented programming and design techniques holds out the promise of dramatically changing the way that we think about, organize, implement, and use programming languages and systems. The combination of object-oriented programming languages and reflective metalevel architectures allows the full power of the object-oriented approach to be brought to bear upon object-oriented languages themselves Together, they have the potential to permit the long deferred promise of truly open programming languages and system to be realized.

Modern programming languages are arguably the single most significant achievement of 40-odd years of software-related research. However, success often breeds a sense of disciplinary complacency. Maybe the question we should be asking ourselves is not what should this-or-that ++ look like. Perhaps we should ask instead what kind of architectural ideas will succeed programming languages themselves.

The challenges we are calling upon the next generation of programming languages to address are quite different from those that drove the design of the current crop of languages. Concurrent computing, distributed computing, persistent object bases, and graphical user interfaces all present challenges that are inadequately addressed by mainstream programming languages. Together, they emphasize the need to provide a way for languages to adapt as they confront changing requirements.

Traditional programming languages were in essence carved in stone when their defining reports (and revised reports, and revised revised reports) were issued. Building languages themselves out of objects can allow programming languages be specialized and to adapt as individual programmers address new problems.

The process of building domain specific resuable artificacts can be thought of as building a high-level, domain specific programming language. The developers of such code should not be impeded by their languages or tools. If such developers are indeed engaged in language design (and I believe they are) we should strive to make sure that our programming systems get out of the way and allow them to do the best job that they can.

A living language is one that is able to adapt and evolve as the needs of the people who use it change. I believe that object-oriented languages with reflective metalevel architectures have the flexibility necessary to meet the needs of the next generation of computing systems.

A programming language with an object-oriented metalevel architecture is one in which programs are themselves constructed out of first-class objects. Metalevel objects, or metaobjects are objects that define, implement, support, or otherwise participate in the execution of application, or base level programs.

A reflective object-oriented language allows a running program to look at or change the objects out of which it is built. Together, these metaobjects constitute the system's self-representation. These objects reify otherwise implicit aspects of the underlying system. The ability to inspect, but not alter, the objects that implement a system is referred to as introspection.

A reflective object-oriented program can access the very objects that in turn define how it works, and can alter them dynamically if necessary. Changes made to these objects are immediately reflected in the actual dynamic state of the state of the system, and vice versa. The requirement that this dynamic constistency be maintained is sometimes refered to as the causal connection requirement.

Programming languages built out of objects are easy to extend. Features may be added to a suitably designed reflective object-oriented language by adding a set of metaobjects to support them to the language. These objects may, of course, be specializations of existing objects. A well designed reflective metalevel architecture can limit the scope of extensions to a single object, class, or computation, or allow them to be in effect system wide. Features that have usually required the definition and implementation of whole new languages, such as backtracking [LaLonde & Van Gulik 1987], futures [Foote & Johnson 1989] and persistence [Paepke 1990] have been added to existing languages using reflective facilities.

Reflection can also allow programmers to create new metalevel objects and selectively substitute them for existing part of the running system. This ability allows programmers to add objects to trace a program's execution, for example, from within the language. Support for debugging in most languages is usually treated in an ad-hoc fashion by individual implementations. An object-oriented reflective metalevel architecture allows support for debugging to be provided at the language level.

A language that supports the dynamic redefinition of existing parts of the system is said to be mutable. A language that supports the addition of new features, but not the redefinition of old ones is said to be extensible [Stroustrup 1991]. The ability to exploit the existing definition of a system to augment its behavior gives the programmer considerable leverage over the rest of the system.

It is easy to dynamically introduce new objects and object types into a running reflective program, since these objects, as well as the objects that define them, are themselves first-class, dynamic objects. By contrast, consider the difficulty associated with dynamically handling a new type of object in a C++ program that has already been compiled.

Because programming systems with object-oriented reflective metalevel architectures have a model of themselves embedded within them, they exhibit a substantial capacity for metamorphosis. Reflection has the potential to extend the runtime reach of a programming system inward into the definition of the language itself, downward into its implementation, and outward into realms currently considered the provinces of operating systems, programming environments and database systems. Reflection has the potential to bring areas as disparate as programming language design, compiler construction, code generation, debugging, tracing, concurrent programming, and semantics together under a single umbrella.

A characteristic of the lifecycle of object-oriented entities is the emergence of structural insight into an application domain as the result of successive reapplication. Constructing the elements of programming systems out of dynamic first class objects can lead to a reassessment of where the walls between objects, environments, operating systems, databases, and command languages should be placed. As a system evolves, internal structure emerges. Objects are ideal for capturing this structure. As walls crumble, these constituent objects can serve as a structural redoubt one level below . Without objects, one would have to fall all the way back into the implementation to reorganize a system. A comprehensive reexamination of how a system supports running objects could permit autonomous objects to break free of the processes that spawned them and migrate unencumbered among other processes, processors, and persistent object bases.

A good sign that a programming language feature is needed is when a lot of people go to a great deal of effort to build it themselves atop existing languages. There is abundant evidence that dynamic metalevel objects are such a feature. Open systems need open languages.

Object-oriented programming languages and systems are having a profound impact on the way that we organize, design, implement, and maintain software. These techniques allow us to treat software components and systems alike as durable, yet malleable artifacts, which evolve along with their requirements Object-oriented languages make it much easier to design software components and systems that can adapt as requirements evolve and change [Foote 1988a]. The judicious use of object-oriented techniques can promote the emergence of reusable abstract classes, components, and object-oriented frameworks [Deutsch 1983] [Johnson & Foote 1988].

An object-oriented framework is composed of a set of abstract classes and components that together comprise an abstract or generic solution to a range of potential application requirements. The framework's abstract classes and components must be customized by the framework's clients to suit the requirements of specific applications. Frameworks, unlike abstract classes, are often characterized by an inversion of control. That is, rather than calling framework elements directly, the client must sometimes instead supply the framework with components that are "called-back" by the framework at an appropriate time.

Durable, reusable object-oriented artifacts emerge most readily from an iterative reapplication of existing abstract classes, components, and frameworks to successive, related requirements. Object-oriented entities evolve at every level along a trajectory that takes them through an initial prototype phase, and expansionary exploratory phase, and a consolidation phase. During the consolidation phase, structural insight gained during successive reapplications is exploited to increase the generality, structural integrity, and reusability of these entities. As entities evolve, many will progress from loosely structured, application specific, inheritance-based "white-box" entities to fully encapsulated, fairly general, component-based "black box" entities.

The current surge of interested in object-oriented reflection and metalevel architectures is, I believe, based on the observation that object-oriented languages and programs are as much themselves an appropriate domain for object-oriented techniques as are windowing systems, operating systems, or accounting systems. The vision underlying this observation is one of a programming system in which the language definition itself is distributed across a constellation of objects which are themselves subject to dynamic scrutiny and modification.

Such a system would allow users to construct new language level objects which would stand on an equal footing with previously existing features. A language built of such programmable objects would be arbitrarily extensible, and would permit language as well as application level objects to be utilized to help the system adapt and evolve as requirements change A particularly intriguing consequence of this approach is that the components of such a system can themselves serve as the basis for an object-oriented framework that can support an evolving family of different programming approaches and paradigms.

Reusable object-oriented frameworks cannot be constructed in a top-down fashion. They are the result of an iterative process that unfolds at all levels of a system as objects are successively reapplied to address changing requirements. The following are design principles that might characterize a linguistic framework.

o Reflective metalevel architectures should be designed with message passing at the bottom, malleable self-representations, extensionality, abstract inheritance, first -class representation, abstract dispatching, and abstract scope.

o All significant elements of a languages' programming model ought to be themselves reflected in first-class elements of that language's metalevel architecture. For instance, if the programming model makes extensive use of a notion like "class", then Class objects should be explicit, first-class elements of the metaarchitecture that coexist with ordinary application objects at runtime.

o Hence, a framework for object-oriented reflective metalevel architectures might draw from a rich palette of potential metaobjects, including variables, selectors, messages, interpreters, script sets, handles, environments, continuations, contexts, message queues, stores, closures, classes, types, prototypes, signatures, methods, code, threads, and instances...

A characteristic of the lifecycle of object-oriented entities is the emergence of structural insight into an application domain as the result of successive reapplication. Constructing the elements of programming systems out of dynamic first class objects can lead to a reassessment of where the walls between objects, environments, operating systems, databases, and command languages should be placed.

Traditional programming environments, whether they are based on the compile/link/load model, or the image model seen with languages such as Lisp or Smalltalk, tend to trap objects on reservations circumscribed by runtime support requirements They may influence or exploit objects outside their addressing spaces only indirectly, via I/O. I believe that advances in hardware and software technology make it appropriate to reassess the relationship among object-oriented languages themselves, their runtime environments, and the rest of the world. For instance, shared memory, distributed, and networked systems, concurrent systems, and object-oriented databases all present novel runtime challenges. It is already clear that reflective techniques are having a significant impact on the way in which we think around concurrent systems. Reflective techniques have also been employed to add persistence to objects in existing image-based systems [Paepcke 1990]. The growing popularity of object-oriented databases also attests to the observation that first-class objects have a place outside individual applications.

Voltaire is said to have said that if God did not exist, it would be necessary to invent him. One can make a case that the architects of systems such as X and the Macintosh Operating Systems have discovered that the same is true of object-oriented programming in general, and of dynamic, autonomous objects in particular. In those cases where linguistic support for object-orientation has not been present, object-like entities have been constructed in a home-brew fashion, out of elements like C structs and pointers to functions. Indeed, it is difficult to think of a significant GUI package that does not employ object-oriented facilities. What is striking in packages like the X Toolkit is not just that object-orientation was found to be indispensable, but that some of the object-oriented facilities that were included go beyond not only C++, but Smalltalk and Lisp as well in terms of metalevel sophistication. The renewed interest in the C++ community in metalevel facilities attests to their necessity.

For instance, the resource managers seen in both X and the Macintosh Toolbox can be thought of as forerunners of genuine rudimentary object-oriented databases. X Resource IDs are reference or handle-like objects with a scope that may span several active address spaces. Atoms are IDs that play a role similar to that of Lisp Symbols. The resource manager itself contains sophisticated facilities for interpreting and converting strings to resources. Since the C (and C++) namespaces are not accessible at runtime, the resource manager also is recruited to aid in the cumbersome task of mapping runtime name strings on to compile time program level names. Many X widgets are themselves framework-like structures, with elaborate callback hooks that perform the sorts of functions one might employ CLOS :before or :after methods for. This all suggests that the next generation of object-oriented programming language will have to cope with a need for features like as expression evaluation, smart handles, and persistent, distributed, and shared objects.

Can reflective object-oriented metalevel architecture help to address these needs? And if so, how? Can the relationships among system components like compilers, loaders, interprocess communication, and storage management be refactored in such a way so as to allow objects to flourish outside the processes in which they were spawned? What sort of facilities might be necessary to support such autonomous objects, and where must these facilities be located in order to allow them to work? And, what sorts of metalevel linguistic manipulation might we undertake to simplify all of this?

It is interesting to speculate as to what some of the answers might be. For instance, if the sort of dynamic translation seen in Smalltalk and Self were available as a sort of operating system level service, along with storage and namespace management services, it is possible to imagine how individual objects might flourish beyond the umbilicals that tie them to their originating processes. A key contribution that reflective languages might make to this vision is that the vastly more complex semantics for handles and namespace management need only be mobilized for objects outside their wombs. Object-oriented techniques themselves are essential if one is to even contemplate such a system organization.

During the early development of American representative democracy, two schools of thought emerged. The Jeffersonians felt that the people could be trusted with decisions such as the election of the president, while the Hamiltonians believed that an educated elite, and not the masses, should make such choices.

Allowing the programmer to make local modifications to the existing components of a programming language reflects a distinctly Jeffersonian philosophy towards language design. It is undeniable that such power has a high abuse potential. The price of freedom, after all, is responsibility.

One can make the case that the Hamiltonian view that the definition of the language itself should beyond the reach of the programmer has unnecessarily hamstrung language as well as application evolution. The traditional view of language design has been that a programming language emerges, fully formed and carved in stone by a single hand, from some castle in the Alps. Mistakes made by the designers of such languages may persist for a generation, until such languages are supplanted altogether. Consider Pascal's inflexible array dimensions. The programs written in these languages must then be translated somehow, or die ignominious deaths. This approach makes it impossible for a language to attempt to cope with new challenges, such as the need to support parallelism, or a persistent object store, or to support application specific extensions.

I believe the argument that reflection is dangerous because it gives programmers too much power is a specious one. Existing programming languages already give clumsy programmers more than ample opportunities to shoot themselves in the foot. I'll concede that reflective systems allow the clumsy programmer to fire several rounds per second into his foot, without reloading. Still, I'm confident that, as is the case with features such as pointers, competent programmers will make appropriate use of the power of reflection with care and skill. Potential abuse by inept programmers should not justify depriving the programming community of a potentially vital set of tools.

Certainly, metaprogramming is not for everyone. Most users will not need to resort to designing and building, as opposed to using, reflective facilities. Metaprogramming should not be undertaken frivolously. However, a language should not be an obstacle to its users, or to its own evolution. The age of Software Stalinism is past.

One of the explanations for the renewed popularity of reflection, particularly in the object-oriented community, is that we have become heirs to a long tradition of trying to make programming languages as open as possible. This section examines some of this tradition.

Nowhere has the open languages tradition flourished more than in the Lisp community. Indeed, Self, Smalltalk, 3-Lisp, 3-KRS, CLOS, ObjVLisp, the Actor languages, and ABCL/R can all trace their ancestry either directly or indirectly to Lisp. A metacircular definition was given for Lisp in [McCarthy et. al. 1962]. This definition gave a blueprint for a program that could take other Lisp programs in the form of Lisp data structures and execute them. This program, in turn, allowed Lisp data structures (s-expressions) to be passed to a function (eval) and executed as code. In [McCarthy 1978] McCarthy recalls the following about the preparation of [McCarthy 1960]:

It is clear that McCarthy recognized that a programming language could be at least as effective as alternative formal approaches for defining how a programming language works. However, McCarthy and his group did not at first foresee the practical potential that their approach had for actual metaprogramming.

In Smalltalk-72 [Goldberg & Kay 1976] [Ingalls 1983] code was viewed by the interpreter as simply a stream of tokens. The object returned by any computation could hijack the local message stream, and gobble down as many tokens as it saw fit, Pac-Man style. Smalltalk-74 introduced a programmer accessible object that represented the incoming message stream. Thus, not only could all the message stream operations be examined in Smalltalk, but the user could also define his (sic) own extensions to the message stream semantics.

With Smalltalk-76, the designers of Smalltalk began to retreat from the most extravagant of such dynamic excesses in the name of efficiency. Still, the imperative that elements of the system itself be aggressively promoted to first-class status was retained. Ingalls referred to the following as the Smalltalk Philosophy:

On the topic of kernel size and openness, Ingalls stated:

This requirement that the user be able to examine or alter as much of the system as possible meshes nicely with our our contemporary working definitions for reflection. Indeed, the extensive set of metaobjects in Smalltalk-80 [Goldberg & Robson 1983] is one of the best existing examples of the power of such objects. [Deutsch and Shiffman 1984] describes a strategy for efficiently implementing what we now call Smalltalk's highly reflective Context objects. It is important to note that way before we had a name for it, the Smalltalk community was doing the seminal work on what we are now calling object-oriented reflective metalevel architectures.

The goal of aggressively promoting elements of the language to first-class status, as well a recognition of the perils of regress can be seen in the Actor community in this passage from [Lieberman 1986]:

This passage from the same paper also recognizes the merits of a small, highly extensible object-oriented kernel:

I believe that we in the object-oriented programming community are discovering a principle that Pacific Rim architects already know. That is: To stay the seismic upheaval that confronts a system during the course of its lifetime, it must be built atop a flexible foundation. We can no longer think of our programming languages and systems as rigid structures that will withstand generations of buffeting in this face of changing requirements. We must instead construct systems that not only build on past experience, but are able to adapt and evolve as well. We must build our houses of brick rather than straw, but make sure that there is shock absorbing material in place in their foundations as well.

The cobbler's children, it has been said, are often the last to be shod. Just as objects are good for building programs, so too they are good for building programming languages and programming systems.

 
[Abelson & Sussman 1985
	Harold Abelson and Gerald Jay Sussman
	with Julie Susmann
	Structure and Interpretation of Computer
	Programs
	MIT Press, Cambridge, Mass.
	McGraw-Hill, New York, 1985
 
[Agha 1986]
	Gul Agha
	ACTORS: A Model of Concurrent Computation
	in Distributed Systems
	MIT Press, 1986
 
[Bawden 1988]
	Alan Bawden
	Reification without Evaluation
	Proc. Symposium on Lisp and Functional
	Programming, 1988
	pages 342-248
 
[Bennett 1987]
	John K. Bennett
	The Design and Implementation of 
	Distributed Smalltalk
	OOPSLA '87 Proceedings 
	Orlando, FL, October 4-8 1977 pages 118-330
 
[Bobrow et. al. 1988]
	D. G. Bobrow, L. G. DeMichiel, R. P. Gabriel, 
	S. E. Keene, G. Kiczales, and D. A. Moon
	Common Lisp Object System Specification
	X3J13 Document 88-002R
	SIGPLAN Notices, Volume 23, 
	Special Issue, September 1988
 
[Bobrow & Kiczales 1988]
	Daniel G. Bobrow and Gregor Kiczales
	The Common Lisp Object System 
	Metaobject Kernel -- A Status Report
	Proceedings of the 1988 Conference on Lisp 
	and Functional Programming
 
[Borning 1979]
	Alan Borning
	ThingLab -- A Constraint Oriented
	Simulation Laboratory
	Technical Report No. SSL-79-3
	Xerox Palo Alto Research Center
	July 1979
 
[Borning & Ingalls 1982]
	A. H. Borning and D. H. H. Ingalls
	A Type Declaration and Inference System
	for Smalltalk
	9th POPL, 1982, pages 133-141
 
[Borning & O'Shea 1986]
	A. Borning and T. O'Shea
	DeltaTalk: An Empirically and 
	Aesthetically Motivated Simplification
	of the Smalltalk-80 Language
	(unpublished) 1986
 
[Borning 1986]
	Alan Borning
	Classes versus Prototypes in 
	Object-Oriented Languages
	Proceedings of the ACM/IEEE 
	Fall Joint Computer Conference
	Dallas, TX, November 1986, pages 36-40
 
[Briot 1989]
	Jean-Pierre Briot
	Actalk: A Testbed for Classifying and
	Designing Actor Languages in the 
	Smalltalk-80 Environment
	LITP 89-33 RXF, Rank Xerox
	ECOOP '89
 
[Chambers et. al. 1989]
	Craig Chambers, David Ungar, Elgin Lee
	An Efficient Implementation of SELF 
	a Dynamically-Typed Object-Oriented
	Language Based on Prototypes
	OOPSLA '89 Proceedings
	New Orleans, LA
	October 1-6 1989, pages 49-70
 
[Cointe 1987]
	Pierre Cointe
	Metaclasses are First Class:
	The ObjVlisp Model
	OOPSLA '87 Proceedings 
	Orlando, FL, October 4-8 1977, pages 156-167
 
[Danvy & Malmkjaer 1988]
	Oliver Danvy and Karoline Malmkjaer
	Intensions and Extensions in a Reflective
	Tower
	1988 ACM Conference on Lisp and Functional
	Programming, Smowbird, UT, July 1988
	pages 327-341
 
[des Rivieres & Smith 1984]
	Jim des Rivieres and Brian Cantwell Smith
	The Implementation of Procedurally 
	Reflective Languages
	Proc. of the 1984 ACM Symposium
	on Lisp and Functional Programming
	August, 1984, pages 331-347
 
[des Rivieres 1988]
	Jim des Rivieres
	Control-Related Meta-Level Facilities in Lisp
	in Meta-Level Architectures and Reflection
	P. Maes and D. Nardi, editors
	Elsevier Science Publishers
	B. V. North-Holland, 1988, pages 101-110
 
[Deutsch 1983]
	L. Peter Deutsch
	Reusability in the Smalltalk-80 
	Programming System
	ITT Proceedings of the Workshop on Reusability
	in Programming, 1983, pages 72-76
	(reprinted in Tutorial on Software Reusability,
	IEEE Computer Society Press, 1987)
 
[Deutsch & Schiffman 1984]
	L. Peter Deutsch and Allan M. Schiffman
	Efficient Implementation of the 
	Smalltalk-80 System
	Proceedings of the Tenth Annual 
	ACM Symposium
	on Principles of Programming Languages,
	1983, pages 297-302
 
[Ellis & Stroustrup 1990]
	Margaret A. Ellis and Bjarne Stroustrup
	The Annotated C++ Reference Manual
	Addison-Wesley, Reading, MA, 1990
 
[Ferber 1989]
	Jacques Ferber
	Computational Reflection in Class-Based 
	Object-Oriented Languages
	OOPSLA '89 Proceedings
	New Orleans, LA
	October 1-6 1989, pages 317-326
 
[Foote 1988a]
	Brian Foote
	Designing to Facilitate Change with 
	Object-Oriented Frameworks
	Masters Thesis, 1988
	University of Illinois at Urbana-Champaign
 
[Foote & Johnson 1989]
	Brian Foote and Ralph E. Johnson
	Reflective Facilities in Smalltalk-80
	OOPSLA '89 Proceedings
	New Orleans, LA
	October 1-6 1989, pages 327-335
 
[Foote 1990]
	Brian Foote
	Object-Oriented Reflective Metalevel
	Architectures: Pyrite or Panacea?
	OOPSLA/ECOOP '90 Workshop on
	Reflection and Metalevel Architectures
	Mamdouh Ibrahim, Brian Foote,
	Jean-Pierre Briot, Gregor Kiczales,
	Satoshi Matsuoka, and Takuo Watanabe,
	organizers
 
[Foote 1991]
	Brian Foote
	Flexible Foundations and Movable Walls
	OOPSLA '91 Workshop on
	Reflection and Metalevel Architectures
	Phoenix, AZ
	Mamdouh Ibrahim, Brian Foote,
	Pierre Cointe, Gregor Kiczales,
	Satoshi Matsuoka, and Takuo Watanabe,
	organizers
 
[Friedman & Wand 1984]
	D. P. Friedman and M. Wand
	Reflection without Metaphysics
	Proc. Symposium on Lisp and Functional
	Programming, pages 348-355, August 1984
 
[Goldberg & Kay 1976]
	Adele Goldberg and Alan Kay, editors
	with the Learning Research Group
	Smalltalk-72 Instruction Manual
	Xerox Palo Alto Research Center
 
[Goldberg & Robson 1983]
	Adele Goldberg and David Robson
	Smalltalk-80: The Language and 
	its Implementation
	Addison-Wesley, Reading, MA, 1983
 
[Goldberg 1984]
	Adele Goldberg
	Smalltalk-80: The Interactive 
	Programming Environment
	Addison-Wesley, Reading, MA, 1984
 
[Halstead 1985]
	Robert H. Halstead, Jr.
	MultiLISP: A language for Concurrent 
	Symbolic Computation
	ACM Transactions on Programming Languages 
	and Systems
	Volume 7,. Number 4
	October 1985, pages 501-538
 
[Hewitt & de Jong 1983]
	Carl Hewitt and Peter de Jong
	Analyzing the Role of Description and Actions
	in Open Systems
	AAAI '83, pages 162-167
 
[Hoeltze et. al. 1990]
	Urs Hoeltze, Bay-Wei Chang,
	Craig Chambers, and David Ungar
	The Self Papers, and the Self Manual
	(unpublished)
 
[Ibrahim & Cummins 1988]
	Mamdouh H. Ibrahim and Fred A. Cummins
	KSL: A Reflective Object-Oriented
	Programming Language
	Proceedings of the International
	Conference on Computer Languages
	Miami, FL, October 9-13 1988
 
[Ingalls 1978]
	Daniel H. H. Ingalls
	The Smalltalk-76 Programming System 
	Design and Implementation
	5th ACM Symposium on POPL, pages 9-15
	Tucson, AZ, USA, January 1978
 
[Ingalls 1983]
	Daniel H. H. Ingalls
	The Evolution of the Smalltalk-80 Virtual 
	Machine
	in Smalltalk 80: Bits of History,
	Words of Advice
	Glenn Krasner, editor
	Addison-Wesley, Reading, MA
	1983
 
[Jefferson 1985]
	David. R. Jefferson
	Virtual Time
	ACM Transactions on Programming 
	Langauges and Systems
	Volume 7, Number 3, pages 404-425, July 1985
 
[Johnson & Foote 1988]
	Ralph E. Johnson and Brian Foote
	Designing Reusable Classes
	Journal of Object-Oriented Programming
	Volume 1, Number 2, June/July 1988 
	pages 22-35
 
[Johnson et. al. 1988]
	Ralph E. Johnson, Justin O. Graver, and 
	Laurance W. Zurawski
	TS: An Optimizing Compiler for Smalltalk
	OOPSLA '88 Proceedings
	San Diego, CA, September 25-30, 1988 
	pages 18-26
 
[Kaiser & Garlan 1987]
	Gail E. Kaiser and David Garlan
	Melding Software Systems f
	rom Reusable Building Blocks
	IEEE Software, Volume 4 Number 4
	July 1987 pages 17-24
 
[Keene 1989]
	Sonya E. Keene
	Object-Oriented Programming in Common Lisp
	A Programmer's Introduction to CLOS
	Addison-Wesley, 1989
 
[Kiczales & Rodriguez 1990]
	Gregor Kiczales and Luis Rodriguez
	Efficient Method Dispatch in PCL
	Proceedings of the 1990 ACM Conference
	on Lisp and Functional Programming
	Nice, France, June 1990, pages 99-105
	The Art of the Metaobject Protocol
	MIT Press, 1991
 
[Kiczales et. al. 1991]
	Gregor Kiczales, Jim Des Rivieres, 
	and Daniel G. Bobrow
	The Art of the Metaobject Protocol
	MIT Press, 1991
 
[Kim et. al. 1989]
	Won Kim and Frederick H. Lochovsky, editors
	Object-Oriented Concepts, Databases, 
	and Applications
	Addison-Wesley, Cambridge, MA, 1989
 
[Krasner et. al. 1983]
	Glenn Krasner, editor
	Smalltalk 80: Bits of History,
	Words of Advice
	Addison-Wesley, Reading, MA
	1983
 
[LaLonde et. al. 1986]
	Wilf R. LaLonde, Dave A. Thomas 
	and John R. Pugh
	An Exemplar Based Smalltalk
	OOPSLA '86 Proceedings 
	Portland, OR, October 4-8 1977 pages 322-330
 
[LaLonde & Van Gulik 1988]
	Wilf R. LaLonde and Mark Van Gulik
	Building a Backtracking Facility in Smalltalk 
	Without Kernel Support
	OOPSLA '88 Proceedings
	San Diego, CA, September 25-30, 1988 
	pages 105-122
 
[Lieberman 1986]
	Henry Lieberman 
	Using Protypical Objects to Implement 
	Shared Behavior 
	in Object-Oriented Systems
	OOPSLA '86 Proceedings 
	Portland, OR, October 4-8 1977 pages 214-223
 
[Lieberman et. al. 1988]
	Henry Lieberman, Lynn A. Stein,
	and David Ungar
	Treaty of Orlando
	Special OOPSLA '87 Addendum to
	the Proceedings
	SIGPLAN Notices, May 1988
	Volume 23, Number 5
 
[Lindsey & van der Muelen 1973]
	C. H. Lindsey and S.G van der Muelen
	Informal Introduction to ALGOL 68
	North-Holland Publishing Co., Amsterdam
	American Elsevier Publishing Co., NY, 1973
 
[Maes 1987a]
	Pattie Maes
	Computational Reflection
	Artificial Intelligence Laboratory
	Vrije Universiteit Brussel
	Technical Report 87-2
 
[Maes 1987b]
	Pattie Maes
	Concepts and Experiments in 
	Computational Reflection
	OOPSLA '87 Proceedings 
	Orlando, FL, October 4-8 1977 pages 147-155
 
[Maes et. al. 1988]
	Pattie Maes and Daniele Nardi, editors
	Meta-Level Architectures and Reflection
	Elsevier Science Publishers
	B. V. North-Holland, 1988
 
[McCarthy 1960]
	John McCarthy
	Recursive Functions of Symbolic Expressions
	and their Computation by Machine, part 1
	Communiations of the ACM
	Volume 3, Number 4, pages 184-185
 
[McCarthy et. al. 1962]
	John McCarthy, Paul W. Abrahams,
	Daniel J. Edwards, Timothy P. Hart,
	and Michael I. Levin
	Lisp 1.5 Programmer's Manual
	MIT Press, Cambridge, MA, 1962
 
[McCarthy 1978]
	John McCarthy
	History of Lisp
	ACM SIGPLAN History of Programming
	Languages Conference
	Los Angeles, CA June 1-3 1978
	pages 217-223
 
[McCullough 1987]
	Paul L. McCullough
	Transparent Forwarding: First Steps
	OOPSLA '87 Proceedings 
	Orlando, FL, October 4-8 1987 pages 331-341
 
[Messick & Beck 1985]
	Steven L. Messick and Kent L. Beck
	Active Variables in Smalltalk-80
	Technical Report CR-85-09
	Computer Research Lab, Tektronix, Inc., 1985
 
[Paepcke 1990]
	Andreas Paepcke
	PCLOS: Stress Testing CLOS
	OOPSLA/ECOOP '90 Proceedings
	Ottawa, Ontario, Canada
	October 21-25, 1990 pages 194-221
 
[Pascoe 1986]
	Geoffrey A. Pascoe
	Encapsulators: A New Software 
	Paradigm in Smalltalk-80
	OOPSLA '86 Proceedings 
	Portland, OR, September 29-October 2 1986, 
	pages 341-346
 
[Smith 1982]
	Brian Cantwell Smith
	Reflection and Semantics in a
	Procedural Programming Language
	Ph. D. Thesis, MIT
	MIT/LCS/TR-272
 
[Smith 1984]
	Brian Cantwell Smith
	Reflection and Semantics in Lisp
	Proceedings of the 1984 ACM 
	Principles of Programming Languages
	Conference
	pages 23-35
 
[Smith & des Rivieres 1984]
	Brian Cantwell Smith and Jim des Rivieres
	Interim 3-LISP Reference Manual
	Xerox Intelligent Systems Laboratory ISL-1
	Xerox Palo Alto Research Center
	June 1984
 
[Smith 1987]
	Randall B. Smith
	Experiences with the Alternate Reality Kit:
	An Example of the Tension Between Literalism 
	and Magic.
	CHI+GI 1987 Conference Proceedings
 
[Steele & Sussmann 1976]
	Guy Lewis Steele Jr. and Gerald Jay Sussman
	Lambda: The Ultimate Imperative
	MIT AI Memo 353
	March 10, 1976
 
[Steele 1976]
	Guy Lewis Steele Jr.
	Lambda: The Ultimate Declarative
	MIT AI Memo 379
	November 1976
 
[Steele 1977]
	Guy Lewis Steele Jr.
	Debunking the "Expensive Procedure Call" Myth
	or, Procedure Call Implementations Considered
	Harmful, or Lambda: The Ultimate GOTO
	MIT AI Memo 443
	October 1977
 
[Steele 1984] 
	Guy L. Steele Jr.
	Common Lisp: The Language
	Digital Press, 1984
 
[Steele 1990] 
	Guy L. Steele Jr.
	Common Lisp: The Language
	Second Edition
	Digital Press, 1990
 
[Stefik & Bobrow 1986]
	Mark Stefik and Daniel G. Bobrow
	Object-Oriented Programming: 
	Themes and Variations
	AI Magazine 6(4): 40-62, Winter, 1986
 
[Stefik et. al. 1986]
	M. Stefik, D. Bobrow and K. Kahn
	Integrating Access-Oriented Programming into 
	a Multiprogramming Environment
	IEEE Software, 3, 1 (January 1986), pages 10-18
 
[Stein 1987]
	Lynn Andea Stein
	Delegation is Inhertance
	OOPSLA '87 Proceedings 
	Orlando, FL, October 4-8 1977 pages 138-146
 
[Stein et. al. 1989]
	Lynn Andea Stein, Henry Lieberman,
	and David Ungar
	A Shared View of Sharing:
	The Treaty of Orlando
	in Object-Oriented Concepts, Databases, 
	and Applications
	Won Kim and Frederick H. Lochovsky, editors
	Addison-Wesley, Reading, MA, 1989
 
[Stroustrup 1986]
	Bjarne Stroustrup
	The C++ Programming Language
	Addison-Wesley, Reading, MA, 1986
 
[Stroustrup 1991]
	Bjarne Stroustrup
	The C++ Programming Language
	Second Edition
	Addison-Wesley, Reading, MA, 1991
 
[Sussmann & Steele 1978]
	Guy Lewis Steele Jr. and Gerald Jay Sussman
	The Art of the Interpreter, or
	The Modularity Complex
	(Parts Zero, One, and Two)
	MIT AI Memo 453
	May 1978
 
[Tiemann 1988]
	Michael D. Tiemann
	Solving the RPC problem in GNU C++
	1988 USENIX C++ Conference
	Denver, CO, October 17-21 1988
 
[Ungar & Smith 1987]
	David Ungar and Randall B. Smith
	Self: The Power of Simplicity
	OOPSLA '87 Proceedings 
	Orlando, FL, October 4-8 1977, pages 227-242
 
[van Wijngaarden et. al. 1976]
	A. van Wijngaarden, B. J. Mailoux,
	J. E. L. Peck, C. H. A. Koster,
	M. Sintzoff, C. H. Lindsey,
	L. G. L. T. Meertens and R. J. Fisker
	Springer-Verlag, Berlin, Heidelberg, New York
	1976
 
[Yokote & Tokoro 1986]
	Yasuhiko YokoteYasuhiko Yokote and Mario Tokoro
	The Design and Implementation of 
	ConcurrentSmalltalk
	OOPSLA '86 Proceedings 
	Portland, OR, September 29-October 2 1986 
	pages 331-340
 
[Wand & Friedman 1986]
	Mitchell Wand and Daniel P. Friedman
	The Mystery of the Tower Revealed:
	A Non-Reflective Description of 
	the Reflective Tower
	ACM Conference on 
	Lisp and Functional Programming
	Boston, MA, August 1986
 
[Watanabe & Yonezawa 1988]
	Takuo Watanabe and Akinori Yonezawa
	Reflection in an Object-Oriented Concurrent
	Language
	OOPSLA '88 Proceedings
	San Diego, CA, September 25-30, 1988
	pages 306-315
 
[Yonezawa et. al. 1989]
	Akinori Yonezawa, editor
	ABCL: An Object-Oriented Concurrent System
	MIT Press, Cambridge, MA
	1989
 

Brian Foote [email protected]
Last Modified: 3 December 1998