On Tue, Sep 6, 2011 at 4:23 AM, Liam Healy <l...@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 <l...@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/ _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
