the vm _is_ the database

[David_Stutz@NeXT.COM]

Well, alright -- I usually don't express myself well...

>>So, you should at least separate "interesting" objects from  
>>"temporary" objects.  The problem is, it may not be easy to  
>>distinguish them automatically.  So, you probably end up telling  
>>the compiler what objects should be considered "interesting".  But  
>>if you do so, theproposal resembles persistency, and is not so new  
>>anymore.

The point is not that the techniques are so new, the point is that  
self fits into them so incredibly well...  I am not suggesting that a  
pig of a database be grafted onto self -- instead, I'm suggesting  
that the existing vm machinery (which already resembles many  
efficient database engines) be examined in the possibly enriching  
light of another closely related, and extensively studied,  
discipline.

You would most definitely want to have a means of expressing which  
objects were of "interest" if such an expensive shadowing scheme were  
used -- once having done this, you would sometimes want to keep the  
very short-lived invocation clones for tracability and reversability,  
if relevant (debugging, for instance, or within a "transaction").  At  
other times, you might elect to not keep anything at all...  As I  
said:

>**Object persistance** is clipped into the vm -- it is important to  
>realize that it is NOT integral to the language -- it is a separate,  
>invokable, service.  You might not even use it, if you're doing  
>something lightweight.

I am less interested in talking about specifics of persistence, and  
more interested in the language implications of a factoring such as I  
suggested.  Where do you go to get your prototypes when you are on a  
large network of 100 mips workstations, all running self and sharing  
some set of prototypes? This may finally be a tractable problem,  
within the self runtime!

David Stutz