On 18/set/2005, at 03:39, Kenny Tilton wrote:
I passed a pathname to load-foreign-library and Clisp complained that it was not a string. Maybe I missed something. Anyway, if CLisp indeed has a limitation in re accepting a pathname for a library, maybe the CFFI wrapper could add that flexibility.
Yes, indeed. The details of CFFI-SYS:%LOAD-FOREIGN-LIBRARY are still very much undefined.
Now, about CFFI's handling of foreign libraries using CLISP, I'm not sure I understand what you want to do. Do you want to define bindings before loading the library, is that it?
When we get around to properly specify and extend load-foreign-library, one of the details in the documentation will be the requirement to load the foreign library before the bindings (and it would probably be nice to *enforce* this). So, you would have, say, bindings in fii.lisp and the calls to load-foreign-library in libraries.lisp, and libraries.lisp would have to be loaded before ffi.lisp. CMUCL requires this (UFFI has some notes about this too) and apparently so does CLISP (not because of its own FFI actually, but because of the way we do it in CFFI).
I say it would be nice to enforce stuff like this because we want the bindings to be portable, thus we want to try our best to avoid behaviour that will work on some lisps but not others. An example of that is UFFI's deref-array macro, in some lisps the type information is discarded so people testing with those won't notice they're passing wrong types etc... CFFI's has been avoiding this kind of behaviour pretty well I'd say.
The current cffi:load-foreign-library is a good example of what we don't want CFFI to be. :-) It'll be fixed.