Subject: Re: Foreign Functions (was Re: Why lisp failed in the marketplace)
From: Erik Naggum <erik@naggum.no>
Date: 1997/02/25
Newsgroups: comp.lang.lisp,comp.lang.scheme
Message-ID: <3065895394194764@naggum.no>


* 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