Response by Aki Yonezawa

My colleagues and I have been working on concurrent object-oriented computing and involved in language design, implementation, and programming. Before I understood much of the CLOS MOP, I came across Brian Smith's idea of computational reflection. Though I am not sure I correctly understand or interpret it, my understanding of it is:

A high level programming language L is ``reflective'' if L allows the user to describe in L itself how to systematically manipulate, change, and optimize the internal representations/components of L's language processor and runtime system.

Writing and efficiently running concurrent/distributed programs on parallel/distributed machines requires various kinds of adaptations and adjustments, including:

language extension/customization,
static and dynamic changes of runtime policies on scheduling,
load balancing and communication management,
debugging and behavior monitoring (e.g.,deadlock detection)

which are pretty much similar to those required for operating systems.

The advanced application programmer knows (or at least expects) the behavior of his programs better than anybody else as he knows the application domain best. He should be equipped with a means to control/tune both his programs and compiler/runtime system. The means is the language he writes. Also the code describing such META-level control has to be modularized separately from the base-level application code, which enhances the programmer's control power of complexity.

Perhaps my real response - which is very short - to the foils begins here:

If we are philosophers, we can spend a long time for arguing what ``meta'' means, but it is kind of unproductive in this context. To be a bit more concrete, the argument should boil down to what should be hidden and what should be exposed. Do any systematic criteria or disciplines for it exit? If so, we have to explicate them. (From art to science!)

Too much exposure, of course, incurs the danger in system reliability. This danger and performance gain are the trade-off. The danger necessitates disciplined use of the exposed. Any systematic way of reducing the danger? Can we devise any software tools to help us reduce it? Or should we have a finer-multi-layered approach?

At any rate, I believe that providing the user with the opportunities of finer control on and more selections of system functionality and behavior pays off because users will start demanding more and more sophisticated service in the future. We are working on reflective systems based on this conviction .

Basically I agree with the authors of the foil in what they say before Section 6. Namely, I believe that open implementation is highly useful if target systems are language processors, operating systems, communication systems, database systems... But as I am not familiar with the Predator system, it is not clear to me how the Predator approach is significant in independence and composability in the context of Open Implementation.

Back to Alphabetical List of Responses

Back to Main OI Workshop Page

Back to OI Home Page

Aki Yonezawa, yonezawa@is.s.u-tokyo.ac.jp

(Last Revised October 1994)