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.