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

[Luís Oliveira]

On 2006-mar-13, at 18:48, Stephen Compall wrote:
>> Surely we want free-translated-object to be called in this case.
>
> It will be.  The problem appears in the current rules for providing a
> fallback when expand-to-foreign-dyn is not provided.  This is
> exemplified in the new tests: one answers T and the other answers NIL,
> when both should answer T or NIL.

Judging from the comment in misc-types.expand.6 I thought you did  
want it to return nil.


> According to node "Optimizing Type Translators", several forms are
> guaranteed to use `expand-type-to-foreign' even when they want the
> semantics of foreign-dyn expansion, when such an explicit expansion is
> unavailable.

I think this is useful.


> 3) Specify that the form answered by expand-type-to-foreign, when
> evaluated, answers a value that does not need to be freed.  This is
> currently implemented by not providing a foreign-dyn expansion method,
> in the case of foreign-typedefs anyway.

This was what I had in mind.


> This does not preclude providing a function to trivialize  
> overriding the
> default behavior in favor of option 3, if the type-defining user so
> chooses.
>
> (defun simple-foreign-dyn-expansion (value var body typename)
>   "Answer a form to be answered from `expand-to-foreign-dyn',
> where VALUE, VAR, BODY, and TYPENAME are the respective args to
> the aforementioned GF.  The result will not be freed."
>   `(let ((,var ,(expand-type-to-foreign value (parse-type typename))))
>      , at body))

I guess that picking option 1 or 3 is a matter of picking the best  
default behavior. Isn't option 3 the most common case?

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt