On Tue, Sep 6, 2011 at 4:23 AM, Liam Healy <lnp@healy.washington.dc.us> wrote:
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.
Oh yes, with-foreign-object should definitely accept the same arguments as foreign-alloc.
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?
Definitely. On Thu, Sep 8, 2011 at 5:23 AM, Liam Healy <lnp@healy.washington.dc.us> wrote:
6. Finding that (parse-type 'complex) is an instance of neither ENHANCED-TYPEDEF nor ENHANCED-FOREIGN-TYPE, the expand-from-foreignT T method is called, which just returns value (first arg).
So there's a gap here, and I'm not sure how to plug it. Should I be making complex-type a subclass of enhanced-foreign-type so that the compiler macro picks up the conversion to lisp?
Oh. That's right, unless it's an enhanced-foreign-type it won't go through the translation mechanism. Adding that as superclass should work. I think we need a new DEFCSTRUCT-like macro, let's call it DEFCSTRUCT* for now. *sigh* With a different macro we can (a) implement call-by-value semantics by default, (2) add the enhanced-foreign-type superclass by default, and probably (3) have a sane value for :CLASS, not sure. Does that makes sense? -- Luís Oliveira http://r42.eu/~luis/