[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LISP FFI to C
- To: cfry@MIT.EDU (Christopher Fry)
- Subject: Re: LISP FFI to C
- From: moon (David A. Moon)
- Date: Fri, 21 Aug 92 11:06:49 EDT
- Cc: 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 23:37:23 EST
> From: cfry@MIT.EDU (Christopher Fry)
>
> 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?
Implementation-dependent, obviously. On the Macintosh, object files for C (and all
other MPW-based static languages) are self-identifying, but on other systems it
might not be possible to distinguish a C object file from some other kind of file.
At the other extreme, on Symbolics Genera a Lisp object file and a C object file are
in identical formats and loaded identically, and I imagine this is true in KCL as
well.
There is no good, portable way to tell a C source file from a Lisp source file,
especially if the Lisp user has modified the readtable. However, there might be
some bad ways, such as assuming that "(in-package" not preceded by a { is unlikely
to be valid C.
If you want this additional feature that the programmer doesn't have to know what
language things are written in to load them, that would create some additional
things that the vendors would need to agree on in order to create a standard.