From: Pierre Parquier
Subject: free Lisp for C++
Date: 
Message-ID: <PARQUIER.96Oct11130642@halles.ilog.fr>
Right now comp.lang.lisp focuses on the Lisp vs. C++ debate.  I think
the following could be of interest to many -- our approach is more how
to get best of both worlds.  And the good news is that our solution is
free on Linux (see below).


··@cs.utk.edu (Norman Ma) wrote:

 > Either way, try not to use both languages.  You may spend more
 > time on integration than research.  I've worked on a project
 > that had to interface LISP and C++ (LISP:intelligence, c++:simulator).
 > The end statistics was that we spent more than 50% of labor hour 
 > on LISP-C++ interface and close to 70% of code was written to
 > transoform data structure back and fourth between the 2 languages
 > on multiple platforms.

Two years ago, ILOG introduced a Lisp to address this problem.  Since
then our customers have developed complex code in Lisp, and used or
developed C++ libraries, and wasted no time in integration.  ILOG Talk
automatically binds C++ code: binding a hairy library requires less
than a hundred lines of code for a hairy C++ library, a straightforward
library is linked in one line.

The technical side of this has been exposed at 1994 Conference on Lisp
and Functional Programming, which can be found in ACM proceedings, and
at http://www.ilog.fr/Products/Talk/cpptalk.html (1).


···@intentionally.blank-see.headers (Thomas Breuel) wrote:

> Yes, the fact that Lisp-C++ interfaces take that much code is a
> problem, but trying to avoid it by not interfacing with C/C++ at all
> is throwing out the baby with the bathwater.  There are too many
> useful libraries with C APIs out there that you can't reimplement.
> [...] Lisp vendors must address this issue better:
> 
>  (1) They should include many more Fortran/C/C++ libraries already
>      interfaced to their systems.  This includes image I/O, video,
>      audio, databases, compression, Web protocols, etc., both vendor
>      specific (eg. SGI's libraries, Windows) and vendor neutral (third
>      party, reference implementations).  There is nothing that will be
>      more discouraging to a potential customer than having to spend a
>      few weeks building tools that they get automatically and for free
>      with other systems before they can start solving their problems.
>      Where are the Tools.h++, Linpack.h++, and Socket.h++ wrapper
>      libraries of the CommonLisp world?

C++ libraries are (most often) object-oriented, so that you really
want the binding to merely expose the objects and behaviors the C++
programmer sees.  Therefore, a blind Lisp/C++ binding is fine, and if
it is automatic, you don't really need your Lisp vendor to make those
bindings for you.  And since you can bind your C++ libraries yourself,
you can also bind your custom C++ extensions of these libraries too.

Conversely, I agree you want your Lisp vendor to supply you with many
C and/or Fortran libraries -- these are a pain to bind, as one has to
create an object model to provide a decent Lisp interface.  This is
very different from C++ library binding.


>  (2) By making FFI a lot easier.  This includes automatic parsing
>      of C/C++ header files, conservative stack marking, C++ classes
>      to manipulate Lisp values, etc.  One may not like it (I
>      certainly don't), but current APIs are almost all build around C,
>      with a little bit of C++ and Fortran.

I concur.  I would add that to be called from C/C++ world, your Lisp
code should not require having control over main().


>  (3) By standardizing at least a portable subset of FFI facilities.
>      There are only two vendors left.  I guess if one of them goes
>      out of business, we have standardization in the commercial
>      implementations :-( Seriously, to avoid that, addressing this
>      issue would be a good idea.

I think there are a few more Lisp vendors around.  But even if you
consider only Common Lisp vendors, FFI is really tough to standardize.
For instance the ability to share objects of both worlds in both
worlds (instead of translating data) depends havily on the memory
management of each Lisp implementation.  Also C++ is a moving target,
and you want your FFI to keep in pace with C++ new oddities --
standardization committees are not quite fast at that job.  I agree it
would be much better to have a standard FFI, one that would make every
program portable -- but I doubt this will happen anytime soon.


Now the good news.  We just made available for free our Lisp for C++
on Linux.  ILOG Talk is selling since 1994 on Unices and Windows95/NT
(ask ····@ilog.com), and is now free on Linux (fetch
ftp://ftp.ilog.fr/pub/Products/Talk/linux/ilog-talk-3.2.tar.gz or
ftp://sunsite.unc.edu/pub/Linux/devel/lang/lisp/ilog-talk-3.2.tar.gz
or any other sunsite mirror).

ILOG Talk automatically binds to any C++ code, providing full OO API
from within Lisp.  Almost all Talk customers use it to develop complex
or fast applications leveraging on existing C++ libraries.  Besides,
there is much more to Talk: scalability, ease of programming,
meta-object protocol, POSIX support, easy socket programming,
efficiency, etc. which are detailed at http://www.ilog.fr/Products/Talk/
-- but that's not this thread's theme.


I hope you'll enjoy!


Pierre Parquier
········@ilog.fr

______________________________________________________________
(1) Abstract:

      A tight, transparent, and portable integration between C++ and
      LISP is desirable and feasible. This paper describes the C++
      interface supplied with ILOG TALK, a modern LISP dialect which
      extends the proposed ISO LISP standard with a module system, a
      metaobject protocol, and an extensive set of libraries. The
      interface parses C++ header files and generates C++ stub
      interface files, as well as ILOG TALK modules which implement
      proxy classes and ILOG TALK foreign function definitions for C++
      functions. The programmer then has nearly complete access to the
      functionality of a C++library.