[Ecls-list] Ca ECL be embedded into C++?
Juan Jose Garcia Ripoll
worm at arrakis.es
Wed Dec 11 09:55:02 UTC 2002
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
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.
More information about the ecl-devel