>Mike wrote:
>> I think we need to be very careful about adding too much bulk to the Squeak
>> environment.  I want to be able to use it for handheld devices,
>
>It is interesting you mention this. I think this is closely related to
>what Tim called a _way_ too complicated and convoluted VM. So here is a
>suggestion:
>
>At the moment everything concerning primitives is kept in the interpreter
>itself (actually it's in both the Interpreter and the DynamicInterpreter).
>However, it is not easily possible to remove this since if you want to
>remove say the entire networking stuff, you'll have to do quite some
>modifications to the VM. And this, in turn, makes porting and adding
>new stuff much harder than it actually *should* be. Why don't we just take
>out stuff that is not needed to actually run squeak in some sort of
>plugins?! The only thing which would be needed is a well-defined interface
>to access, register and unregister from the VM. Than we could put a whole
>lot of stuff in separate classes (such as BitBlt) and keep the actual
>interpreter small.

I disagree with part of this; it is actually *quite* easy to
remove the VM support for optional features such as sound I/O and
networking. The way to do it is to make stubs for the C functions
that do the real work, and to have these stubs call "sucess(false)".
This will make the primitives simply fail if they are called. Yes,
some glue code still remains in the interpreter, but it consumes
a trivial amount of space.

The real argument for Interpreter Plugins is that they would
allow folks to add primitives without recompiling or even
re-linking the interpreter. This would greatly facilitate
experimentation, I think. The only downside is that we'd need a
cross-platform way of handling DLL's. This probably isn't
too difficult, although its not an area that I know much about.

	-- John