[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.
-pete