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
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
