In article <················@arolla.idiap.ch> ···@arolla.idiap.ch (Thomas M. Breuel) writes:
In article <·····@castle.ed.ac.uk> ····@castle.ed.ac.uk (Jeff Dalton) writes:
Nonetheless, I think ML is a good langauge. I happen to prefer
Lisp, but I'm perfectly happy for other people to prefer ML.
....
Why does it have to be "either...or"? A language that combines a
static type checker with Milner-style polymorphism (SML), dynamic
typing (Lisp), pattern matching (SML), incremental interactive
development (Lisp and SML), late linking (Lisp), a powerful module
system (SML), built-in support for functional programming (SML), a
convenient and powerful foreign function interface (C++), a data
description language (C/C++), semantics suitable for efficient
numerical computation (FORTRAN), and simple and extensible syntax
(Lisp) is perfectly imaginable. I find all these features convenient,
and I don't see why I shouldn't have them all.
....
.... With Lisp, I get the impression that it is
somewhat stagnant these days.
I myself like ML (even if I found that there is really NO programmer's
environment for it - moreover I found myself making a lot of mistakes
programming in it *because* of the synctatic rules - but that's my
problem :) ). I believe that all the research gone into type
inferencing is very important and you can already see its influence in
the Lisp community (the CMU CL Python compiler is an example).
This is clear the field before I declare myself a CL zealot :). Yet my
faith in the future of Lisp *IS* shaking.
A couple of weeks somebody came up with a list of desiderata for the
evolution of (Common) Lisp. Some of them are contained in the list
above.
I apologize if somebody finds this discussion annoying, but I want to
reopen the wounds in order to see something happening in a possibly
near future.
In my opinion, Lisp suffer from a "closed world assumption" which is
mirrored within the community itself. Technically, this "closed world
assumption" is immediately mirrored within the community itself. In
particular I believe that the lack (at this point in history) of
1) a portable foreign function interface
2) a portable low level interface to the underlying OS (i.e. UNIX or
whatever runs on PCs and MACS)
3) a portable (and available) graphical/windowing environment
Is what keeps people away from using Lisp.
So much for griping. Please do not reply by pointing out what "is out
there" (I know of WCL and CLIM etc. etc.). Just tell me whether you
agree or not and whether you think there are the technical and economical
possibilities to achieve some result and to get LISP going again.
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
From: Fernando Mato Mira
Subject: Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...)
Date:
Message-ID: <21mrh3$mcq@disuns2.epfl.ch>
In article <·····················@image.cs.nyu.edu>, ·······@image.cs.nyu.edu (Marco Antoniotti) writes:
>
> In my opinion, Lisp suffer from a "closed world assumption" which is
> mirrored within the community itself. Technically, this "closed world
> assumption" is immediately mirrored within the community itself. In
> particular I believe that the lack (at this point in history) of
>
> 1) a portable foreign function interface
> 2) a portable low level interface to the underlying OS (i.e. UNIX or
> whatever runs on PCs and MACS)
> 3) a portable (and available) graphical/windowing environment
>
> Is what keeps people away from using Lisp.
>
I think you should add:
4) portable object files (.fasl) across run-time facilities provided by
different vendors for a given platform.
*5*) Delivery costs comparable to those of C++ for non-higher-order run-time
environments (I think that, for commercial CLs, this is only valid for ACL/PC now).
--
Fernando D. Mato Mira
Computer Graphics Lab "There is only one Language
Swiss Federal Institute of Technology and McCarthy is its prophet"
········@di.epfl.ch
FAX : +41 (21) 693 - 5328
Disclaimer:
disclaim([],[]).
disclaim([H|T],[DH,DT]) :- fixed_point_disclaimer(H,DH),
disclaim(T,DT).
fixed_point_disclaimer(Text,fixed_point_disclaimer(Text,_)).
·······@image.cs.nyu.edu (Marco Antoniotti) writes:
>1) a portable foreign function interface
>2) a portable low level interface to the underlying OS (i.e. UNIX or
> whatever runs on PCs and MACS)
>3) a portable (and available) graphical/windowing environment
What I really miss, is a portable function to run a process of the
underlying operating system and to connect streams to the i/o-pipes of
that process. Something like 'run-program' in CMU CL.
Although this is not portable to all Lisp platforms, it would be
useful for UNIX and the modern 32-bit OS for PCs, Windows NT and OS/2.
On platforms without standard processes with simple i/o-pipes (Lisp
Machines, MacIntosh) this could run a process on a UNIX machine
connected to it.
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@wavehh.hanse.de>,Voice+4940-5221829,Fax.-5228536
------ C is a good language - for implementing programming systems -------
From: Jeff Dalton
Subject: Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...)
Date:
Message-ID: <38351@castle.ed.ac.uk>
In article <·····················@image.cs.nyu.edu> ·······@image.cs.nyu.edu (Marco Antoniotti) writes:
#A couple of weeks somebody came up with a list of desiderata for the
#evolution of (Common) Lisp. Some of them are contained in the list
#above.
Lisp has evolved rather than been designed, and that's what I'd like
to see continue. I don't think it makes sense to "improve" Lisp by
finding out what people who don't like Lisp want and then doing that.
I don't think it's possible to satisfy those people without turning
the language into something that isn't Lisp.
#In my opinion, Lisp suffer from a "closed world assumption" which is
#mirrored within the community itself.
Part of it, perhaps.
# In particular I believe that the lack (at this point in history) of
#
#1) a portable foreign function interface
#2) a portable low level interface to the underlying OS (i.e. UNIX or
# whatever runs on PCs and MACS)
Other languages typically don't define foreign-function interfaces.
Instead, they can exploit (de facto) standard procedure call and object
file standards. These languages and standards don't make much, if
any, effort to accommodate Lisp. All the work has to be done by
Lisp implementors and designers, and I'm not surprised that standards
have not yet emerged.
#3) a portable (and available) graphical/windowing environment
Well, there are some of these, and some parts (e.g. CLX) are
fairly standard. However, I'd agree that the Lisp community blew
it here. Lisp started out with a huge lead in this area (IMHO).
-- jd
From: Frederick Staats
Subject: Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...)
Date:
Message-ID: <fritz.742503691@Cadence.COM>
STANDARD DISCLAIMER ·····@cadence.com (Frederick Staats) All opinions
are my own and may not represent the views of my employeer Cadence Design
Systems, Inc.
····@castle.ed.ac.uk (Jeff Dalton) writes:
>In article <·····················@image.cs.nyu.edu> ·······@image.cs.nyu.edu (Marco Antoniotti) writes:
># In particular I believe that the lack (at this point in history) of
>#
>#1) a portable foreign function interface
>#2) a portable low level interface to the underlying OS (i.e. UNIX or
># whatever runs on PCs and MACS)
>
>Other languages typically don't define foreign-function interfaces.
>Instead, they can exploit (de facto) standard procedure call and object
>file standards. These languages and standards don't make much, if
>any, effort to accommodate Lisp. All the work has to be done by
>Lisp implementors and designers, and I'm not surprised that standards
>have not yet emerged.
However "most" other languages that use these de facto standard
procedure calls and object file standards do not have garbage
collection on their fundmental data types. Once you throw in
implementation specific garbage collection there is no safe and
standard way use a pointer to reference data which my be marked for
collection. This is a tricky area, do not under estimate the need for
a standard foreign function interface, especially when LISP is being
as an embedded as part of a larger application.
I also agree that the portable low level interface to the underlying
OS is invaluable. Once you have seen what it takes to port any large
application to a new environment (even just another flavor of UNIX)
you will see what I mean.
--
Frederick Staats, Applications Engineer ·····@Cadence.COM
Cadence Design Systems, Inc.
555 River Oaks Parkway, Bldg. 1 (408) 428-5225 (Voice)
San Jose, CA 95134 (408) 954-8917 (Fax)
From: Thomas M. Breuel
Subject: Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...)
Date:
Message-ID: <TMB.93Jul13144804@arolla.idiap.ch>
In article <···············@Cadence.COM> ·····@Cadence.COM (Frederick Staats) writes:
However "most" other languages that use these de facto standard
procedure calls and object file standards do not have garbage
collection on their fundmental data types. Once you throw in
implementation specific garbage collection there is no safe and
standard way use a pointer to reference data which my be marked for
collection. This is a tricky area, do not under estimate the need for
a standard foreign function interface, especially when LISP is being
as an embedded as part of a larger application.
I don't think this is necessarily a big problem. A basic foreign
function interface would not have to support more than passing around
scalar data (numbers, characters) and opaque C (machine-) pointers.
Any implementation can support those facilities efficiently (provided,
of course, that there is C/FORTRAN code to link with).
For a little more efficiency, you might also provide optional
facilities to pass Lisp arrays of integers and floating point numbers
as 1D arrays or pointers to C/FORTRAN code. The necessary protection
of Lisp objects from garbage collection can even be done in portable
CommonLisp.
I wouldn't be surprised if people faced with the problem of porting
Lisp code using foreign functions among implementations had already
come up with a portable interface layer to implementation specific
facilities. What about it? Does anybody have code/experience to
share? What about a free parser that looks through ".h" files and
outputs some kind of Lisp foreign function declarations?
Again, I think this issue is crucial. Other languages are addressing
it (C++, Sather, etc.), and Lisp should as well.
Thomas.
From: Jeff Dalton
Subject: Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...)
Date:
Message-ID: <38552@castle.ed.ac.uk>
In article <···············@Cadence.COM> ·····@Cadence.COM (Frederick Staats) writes:
#STANDARD DISCLAIMER ·····@cadence.com (Frederick Staats) All opinions
#are my own and may not represent the views of my employeer Cadence Design
#Systems, Inc.
#
·····@castle.ed.ac.uk (Jeff Dalton) writes:
#
##In article <·····················@image.cs.nyu.edu> ·······@image.cs.nyu.edu (Marco Antoniotti) writes:
#
### In particular I believe that the lack (at this point in history) of
###
###1) a portable foreign function interface
###2) a portable low level interface to the underlying OS (i.e. UNIX or
### whatever runs on PCs and MACS)
##
##Other languages typically don't define foreign-function interfaces.
##Instead, they can exploit (de facto) standard procedure call and object
##file standards. These languages and standards don't make much, if
##any, effort to accommodate Lisp. All the work has to be done by
##Lisp implementors and designers, and I'm not surprised that standards
##have not yet emerged.
#
#However "most" other languages that use these de facto standard
#procedure calls and object file standards do not have garbage
#collection on their fundmental data types. Once you throw in
#implementation specific garbage collection there is no safe and
#standard way use a pointer to reference data which my be marked for
#collection. This is a tricky area, do not under estimate the need for
#a standard foreign function interface, especially when LISP is being
#as an embedded as part of a larger application.
I'm not sure what you're aiming at here. No amount of Lisp
standardization will solve this problem, because it requires
change in implementations of other languages.
#I also agree that the portable low level interface to the underlying
#OS is invaluable. Once you have seen what it takes to port any large
#application to a new environment (even just another flavor of UNIX)
#you will see what I mean.
But I have ported applications to other flavours of Unix, and
I don't see what you mean.
-- jd
In article <·················@dennis.flw.att.com> ···@dennis.flw.att.com (Lawrence G. Mayka) writes:
In article <·················@arolla.idiap.ch> ···@arolla.idiap.ch (Thomas M. Breuel) writes:
That seems to indicate that the idea of a standard FFI interface isn't
off the wall, and that implementations already provide enough similar
functionality to make a useful standard FFI feasible.
Hopefully, people involved in standardizing Lisp dialects will take
notice, and we will sooner or later see some standard (sooner better
than later!).
I'd be happy enough with a de facto standard, agreed upon among the
major Common Lisp vendors, in this area (FFI) as well as others.
I surely agree with that point, but the current situation is the
following:
CMU CL has its ALIEN package
(A)KCL has its own way to include C.
Lucid has its FFI (which is whi you need it to run Lispview)
Allegro has its FFI (which is why you need it to run CORBA)
Harlequin has its own FFI.
I have access only to CMUCL (and soon to MCL it looks like), so if
anybody has worked out some package that translates into each
different FFI, please tell everybody.
Have a nice day
Marco
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
B. Brecht
In article <·····················@image.cs.nyu.edu> ·······@image.cs.nyu.edu (Marco Antoniotti) writes:
CMU CL has its ALIEN package
(A)KCL has its own way to include C.
I haven't worked with these yet...
Lucid has its FFI (which is whi you need it to run Lispview)
Allegro has its FFI (which is why you need it to run CORBA)
Harlequin has its own FFI.
These three are sufficiently similar that a (not very) clever macro
can translate between them. There are some differenced w.r.t. loading
the files, but that is easily handled. Sorry, but I can't post the
macro :-(.
I have access only to CMUCL (and soon to MCL it looks like), so if
anybody has worked out some package that translates into each
different FFI, please tell everybody.
Have a nice day
Marco
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
B. Brecht
Who'd *want* to have my opinions!?
--
____/|
Michael Haynie \ o.O| ACK!
···@wisdom.attmail.com =(_)= THPHTH!
U
Has anybody got a simple readtable with their own macro characters that
permits conversion from C expression syntax into a LISP equivalent
that they are willing to part with? I'm lazy enough not to want to code
this puppy up.
ie: I want to parse symbols mixed with various C operators with the assumption
that the symbols in the expression do not contain operator characters.
Say a string contains something like "p1*p4==(value1/(val10+ val12))" would
convert into a common lisp form of something like:
(eql (* p1 p4) (/ value1 (+ val10 val12)))
I don't want to parse all C-code but just simple string expressions like
above.
Curt Eggemeyer
Jet Propulsion Laboratory
4800 N. Oak Grove
Pasadena, Ca. 91109
Internet: ····@eraserhead.jpl.nasa.gov phone: (818) 354-6592
From: Mark Kantrowitz
Subject: Re: Parsing horrific C expression syntax
Date:
Message-ID: <CAHMI5.4wy.1@cs.cmu.edu>
In article <··········@elroy.jpl.nasa.gov> ····@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) writes:
>
>Has anybody got a simple readtable with their own macro characters that
>permits conversion from C expression syntax into a LISP equivalent
>that they are willing to part with?
>
>ie: I want to parse symbols mixed with various C operators with the assumption
>that the symbols in the expression do not contain operator characters.
>
>Say a string contains something like "p1*p4==(value1/(val10+ val12))" would
> convert into a common lisp form of something like:
>
> (eql (* p1 p4) (/ value1 (+ val10 val12)))
>
The infix package available from the Lisp Utilities Repository
(anonymous ftp to ftp.cs.cmu.edu in the directory
/afs/cs.cmu.edu/user/mkant/Public/Lisp/
as the file infix.lisp) does something similar. There are some
deliberate differences in the syntax from C syntax, but you could
always modify it to read more C-like expressions.
--mark
In article <············@cs.cmu.edu> ······@cs.cmu.edu (Mark Kantrowitz) writes:
>In article <··········@elroy.jpl.nasa.gov> ····@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) writes:
>>Has anybody got a simple readtable with their own macro characters that
>>permits conversion from C expression syntax into a LISP equivalent
>>that they are willing to part with?
>The infix package available from the Lisp Utilities Repository
>(anonymous ftp to ftp.cs.cmu.edu in the directory
> /afs/cs.cmu.edu/user/mkant/Public/Lisp/
>as the file infix.lisp) does something similar.
You can also get my PARCIL program from cambridge.apple.com in pub/mcl2/contrib
It's not as capable as the INFIX program, but it's considerably smaller and
simpler.
Erann Gat
···@robotics.jpl.nasa.gov
From: Thomas M. Breuel
Subject: Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...)
Date:
Message-ID: <TMB.93Jul13143651@arolla.idiap.ch>
In article <·····@castle.ed.ac.uk> ····@castle.ed.ac.uk (Jeff Dalton) writes:
#1) a portable foreign function interface
Other languages typically don't define foreign-function interfaces.
Well, C++ did, and that's probably one of the main reasons for its
rapid acceptance, despite its many shortcomings.
Instead, they can exploit (de facto) standard procedure call and object
file standards. These languages and standards don't make much, if
any, effort to accommodate Lisp. All the work has to be done by
Lisp implementors and designers, and I'm not surprised that standards
have not yet emerged.
Note that C++ features like overloading, type-safe linkage,
semi-automatic memory management, and (soon) garbage collection are
currently supported by C compilers, assemblers, and linkers that were
written with none of those features in mind.
Thomas.
Well, since I started it I will keep going.
BTW. Thanks to all who send me private mails. I appreciate them all.
In article <·················@arolla.idiap.ch> ···@arolla.idiap.ch (Thomas M. Breuel) writes:
Well, C++ did, and that's probably one of the main reasons for its
rapid acceptance, despite its many shortcomings.
I still believe that its rapid acceptance has *MUCH* more to do with
the facts that.
a) the so called "foreign funtion" interface of C++ was 'de facto' the
ability to link standard C (and FORTRAN).
b) C++ was soon "available" at a nominal cost on any UNIX box as soon
as it was defined
b1) C++ is now available at reasonable prices on PC's.
This is to say that CMUCL did a lot for the Lisp Community as (A)KCL
did in the earlier days.
Note that C++ features like overloading, type-safe linkage,
semi-automatic memory management, and (soon) garbage collection are
currently supported by C compilers, assemblers, and linkers that were
written with none of those features in mind.
Sorry, but I cannot resist! :) Why introducing a *BAD THING* as
Garbage Collection in C++?!? Didn't we have languages (guess which one)
that used the same barbaric technique in 1984?
(setq *SARCASTIC-MODE* :OFF)
When I posted the original message, I wasn't actually interested in
the inner details of a FFI X implementation. My point was that it
would be SO MUCH BETTER to be able to write a single piece of code to
implement a C call than to write one for
LUCID
Allegro
CMUCL
(A)KCL
HARLEQUIN
MCL
etc...
I might be out of touch with the current dpANS effort, but an
agreement on such a thing would really facilitate the acceptance of
CL.
Of course such a facility should come bundled and at NO FURTHER
COST with each copy sold.
I hope some of the vendors are listening!
Have a nice day
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
B. Brecht
From: Thomas M. Breuel
Subject: Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...)
Date:
Message-ID: <TMB.93Jul13234354@arolla.idiap.ch>
In article <·····················@image.cs.nyu.edu> ·······@image.cs.nyu.edu (Marco Antoniotti) writes:
|In article <·················@arolla.idiap.ch> ···@arolla.idiap.ch (Thomas M. Breuel) writes:
| Well, C++ did, and that's probably one of the main reasons for its
| rapid acceptance, despite its many shortcomings.
|
|I still believe that its rapid acceptance has *MUCH* more to do with
|the facts that.
|a) the so called "foreign funtion" interface of C++ was 'de facto' the
| ability to link standard C (and FORTRAN).
Well, it wasn't entirely "de facto". There is explicit support in the
language for it, and it is not entirely trivial (don't let the
syntactic similarity between C and C++ declarations fool you...).
|When I posted the original message, I wasn't actually interested in
|the inner details of a FFI X implementation. My point was that it
|would be SO MUCH BETTER to be able to write a single piece of code to
|implement a C call than to write one for [...]
|I might be out of touch with the current dpANS effort, but an
|agreement on such a thing would really facilitate the acceptance of
|CL.
I agree completely; I merely cited the rapid and widespread acceptance
of C++ as one possible indication that the market likes such
facilities.
Thomas.
From: Trevor Blackwell
Subject: Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...)
Date:
Message-ID: <1993Jul13.174423.15883@bnr.ca>
In article <·················@arolla.idiap.ch>, ···@arolla.idiap.ch (Thomas M. Breuel) writes:
|> In article <·····@castle.ed.ac.uk> ····@castle.ed.ac.uk (Jeff Dalton) writes:
|> #1) a portable foreign function interface
|>
|> Other languages typically don't define foreign-function interfaces.
|>
|> Well, C++ did, and that's probably one of the main reasons for its
|> rapid acceptance, despite its many shortcomings.
Er... Seems to me that C++'s only foreign language interface is to C, which
isn't very awe-inspiring. On the Mac, for instance, where most of the OS
is written in Pascal, the C++ compilers have to go through a lot of
contortions to make Pascal calls. This isn't very portable.
But, I must say that the lack of a FLI is the MAIN reason why we don't
have Lisp and several other languages in our system right now.
Also, a FLI is much more than just a means of making procedure calls
to foreign-language procedures. We build an interface between Prolog
and Smalltalk - there was a lot of head-scratching over how to convert
basic types (atoms, lists, etc) into objects (Symbol/String, Collection, ...)
That, I think, is often the more difficult problem.
Especially gross is calling C from Smalltalk or Lisp: you have to worry about
where objects were allocated, whether they are GC-able, whether the GC
might move them when the C code is using them, on and on.
It'd be nice to bit the bullet and write your whole OS in Lisp (I'd
use Smalltalk), but that's been tried, and it didn't go over well.
You Lisp dudes should look at how Objectworks\Smalltalk 4.1's CPOK
(C Programmers Object Kit) handles C. It's very well thought out, and
it could make an excellent standard for Lisp FLIs.
|> Note that C++ features like overloading, type-safe linkage,
|> semi-automatic memory management, and (soon) garbage collection are
|> currently supported by C compilers, assemblers, and linkers that were
|> written with none of those features in mind.
--
-------------------
Trevor Blackwell. Internet: ······@bnr.ca
(613) 763-4835
From: Thomas M. Breuel
Subject: Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...)
Date:
Message-ID: <TMB.93Jul13234739@arolla.idiap.ch>
In article <······················@bnr.ca> ······@bcarh51f.bnr.ca (Trevor Blackwell) writes:
|Er... Seems to me that C++'s only foreign language interface is to C, which
|isn't very awe-inspiring.
What languages other than FORTRAN and C would you possibly want to
interface with? :-)
|Also, a FLI is much more than just a means of making procedure calls
|to foreign-language procedures. We build an interface between Prolog
|and Smalltalk - there was a lot of head-scratching over how to convert
|basic types (atoms, lists, etc) into objects (Symbol/String, Collection, ...)
|That, I think, is often the more difficult problem.
|Especially gross is calling C from Smalltalk or Lisp: you have to worry about
|where objects were allocated, whether they are GC-able, whether the GC
|might move them when the C code is using them, on and on.
I think one problem with Lisp foreign function interfaces in the past
has been that they have tried to do too much. Passing numbers, 1D
arrays of numbers, and opaque pointers either way is enough for many
applications, in particular, if you write your libraries with
interoperability in mind. Icing on the cake would be to pass
functions implicitly closed over some global environment back and
forth.
Thomas.
From: Barry Margolin
Subject: FFI (was Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...))
Date:
Message-ID: <2205i2INNk8q@early-bird.think.com>
In article <·················@arolla.idiap.ch> ···@idiap.ch writes:
>I think one problem with Lisp foreign function interfaces in the past
>has been that they have tried to do too much. Passing numbers, 1D
>arrays of numbers, and opaque pointers either way is enough for many
>applications, in particular, if you write your libraries with
>interoperability in mind.
Unfortunately, the FFI is usually used to call libraries that weren't
designed with inter-language calling in mind. Conspicuously absent from
your list of data types to pass is structure pointers. Many libraries take
parameters or output values in structures, so Lisp callers need to be able
to fill in and extract values from foreign structure types. You can do
this with opaque pointers by writing a bunch of accessor functions in the
foreign language, but that's lots of work, and the precise kind of thing
that's nice to automate.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
From: Thomas M. Breuel
Subject: Re: FFI (was Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...))
Date:
Message-ID: <TMB.93Jul14125624@arolla.idiap.ch>
|In article <·················@arolla.idiap.ch> ···@idiap.ch writes:
|>I think one problem with Lisp foreign function interfaces in the past
|>has been that they have tried to do too much. Passing numbers, 1D
|>arrays of numbers, and opaque pointers either way is enough for many
|>applications, in particular, if you write your libraries with
|>interoperability in mind.
|
|Unfortunately, the FFI is usually used to call libraries that weren't
|designed with inter-language calling in mind. Conspicuously absent from
|your list of data types to pass is structure pointers. Many libraries take
|parameters or output values in structures, so Lisp callers need to be able
|to fill in and extract values from foreign structure types. You can do
|this with opaque pointers by writing a bunch of accessor functions in the
|foreign language, but that's lots of work, and the precise kind of thing
|that's nice to automate.
That's exactly what I was saying: "I think one problem with Lisp
foreign function interfaces in the past has been that they have tried
to do too much".
With a basic FFI standard, I could write Lisp and C/FORTRAN code that
interfaces with one another, portably, across platforms. Sure, I may
have to write wrappers for some existing C libraries to access
structures, but at least I can get my work done and run the same code
on lots of different Lisp platforms. Note, incidentally, that such
problems are virtually non-existant for interfacing with FORTRAN
code. Furthermore, note that creators and accessors for C structures
could be generated automatically in a C->C source transformation.
The ability to pass numbers and opaque pointers (and possibly 1D
arrays of numbers) is present in most existing Lisp FFIs. Thus,
vendors could implement such a basic standard quickly, and no vendor
would have to feel "left out".
Individual implementations would still keep their more powerful,
unportable facilities, and that's nice. Maybe eventually, they could
be made to converge towards a single approach as well. But I don't
want to hold my breath that long...
Thomas.
From: Jeff Dalton
Subject: Re: Is the Lisp Language Stagnant? (longish) (Was: Re: EuLisp ...)
Date:
Message-ID: <38554@castle.ed.ac.uk>
In article <·················@arolla.idiap.ch> ···@idiap.ch writes:
#In article <·····@castle.ed.ac.uk> ····@castle.ed.ac.uk (Jeff Dalton) writes:
# #1) a portable foreign function interface
#
# Other languages typically don't define foreign-function interfaces.
#
#Well, C++ did, and that's probably one of the main reasons for its
#rapid acceptance, despite its many shortcomings.
Did it define one that will work for Lisp or Prolog? That will
work for arbitrary implementations of C, e.g. using a different
argument-passing convention?
# Instead, they can exploit (de facto) standard procedure call and object
# file standards. These languages and standards don't make much, if
# any, effort to accommodate Lisp. All the work has to be done by
# Lisp implementors and designers, and I'm not surprised that standards
# have not yet emerged.
#
#Note that C++ features like overloading, type-safe linkage,
#semi-automatic memory management, and (soon) garbage collection are
#currently supported by C compilers, assemblers, and linkers that were
#written with none of those features in mind.
So? KCL uses the ordinary C compiler and linker, so there's a
sense in which they can also support everything in Lisp. All
the interesting work has to be done by the Lisp implementation,
just as I said. I wouldn't call it support. All it amounts
to is that the standard tools can be used at a low enough
level.
It's not possible to have a garbage collector that works correctly
in all cases for ordinary Algol-ish languages. Even "conservative"
collectors rely on pointers looking like pointers even if other
things also look like pointers. So C++ isn't going to be able
to solve this problem either.
-- jd
From: Fergus James HENDERSON
Subject: Re: foreign language interfaces (was: Lisp ...)
Date:
Message-ID: <9319917.19838@mulga.cs.mu.OZ.AU>
····@castle.ed.ac.uk (Jeff Dalton) writes:
>···@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>·····@castle.ed.ac.uk (Jeff Dalton) writes:
>##In article <·················@arolla.idiap.ch> ···@idiap.ch writes:
>###In article <·····@castle.ed.ac.uk> ····@castle.ed.ac.uk (Jeff Dalton) writes:
>### #1) a portable foreign function interface
>###
>### Other languages typically don't define foreign-function interfaces.
>###
>###Well, C++ did, and that's probably one of the main reasons for its
>###rapid acceptance, despite its many shortcomings.
>
>##Did it define one that will work for Lisp or Prolog?
>
>#Well, the mechanism allows for any language, but implementations are only
>#required to support interfacing to C. However it would not be quite as
>#transparent for Lisp or Prolog: with C, you can do
># extern "C" {
># #include "some_c_header_file.h"
># }
>#but things would not be this simple with Lisp or Prolog.
>
>What makes you think it would work at all? It doesn't sound
>like the defined interface provides the necessary stuff.
Let me clarify: as a foreign-function interface it will work fine,
as a portable foreign-function interface it will leave a lot to be
desired. It would be portable only to other Lisp/Prolog implementations
that represented data in the same format as the original Lisp/Prolog
implementation that you were interfacing to.
>##That will work for arbitrary implementations of C, e.g. using a different
>##argument-passing convention?
>#
>#Yes, it will work for any calling convention.
>
>I don't see how.
Let me clarify again. The C++ implementation could have a different calling
convention to the C calling convention. The C++ compiler would have to
know about the C calling convention, and calls to `` extern "C" '' routines
would use this convention rather than the normal C++ calling convention.
The C++ compiler could support interfacing with multiple different C
implementations, by the use of compiler switches to specify which C
implementation you were interfacing to. The C++ compiler could not support
interfacing to multiple different implementations of C simultaneously
without specifying a different name for each of these implementations,
i.e.
extern "GNU C" foo();
extern "Borland C" bar();
extern "C" baz();
main() {
foo(); // uses GNU C's calling convention
bar(); // uses Borland C's calling convention
baz(); // uses whichever calling convention was specified as
// the "C" default by the command-line switches
}
>#However if the data representation was changed (eg. different sized
>#function pointers or differently padded structs) then you would suffer
>#the same loss of transparancy, ie. it would not be sufficient
>#to simply wrap #includes inside extern "C" declarations.
>
>Well what would you do then? It sounds like all the interesting
>stuff is not defined.
Yes, you are right that all the interesting stuff is not defined.
In that case you would have to convert the interface (header) files
into an appropriate form first. For example, suppose that in "Acme C++"
arrays were aligned at 8-byte boundaries, but your C++ compiler only
only aligned them at 4-byte boundaries. Then if the Acme C++ header
file looked like
struct S {
char c[1];
int x;
}
void foo(struct S *);
then this would need to be converted to
struct S {
char c[1];
char __acme_padding[4];
int x;
}
extern "Acme C++" void foo(struct S *);
before you could use it to interface to the Acme C++ routine.
With a bit of luck your vendor might provide an tool to automate
this conversion task.
--
Fergus Henderson This .signature virus might be
···@munta.cs.mu.OZ.AU getting old, but you still can't
consistently believe it unless you
Linux: Choice of a GNU Generation copy it to your own .signature file!
From: Fergus James HENDERSON
Subject: Re: type-safe linkage with traditional linkers (was: Lisp)
Date:
Message-ID: <9319916.19101@mulga.cs.mu.OZ.AU>
········@tolstoy.uwaterloo.ca (Michael Coffin) writes:
>···@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>
> [...] C++ achieves type safe linkage with traditional linkers
> using name mangling.
>
>According to my edition of "The Annotated C++ Reference Manual,
>Section 7.3c (page 127),
>
> "Handling all inconsistencies---thus making a C++ implementation
> 100% type-safe---would require either linker support or a
> mechanism (an environment) allowing the compiler access to
> information from separate compilations."
>
>Has this statement been superceded by improvements in name-mangling
>technology?
Well, yes and no. Current C++ implementations that use traditional linkers
(Cfront and g++ - I don't know of any others) are not 100% type-safe.
On the other hand it would not be that difficult to make them 100% type-safe.
The above statement in the ARM is incorrect IMHO, by I wouldn't say that
it has been superceded by improvements in name-mangling technology, since
the improved technology has not actually found it's way into any products.
Current C++ implementations don't encode the return-type of functions or
the types of variables. The reason for this is so that the linker will
continue to detect multiple definition errors. It would be trivial to
change the encoding algorithm so that it did encode the return-type,
which would give you 100% type-safe linkage, but would not give you
100% multiple-definition-safe linkage.
It would also be possible to achieve 100% type-safe linkage _and_ 100%
multiple-definition-safe linkage by emitting two symbols for every
variable or function definition, the real one with a full type encoding,
plus a dummy one which didn't encode the return type. The real symbol would
catch type errors and the dummy symbol would catch multiple-definition errors.
As to why this is not done by current C++ implementations, I think the
reasons are practical rather than theoretical. Probably the assuption that
there is exactly one symbol per variable/function is fairly well ingrained
in the compiler source code, so changing it might be difficult. Also this
scheme would result in slightly larger object files. Or maybe they just
never thought of it :-)
--
Fergus Henderson This .signature virus might be
···@munta.cs.mu.OZ.AU getting old, but you still can't
consistently believe it unless you
Linux: Choice of a GNU Generation copy it to your own .signature file!