Could anyone over there tell me how to include C subroutines which
would be written in a file into a Lisp program and how to call them
from Common Lisp? I need to do system call to excute some shell
commands, thus I have to write C code to deal with it.(Is that
right?) And my routines would be called by Lisp program. Do I need
some interfaces to make the C routines be recognized by Lisp?
Any information and suggestion would be very helpful. Thanks in
advance.
In article <················@tenacity.cs.uchicago.edu> ··@tenacity.cs.uchicago.edu (Teng Li) writes:
>Could anyone over there tell me how to include C subroutines which
>would be written in a file into a Lisp program and how to call them
>from Common Lisp? I need to do system call to excute some shell
>commands, thus I have to write C code to deal with it.(Is that
>right?) And my routines would be called by Lisp program. Do I need
>some interfaces to make the C routines be recognized by Lisp?
There's no standard mechanism for this. However, most Lisp systems include
a facility called "foreign function calling" that supports this. In
general, you use an implementation-dependent macro to define a Lisp
function that will invoke the C function, properly converting the
arguments. For instance, in Lucid Common Lisp, you would write something
like this:
(def-foreign-function (lisp-function
(:language :c)
(:name "_c_function_name")
(:return-type :signed-32bit))
(int-arg :signed-16bit) (string-arg :string))
This defines a Lisp function named LISP-FUNCTION that invokes a C
function named c_function_name, which would be prototyped as
int c_function_name (short, char*);
You also have to link the object file that contains the C function into
your Lisp process. In Lucid, LOAD-FOREIGN-OBJECTS and LOAD-FOREIGN-LIBRARY
are used to do this.
As I said, the precise syntax differs from implementation to
implementation, so you'll have to check your documentation for the
specifics.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
If all you need to do is run shell commands, another option to writing
foreign function calls would be to use the lisp function that executes
shell commands, if there is one in your dialect of lisp. In Lucid,
there are two of these, 'shell', and 'run-program', both of which work
rather nicely.
Hope this helps.
-tom murray
Regarding call C proceudre from Lisp; ··@tenacity.cs.uchicago.edu (Teng Li) adds:
> Could anyone over there tell me how to include C subroutines which
> would be written in a file into a Lisp program and how to call them
> from Common Lisp? I need to do system call to excute some shell
> commands, thus I have to write C code to deal with it.(Is that
> right?) And my routines would be called by Lisp program. Do I need
> some interfaces to make the C routines be recognized by Lisp?
Barmar answered the foreign function part so I won't deal with that.
If all you need to do is execute shell commands, many Common Lisp's
already have an extension to do that. Lucid's is RUN-PROGRAM, KCL's
is SYSTEM.
--
dan
In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: ·······@encore.com
Under Symbolics Genera you can make transparent function calls to foreign
languages such as "C" through the Remote Procedure Call (RPC) facility.
The calls are made across a network, but the programmer doesn't need to
worry about programming the network. The extensible call description
language (a bunch of Lisp macros) takes care of writing the function
stubs (eg., in C and/or LISP), and (in conjunction with the underlying
RPC/XDR implementations) automatically converting the foreign data
types, errors, and so forth.
I don't think this is exactly like what you were wondering about: you
sounded like you were thinking of simpler, single-process environment
where you would link multiple foreign programs together.
The Symbolics implementation is oriented more towards multiprocessing,
and was developed primarily for embedded co-processor systems.
On the Symbolics, the network could just be a shared-memory interface
(this is how it's done in MacIvory - our embedded Macintosh system), or
it could be a conventional network such as UDP/IP. As I mentioned, the
programmer doesn't really worry much about this though.
What do people think of the idea of using such high-level description
languages to foreign function calls? What do you think of RPC/XDR
in this kind of context (especially you C hackers out there)?
It seems to me like this kind of transparent interface might be a
general solution to the cross-language problem. Clearly some sort of
protocol is needed, RPC/XDR being the popular (?) standard with a
relatively (!) nice interface. You certainly don't want programmers to have
to deal separately with the idiosyncratic storage conventions and
related miscellaneous semantics of all the different languages and
implementations that they want to talk with.
The main issue with RPC/XDR in particular, is efficiency.
I guess that (theoretically) it should be possible for such a system to
be smarter about the packing and transport implementations - at compile
time, maybe at run time, maybe with declarations from the programmer.
The calls implementation in a given situation could wind up being more
like dynamic linking. A high-level cross-language calling protocol
would allow source code portability, and leave system implementors free
to make things as efficient as they want and avoids trying to invent
agreements about low-level repreesntation conventions on all machines.