Luís Oliveira wrote:
>So, the idea came up of providing some sort of compiler-macro-like
>facility for type translators.
I'm happy to see that progress is being made here, although I currently have no
time to look at it and give feedback.
>As I said, I'm trying to keep this simple, so the way this works now is
>that one of these translators completely hijacks the normal
>translators. Namely, it wouldn't follow the typedef chain and apply all
>translators (what would it use the run-time ones? the
>macroexpanion-time ones?
I had the feeling that ther was a slight error in the old transformers: the
transform-*-FORM should have defaulted to the run-time call to convert-*, but
the default was the identity function. The idea is: if there's a compile-time
(actually, macro-expand time) optimization, do it; otherwise call run-time
converters.
>foreign-slot-value (or mem-ref/mem-aref). Would it be a good
>idea to use
>these translators in the respective compiler macros?
The mechanism should be general: if the type is known, handle it.
I think that James' :translate-p is the wrong direction, at least, my
understanding of it. Who's going to use it? With all theses current dreams
about automatic translation via swig, cparse, xyz, are they going to set that
flag or not? Can the automated translators actually decide whether to set that
flag?
Regards,
Jörg Höhle.
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
