Am I correct in presuming that this will all be done "behind the scenes," in that the same message

	<primitive: 'foo' module: 'bar'>

would be used to access either?  That being said, can we be assured that the identifier 'foo_bar' will be recognized on every machine, or must we put limits on aggregate length "+1 for the hypen" to cater to the least common denominator machine?

If you do this, may I suggest that the search path begin with external modules, so that even when a fat executable exists, the search will first be made to see if a substitute module exists, so that the fat VM can be extended simply by adding a new plugin, without having to do surgery on the VM executable or a new system install of the thin one?

IMHO, the single best way to address this is to assure, at least, that a plugin directory can be used on all platforms that can support it.  (are there any that can't?)

It may be time to consider developing tools to facilitate management of plugins, checking versions and the like, so that an individual can readily determine which plugins are available, which are not -- and what versions are present.  Once again, a plugin folder or a common plugin extension would be helpful in this regard to identify which files are plugins and which are not.  (Apple has a wonderfully low-tech solution -- they have two folders for extensions, one for ones turned on and another for ones turned off.  Then, they provide a simple, easy to use interface that moves extensions from one folder to another.  Logistically, everything is hidden except at the appropriate level).

To that end, is it perhaps sensible to add reflective capabilities to the plugin files, perhaps a uniform, automatically generated routine that will return plugin identifier name, names of public functions and the version/date of generation information?

> Andrew,
> > Regarding your concerns about distributing all these plugins: > I have been
> working on a mechanism that allows to build 'fat' and 'lean' > VMs. A 'fat' VM
> can have an arbitrary number of plugins builtin so that you > need only a
> single executable for whatever you're redistributing. It's > actually quite
> simple since it does only involve a few modifications to the > generated code
> and a slightly different primitive lookup. The latter is > important for the
> name space issue - one of the modifications I made was to > prefix an exported
> primitive with it's plugin name if it is generated directly > for the VM.
> Therefore, you've got two ways of looking up an external > primitive which is
> either
> > 	'primitiveName' from 'moduleName'
> > if the primitive resides in an external module, or
> > 	'moduleName_primitiveName'
> > if the primitive is linked directly into the VM. In addition > to a few more
> changes this should allow us to keep the number of external > plugins in a
> reasonable range.
> >   Andreas
> > > >