[Paper Contents] [Previous] [Next] [Eclipse Home Page]

4: Using C from Lisp

The following code can be used in any ANSI Common Lisp implementation to declare MY-FUNCTION to be a function of two arguments (a FIXNUM and a BASE-CHAR) that returns a DOUBLE-FLOAT:
   (DECLAIM (FTYPE (FUNCTION (FIXNUM BASE-CHAR)
			     DOUBLE-FLOAT) 
		   MY-FUNCTION))

The C code produced by Eclipse COMPILE-FILE for a call such as (SETQ X (MY-FUNCTION Y Z)) might be something like the following (see Section 3):

   clObject usrMyFunction(clProto);
   ...
   clSetq(x, usrMyFunction(y, z, clEOA));

ANSI defines the FTYPE declaration only for the CL:FUNCTION list-form type-specifier. Eclipse defines FTYPE for two other list-form type-specifiers as well: C:FUNCTION and C:MACRO. Here is some Lisp code that uses this:

   ...
   (DECLAIM (FTYPE (C:FUNCTION (C:INT C:CHAR)
			       C:DOUBLE) 
		   FOO C::BAR) 
	    (TYPE C:DOUBLE X) 
	    (TYPE C:INT Y) 
	    (TYPE C:CHAR Z)) 
   ...
   (SETQ X (FOO Y Z))
   ...
   (SETQ X (C::BAR Y Z))

Eclipse COMPILE-FILE then generates C code like this:

   double usrFoo __P(int, char), bar __P(int, char);
   ...
   x = usrFoo(y, z);
   ...
   x = bar(y, z);

Note the different C function declaration and assignment, and the lack of clEOA. Note also that the names of symbols in the C package are not mangled, but USER::FOO becomes usrFoo(). (See Section 2.1).

This simple extension of the type system by Eclipse provides a more direct, lower level interface than the more typical wrapper functions generated by foreign function interfaces. Of course, there is no reason that a user- or system-provided foreign function interface abstraction can't be built on top of this.

As it stands, however, callers of C code in Eclipse currently suffer the same hardships as callers of C code in any portable C application:

Because of this, there is little reason for the Eclipse interpreter (i.e., EVAL) to accept calls to C:FUNCTIONs or C:MACROs.


[Paper Contents] [Previous] [Next] [Eclipse Home Page]