Re: multiple return values
- From: "Kaz Kylheku" <kkylheku@xxxxxxxxx>
- Date: 7 Jul 2005 09:17:37 -0700
chairam wrote:
> Hi, I'm studying lisp
>
> Some function like: truncate, floor, round, return 2 values
>
> if you want to catch all values you have to use multiple-value-bind
> but:
> why 2 values and not a list of 2 values?
The storage locations that hold arguments and return values are not
first-class objects. They are data communication pathways. It's
important to be able to implement those pathways efficiently on a given
processor.
If the aggregate that holds return values were represented as a first
class list, then the program could retain a reference to that list. The
list would have to be allocated in the usual way and subject to garbage
collection.
The way it is right now, the program cannot get a handle on the place,
or places, which hold return values. It can only retrieve copies of the
values held in those inaccessible storage locations.
This is similar to how it works in other languages. For example in C, a
function can return a struct object. However, that returned struct
isn't a first class object. You cannot take the address of a member,
and if it contains an array, you therefore cannot use that array.
struct foo { int x; int y[3]; };
struct foo func(void);
...
z = func().x; /* okay to access x */
func().x = 3; /* error, returned struct isn't an lvalue */
func().y; /* error, cannot take address of any part */
These restrictions give the implementation a lot of freedom with
respect to implementing procedure linkage.
For instance, return values can be placed into registers, or pushed
onto the stack, or placed into a memory area that is reserved by the
caller, which could be on the stack.
None of these locations are programmer-visible first class objects in
the high level language; they are managed by the compiler. If registers
are used, the compiler takes care that the generate code knows what is
clobbered and what is saved. If return values are pushed on the stack,
the compiler ensures that everything is popped off the stack even if
the high level program doesn't use some or all of the return values.
Keeping the memory locations and the entire mechanism shrouded from the
programmer allows for optimizations. If a memory area is used for
return values, in principle it would be possible to allow the
programmer to see that area as an object in the high level language.
But that would just invite bugs, probably because that memory is quite
likely quickly disposed of and then reused again for another purpose.
For instance, suppose that the stack top is used for returning values.
As soon as the compiler-generated code which called the function cleans
those values off the stack, any subsequent evaluation can re-use the
same space by pushing values there. The programmer must use the
appropriate high level mechanism to ``rescue'' some or all of the
return values from that memory before it is gone.
> I have my own opinion but appreciate others'
That's wonderful! Now all you need is a time machine. :)
.
- References:
- multiple return values
- From: chairam
- multiple return values
- Prev by Date: Re: multiple return values
- Next by Date: Re: Lisp in Visual Basic? Or at least some tiny lisp implementation to repeat?
- Previous by thread: Re: multiple return values
- Next by thread: Re: multiple return values
- Index(es):
Relevant Pages
|
