Self/R not started yet - some plans

[Jecel Assumpcao Jr]

2001 was a "hardware year" for me and I haven't written yet the first 
line of code for Self/R. I did work a little on its design and have 
posted a Swiki address here with more information.

Just a quick review in case someone has no idea what I am talking 
about: Self/R is supposed to be a reflective implementation of Self. 
What Self does with a C++ virtual machine, Self/R would do in Self 
itself with "meta objects". That makes some things easier - if you want 
to add a new kind of message to Self 4.1.4 you will have to change some 
source text files, recompile everything and restart Self to see the 
effect. In Self/R you would get the use all the great tools available 
in that environment and would be able to see the effect of your changes 
while the system is running.

I think everyone can agree that this is a very good thing to have. But 
I have been thinking a lot about "the community", as John and Albertina 
have put it. It would be very desirable for us all to work together 
around a single code base instead of having two separate 
implementations (which would be worse than having two lists ;-). So I 
have been trying to evaluate how far I can go by adding Self/R features 
to Self 4.

There are some things that have nothing to do with reflection and could 
be written in Self 4 without any changes at all to the virtual machine:

   1) the 3D and Zooming graphical user interface
   2) the extensible event system
   3) multi natural language support
   4) simpler graphical syntax

The next two would require patching the C++ code, but I don't think 
they would be too much trouble:

   5) primitive objects instead of primitive messages
   6) the cache manager

The last one might be possible to do in C++, but it would be a really 
major project:

   7) the persistent object store/virtual memory/security/viewpoints

The problem with doing things in this order is that 6 and 7 can make 
possible a different Self programming style that would make 1-4 much 
simpler. I won't go into details about what each of the projects listed 
above actually is unless there are people interested in them.

Note that having 1-7 would make Self 4 more interesting for my project 
and do most of what I want reflection for, but it still wouldn't be 
Self/R. But as the saying goes, "perfect is the enemy of good enough".

Until recently I simply had to have a "Self in Self" compiler to get my 
hardware to work. Self/R would have to be built in any case. But I have 
now changed my design (it is now less Transmeta-like and more 
PicoJava-like, though that is a very poor analogy) and a "black box" 
virtual machine (like Self 4) looks like a reasonable option for 
running the same software on normal computers as I do on my hardware.

So for now "Self/R" will mean "Self 4 running on my hardware". In the 
hope of helping keep the community together I will put off having it 
mean "Self in Self" as long as I can.

Does this make any sense?

Cheers,
-- Jecel