[cffi-devel] Converting foreign structures with CFFI generic functions

[Liam Healy]

On Mon, Sep 5, 2011 at 10:16 AM, Luís Oliveira <luismbo at gmail.com> wrote:
> On Mon, Sep 5, 2011 at 4:43 AM, Liam Healy <lnp at healy.washington.dc.us> wrote:
>> (defcstruct (complex :constructor complex :deconstructor (realpart imagpart))
>>   (dat :double :count 2))
>>
>> You can get a pretty good sense of what the :constructor and
>> :deconstructor args do quickly, and I bet most people could write
>> their own defcstruct and appropriate converter quickly with no trips
>> to the manual.
> [...]
>> No one would be forced to use the macro, you could still write the
>> defmethods by hand as you propose.  Macros eliminate or minimize cut
>> and paste.
>
> My broader point, I guess, is that one must be careful not to mistake
> concision for abstraction and that the latter is more important.
> Anyway, I understand your point. Let's get the plumbing right first,
> and we'll get back to the macro sugar later.

Agreed.

>
>
>> I don't envision making CLOS objects the CL equivalent of foreign
>> structures I need (I assume you mean of CLOS object of metaclass
>> standard-class), but I have no objection to providing some default
>> methods.   My inclination would be to make the default CL equivalent a
>> list.   That's how it is for fsbv:defcstruct.   It is unclear to me
>> how making CLOS objects simplifies the recursive conversion task.
>
> I don't think using CLOS objects has any impact on handling
> recursiveness. I started thinking about conversion to CLOS and mixed
> things up, sorry.

OK

>
>
>> I don't understand your BTW statement.
>
> I was just mentioning that a possible default translation could be to
> make an opaque object with accessors that handle translations on
> demand. Not a very important issue at this point. We can discuss it
> later.

OK

>
>
>> If CFFI had a translate-into-foreign-memory, then a
>> translate-to-foreign could be an ordinary function:
>> (translate-into-foreign-memory source type (foreign-alloc type))
>> Wouldn't that do everything it needs to?
>
> Pretty much, yeah.
>
>
>> (BTW, I get confused by foreign-alloc's :initial-element/contents
>> arguments.  Is this calling translate-to-foreign?  It seems like it
>> presumes some kind of translation facility.  Or does it simply do
>> nothing if type is a foreign structure?)
>
> initial-element and contents will in fact go through
> translate-to-foreign, IIRC. Is that an issue?

On the contrary, it's welcome.  Can we add these to
with-foreign-object(s) too?  Notice (http://repo.or.cz/w/fsbv.git)
fsbv:with-foreign-objects has
bindings ::= {(var type &optional initial-value)}*
This is another macro sugar issue, so no problem deferring, but it's
be nice to have ultimately.

The point of confusion for me is that when writing the translator, I'm
calling a function which has an option to use the translator.
Clearly, I need to avoid using the :initial-* arguments, which is what
I had assumed, just wanted to confirm that.

>
>
>> I don't know what expand-into-foreign-memory is.
>
> Have a look at:
> <http://common-lisp.net/project/cffi/manual/html_node/Optimizing-Type-Translators.html>.

OK, so it's an optimization issue.  Can this be deferred until later?

>
> Cheers,
>
> --
> Luís Oliveira
> http://r42.eu/~luis/
>

I've written some code to see how this approach would go:
https://github.com/cffi/cffi/blob/cd744b78e13d2469f22cd1b7116c75499c63c8f5/src/structures.lisp
Look under "Luis' approach".  It all seems to work except for
translation of real-and-complex back to Lisp; I can only get it to
translate the complex if it's a macro.  Any thoughts why?

Liam