Hi,
I wrote:
Lisp vectors at non-moving locations. I haven't yet investigated how one could make transparent use of such a feature, even though any Allegro user would find it suboptimal if cl+ssl (or any other library) would not make best use of her/his Lisp implementation.
Here's a possible solution path:
Let the cl+ssl's stream object have slots for both a Lisp vector and a foreign entity. The latter is either a pointer to the Lisp vector, if it could be allocated with a fixed location (Allegro (unverified)), or a foreign-alloc'ed memory area in all other cases. Then read-ssl uses this pointer (or array). In the non-Allegro case, CFFI's block copying routine is invoked to copy from foreign to Lisp memory.
So this does not go without #+/#- in the cl+ssl library. To me, this is not surprising. It corroborates what Duane Rettig said some time ago in comp.lang.lisp: there won't be a unification of CL's many FFI. He did not say that because UFFI did not exist at that time, but because beyond the common features that can be captured by UFFI and CFFI, there's a great variability among implementations. Similarly, all implementations feature some extensions beyond ANSI-CL!
Another consequence of all I said is that I consider the shareable- vector.txt specification not mature or possibly to be rejected.
o :in and/or :out are missing, and BTW would lead to what James Bielman dislikes: inconsistency, because some implementations would ignore it, being able to bypass copying.
o without :in/out specification, the double copying penalty that I talked about, and that the specification's last example contains, is not acceptable.
o Implementating this using si::without-gc is not acceptable (e.g. cmucl) because of a too long and uncontrolled lifetime. Better use the vector copying API. Be safe, not disabled.
o It's somewhat superfluous given a good vector copying API.
So what's left? Not enough, IMHO. Something that solely works on Allegro (IIRC they can allocate Lisp vectors at a fixed address). IMHO there's not enough benefit for other implementors to add that.
I myself would prefer, if any, the converse: allow all SEQUENCE functions to work on foreign arrays...
Regards, Jörg Höhle