Luis Oliveira writes:
>I think the behaviour here
>should be uniform since ideally users would test a set of CFFI
>bindings on one implementation and be confident that it would work on
>the other supported lisps.
We all agree on that. However, how do you expect to prevent a long-time
Allegro user to inadvertently write 0 instead of (cffi:null-pointer)?
This is exactly the same with CLISP+Lispworks with NIL.
We don't have static typing in CL, or at least, not without a cost. Strong
typing is all we have.
I suggest the solution is NOT to add (check-type x ...) but to leave the
individual FFI's as is.
Allegro must have a reason to stick to integers, even though it's over 10 years
that I criticized it the first time :-)
BTW, CFFI reinvented the pattern "normal+other-as-different(e.g.NIL)-type" with
:string. See foreign-string-to-lisp etc. It's a nice pattern, indeed. Why
fight it for :c-pointer, but accept it for :string?
But here, I'm not arguing in favour of a NULL->NIL conversion. I'm in favour of
leaving the respective implementation's FFI as is, and not generate code for
CLISP to turn NIL back into a pointer with a 0 address. I agree that I
wouldn't argue with that much heat if this were not related to performance.
I believe that if somebody wanted a higher expectation for portability, then
s/he might use a "debug converter", which would turn every pointer into a CLOS
instance that CFFI would then somehow typecheck at run-time. Obviously, that
should be a debug aid only, and not for general code.
Similarly, I have a uffi:def-foreign that'll do nothing but type-check at
compile (macro expansion) time. I found several bugs in libraries using UFFI
this way.
Regards,
Jörg Höhle.
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
