Reflective architecture

[Tril]

On Sun, 27 Dec 1998, RE01 Rice Brian T. EM2 wrote:

> > In fact, for a given system, we should start with the boundaries between
> > objects (abstractions), including their nested structure, being chosen for
> > easy understanding by the user.  This initial topology is also convenient
> > because it is completely platform- independent.  Initially set each object
> > as a decentral node of information flow, all with equal priority.  Then
> > begin observing where information flows.  The paths that are frequently
> > travelled by information can be combined, and abstracted:  effectively
> > creating a completely different set of objects.  These are system-objects,
> > and they are a result of: the user-objects which serve as the
> > specification for the tools in the system; the user's habits and
> > preferences, which impact the ways in which tools are used, and the flow
> > of information between them; and the hardware platform.  If any of these
> > aspects change, the system-objects should be changed to adapt. 
> > 
> I knew it!  You came up with just the right point about my short
> introduction on the object / message paradigm for computation!  Fantastic!
> Notice that this problem is quite NP-hard, and so requires some fancy
> thinking, or at least a random-number generator for the system to make
> "intuitive leaps".  The point is that the discrete events you would like to
> manage in this system (vis information flow) are exactly the object /
> message paradigm.

I'd still like to abstract message passing out entirely.  Instead of
communication between discrete components, I can just treat "talking"
components as connected, temporarily.  The objects would be a single
larger one for the duration of the communication.  In other words
passing arguments (messages, some say) to functions is a constructor for a
new function.  It's an invocation of partial evaluation...

> > User-objects are the medium by which the user to controls and communicates
> > with the system.  User-objects are easier to understand than
> > system-objects, because user-objects are specifically designed around the
> > way humans think.  System-objects are much harder to understand, but their
> > structure corresponds with the way people think.  Also, user-objects
> > contain more information, because some information is lost during
> > translation to machine architectures.  Each time the system regenerates
> > the system-objects, different parts of the user-objects may be used. 
> > 
> I disagree about the system objects containing less information.  That's
> just an artifact of computing tradition to leave the information density in
> 'user space'.  If we had a set of objects designed to come up with ways of
> explaining things to the user in various ways, then we could probably easily
> connect the user with the kind of information they want to know about the
> system.  The system object idea that you have would probably only be a
> partially-evaluated version of some high-level user objects.  The best way I
> can think of to explain it would probably be that the mathematical
> operations that the usual kernel has in its code to make it work are the
> focal point for your 'loss of information during translation'.  I think that
> with an adequate construction by user objects of mathematical systems, that
> information would stay intact, and be used as a 'user guide' to explaining
> how the system relates to the hardware.

I was referring to the fact that you can compile a high level language to
machine code, but you can't do the inverse, because information (symbol
names, comments, and often even the flow structure is changed by
optimizations) is lost during compilation.  That is why high level objects
(source) must be kept, for the user to look at.

> > We call such a system reflective, because the system-objects reflect the
> > user-objects.  A kernel architecture (and other architectures) presumes a
> > particular information flow among objects.  In a reflective system,
> > nothing about topology is presumed, so the maximum freedom in architecture
> > can be achieved. 
> > 
> I think that this last statement still needs work in explaining how the
> system objects reflect the user objects.  You may want to say that the
> reflective system contains its assumptions as first-order objects or
> something, and that reflection includes the ability to create environments
> from those assumptions.

Actually, I think there is confusion because I say this is a definition of
reflection, when it is only an example of what can be done in a reflective
system.  The term I think I want is a background optimizer.  It can only
be as extensive as described (or maybe exist at all?) in an open,
reflective system. 

> > The actual reflection process, or creating system-objects from
> > user-objects, need not be solely a manual nor automatic process.  Ideally,
> > the user and system cooperate in the process, because the system cannot
> > consider as many possibilities or come up with new approaches, and the
> > user cannot continuously repeat trivial actions. 
> > 
> That sounds like the linear system (computational device) vs nonlinear
> system (human mind) that I was talking about before.  Is that the idea?

Yes, I think it's similar.  The "system" we want to achieve isn't a
software system, but a synergy between human and machine.  So we're
designing the software part to fit well with the user.  The two complement
one another.  But really if the user is helping the system, it's only to
help the system help the user back (or some other user).

David Manifold <dem@tunes.org>
This message is placed in the public domain.