home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!paladin.american.edu!europa.asd.contel.com!darwin.sura.net!mips!sdd.hp.com!uakari.primate.wisc.edu!ames!data.nas.nasa.gov!taligent!apple!cambridge.apple.com!moon
- From: moon (David A. Moon)
- Newsgroups: comp.lang.lisp.mcl
- Subject: Re: LISP FFI to C
- Message-ID: <9208211501.AA13263@cambridge.apple.com>
- Date: 21 Aug 92 15:06:49 GMT
- Sender: info-mcl-request@cambridge.apple.com
- Lines: 21
- Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
- Full-Name: David Moon
- Original-To: cfry@MIT.EDU (Christopher Fry)
- Original-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.
-