From: Mike A. Caplinger
Subject: CL standard for foreign function interface
Date: 
Message-ID: <827@thumperbellcore.com>
Would a de facto standard for declaring interfaces to foreign functions in
Common Lisp be appropriate?  That is, I want to call some C function
from CL so I declare its arguments and return values, then link it
in to my Lisp incrementally.  I've observed that Lucid, Franz, and Kyoto
Common Lisp all provide this functionality (under Unix, anyway) and that
many people use it, but that it's slightly different from CL to CL and
so the code's all non-portable.  Does anybody else see this as a big
problem?

	Mike Caplinger, ····@bellcore.com
From: ···@bcsaic.UUCP
Subject: Re: CL standard for foreign function interface
Date: 
Message-ID: <1890@bcsaic.UUCP>
In article <···@thumperbellcore.com> Mike A. Caplinger writes:
>Would a de facto standard for declaring interfaces to foreign functions in
>Common Lisp be appropriate?  That is, I want to call some C function from CL
>so I declare its arguments and return values, then link it in to my Lisp
>incrementally.  I've observed that Lucid, Franz, and Kyoto Common Lisp all
>provide this functionality (under Unix, anyway) and that many people use it,
>but that it's slightly different from CL to CL and so the code's all non-
>portable.  Does anybody else see this as a big problem?
>
>	Mike Caplinger, ····@bellcore.com

It has been my experience that an interface to procedureal languages such as
C, Fortran, and even Ada ( :-)) is needed more and more frequently.  The
reasons may vary in detail but most amount to a desire to avoid reinventing
the wheel in Lisp.  Systems that couple numeric and symbolic computation are
also appearing more frequently in problem solving tasks.  For these reasons
I think a standard for a foreign function interface would be very beneficial.
It would help to increase portability and therefor reduce the labor required
to build and maintain systems.  The hardest part, I believe, is to determine
a 'language' for implementing such an interface that would account for all
(or at least most) present procedural languages and possible new such
languages.  Perhaps we could build a knowledge-based system that would
create such an interface language!  (He says, smiling).

-- 
TJ {With Amazing Grace} The Piper
(aka Ted Jardine)  CFI-ASME/I
Usenet:  ...uw-beaver!ssc-vax!bcsaic!ted
CSNet:   ···@boeing.com