From: cfry@MIT.EDU (Christopher Fry)
Newsgroups: comp.lang.lisp.mcl
Subject: Re:  LISP FFI to C
Date: 21 Aug 92 18:15:20 GMT
Original-To: moon@cambridge.apple.com (David A. Moon)
Original-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.