On Fri, Sep 9, 2011 at 4:46 AM, Joerg-Cyril.Hoehle@t-systems.com wrote:
Hi,
Luís Oliveira wrote:
I agree that DEFCSTRUCT* is a lousy name, but DEFCSTRUCT-BY-VALUE is misleading, since there's more going on.
I recommend you look again at CLISP's FFI http://www.clisp.org/impnotes/dffi.html It is essentially call by value. It will convert (de-/serialize) arbitrarily nested structures to and from Lisp, for instance a full linked list of objects given a single pointer (and hang on a circular list...). Passing stuff by reference (i.e. using the type (C-POINTER XYZ) was a late addition.
On a quick read, I can't discern how CLISP differentiates syntactically between call by reference and by value.
Note that automated return by value is not void of problems. Old APIs use structs or &out pointers with flags indicating which fields are valid and you better not convert back an invalid char* (or random bits as a float). Modern APIs tend to do better here, esp. those that have been influenced by remote design thoughts (RPC, network transmission etc.).
The old Haskell/Direct had a domain specific language to express such dependencies and I've found myself suggesting some for CLISP (e.g. a :guard to prevent dereferencing some slots, as in (def-c-fun foobar (:return-type int) ... (errorstr (:type c-string) (:out :alloca) (:guard (zerop return))) => foobar returns type (values integer (or string null)) with integer return value being not 0 => NIL as second value, no string (or the converse, I forgot how I originally conceived the guard)
Regards, Jörg Höhle
This is a good point; it would be nice to have some means to prevent autoconversion.
Liam