Am 01.07.2008 um 21:25 schrieb Eliot Miranda:
> I would go further and rip out support for named primitives from the  
> VM and put it up in the image where it belongs.  I would build the  
> machinery for looking up named primitives in the image and have a  
> primitive that allowed one to slam a function address into a method.
>
> For me the VM should include an execution engine, a small and fast  
> FFI and nothing else.  One needs some VM support to bootstrap the  
> FFI.  i.e. the VM must include a primitive to load a platform  
> library and another to lookup a name in it.  But other than that  
> everything can be up in the image.  When one invokes a method with a  
> primitive that has not been bound to a function yet then the  
> primitive fails and the image's primitive failure code looks up the  
> primitive's name and retries the call or reports an error if the  
> library or name can't be found.

Well, until now FFI was intentionally optional. Making it mandatory  
would immensely widen the Smalltalk-System interface, in fact, there  
would be no clearly defined interface anymore. Until now, Squeak is a  
relatively safe place, bad crashes are rare etc. Whenever you deal  
with FFI the next crash is only minutes away. Also, you could expect  
that the image would soon fill up with lots of platform-specific code.  
But more importantly, it would make sand-boxing impossible, as any  
code in the image can do anything to your machine if it has access to  
FFI.

So it would simplify the VM at the expense of added complexity in the  
image. Which may of course fit the bill for Croquet which already  
relies on FFI, and except for Etoys nobody really uses the sand boxing  
anyway.

- Bert -