[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Multiple return values
From: |
Peter Keller |
Subject: |
Re: [Chicken-users] Multiple return values |
Date: |
Wed, 9 Oct 2002 15:14:54 -0500 |
User-agent: |
Mutt/1.2i |
On Wed, Oct 09, 2002 at 09:39:22PM +0200, felix wrote:
> `define-external' is exactly what you want.
Well, the documentation was kinda bad for this, so I don't really know
what it is for or how to use it correctly. But I haven't looked recently
at the docs, so you might have made a bunch of additions I don't know
about yet. I remember you saying you were working on the docs for the
FFI a while ago.
> > What about arrays?
> >
> > ;; does this make sense?
> > (let-location ((i integer (s32vector 1 2 3 4 5 6 7)))
> > ...)
> >
>
> No. `i' is an integer, but you assign a vector.
Though, in C, a reference parameter in a function is the same as for a
single variable, or an array, you could utilize this. I don't see why you
couldn't do with locations what I did with the intp-* functions and make
them based on arity for if they deal with a vector in the location or
not. A location pointing to a single integer is equivalent to a location
pointing to the first element of a srfi-4 vector....
> It should generate more compact and more efficient code
> (just slightly).
Cool! This might shrink the GNU MP FFI a little bit. THat thing turned out
to be huge.
> Hey, you're welcome. I have to thank you and all others for
> doing so much work for it. Your MP library, and the mass of code
> Tony is grinding out will hopefully converge to something
> genuinely competitive to other Scheme implementations (or even
> other language environments).
Neat!
There are plenty of other lib FFIs that are in my queue(zlib, opcodes,
opengl/glut, sdl, png, jpeg), but I want to get the knowledge down of
chicken's FFI so I can produce intelligent scheme interfaces to them.
Currently, zlib is sorta waiting on this discussion.
> You mean for locations? Unfortunately we can not properly
> compute the size of a struct. Too many factors come into
> play, like struct-alignment, etc. But what we need is some
> kind of `sizeof' operator...
Hmm...
-pete