[cffi-devel] must cffi-sys::with-pointer-to-vector-data go?

[Hoehle, Joerg-Cyril]

rif (Raymund IIRC?) [rif at MIT.EDU] wrote:

>I'm not sure I fully understand your example or concern.

There's a .sig along "Common Lisp is for the things that work."

>Obviously, if my program is multithreaded or the C program needs to
>maintain the state across calls or I don't know what else, then the
>semantics become very different.
[...]
>documentation caveats that it's not going to DTRT across all platforms
>if you require true sharing?

Calling something "shareable vector" and recognizing it's not true sharing is not something that works.

Does this make my position clearer?

There's IMHO already too much broken SW and APIs out there in the world (Lisp, Java, Python, C++, c#, C, whatever).  We should try to focus on
a) things that work
b) things that work at large
c) things that work reliably

The environment API descibed in CLtL2 was removed from ANSI-CL.
Why? because it was found to be subtly broken.
No more reason than that.
And I showed that it's blatantly broken to try to mimic shared vectors with copying.
Do you see the parallels?

In summary, I'm not against an optional shared-vector API at all.
It may even be a distinguishing feature of CFFI vs. UFFI that it provides many optional APIs.  But I'm really opposed to broken things, e.g. trying to provide/implement the shared-vector API using copying.
Please strive for correctness, not brokeness.

Regards,
	Jorg Hohle.