Hi Michael, as you know I am very interested in distributed objects and
have the same vision as you.

Michael van der Gulik <mikevdg at hetnet.nl> wrote:
> - are you thinking in any way about how your language would run on 
> multiple machines (i.e. by making it possible to have "special" objects 
> that may act as stubs)?

Yes, and since I'm moving message lookup into the image it will be even
easier to recognize stubs.

> - have you considered how your VM could possibly work on a computer with 
> multiple processors (processes or CPU's).

Not too much, I will have to think about it some more.  The goal is
model the VM like a real hardware machine and put as much as possible
into the image.  So maybe the ProcessScheduler in the image would pick
an available processor from the VM when resuming a Squid process.

> - have you considered having multiple sources for objects - i.e. from 
> multiple images, object storage databases, remote objects, ...

Yes, I have though about loading multiple images (better though of as
segments) into the same VM.  Cross pointers would still have to be
maintained or reified so the segments can be saved to their respective
files.  It might be just as easy to load each segment in to its own VM
and reuse the distributed objects protocol.  But the important thing is to
support cross pointers between segments (images), which I have always
anticipated.

Necessary primitives can always be added to the VM to support
cross-pointers, multiple processes, etc.  But most of the work should be
in the image.  Support primitives should just provide the necessary
access to internal state.

> (thought: making assignment ( := ) and reading of variables forms of 
> message passing that could be overrided would allow these tricks)

If your talking about instance variables and global variables, then
Squid does exactly that.  Inst/Class var assignments and reads are
compiled to message sends.  However, temp var assignments and reads
are compiled to "move" bytecodes.

> - And  would it be possible to make a language-independant VM, perhaps 
> with modifications to respective compilers, that could compile and 
> interpret Squeak, ANSI Smalltalk or Squid.

Yes.  That is why I'm defining a low-level VM so any compiler can
compile to it.  Particularly, an adaptive optimizing compiler.

Cheers,
Anthony