reflective architecture

[Maneesh Yadav]

Hello all, before I start, La Jolla is awsome, I love it here.

Something I've been wanting to say for ahwil, I still really can't comment
fairly on Brian's stuff.  Although he does provide definitions in his
paper, there is a lto of stuff I am still shaky on (catagorey theory,
formal grammars, knowledge based representation).  I therefore can't
really do alot before I read up on those areas and have a firm
understanding.  I am trying, but it will take awhile.  I think I am one of
the few that admits to this, I see too many people being critical when
they don't (like me) have the fundamentals.  Brian, perhaps it would be
good to setup a pedagogy of books that one should read to be lead in the
direction of coming up with formalisms to define concepts.  I can't even
understand the journals on the subject...and for any of those who think
Brian's idea is acedemic BS...there already is a tremendous amount of work
done in this field; and no one will come up with a good model until the
funadmentals are mastered.

Side note,
I met up with a long time phone/email friend/teacher for the first time a
while aog, John McCarthy.  If any of you were into the 3d coding scene
years ago he make the 3dVect library along with the games Outer Ridge and
Forified (both done entirely in asm, when you see them you'll appreciate
how good a coder he is) plus tonnes of other little asm graphics code
snippets.  It was remarkable chance that we were in the same city at the
same time, and he just now got a job at 989 studios making games for a
handsome (and well deserved) sum.  He made Outer Ridge out of his basement
in 100% asm years ago, and look where he is now.  That is a real coder.

BTW Brian, when will you be in San Diego?


On Wed, 26 May 1999, RE01 Rice Brian T. EM2 wrote:

> 	[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.
>