Hi, Luís Oliveira wrote:

Also we need to handle encodings. That's really important. I almost feel sorry for wasting your time on small optimization issues when there are much more important things to do.

Right, once the block memory interface is implemented for all Lisps, we can optimize strings.lisp

Block operations are no silver bullet either. E.g. with-foreign-string maps nicely to CLISP's ffi:with-foreign-string. Using block operations instead would still do more work (and it's unclear whether block operations would work fast in CLISP with strings or rather arbitrary encodings, or whether the block code would resort to a LOOP). James Bielman wrote:

how about adding "cffi/src/optimizers-clisp.lisp" (and associated files for other implementations) that use compiler macros to perform the optimization?

It's maybe the best one can do given your preference for implementation-specific files. Yet I felt somewhat strange about writing compiler-macros for macros (e.g. with-xyz), not functions. The typical counter argument is risk of drift between the two files containing the original function or code and the other with the macro optimizer. So far, the cffi-impl.lisp files which contain both a low-level function, followed by the optimizer version are very nice to review. One immediately sees the correspondance between the two forms. There's no risk that somebody will edit one and forget to edit the other. That's very different with code spread across files. Especially, handling of border cases may then vary across implementations. E.g. I remember having to modify my version of uffi:with-cstrings to accept an empty list of bindings: all optimizers would need to be modified similarly. Regards, Jörg Höhle.