I've seen a number of tools that purport to read a .h file and then
automagically create an FFI. If these tools actually were to fully
and completely work, then we'd have all of the standard C libraries
to work with.
Now, it's true that these libraries, in themselves, may be badly
designed or a poor fit for functional or otherwise lispy programming,
but hey. We've got lambda, we've got defun, we've got macros....
a programmer with access to the c libraries ought to be able to
hang any interface on them he wants to.
Shouldn't it be possible for a lisp system to have an "automatic
importer" for c libraries with .h files? What could the compiler
support to make it easy?
Is garbage collecting these C'ish data structures a big fat hairy
deal? There's the Boehm collector if conservative is okay, I guess.
Bear
Ray Dillinger <····@sonic.net> writes:
> I've seen a number of tools that purport to read a .h file and then
> automagically create an FFI. If these tools actually were to fully
> and completely work, then we'd have all of the standard C libraries
> to work with.
They certainly work for me. I regularly use a 10 megabyte .lisp file
full of foreign function, type, and structure definitions generated
automatically from the header files of Intel IPP library. No human
intervention was required.
The hairy part is creating an interface that you actually want to use.
For certain numerical libraries this task could be semi-automated, but
I doubt there could ever be a general purpose, high-level Lisp
interface generator.
Carl Shapiro <·············@panix.com> writes:
> They certainly work for me. I regularly use a 10 megabyte .lisp file
> full of foreign function, type, and structure definitions generated
> automatically from the header files of Intel IPP library. No human
> intervention was required.
Interesting. What tool do you use to generate the bindings?
Mario S. Mommer <········@yahoo.com> writes:
> Carl Shapiro <·············@panix.com> writes:
> > They certainly work for me. I regularly use a 10 megabyte .lisp file
> > full of foreign function, type, and structure definitions generated
> > automatically from the header files of Intel IPP library. No human
> > intervention was required.
>
> Interesting. What tool do you use to generate the bindings?
This particular translation was done with the LispWorks foreign
parser.
On 20 Mar 2005 06:10:13 -0500, <·············@panix.com> wrote:
> Mario S. Mommer <········@yahoo.com> writes:
>> Carl Shapiro <·············@panix.com> writes:
>> > They certainly work for me. I regularly use a 10 megabyte .lisp file
>> > full of foreign function, type, and structure definitions generated
>> > automatically from the header files of Intel IPP library. No human
>> > intervention was required.
>>
>> Interesting. What tool do you use to generate the bindings?
>
> This particular translation was done with the LispWorks foreign
> parser.
That is an impressive feat, is there something special in the LW FFI?
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
GP lisper <········@CloudDancer.com> writes:
> On 20 Mar 2005 06:10:13 -0500, <·············@panix.com> wrote:
...
> > This particular translation was done with the LispWorks foreign
> > parser.
>
> That is an impressive feat, is there something special in the LW FFI?
There is nothing impressive about the ability to translated header
files into FFI declarations. This is pretty standard stuff. Most all
of the noteworthy Lisps have this feature, some for >10 years.
If your Lisp forces you to write all of your FFI declarations by hand,
you are using the wrong Lisp. Period.
GP lisper <········@CloudDancer.com> wrote:
> That is an impressive feat, is there something special in the LW FFI?
No. On Windows it tries to call "cl /nologo /E /Tc file.h" while generating
the FFI interface, and the parsing of the preprocessed header files is not
very difficult.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> GP lisper <········@CloudDancer.com> wrote:
>
> > That is an impressive feat, is there something special in the LW FFI?
>
> No. On Windows it tries to call "cl /nologo /E /Tc file.h" while generating
> the FFI interface, and the parsing of the preprocessed header files is not
> very difficult.
A free version of the Visual C++ Professional compiler is available
for download on MSDN.
http://msdn.microsoft.com/visualc/vctoolkit2003/
This is more than adequate for use with the Foreign Parser.
Ray Dillinger <····@sonic.net> writes:
> I've seen a number of tools that purport to read a .h file and then
> automagically create an FFI. If these tools actually were to fully
> and completely work, then we'd have all of the standard C libraries
> to work with.
You are talking about such tools as gcc-xml and ffigen?
> Now, it's true that these libraries, in themselves, may be badly
> designed or a poor fit for functional or otherwise lispy programming,
> but hey. We've got lambda, we've got defun, we've got macros....
> a programmer with access to the c libraries ought to be able to
> hang any interface on them he wants to.
How portable do you want to be? OpenMCL has a rather nice FFI system
that uses ffigen. The distribution has already got interface
databases included for some libraries.
> Shouldn't it be possible for a lisp system to have an "automatic
> importer" for c libraries with .h files? What could the compiler
> support to make it easy?
Magic. Heh.
It's already pretty easy if you aren't dealing with complex C
structures or function pointers. When you get into that arena then
you need to be able to deal with alignment issues (perhaps) and call
back functions. UFFI does not have callback support.
A surprising issue is dealing with #define and friends properly.
> Is garbage collecting these C'ish data structures a big fat hairy
> deal? There's the Boehm collector if conservative is okay, I guess.
For every malloc() there must be a free(). Frankly I find dealing
with foreign memory painful. I've used with-* style macros to wrap
the usage of allocated foreign memory in unwind-protect so that free
can be called on it. Things get messy if you have to hold onto that
memory for a while.
Lisp can play with C, but only with parental supervision.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Ray Dillinger wrote:
>
>
> I've seen a number of tools that purport to read a .h file and then
> automagically create an FFI. If these tools actually were to fully
> and completely work, then we'd have all of the standard C libraries
> to work with.
>
> Now, it's true that these libraries, in themselves, may be badly
> designed or a poor fit for functional or otherwise lispy programming,
> but hey. We've got lambda, we've got defun, we've got macros....
> a programmer with access to the c libraries ought to be able to
> hang any interface on them he wants to.
>
> Shouldn't it be possible for a lisp system to have an "automatic
> importer" for c libraries with .h files?
Of course. Unfortunately, Lisp vendors are too dim to see that
particular light.
> What could the compiler
> support to make it easy?
Let's make that "zero" and let the IDE deal with it by producing valid
Lisp on the fly. Well, OK, it would be nice to have the Lisp advantage
and just recompile one bit of "C" header code and have The Right Thing
happen...
>
> Is garbage collecting these C'ish data structures a big fat hairy
> deal? There's the Boehm collector if conservative is okay, I guess.
Moon on a stick! (I have no idea what that means, but Burdick said it to
me once when I was whining about CVS.) The application can work out when
to free things. And that is not the heresy it seems to be.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> Ray Dillinger wrote:
>> Shouldn't it be possible for a lisp system to have an "automatic
>> importer" for c libraries with .h files?
> Of course. Unfortunately, Lisp vendors are too dim to see that
> particular light.
>> What could the compiler
>> support to make it easy?
> Let's make that "zero" and let the IDE deal with it by producing valid
> Lisp on the fly. Well, OK, it would be nice to have the Lisp advantage
> and just recompile one bit of "C" header code and have The Right Thing
> happen...
A C-to-lisp compiler? We still wind up with an FFI problem, it's just
moved back to the OS interface instead of the library interface. Or
maybe the OS interface is relatively small? A few crucial things, like
dealing with its abstractions over interrupts and hardware ports, and
lispy versions of all the c libraries could be autocreated and work?
Bear
Ray Dillinger <····@sonic.net> wrote:
+---------------
| Kenny Tilton wrote:
| > Lisp on the fly. Well, OK, it would be nice to have the Lisp advantage
| > and just recompile one bit of "C" header code and have The Right Thing
| > happen...
|
| A C-to-lisp compiler? We still wind up with an FFI problem, it's just
| moved back to the OS interface instead of the library interface. Or
| maybe the OS interface is relatively small? A few crucial things, like
| dealing with its abstractions over interrupts and hardware ports, and
| lispy versions of all the c libraries could be autocreated and work?
+---------------
Hmmm... You guy have just given me a really evil idea... ;-} ;-}
Many [well, several] current operating systems permit some degree of
virtualization, such as VmWare, User-Mode Linux, or even just the
Linux emulation offered by the BSDs (especially FreeBSD). Suppose,
as an alternative to running the nasty C or C++ or Java code in a
separate process connected with a pipe or socket [a common solution
when the FFI is too messy], you hosted a User-Mode Linux (say)
*inside* your Lisp image, and then ran the nasty C or C++ or Java
code inside a virtual machine under Lisp's control. Could this
provide any advantages over either direct FFI in the same process
or pipe/socket communication in a separate peer process?
Lisp would not be "the" operating system, but would be a middleware
operting system virutalization layer [an O/S without needing all of
the messy hardware-dependent "real" O/S stuff.] That is, the Lisp code
would intercept any system calls from the slave "process" and could
provide "interesting" results to certain of the trapped file I/O calls,
say, while passing the rest on to the underlying O/S.
Just a thought... ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607