Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!ai-lab!life!tmb From: tmb@ai.mit.edu (Thomas M. Breuel) Newsgroups: comp.lang.clos Subject: Re: CLOS' popularity Message-ID: Date: 25 May 91 01:56:35 GMT References: <16144.9105222015@subnode.aiai.ed.ac.uk> <9105231427.AA09586@cheops.cis.ohio-state.edu> Sender: news@ai.mit.edu Distribution: inet Organization: MIT Artificial Intelligence Lab Lines: 20 In-reply-to: duff@starbase.mitre.org's message of 23 May 91 18:25:39 GMT In article duff@starbase.mitre.org (David A. Duff) writes: >But the foreign function interface is a good way to get to this >"mainstream" software. If you thought about it, you might be able to write >the interface automatically. You could even think of LISP as the glue that >holds your C together. This might give you most of the best of both worlds. yes, i have done a considerable amount of development with lisp in this mode (lisp as glue). Unfortunately, among system programming languages, C is the least suitable for interfacing with other languages. The main reason is C's unfortunate confusion of arrays and pointers. ANSI C has now at least opened the door to letting you view "pointers" as "displaced-to arrays", but it will probably be a long time (if ever) until C vendors catch on to the fact that the information of what range a pointer is valid over should be kept at runtime, both for better error detection, and to allow better interfacing with other languages. Thomas.