on the HAL-9000

[David Jeske]

On Sun, Oct 11, 1998 at 03:08:47PM -0700, RE01 Rice Brian T. EM2 wrote:
> This is just a follow-up to the previous post to add some ideas that I
> forgot to mention.

I'll respond to your previous post later..

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

In my opinion, Tunes should be as close to the 'total reflection at
all costs' side of the curve as possible. For situations where
performance is more important, there should be a path for letting
people who know about optimization on the hardware plug in optimizers
which will help make the code that actually runs more static. It
should be Tunes' job to keep even this static code tied to the high
level description of the same code, so that it can always reflect on it.

As a small concrete example, if your language lets you make a
data-structure, how tunes represents this on the hardware should be
irrelvant. When you write code to deal with this data structure, Tunes
(and the underlying compiler) should be able to generate static code
which access this data structure as if it were a static structure, if
you use some kind of reflection to get at the data, Tunes will know
the static layout of the structure in memory. If you use reflection to
add a data-member to the structure, Tunes can decide whether or not to
invalidate the static code and recompile it.

In other words, we should not be compromising full type-information
and reflection under any circumstances. We should be focusing on full
functionality at all times, and methods of reaching better performance
which don't defeat having full run-time information available.

In fact, this should not even prove that difficult. I could imagine a
C compiler which would store full run-time information about the names
and static offsets of all data structures and functions. This would
incur zero penalty to static code and yet would allow you to get at
those items in a reflective fashion.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net