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:
clObject
s 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:FUNCTION
s or
C:MACRO
s.
Because of this, there is little reason for the Eclipse interpreter
(i.e., EVAL
) to accept calls to C:FUNCTION
s or C:MACRO
s.