[Ecls-list] Ca ECL be embedded into C++?

[Juan Jose Garcia Ripoll]

On Wednesday 11 December 2002 17:09, Andrew Topp wrote:
> It is possible. I know this because I'm doing it. My project
> (http://unicorp.sourceforge.net/) uses ECL as its commandline
> interpreter and script engine, among other things for the future.
>
> Unfortuneately, the project's currently being neglected, and only works
> with ECL 0.6. Juan was assisting me a bit with some modifications to ECL
> and patches to UC regarding 0.7+ and its function name changes, etc. I'm
> not sure how that's going.

Slow :-) Christmas is coming and I am taking two weeks off. This should help 
me find some time to help you with Unicorp. Unless, of course, some nice girl 
distracts me. But we already know that this does not happen to me frequently 
:-)

> I'm using the CLOS streams and cfuns called from there to take the
> inputted commandline and break out of the Lisp toplevel when no more is
> available.

With Qt, and with the requirements exposed in the previous e-mail, it should 
be easier than with unicorp. You do not need to set up a listener. You can 
construct a string, parse it into a list (using c_string_to_object) and 
evaluate it using cl_safe_eval().

Furthermore, you will like to have a look at the "ecl-config" executable. It 
works pretty much like "glib-config", or other *-config programs from the GNU 
world. It tells you which flags and libraries you have to pass to the 
compiler in order to link ECL into your application.

> Feel free to look. I'm pretty sure its laid out reasonably well. You
> want to look at unicorp/plugins/lisp/*.cpp in the CVS.

Yes, the source in Unicorp is rather clear. I am planning to write some demos 
myself, and will accept third-party demos as well. So, if you get some nice 
hello-world program with Qt, please submit it!

> I had similar problems at the start of developing UC with ECL :).
> Experiment a bit with the Lisp->C compiler, stop it from deleting the
> sources it generates and look at them. The external.h and
> lisp_external.h headers also do ok as documentation.. and there's always
> the source.

This is partly my fault, but I saw no point spending a lot of time writing 
documentation, when things are prone to change. For instance, I am now doing 
more changes on the C names of functions (I intend to apply the cl_*, si_*, 
ecl_* prefixes which I explained long ago). And the FFI is also going to 
change -- maybe with ideas from CMUCL.

One more thing: the interface for C/C++ users is not fixed. If you think 
there's some functionality missing, feel free to send a message to the list.

Best regards

Juanjo