Re: drop low-level or not, CLISP typed foreign references

> > Here's a question: should I remove low-level interface in the hope of
>
> No. "Worse is better" teaches me that there's more return on invest to
> have something working first, then [possibly] enhance later. It doesn't
> say whether the low-level interface may even be enough. In the FFI case,
> I've strong feelings it's not enough.

I understand. My point was directed that if CLISP can't support the 
low-level interface (allocate and free foreign objects), then getting
rid of them and just using with-foreign-object may allow CLISP to be
supported as well.

> My favourite FFI is CMUCL's, BTW. You once said you prefer ACL's.

I may have said that. If I did, what I meant is that I know ACL's best 
since I have used it the longest. I also like the open-coding it can do.

However, after learning LW and CMUCL, I like CMUCL the best as well. The
(with-alien) macro is particularly efficient and using declaration of
alien types the compiler can open code many things. The :in-out function
arument macros are convenient and seem to work well.

> Yes - even support twice :-) But what do you mean exactly by "support"?

Be able use pointer arithmetic to interpret the results.

> CLISP's FOREIGN-ADDRESS type is sort of a tuple of a pointer and an
> offset. So CLISP *can* internally precisely represent a pointer that's N
> away from its base pointer. But how to say it to CLISP in a specific
> situation (strtol)?
>
> CLISP's FOREIGN-VARIABLE type is sort of a tuple of a FOREIGN-ADDRESS
> and a foreign (C) type description.
>
> So the strtol :out argument could create a foreign-variable and make use
> of the offset. But the offset is not available to the Lisp programmer
> and I don't consider this a weakness.
>
> The C-level programmer would have to state that the base pointer for the
> output object is the input pointer and reuse it.

Thanks for the detailed information. I'll reread the imp-notes for CLISP
and think about your message. I would like to support CLISP, if possible,
with UFFI. Looking at foreign-variable and foreign-address, perhaps I
can plug in my own malloc and free to allocate arbitrary objects outside
of a function call.

Thanks for your insights.

Kevin