reflective architecture

[RE01 Rice Brian T. EM2]

	[questions about reflective system bootstrapping from Ken Evitt.]

> You are basically right, but the problem is that having just one model
> which is reflective is not enough.  You have to support all possible
> reflective models, and switch between them at the drop of a hat.  E.g.
> Brian may do some work in Arrow and I work in my little world of types and
> objects, but the system allows us to see what each other is doing in our
> native viewpoint.  If Brian writes some arrow construction that is
> complicated to express in types and objects, then I'd rather look at the
> Arrow version.  But I'd do it by emulating Arrow inside my system.  Then
> the reflection of my own system allows me (somehow) to reify the emulated
> Arrow system back into the running objects+Types system.  In Arrow, Brian
> would do the reverse.  Except that we're not really in different systems
> at the high level since they interchange, and we may not be at different
> systems at the low level since we could be using the same implementation
> of tunes. If we have completely different implementations it is separate
> from the high level view that we choose to use.
> 
this logic applies to my current work on the paper.  basically, applying
Godel's theorem of the incompleteness of standard first-order predicate
logic (or, generally, any first-order theory) to the subject of reflection
tells us that no single model of "self" can ever be complete.  in other
words, there will always be some questions about the system that it will
never understand or encapsulate if it is stuck with one theory or a set of
theories of itself.  the idea behind the "model-level reflection" term is
that instantiating models in a general-purpose way and working within that
framework is the key to overcoming this limitation.  the arrow system is
supposed to answer this requirement by cutting through the implicit
assumptions down to some "minimal" semantic level.  obviously, my writing
hasn't answered this question yet, and perhaps i should leave the formal
proof to another paper.

however, the results of my final work on the paper should show some polish
(even without TeX).  hopefully, i can close the work on the paper shortly
and direct the loose ends towards questions in the conclusion.  i apologize
if you all were expecting a self-contained work, but i have found that more
thinking must be done for that.  so, i will simultaneously refine the
ArrowWorld prototype, perhaps introducing several different prototype
systems and releasing them for review and experimentation.  it should help
answer some of our questions.

btw, are there any comments about the source code?  any bugs discovered?  i
know that the class definitions beyond Arrow itself are relatively empty.

here's a list of functionality for ArrowWorld:
* a general purpose quantifier message for queries about the state of the
system.  it would take as an argument a graph of the message (like a CONS
tree) and answer an ArrowGraph that satisfies the definition.  the answer's
intension would be the argument message itself (by default), and caching of
instances that the system requests from that ArrowGraph would happen
automatically (via the ArrowGraph class).  this message would be the
fundamental dynamic construct for the system.  it would automatically add
the answer to UserGraph and SelfGraph.
	syntax: "forAll: anArrowGraph"
* a way to collect arrows that the user makes (directly or indirectly) into
new graphs, and a way to test and then specify the intension of these new
graphs, so that the system has a fundamental way to move information from
"user choice" to "system deduction".  this will also allow for garbage
collection.
* an instance of ArrowWorld with some state that defines a basic reflective
framework, like the "is an element of" relation, relations representing the
fundamental arrow logic relations, and others (any ideas?).

this seems like a basic set of tools from which we may build a complete
system.