[Ecls-list] embedding questions

[Juan Jose Garcia-Ripoll]

On Sat, Dec 8, 2012 at 8:46 AM, Peter Keller <psilord at 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!

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121208/9a1555ed/attachment.html>