[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LISP FFI to C
Here's part of an interesting thread on the MCL mail list:
--- Forwarded mail from cfry@MIT.EDU (Christopher Fry)
>From firstname.lastname@example.org Thu Aug 20 22:46:02 1992
Date: Thu, 20 Aug 92 23:37:23 EST
From: cfry@MIT.EDU (Christopher Fry)
To: email@example.com (David A. Moon)
Subject: LISP FFI to C
Cc: cfry@MIT.EDU (Christopher Fry), Bruce Lester <72110.1107@CompuServe.COM>,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com
> Date: Thu, 20 Aug 92 18:15:42 EDT
> From: firstname.lastname@example.org (David A. Moon)
> To: cfry@MIT.EDU (Christopher Fry)
> Subject: Re: LISP - Oracle
> Cc: Bruce Lester <72110.1107@CompuServe.COM>, email@example.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
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: firstname.lastname@example.org
POBox 240002, M/S JY-58 UUCP: ...!uw-beaver!bcsaic!hsvaic!george
Huntsville AL 35824-6402 Phone: 205+464-4968 FAX: 205+464-4930