Reflection

[Tril]

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.

Here is something to think about. How to make the Linux kernel reflective? 
Put a compiler in the kernel.  Put the source code in the kernel.  Put
functions to view and manipulate the source code in the kernel (I mean a
syntax-directed editor). Then put in the last tricky function, which
replaces the running kernel with a newly compiled one.  Presto, fully
self-contained system [wait, add source code to the compiler, too!].  (No,
you probably don't have enough RAM for this monster kernel to entirely
fit. But swapping code in from disk has been done already.)  BTW, if you
don't put any of this in the kernel, but you still have it all, you have a
reflective system (but not reflective kernel).  Only the last step is
really bad, because it requires rebooting :) 

> Could mOS support reflection? It does have some properties that makes it
> more suitable for reflection. Each system is devided into lots and lots of
> small units, each one (or the vast majority) movable, and replacable in
> real-time. Updates are also noticed as they are done, not by a reboot.

Sounds good so far.  Just consider the above example for mOS, instead of
Linux, and you will get an idea of what you are up against.

Remember, every system has reflection.  It's just how long the road is
(and how bumpy) from one system to the changed system. 

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

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

Well, it could be done with the help of the user.  Anything in Tunes can
be done either with, or without, the help of the user.  Usually the user
helps first, then when s/he is comfortable with what is going on, sets it
on autopilot.  (this is true for every action in the system, not just
reflective activities.)

David Manifold <dem@tunes.org>
This message is placed in the public domain.