On Sat, Dec 8, 2012 at 8:46 AM, Peter Keller <psilord@cs.wisc.edu> wrote:
I'm about to use ECL for some embedding work, namely having a front
end C interface to a well-known C plugin system with an ECL backend
implementing all of the plugin functionality.

Good! Please report both success and any problems you may find.
I have a few questions before I begin:

1. Is the API denoted in ecl/externals.h pretty stable? Do people think
it is going to change much in the future?

Pretty much stable for all prefixed names (ecl_, cl_, si_). Not prefixed names will get prefixed in a near future, with a compilation flag allowing to use the old names.

But try to stay away from non-standard Common Lisp functions, just in case.
2. Are there any issues or special considerations with creating CLOS
objects and then calling methods on them from the C side? Will those
methods dispatch correctly on the arguments without additional poking
from the C side?

I do not understand your concerns here. Function calls using a symbol name work the same in the interpreted and compiled world, and in the compiled world we use the same code that you will use in C.
3. I have a situation where I have C structures full of data and want
to push them into/bring them out of the Lisp side. Are things like
si_make_structure what I'm supposed to use on the C side? Are there
idioms I should know about to perform this type of data translation?

NO! Please learn to use foreign function interfaces, either the ones supplied by ECL, http://ecls.sourceforge.net/new-manual/ or some other one, such as CFFI.

Note that it is definitely easier to write C code embedded in lisp code than try to reproduce all functionality of lisp in your plugin, which is why you should consider using ECL to compile your code.
4. I will have a couple of C files and a pile of lisp files when I'm
done. I assume that I'd just compile and assemble them into a shared
library as denoted elsewhere in the docs and on this list? Are the ecl
non-private functions and symbols minimized in the exports of the
library to lessen the chances of stomping on something in the
application when the plugin gets loaded?

Lisp files only export an init function with a very ugly name and whatever function name that you declare it to export (there is some obscure declaration for that, but right now I do not remember which one).

5. If I si_safe_eval something like (setf a 3), then later si_safe_eval
on the variable a, is that defined? Are toplevel bindings of specials,
functions, macros, persistent between invocations to si_safe_eval?

This question is not related to the evaluation, but to Common Lisp environments. Each thread has its own environment, plus there is a global environment that encompasses all of them. When you evaluate code in a thread, it affects both of those environments.

* If there was a global variable binding around your evaluated form and you assign to that variable, then the change stays local

* If there was a thread-local binding, then the change affects only that thread

* Otherwise the change affects the global environment.

Really, there is nothing different in embedding ECL from running normal lisp code. Please use this for reasoning about how things work: your standard ECL interpreter is just a stupid embedding of ECL in a four lines program!


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)