(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:

• Functions must be declared before they can be used.

• Arguments to functions must be of the correct primitive C type. Neither Eclipse nor the C compiler will automatically convert data from, say, clObjects that happen to be a FIXNUM, to int. Instead, programmers must explicitly use system- or user-supplied conversion functions, that are themselves declared in Lisp as C:FUNCTIONs or C:MACROs.

• Newly compiled C code cannot be dynamically loaded into a running application. Instead, a new executable must generally be compiled, linked, and run. (See Section 3.5.2)

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