Re: static-vectors

Hi,

[a bit late]

>> You should report the bug to the author of static-vectors package:
>> Stelian Ionescu <[email protected]>
>Perhaps nicer would to make a feature-request at https://github.com/sionescu/static-vectors

Indeed, the page should mention that there cannot be static-vectors in Common Lisp. The reason is simply that it is completely at odds with how some systems freely choose to implement the Lisp abstractions.
"static", i.e. non-moving is utterly incompatible with CLISP's *moving garbage collection*. Other Lisps may
1- use the conservative Boehm GC which *does not* even know how to move things around, or
2- provide some means to "pin" objects for the sake of the FFI, such objects would not be moved anymore, or
3- provide means to allow foreign objects to act like Lisp arrays, such that those alien objects can be passed to native Lisp functions.

CLISP does not have a concept of pinning. This eliminates 1 and 2.

What CLISP does have, is a concept of "generic" sequences (but not in the CLOS sense). All sequence functions operate upon a descriptor. That descriptor knows how to retrieve or set an element. I believe this is not documented, but it has been in the source for decades. Have a look.
I once did that *experimentally* for FFI:ARRAY types. The overhead makes it dog slow, so if you expect static vectors to give you fast access to C arrays, you loose big. I never released that code and would not know where I might have stored it, so don't ask.

However, I felt that code was missing something important: It only works using SEQUENCE operations, e.g. NTH, cf. the CLHS SEQUENCE dictionary. But what people want is not sequences, it's arrays (or vectors). But CLISP's "generic" sequence mechanism doesn't work with ARRAY objects. That's the fundamental reason why I did not develop that experimental code any further.

Summary:
 - Static vectors is inherently non-portable and thus non-existent in some implementations.
- Instead IMHO, another API should be designed by libraries that think they might need static vectors (some ssl lib comes to mind...)

Alternatively, nice guys like Pascal Bourguignon might suggest playing with packages and visibility:
 - Define a package STATIC-CL
 - Have it import and export everything from CL
 - However shadow the original LENGTH, MAKE-ARRAY, AREF ; all array functions.
 - Define generic replacements of all these functions that STATIC-CL will export
Now define methods for AREF, (SETF AREF) etc. that will operate on CLISP's FFI:FOREIGN-VARIABLE type, if it's of the FFI:C-ARRAY kind.
- Voilà, you will have STATIC-CL:AREF that can work on static C arrays, allocated in C or via whatever foreign function, as well as all standard Lisp arrays.

So basically, there are two parts:
1. Package gymnastics whose sole purpose is to make the AREF family of functions generic.
2. Providing AREF methods for the FFI array objects.

There's still something missing: You will need to convince those unportable libraries that want to use static vectors to produce an object of type FFI:FOREIGN-VARIABLE (well, you could cast a FFI:FOREIGN-ADDRESS).

Regards,
	Jörg Höhle


_______________________________________________
clisp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-list