home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / lisp / mcl / 1283 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  1.8 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!sdd.hp.com!uakari.primate.wisc.edu!ames!data.nas.nasa.gov!taligent!apple!cambridge.apple.com!moon
  2. From: moon (David A. Moon)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re: LISP - Oracle
  5. Message-ID: <9208202210.AA20652@cambridge.apple.com>
  6. Date: 20 Aug 92 22:15:42 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 25
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10. Full-Name: David Moon
  11. Original-To: cfry@MIT.EDU (Christopher Fry)
  12. Original-Cc: Bruce Lester <72110.1107@CompuServe.COM>, info-mcl@cambridge.apple.com,
  13.         kgrant@us.oracle.com
  14.  
  15. > Date: Tue, 18 Aug 92 15:05:20 EST
  16. > From: cfry@MIT.EDU (Christopher Fry)
  17. > 
  18. > Franz, Lucid, Symbolics, and Harlequin seem to be moving in this direction.
  19. > I'm not sure what Apple's plans are but please join me in encouraging
  20. > Apple to cooperate here. In particular, a standard FFI to C code
  21. > might go a long way toward writing useful portable utilities like an SQL
  22. > interface.
  23.  
  24. I will just offer my own opinion here, intended to cut the Gordian knot that I 
  25. think prevented foreign function interface standardization in the past, which 
  26. is that the various vendors couldn't agree on the syntax of the Lisp macro 
  27. that declares a foreign function and specifies the types of its arguments and 
  28. result.  The answer is, don't have a Lisp macro for this, make the Lisp 
  29. compiler read C header files instead.  It's not very hard to implement.  This 
  30. is more convenient for the user, too.
  31.  
  32. The vendors would still have to agree on the mapping of C names and types to 
  33. Lisp.  I have an opinion on that, too, but it's too lengthy to include here.
  34.  
  35. Feel free to forward this message to other vendors or mailing lists if you 
  36. wish.
  37.  
  38. These are my personal opinions, not necessarily the opinions of Apple Computer 
  39. nor of the Macintosh Common Lisp product developers.
  40.