LISP FFI to C

[george@hsvaic.boeing.com (George Williams)]

Here's part of an interesting thread on the MCL mail list:

--- Forwarded mail from cfry@MIT.EDU (Christopher Fry)

>From info-mcl-request@cambridge.apple.com Thu Aug 20 22:46:02 1992
Date: Thu, 20 Aug 92 23:37:23 EST
From: cfry@MIT.EDU (Christopher Fry)
To: moon@cambridge.apple.com (David A. Moon)
Subject:  LISP FFI to C
Cc: cfry@MIT.EDU (Christopher Fry), Bruce Lester <72110.1107@CompuServe.COM>,
        info-mcl@cambridge.apple.com, kgrant@us.oracle.com, york@lucid.com,
        jonl@lucid.com, swm@scrc.symbolics.com, rwk@crl.dec.com

> Date: Thu, 20 Aug 92 18:15:42 EDT
> From: moon@cambridge.apple.com (David A. Moon)
> To: cfry@MIT.EDU (Christopher Fry)
> Subject: Re: LISP - Oracle
> Cc: Bruce Lester <72110.1107@CompuServe.COM>, info-mcl@cambridge.apple.com,
>         kgrant@us.oracle.com
> 
> > Date: Tue, 18 Aug 92 15:05:20 EST
> > From: cfry@MIT.EDU (Christopher Fry)
> > 
> > Franz, Lucid, Symbolics, and Harlequin seem to be moving in this direction.
> > I'm not sure what Apple's plans are but please join me in encouraging
> > Apple to cooperate here. In particular, a standard FFI to C code
> > might go a long way toward writing useful portable utilities like an SQL
> > interface.
> 
> I will just offer my own opinion here, intended to cut the Gordian knot that I 
> think prevented foreign function interface standardization in the past, which 
> is that the various vendors couldn't agree on the syntax of the Lisp macro 
> that declares a foreign function and specifies the types of its arguments and 
> result.  The answer is, don't have a Lisp macro for this, make the Lisp 
> compiler read C header files instead.  It's not very hard to implement.  This 
> is more convenient for the user, too.
If a C library vendor could sell their object files plus C header files to
Lisp hackers and the lisp hacker could just use them with no need to write
calls to def-foriegn-function, that would be a huge win because C vendors wouldn't
have to know lisp and Lisp users wouldn't have to know C.

Could it be arranged such that the CL function LOAD recognized when it was passed
a C object file, a C header file, or a lisp file and did the right thing?

MCL has foriegn "environments". If we just said "There's only one foriegn envirnment"
and simply specified that you've got to load the C header file(s) before its corresponding
object file(s), that would be pretty easy for the user.
 
> The vendors would still have to agree on the mapping of C names and types to 
> Lisp.  I have an opinion on that, too, but it's too lengthy to include here.
I imagine that whatever automatic mappings you came up with, someone would want 
to override some of them. Do you believe its possible to come up with a set
likely to be right 99% of the time provided the Lisp user didn't care about
optimizing the types or didn't care about the function names as long as
they were unique and contained within them the C fn name?

Chestnut has done Lisp-to-C automatic function name mapping. While considering
the C-to-Lisp mapping problem, we should see if we could convert a Chestnut-made
C function name into the Lisp name in the original Lisp source that it came from.
 
> Feel free to forward this message to other vendors or mailing lists if you 
> wish.
Done to Lucid and Symbolics. Don't have an address for Franz. or Harlequin
so anyone who does, please forward this. 
> These are my personal opinions, not necessarily the opinions of Apple Computer 
> nor of the Macintosh Common Lisp product developers.


--- End of forwarded message from cfry@MIT.EDU (Christopher Fry)

George Williams            BCS Huntsville Artificial Intelligence Center
Boeing Computer Services   Internet: george@hsvaic.boeing.com
POBox 240002, M/S JY-58    UUCP: ...!uw-beaver!bcsaic!hsvaic!george
Huntsville AL 35824-6402   Phone: 205+464-4968 FAX: 205+464-4930