Wednesday, March 29, 2006

Ideas for a Lisp FFI wiki

A person named “Sacha” recently made the following comment on c.l.l in a thread entitled “CLISP and win32 clipboard access”:

> I've been recently working a lot with .NET, and found
> to be very usefull.
> This web site is providing the .NET world equivalent to FFI for win32 calls.
> Wouldn't it be very nice to have such a wiki for FFIs ?

Yeah, I think there are several features of that could/should be replicated in a Lisp FFI wiki:

  • entries for

  • data structures and immediate types

  • function signatures

  • consistent structure across each entry

  • summary

  • complete FFI definition that you can copy&paste

  • perhaps for just CFFI?

  • usage notes or gotchas

  • example code

  • alternatives, if any, for the current entry

  • pointer to relevant doc in the native library (e.g., ImageMagick manual, Gtk+ manual, MSDN, etc)

  • FAQ

  • pros and cons of the various FFIs

  • address SWIG, Verrazano, and other automation tools

  • search

  • a search engine that has a decent syntax and the ability to constrain the search to specific areas (e.g., Google's group: modifier)
In other words, not a jumble of info thrown together, but an organized format that has had some thought put into it. To be useful, this wiki would have to be fairly extensive.

One other crazy thought I had about this is if the wiki was organized via tags a la rather than (or in addition to) a hierarchy. I’d bet that would be especially handy for folks implementing portability layers. E.g., you could search on the combination of “window” and “creation” tags to see FFI definitions for window creation functions in the various UI libraries.


Sacha said...

I think that just a wiki would already be better than nothing at all.

Windows is key to an hypothetical lisp revival, I beleive a code repository like this one would help a lot.

Luís said...

Most of the stuff you mention is already addressed in the CFFI User Manual. Is it not?

Jack Unrue said...

To Luís:

Yeah, I think the way that the CFFI manual structures the individual entries is great. It's very thorough, in my opinion. Actually, the whole thing is well done.

But just to make sure I'm being clear, and I think this is what Sacha was getting at as well, the point of the wiki would be to catalog entry points in specific libraries. CFFI is (in my opinion) emerging as a portable standard, so I would think that every entry in the wiki be expressed *at least* in terms of CFFI.

So I'd be happy if this FFI wiki followed the CFFI manual's convention, but also added a couple features: search, pointers to each native function/type docs, and of course the dynamic discussion you get inherently in a wiki.

Jack Unrue said...

To: sacha

This is just my opinion obviously, but in some ways I agree with you. Something is better than nothing. But I think the initial startup effort would have to be followed with some organizational work. Or else people are going to get annoyed -- those sort of complaints might be a good source of feedback in terms of how the actual users would like to see this structured.

But hey, it's up to whoever puts in the time and energy. I would be very willing to contribute entries.

Sacha said...

to Luis : this pinvoke web site has almost all the win32 API translated to .NET, the goal would be to have the same thing for FFI (or CFFI)

to Jack : An FFI repository would have a larger scope than pinvoke, so yes, it might be usefull to have a bit more than just a wiki.
But ... The hard part is to get the people to contribute. Why not use already existing facilities ? CL Gardeners, cliki ?
Then once there is enough information it's soon enough to worry about the cosmetics.

Anyways, I can't help much on all this as I have no code to contribute =P