>>"MC" == Martin Cracauer schrieb am Mon, 24 Feb 97 11:06:01 GMT:
>> The bigger problem here is the lack of a stardard C interface for
>> lisps. Until that exists, any package, such as Winterp will only
>> run on top of the lisp version it was built for.
MC> I don't think that makes too much sense. The semantics of alien
MC> integration for the various implmentations of Lisp are too
MC> different. Just a few points:
[list of points deleted]
MC> An then, most important, how will you handle cases where the lisp
MC> runtime lacks one of these features? For good performance, there
MC> is no other way than to conditionalize code on the base of lack
MC> or suport of features.
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 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.
Just my 2c,
Holger
--
holger_schauer :-
mail_address(···············@gmd.de"),
project("BGP-MS/AVANTI, GMD Sankt Augustin, FIT.MMK"),
www_home_page("http://www.uni-koblenz.de/~schauer/index.html").
(^:= A donkey came to my office. It had a theory about people anaphora...
From: Erik Naggum
Subject: Re: Foreign Functions (was Re: Why lisp failed in the marketplace)
Date:
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
From: Ray Dillinger
Subject: Re: Foreign Functions (was Re: Why lisp failed in the marketplace)
Date:
Message-ID: <3314B47C.37EC@sonic.net>
Erik Naggum wrote:
> <Deleted -- a call for more complete and robust operating system support
of language features including, but not limited to, FFI.>
I have been considering this question lately, and I think I disagree.
The vendors of various operating systems have decided independently
what abstractions they will support, and there is not always an
isomorphic mapping between those abstractions and the abstractions
of a particular language. This leads to the kind of trouble we're
having with FFI and filesystems, for starters; not only are various
language implementations incompatible with each other, they are often
not fully implemented insofar as they don't match the prefab set of
abstractions defined by the OS.
I'm more of the opinion that the services provided by the operating
system should be unspeakably simple -- dealing perhaps with disk
sectors even rather than files -- and the entire abstraction supported
by languages then ought to be built in the language implementations.
The benefit of course is that you'd not have people trying to do the
square-peg-in-the-round-hole business that you get with, eg, trying
to support file security on DOS, or all of the open options on UNIX,
or whatever. The drawback of course, is that language vendors
would have to be drilling their own holes, in terms of fully
implementing the abstractions supported by their languages, instead
of trying to map them onto the set of abstractions supported by the
OS. The effect is that the compatibility barrier would shift from
language/OS to language/language -- probably no worse than todays
incompatibility barriers -- but the abstractions specified by the
language would, at least, be fully implemented.
Bear
From: Bengt Kleberg
Subject: Re: Foreign Functions (was Re: Why lisp failed in the marketplace)
Date:
Message-ID: <5f1735$3nn$1@euas20.eua.ericsson.se>
In article <·····················@hamlet.zeus.gmd.de>, ·······@zeus.gmd.de (Holger Schauer) writes:
...deleted
>
>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.
>
There was a long thread discussing this about 6(?) months ago in comp.lang.scheme.
Perhaps there is a news group archive?
--
Best Wishes, Bengt
--------------------------------------------------------------------
Email: ·············@enea.se (Enea Data AB, Sweden)
Disclaimer: Nothing abovementioned has any connection to Enea Data AB
``At the moment money does indeed make the world go round but unfortunately
the direction of that applied rotation is all downhill.'' ······@netreach.net
·······@zeus.gmd.de (Holger Schauer) writes:
>>>"MC" == Martin Cracauer schrieb am Mon, 24 Feb 97 11:06:01 GMT:
> >> The bigger problem here is the lack of a stardard C interface for
> >> lisps. Until that exists, any package, such as Winterp will only
> >> run on top of the lisp version it was built for.
> MC> I don't think that makes too much sense. The semantics of alien
> MC> integration for the various implmentations of Lisp are too
> MC> different. Just a few points:
>[list of points deleted]
> MC> An then, most important, how will you handle cases where the lisp
> MC> runtime lacks one of these features? For good performance, there
> MC> is no other way than to conditionalize code on the base of lack
> MC> or suport of features.
>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 would say that a standard alien interface that keep performance loss
to a minimum would be:
1) so complex that it is very hard to learn, maybe harder than
learning several individual alien interfaces.
2) using it with performance in mind would still require a lot of
conditionalization of code on the base of the supported features
(namely neccessary conversions).
The difference would be that you conditionalize your code on the base
of alien features, not Lisp implementations.
I.e.: #+alien-no-string-conversion instead of #+cmu
If someone doesn't have the need for optimal performance, I think the
macro used by ILU is just fine. The fact that people didn't jump on it
and implemented it for every CL implementations show somewhat that
such a simple interface is not of real interest for people.
I think defining a standard alien interface that is a full superset of
existing interfaces is not worth the effort. You will still have to
conditionalize and I don't think the time required to design and
implement for the abstractional layer "standard alien" will not pay
off.
And all this discussion is just about defining the interface between
Lisp and alien code.
We didn't even touch of problem of actually loading alien code. Not
all Lisp implementations can load object files of the underlying
implementation. Some require linking it in, which from the logical
view of the alien interface means that loading alien code requires to
restart the whole Lisp image. You definitivly want to coditionalize
your code on that fact.
>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.
IMHO, more popularity would not be the result of an standard alien
layer, but the result of applications thereof.
The question is: What applications do you think of? How many of these
implementations can be implemented on top of a subset of available
alien interfaces. Is performance important for these applications?
For my own work, I found that every use of aliens required good
performance. And please keep in mind that I don't use aliens to
replace Lisp code for better performance, my implementation is usually
fast enough. I use aliens for system access and to reuse existing C
libraries (i.e. regular expressions).
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin