API scheme for externals (Re: R: [PD] Re: [PD-announce] clr: externals in CLR assemblies

[Kjetil S. Matheussen]

Mathieu Bouchard:
> BTW, anyone looked at SWIG ?

Yepp, I've used it some times.


> It could provide a multilanguage interface to
> Pd's API and/or Flext's API. SWIG generates wrappers from C++ code to
> Python, Ruby, Perl, Java, C#, Tcl, PHP, Lua, and several kinds of LISP
> (Guile, AllegroCL, CMUCL, ...).
>
> SWIG might be the key to unifying the Pd API in various programming
> languages (currently, PyExt, GridFlow, k_guile, all do things quite
> differently from each other). Note that I don't want a "common
> denominator" API which would prevent from using any special features of a
> given language in the Pd API for that language. Nevertheless I would like
> language-specific APIs to be easy to guess (deduce) so that it's easy to
> start writing externals in language X for someone who has general
> experience in language X and experience in writing Pd externals in
> language Y.


Well, do you think theres so many different functions that we should
invovle a common API set? Perhaps its a good idea, but theres only about 
10-15 very essential functions and various, eh, esoteric ones, that hardly 
anyone use. Anyway, when making k_guile, I did follow the API of PyExt 
naming, so at least those two should be quite common. (by the way, k_guile 
is soon going to be marked as obsolete, the snd external is far superior).

Regarding SWIG, its a beast that creates totally crazy code. I have used
it for radium, ceres and mammut, but its doing too much, I think. At least 
for this. But maybe its worth looking into. The challenge about external 
language externals is anyhow threading, garbage collection, time 
spent doing things, and other things that can ruin dsp operations, 
not the API.

So, I think that a more sober approach would be to make some kind 
of official guide-lines for making external languages externals, and put 
it into some kind of official documentation.