[Ecls-list] Tighter c/c++ integration, toplevel inline c/c++ code ???

[Seth Burleigh]

I was wondering if it is currently possible to embed toplevel c/c++ code
in a lisp file (structure definitions, but most importantly c/c++
functions/methods). Just some ideas, i was wondering how 'difficult' the
below would be, if it is worth it, etc.

I can think of a couple of reasons for this:
(1) A C/C++ program wants to call a lisp function with its own data
structures: it doesn't want to worry about interconverting between
representations (currently, all lisp functions take only ecl objects).
Rather, the lisp program should automatically create a toplevel c
function which can do the interconversions (the macro forces the user to
define c types of arguments) and then call the appropriate lisp function
with the data. Otherwise, a separate c file would have to be created
which does the interconversions. However, this is not optimal because
the transfer between data representations can be done automatically by
macros.


(2) Intertwined development/tight integration: if an algorithm needs to
be implemented in c/c++ for efficiency, it is much more convenient to
define it in the lisp code than create another c/c++ file (if its being
used by lisp functions in that package). And an algorithm like this
would probably need to be created using multiple c/c++ functions (for
modularity) which take c/c++ data types, rather than inefficient
interconversions to/from lisp objects.

Of course, the code would also have to be able to call lisp functions
defined in the current package in order for this to be effective (or to
be able to call lisp functions which have been designated as
'callbackable', like in gambit-c scheme)

For #2 above, it would be convenient to also be able to export the
function, i.e. place code in the .h file (which i think is already
possible). It would also be necessary, to be able to call this c code
from lisp functions in the current package.

(3) Programs built in c++ already have a class hierarchy. If you want to
create a subclass which the c++ program can use, you need to be able to
directly input toplevel code (i.e. define a class, methods, etc). Again,
this could be done in another c/c++ file, but tight integration with the
lisp code would result in  quicker development (in my opinion).

Already, it is possible to have embedded language highlighting/indenting
in emacs, which would help with this level of c/c++ integration.

Alot of the above is what gambit-c's foreign function interface is
capable of, so maybe some inspiration could be drawn from there.