From ... From: Erik Naggum Subject: Re: Foreign Functions (was Re: Why lisp failed in the marketplace) Date: 1997/02/25 Message-ID: <3065895394194764@naggum.no>#1/1 X-Deja-AN: 221408398 References: <5eg0oj$tbb@Masala.CC.UH.EDU> <5eg59n$33h@fido.asd.sgi.com> <1997Feb24.110601.16097@wavehh.hanse.de> mail-copies-to: never Organization: Naggum Software; +47 2295 0313; http://www.naggum.no Newsgroups: comp.lang.lisp,comp.lang.scheme * Holger Schauer -> Martin Cracauer | So, would you say that it is not possible to define such a standard | interface because it would require uniform implementation details ? | Or would you say it is possible but not very probable that | lisp-vendors (free lisp vendors alike) can and will standarize on | such an interface? I don't know what Martin would answer, but part of the problem with foreign function interfaces as far as I have been looking at them is that they must be _very_ efficient and that this efficiency is very difficult to obtain across the wide range of ways you can implement Common Lisp on various current hardware, more so on various no-longer-current hardware. also, there has been little concensus on which language it is useful to talk to. C is relatively easy, but other languages that do fancy typing stuff are much harder, and the more automatic elements there are in the code, the more the interface needs to replicate of the other language. a few language-independent standards are being developed in ISO/IEC JTC 1/SC 22 these days. I have looked at CD 10967-2 Information Technology -- Language Independent Arithmetic -- Part 2: Elementary Numeric Functions. if the rest of this standard is as good, there's at least hope of something good coming out SC 22. Lisp is recognized as an important part of these standards. | I think from the user's point of view a standarized foreign-function | interface would be great. There is no doubt that such a thing will | involve a lot of difficulties and work for the lisp vendors. On the | other hand, I could imagine that if we had such a standarized interface | lisp could also gain some more popularity. I don't think Common Lisp needs foreign function interfaces to all sorts of other languages while these other languages are somehow viewed as closer to the hardware. in several languages, unlike C, invariants are maintained in abstract data types by running code in accessors, and it is not valuable to have a foreign function interface only to static data. if the other language cannot cooperate, there's little point in crying for a standard FFI for Common Lisp alone. in other words, I would like all languages to recognize the need for FFI's, and to find a more abstract data and function interface language. this language will probably be "dumber" than any of the languages that talk to it, but to me, this rhymes well with the need for a foreign function _interface_. too complex interfaces suggest that the design is not sufficiently well thought-out. on the other hand, I would have liked a native Unix system call interface that could skip the dumbing-down that the C interface library represents. e.g., most system calls in most Unix implementations return an error as a CPU flag, not as some stupid special value and setting a global variable like the C library exports to C programmers. that is, it should be fairly simple to create a condition system for Unix system calls that could be more efficient and less insane than the C stuff we have to deal with via today's foreign function interfaces. Ada has gone this route, to create "bindings" to the POSIX kernel. as it happens, I tend to spell it "POSUX" and think it would be foolish to replicate this monstrosity (it's grown a lot bigger than the Common Lisp standard, all parts counted), but the Unix kernel isn't _that_ far from supporting the needs of the Common Lisp file system interface. if you allow me a digression, I would have liked a Unix implementation to honor the many options to `open', including versions and the ability to abort writing a file. this is doable, but it requires the will to do more than the Unix kernel normally does. I don't think this is any different than the C library does in the cases where the Unix kernel does not do what the programming interface is required to export. (end digression.) I could summarize my position as "C is not the best that Unix can get". #\Erik -- if you think big enough, you never have to do it