Re: with-alien-allocation & trying to avoid superfluous alloc+free

> A difficulty with CLISP is that stack-allocated things are only
> accessible encapsulated around a foreign function call
> (FFI::FOREIGN-CALL-OUT). They are not available separately in any way
> (like CMUCL's WITH-ALIEN or MCL's WITH-ALLOCATION which John DeSoi
> reported). This feature could be a useful extension to CLISP.
>
> If I were to add to CLISP some WITH- functionality, it would still not
> be as efficient as today, since every invocation would create
> FOREIGN-VARIABLE (Lisp) objects, which need to be GC'ed. CMUCL does a
> lot of compile time analysis to remove this sort of boxing. CLISP today,
> by integrating some WITH- functionality into FFI::FOREIGN-CALL-OUT,
> eliminates the need of explicit temporary objects for many common
> situations (at the cost of headaches in the few less common situations).

Thanks for the explanation of CLISP behavior. It is helpful.

> Again I believe (my DSL dream) that more declarative interfaces are
> easier to translate, whereas imperative code (e.g. allocate this, then
> that, then setf that, then call, then convert this, then free) is hard
> for portability.

In attempting to provide a universal interface where valid UFFI code works
on all platforms, I see your point that the lower-level interface may be a
limitation.

Here's a question: should I remove low-level interface in the hope of
being able to support CLISP? Right now, to support the strtol routine
(examples/strtol.cl), I need to do pointer arithmetic to properly handle
the output of the C function. With your knowledge of CLISP, can you think 
of a way to support strtol with its FFI?

> I think WITH- provides a useful abstraction, not hindering flexibility
> nor performance too much.

So far, the with-foreign-objects macro that you suggested is a big win as 
it can choose the most efficient technique for each implementation.

Thanks again for your thoughts, I appreciate them.

Kevin