----- Original Message ----- 
From: "Mathieu Suen" <mathk.sue at gmail.com>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, November 07, 2007 3:42 AM
Subject: Re: What would Squeak be like without non-local returns


> By the way I have a suggestion for the #class and #==.
> Instead of building a new VM you could patch the compiler to avoid 
> emitting the bytecodePrimEquals...
> So people can just use you code without having a compiled VM.
>

I have actually decided that #== and #class are protocol belonging to the 
reference and not to be eventually sent.  So I disabled the VM changes I 
made in this regard.   I see now that I am more familiar with the Compiler, 
that I could patch the compiler to make these msg sends, rather than 
bytecodes and if I change my mind about these, that is definitely that 
approach to take.

There is a need for an #eventuallyEquals: operation, when the distributed 
stuff is added back in to the framework.  Object a holds Object b from Vat 
B, and Object c calls Object a with a remote reference to Object b, called 
b'.  b should equal b'.

Since I no longer need vm changes for #== and #class, the only current 
changes I have are for the Larger Contexts (80) and for the extra long 
jumps, added to support the combined macros I added to the compiler for 
#ifTrue:, #whileTrue: and so on.  I still haven't gotten those changes to be 
stable.

As the roadmap on http://wiki.squeak.org/squeak/6011 describes, I plan on 
protecting primitives to allow them to have eventual arguments.  This would 
entail vm changes.  Finally, supporting messaging between vats may entail vm 
changes, which I attempted last week but failed.  I tried to add a word to 
every object header, but it kept crashing on me.

So, in summary, vm changes are possible for:
    - support Compiler changes for combined macros
    - protecting Primitives from eventual arguments
    - support messaging between multiple vats

Cheers,
Rob