>-------------------------------------
>MyPlugin>>mySmallIntegerAdd: arg1 arg2: arg2
>	"Primitive. Add two integers. Optional."
>	< primitive: 'mySmallIntegerAdd' module: 'myModule'
>	  returns: SmallInteger
>          arguments: (SmallInteger SmallInteger)>
>
>        ^arg1 + arg2
>-------------------------------------
>
>This doesn't affect the Smalltalk code at all. If I think about it, that's
>the place where the spec really belongs.

I don't disagree.  In practice, however, the calling procedure might 
exist in a plurality of places, not in just one, and in the calling 
Class, not some other "plugin class."  This syntax invites a 
dangerous duplication of code, IMHO.

But I do believe that the information should be inline in the Plugin 
class definition of the primitive, along the lines of Andreas' 
remarks.

A separate and distinct issue would be to provide functionality for 
DIRECT calls to EXISTING plugins written in different languages, with 
implicit coercions, along the lines of the GNU Smalltalk, thereby 
permitting API's to be written from inside of Smalltalk and obviating 
the necessity of writing pure glue plugins unless the glue is 
actually providing certain functionality.  I had started writing such 
a PluginPlugin several times, but was sidelined with more interesting 
projects.  It would be nice to have access to such functionality 
"built-in," perhaps, but this is another issue entirely.

It would be necessary to distinguish a "pure" plugin from a Squeak 
primitive plugin to avoid a call to setInterpreter, perhaps by using 
a keyword cModule or the like.