[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LISP FFI to C
- To: moon@cambridge.apple.com (David A. Moon)
- Subject: Re: LISP FFI to C
- From: cfry@MIT.EDU (Christopher Fry)
- Date: Fri, 21 Aug 92 13:15:20 EST
- 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: Fri, 21 Aug 92 11:06:49 EDT
> From: moon@cambridge.apple.com (David A. Moon)
> To: cfry@MIT.EDU (Christopher Fry)
> Subject: Re: LISP FFI to C
> 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.
Proposal: add a keyword to LOAD called :FILE-KIND indicating the possible file
kinds for the file being loaded.
It would take symbols:
:lisp-source, lisp-compiled, c-source, c-compiled, etc.
[note I've avoided the word "object" because of the ambiguity with object-oriented
programming]
or a list of the same.
We could also have :lisp stand for (:lisp-source :lisp-compiled)
Likewise for other languages.
The default value for the keyword would be :lisp [indicating just the current behavior.
Vendors would be required to support :lisp but not the other lnaguages.
However if they do support he other languages, they would be encouraged to
conform to this guideline.
If kind :c-source file is passed, it could either be a header file or the actual c source.
If the actual c-source is passed, only the "header" info would be extracted. You'd still
have to pass in the c-compiled. [Well I suppose some eager hacker could pass the
c-source to a c compiler and generate the .o file then load it.]
:FILE-KIND might also take another special value, :GUESS-FROM-NAME
In the C world, I believe types of .h, .c, and .o are at least very common.
.l, .lsp, .lisp, .fasl, .fsl and maybe a few others ought to cover all the lisp
cases. If file names turn out to be unambiguous enough, :GUESS-FROM-NAME could even
be the default value for :FILE-KIND.