drop low-level or not, CLISP typed foreign references

Hi,

Kevin Rosenberg wrote:
> 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.

So my hope is that an interface can be discovered(!) as soon as possible that eliminates the need for the low-level interface. I haven't yet found an end in this area.

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


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

Yes - even support twice :-) But what do you mean exactly by "support"? It would not be a one-liner.

o At wrapper level: return a displaced array to the rest of the string.

o At the internal level, not at what the Lisp-level programmer sees or what I intend for her/him to see (see my other mail about strtol):

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.

More quoting from my article about FFI design: "
The [strtol] functionality is uninteresting from a Common Lisp point of view, as PARSE-INTEGER &KEY JUNK-ALLOWED supersedes it completely and portably. The Lisp function also returns two values: the number parsed and how much of the string was read (as an index instead of a pointer)."

Regards,
	Jorg Hohle