[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 16:31:12 -0500
User-agent: Mutt/1.2i

On Wed, Oct 09, 2002 at 10:41:08PM +0200, felix wrote:
> Peter Keller wrote:
> Not quite: the location represents a piece of storage that contains
> the a data object of the given type. So the actual *size* is crucial.
> The situation is different for pointers, of course.
> But since vectors can be passed directly to foreign code, plus
> locatives, I'm not sure what you want to achieve with your example

I think (if I understand your and my argument correctly) that I only
want a unification of the two ideas into a single syntax sine I think we
are agreeing.

For example(using the foobar external definition example):

Using locations to reference a single variable:
(let-location ((i integer 42))
        (foobar (location i))
        (print "i is now 43: " i))

Using s32vector to reference a single variable:
(let ((i (s32vector 42)))
        (foobar i)
        (print "i is now 43: " (s32vector-ref i 0)))

To me, those should be the same since they represent the same thing from the
point of view of the C interface, whose prototype is void foobar(int*) no
matter which method you use above.

I very much like your (location ...) abstraction however. Maybe it can be
made more general.

(location 's32vector var)
(location 'integer var)
(location 'unsigned-int var)

Now, let-location doesn't even exist(if I understand it correctly),
and the compiler possibly at compile time can check to see if this is
true with the binding passed to it.

> (but I'm not too receptive today, vacation is over, 8 hours of C++
> coding take their toll...)

Yeah, I've been porting 32-bit system code to 64-bit linux IA64 all day
today. Feh. Now you know why I'm complaining so much about long long. :)

Eh, I've lost plenty of arguments before, I usually fight until I'm
proven wrong and I understand why. Then I shut up until I create a better
argument, if ever. :)

> Cool. Hm. This calls for a decent C-headerfile parser, actually...

Yeah, bigloo had a nice(well, functional, it didn't handle #ifdef too
well) one of these. The FFI in bigloo was nice, but exceedingly complex,
and I don't know if it was that way because it is a hard problem to
represent syntactically, or if it just evolved into it after a while
with a lot of baggage.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]