> From: johnson at cs.uiuc.edu (Ralph E. Johnson)
> At 3:09 PM 2/27/99, Dan Ingalls wrote:
>> [ assume native methods, allow those to trap to interpreter ]
>> [ every class as its own interpreter ]
>> [ revisit approach by interoperating ST, Java, others ]
>> [ issues of integrating memory ... ]
>
> This is a lot like what I said the last time we met.  However, I think 
> that the lowest level of execution should be just functions, not  
objects.
> I'd make objects be the next level up.  I believe that you want the 
> bottom level to include double-dispatching.  In my opinion, that is 
> too complicated.  The bottom level should be close to the machine. 

This is starting to become overload, so many of my favorite  
Squeakhancements at once!

Objective-C (which started as a pre-processor generating C)  
demonstrates that going from a machine level, procedural (C  
functions) execution model to a fully dynamic Smalltalk-like one  
pretty much takes a single function, lookup(), which returns a  
function pointer pointing to the method body to invoke ( method <-> C  
function) + some related runtime support.  The language extensions  
requiring the pre-processor are just syntactic sugar, the same code  
could just as easily be generated from Squeak using a slightly  
modified Squeak->C-translator (or other code generation techniques).   


Interoperability with current Objective-C could be a good starting  
point for studying multiple language/environment integration.   
Changing the meaning of some bit combinations in the object header (  
low 2 bits, use 00 as the 'reserved' bit combination and let that  
denote an Objective-C class) and modifying the messager to switch to  
Objective-C dispatching would almost do the trick.  Likewise, the  
Objective-C messager has to be modified to recognise non zero in the  
low 2 bits of its 'class-pointer' as a word-1 of the Squeak object  
header ( + the SmallInteger coding).

I haven't thought about doing the switch on a per-method basis yet,  
as a matter of fact I was thinking about making the granularity  
broader, maybe on a per package/moduke basis.

Marcel