[Henrik had asked why it wasn't possible to call a Squeak method  
from the outside]
[Andreas gave lots of good, technical reasons[

Although the reasons Andreas gives are all excellent, I don't really  
think they answer Henrik's question, which I would restate as  
follows:  why are there all these (absurdly) difficult obstacles to a  
rather straightforward requirement.  After all, what more basic  
requirement can you have for a method than invoking it?

The answer, as so often, is architectural mismatch (*).  Squeak is  
built around architectural assumptions that make it difficult for it  
to interoperate with other systems.  One of these assumptions, and  
one talked about at length in the referenced paper, is ownership of  
the event-loop, of the thread of control.

A system that assumes it has control of the event loop will be  
difficult to impossible to integrate with other systems that make the  
same assumptions.  On the other hand, a stand-alone system must take  
charge of the event loop, and Squeak does, in essence, play the part  
of a stand-alone system, with the integration problems that we keep  
running into.

However, I believe it should not be too difficult, and quite useful,  
to re-cast Squeak as a reactive system, similar to the way Objects  
were turned into re-active entities in Smalltalk-76 [I hope this  
characterization is correct].  One of the keys to this is that  
object-oriented systems, unlike procedural ones, don't really need to  
be active in order to offer well differentiated reaction to external  
stimuli.  After all, the basic dispatch-mechanism used in OO is  
equivalent to a top-level "receive, dispatch" loop.

A recasting of Squeak would essentially turn it into an object,  
replacing the top-level byte-code-based interpret() loop with an  
interpreter function that takes an object and a message as an  
argument, sends that message to the object and returns.  This would  
allow Squeak to be integrated much more cleanly into modern operating  
systems that provide event-loops for their applications.  Current  
stand-alone behavior can be trivially regained by a single top-level  
loop that repeatedly calls this function.

I also notice more and more ad-hoc OO-style dispatch tables in the  
VM-support code.  When are we going to bite the bullet and use real  
OO for that?

Marcel

(*) "Architectural Mismatch, or, Why it's hard to build systems out  
of existing parts", David Garlan, Robert Allen, and John Ockerbloom,  
Proceedings of the 17th International Conference on Software  
Engineering, April 1995.