[cffi-devel] %expand-type-to-foreign-dyn vs *runtime-translator-form*

[Stephen Compall]

I was looking at the new type translator expansion interface and noticed
that one would experience different behavior depending on method
definitions.  I'll use expand-to-foreign-dyn as an example:

If a translation method is available [for some defn thereof], as found
by compute-applicable-methods, but that method answered
*runtime-translator-form*, the final result of the expander would be
something like

`(multiple-value-bind (,var ,param)
     (translate-type-to-foreign ,value ,type)
   (unwind-protect
       (progn , at body)
     (free-type-translated-object ,var ,type ,param)))

Otherwise, both implementations of expand-type-to-foreign-dyn would
short-circuit the generic function call and return

`(let ((,var ,(expand-type-to-foreign value type)))
   , at body)

Though only if by similar heuristic they found that a one-way expander
was available.

I've rearranged things here to combine the cases, eliminate the
*runtime-translator-form* exportation, and make the code simpler.
Currently, both cases are collapsed into the former expansion.  However,
this breaks some misc-types.expand tests, as it breaks this guarantee
listed in that file: Ensure that macroexpansion-time translators are
called where this is guaranteed (defcfun, defcvar, foreign-funcall and
defcallback)

Now, expand-to-foreign is undocumented (:), so I am not sure what its
semantics are supposed to be anyway.  (In particular, I don't see
whether the expand-type-* specializations for foreign-typedef are
following the actual-type chain.)  If it is precisely like a compiler
macro, this can easily be fixed by changing translate-type-to-foreign to
expand-type-to-foreign in the current expansion, and things will work
nicely.  However, I must be able to call free-type-translated-object on
the results of the forward-expanded form for this to work.  Can I rely
on this guarantee, so that I can in return reoffer the aforementioned
guarantee?

-- 
Stephen Compall
http://scompall.nocandysw.com/blog
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20060228/8770078b/attachment.sig>