On Mon, Sep 5, 2011 at 10:16 AM, Luís Oliveira luismbo@gmail.com wrote:
On Mon, Sep 5, 2011 at 4:43 AM, Liam Healy lnp@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/s... 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