Re: is allocate-foreign-object really a macro?

On Fri, Apr 19, 2002 at 09:31:54AM +0200, Hoehle, Joerg-Cyril wrote:
> > You are right, it could be a function. I chose to make it a macro for
> > efficiency sake as well as being consistent with the almost all of the
> > other forms of UFFI: a macro wrapper around native FFI's.
> I didn't notice this. You should highlight this in your design
> section. This is important to know and consider, also for the user.

Good idea!

> Yesterday afternoon, I quickly looked at UFFI again, looking at what
> CLISP still needs to provide to enable a "port" from UFFI to CLISP. I
> believe it's not much anymore.
 
Great.

> ;UFFI supports some keywords:
> (defun uffi:convert-from-foreign-string (address &key length (null-terminated-p T))
> This would be much harder to write as a macro.

Yes. I think it is more complex to write macros, and I know of a design
rule that says "only use macros when there is no other means to acheive
desired functionality." One design goal of UFFI is to have a minimal to
no effect on performance compared to using a UFFI. That is why I use
macros more than is strictly necessary. BTW, ACL doesn't support inline
functions, so to really inline code, ACL requires macros. I don't like
that.

> Please don't expect too much now. I have *no* plans to port it
> myself. I'm already busy with way too many things in CLISP etc. But I
> *do* offer to create functionality that CLISP needs to provide for
> this purpose. E.g., I have experimental WITH-FOREIGN-STACK macros.

That sounds fine. I'd be glad to work on a CLISP port after I help
finish John and Reine finish the MCL and Corman ports. I'm glad to you
are adding the functionality to CLISP to support UFFI!


-- 
Kevin Rosenberg
kevin-HJRc7zDS/[email protected]