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.