NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/lisp/mcl/1284

Internet Message Format | 1992-08-20 | 3.6 KB

Path: sparky!uunet!cs.utexas.edu!swrinde!sdd.hp.com!uakari.primate.wisc.edu!ames!data.nas.nasa.gov!taligent!apple!cambridge.apple.com![e-mail]
From: [e-mail] (Christopher Fry)
Newsgroups: comp.lang.lisp.mcl
Subject: LISP FFI to C
Message-ID: <[e-mail]>
Date: 21 Aug 92 04:37:23 GMT
Sender: [e-mail]
Lines: 53
Approved: [e-mail].C0M
Original-To: [e-mail] (David A. Moon)
Original-Cc: [e-mail] (Christopher Fry), Bruce Lester <[e-mail]>,
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail]

> Date: Thu, 20 Aug 92 18:15:42 EDT
> From: [e-mail] (David A. Moon)
> To: [e-mail] (Christopher Fry)
> Subject: Re: LISP - Oracle
> Cc: Bruce Lester <[e-mail]>, [e-mail],
>         [e-mail]
>
> > Date: Tue, 18 Aug 92 15:05:20 EST
> > From: [e-mail] (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.