Reflection

[David Jeske]

On Tue, Jan 01, 1980 at 01:34:58AM -0800, Tril wrote:
> On Fri, 1 Jan 1999, Anders Petersson wrote:
> > The problem is that knowing the meaning of reflection doesn't bring you any
> > closer to the implementation of the OS. The idea is so general that it is
> > no more than a vague goal. Tril has said over and over again: this can be
> > done with reflection. Yes, in most cases he's right, but that says nothing
> > about *how* reflection is to be achieved. Until someone finds
> > out/alternatively tells me, I regard this idea to be nothing but an
> > achademic property to strive for in the design.
> >
> > It's like saying "our OS will be fast". You can say the system will be
> > good, since its speed will solve this and this, but if you don't know *how*
> > it will achieve its speed, you're in trouble.
> 
> Yes that was the intent of that post.  I realize the details are not
> specified.  We in the tunes project are working on it.  Actually, it might
> be far off, maybe even the last thing added.  Consider it the final goal,
> maybe.

I'd like to elaborate a bit on what tril said. I agree that he tends
to use the 'do it with reflection' fallback answer a bit too often,
but we don't fault him for it. :) Here is my own description of what
reflection means to Tunes in a functional sense, similar things have
been said by others many times on the Tunes list. This is going to be
a bit too close to implementation for most of the Tunes members, but
it may be more useful to UniOS people:

We should not throw out information about software as we translate it
from level to level. For example, when you compile a C program today,
it throws out argument types. It throws out information about
structure arrangement. It throws out information about enums. All this
information is 'buried' in the code which it generated. The code is
dependent on it. However, even if you had the original C source
around, without the compiler flags, version, and other environment
settings, there is no way you can guarantee to regenerate this
information correctly. Thus, the system can not reflect on the data
which it has right now (in this case a shlib), to understand what it
is.

One example of how an existing system might become 'more reflective'
in this useful way, would be for libraries/shlibs to include argument
type inforation, structure arrangement, structure element names, enum
descriptions, and similar data, _in the compiled library itself_. It
should also include a description of the function calling convention
the functions are expecting, and the binding dependencies it has with
the outside world. In this improved format, I could write a binding to
connect a script language to 'any sharedlib'. It would have all the
information it needed about structures, enums, other types, function
paramater passing, etc within the shared lib. Then you would only have
to write the binding description once.

Was that more concrete?

>> What speaks against is that mOS shows the user the true system topology. It
>> is not as I understand Tunes does - to present the user with a view that is
>> independent of the underlaying structures.
> 
> There is a view that is independent of underlying structures, but the user
> can cross it.  Normally there will just be a warning message that says,
> "if you go here and change stuff, it won't be platform-independent
> anymore."  You can still do stuff there, and it's all still objects.  I
> expect lots of hackers to do this.  It will be necessary to spend time
> here in order to find optimizations to make the system fast.

My understanding is that the intent of Tunes is to allow people to
specify lower-level information as much as they want, but to never
require that lower-level optimization information to run the
functional code. Cases which deal with low-level issues like hardware
access do not fall into this category because the low-level issues are
part of the required functional description.

>> As reflection changes the way the system is structured, without any
>> help from the user, reflection could confuse for the user by
>> changing the way *the user* sees the system.

Certainly. I'd like to rephrase what you said. The more indirection
which is possible in a system, the more confusing it is going to
be. Directness is much easier to understand. However, directness is
also much harder to maintain. I personally think the challenge of
presenting a system like Tunes is to find a way to represent a
reflective system in a direct way.

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