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.