John,


> 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)".

But that's exactly what I consider to be more work than *should* be
necessary ;-) BTW, to give the discussion another impulse, we can not only
plugin stuff from external code. We could also provide a Smalltalk plugin
interface for stuff that is translated into C code. It's actually easy to
do: Provide a InterpreterPlugin class (containing some interpreterProxy)
reference which just forwards all the stuff to an Interpreter during
simulation. When translating a new VM into C source, choose the
interpreter and the (subclasses of) InterpreterPlugin you want to have in
the new VM and translate the entire stuff in your final interpreter
source. The only thing that needs to be changed for this is the
initialization of the primitive table from the core interpreter plus
the selected plugins but that's fairly easy to solve.

> 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.

It's trivial on Wintel and Unix (even though I'm not sure how different
dlopen and dlsym behave in different Unix derivates).

  Andreas
-- 
Linear algebra is your friend - Trigonometry is your enemy.
+===== Andreas Raab ============= (raab at isg.cs.uni-magdeburg.de) =====+
I Department of Simulation and Graphics      Phone: +49 391 671 8065  I
I University of Magdeburg, Germany           Fax:   +49 391 671 1164  I
+=============< http://isgwww.cs.uni-magdeburg.de/~raab >=============+