on the HAL-9000

[RE01 Rice Brian T. EM2]

This is just a follow-up to the previous post to add some ideas that I
forgot to mention.

	The Tunes system's dynamic compilation tools, it's interface-generating
capabilities, and its proof systems are all based on its ability to
reflect.  One of the most important questions, I believe, is 'How should
this reflective ability be managed?'.  After all, Tunes would be a
little annoying if it spent more time thinking about an action it was
planning than the user was willing to allow it.  Suppose a part of the
system hangs, even for reasons that the system cannot control.  How will
the event be handled?  How will it be detected?
	Conceivably, every piece of code or data could be reflected upon
whenever the system encounters a reference to it, each with its
multitude of specifications, mostly shared.  Certainly every piece of
code or data should be reflectable, but when does abstraction access
time become more of an issue than the run-time efficiency of the system?
 There seems to be a trade-off curve for execution versus reflection
efficiency based on usual coding techniques (with traditional software
on a lower curve than Tunes products, of course ;).  I base this
impression on the various programming languages and their relative
compilation efficiencies (and including social factors which make a
language more popular as part of a language's efficiency rating).
	Basically, how does reflectional policy affect the Tunes system?  Could
we derive the reflectional policy from the Tunes ideals?

	P.S. concerning proof-generators: It has occurred to me the possibility
of a homo-iconic system of logic where all systems of statements,
including a program's code, are represented by special graphs
(data-structures of specially-linked lists).  Proof-generators could be
made extremely efficient by only operating on this form of the code.
I'll have to think more on this.