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:
- 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?