[cffi-devel] Clisp load foreign library

[Kenny Tilton]

Luis Oliveira wrote:

> 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? 

Yes.

>
>
> 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.
>
I agree that it would be nice to avoid having a system work on one Lisp 
but not another because the first Lisp is more forgiving, but I do not 
like the idea of propagating limitations ("thou shalt not define a 
binding before loading the library") unnecessarily. UFFI was famous for 
being no better than the worst platform it supported.

The CMUCL way confuses run time with compile time. Lisp is all about 
dynamism, in this case not attempting to resolve a binding until it is 
invoked. It seems to me that either CMUCL needs to be fixed, or CFFI 
needs to do something cute to fix it. By the latter I mean just do what 
it takes, perhaps merely make a note at compile time (of the DEFCFUN 
form) and then do the actual binding the first time the binding gets called.

Possible?

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it."
    Elwood P. Dowd, "Harvey", 1950