Hi,

Luis Oliveira wrote:

IMHO, one of biggest drawbacks of UFFI (one that I found while testing uffi-compat on a couple of libs) is the lack of uniformity. For example, in libs primarily developed on lisps with typed pointers (eg: SBCL), many (a few?) operations had bogus types and these bugs didn't show up in these lisps but caused errors on others (and uffi-compat, with whatever lisp).

I don't know whether "uniformity" goes straight to the point. It's clear that UFFI's dual approach is likely to lead to errors. Yet I can understand the design decisions. What I'm missing, is not uniformity but a debugging tool, i.e. one that would match the UFFI given type with the internal SBCL type and throw an error. Then SBCL people would be confident in being able to write portable code.

Similarly, I've criticized UFFI for heavy use of EVAL and not clearly specifying what gets evaluated at what time. I think your recent patch to uffi-compat: "Fix parsing of types to match UFFI's behaviour" is not TRT w.r.t. "uniformity". Instead, the type checker I mentioned previously raises errors and allows me to send people bug reports for too many or not enough quotes around UFFI type forms. This becomes especially annoying when writing macros that either analyse or create UFFI forms. Yet, I understand your patch in terms of interoperability, meaning that you want cffi-uffi-compat to accept all the broken SW that the original UFFI accepts as well. That's perfectly fine.

Sadly, one HD crash back in July caused me loss of the diffs I had prepared back then to cl-gd, clsql and a few other packages which all contain quoting not in accordance with the UFFI documentation. My checker is in sourceforge's patches section, named "preliminary UFFI code" or so.

Regards, Jorg Hohle