Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!ihlpb.att.com!nevin1
From: nevin1@ihlpb.att.com
Newsgroups: comp.lang.icon
Subject: Re: lifetime of variables
Message-ID: <9005040241.AA13224@megaron>
Date: 4 May 90 00:41:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 41

>Why is it that a procedure like
>
>  procedure return_table()
>    tbl := table()
>    return tbl
>  end
>
>works. [...]
>If I had no familiarity with Icon, I'd probably way
>"make tbl static or global, 'cause it'll disappear when return_
>table() returns, and all you'll be left with is a pointer aiming
>into the great void."

[Side note:  the above is a good explanation of a very common C
programming error.]

The the table sticks around because is it is stored in that
area of memory commonly referred to as the "heap".  (This is the same
type of memory that C's malloc() function returns pointers into.)

[Note:  there are other ways of implementing call-return mechanisms
(eg: copy the object before returning), but they have other problems
associated with it.]

One purpose of a heap is to have objects survive procedure calls and
returns.  Like static variables, it has limited visibility.  However,
it differs from statics in that each call to a function like your
return_table() returns a DIFFERENT table each time.  (I don't mean to
say that if tbl were declared static that the return_table() would
return the same table each time; its behavior would not change.  What I mean
is that in the framework of a language like C, if you return a pointer to
a static you will always get the same address, while if you return a
pointer to something malloc()ed you will get a different address.)

The other purpose to having a heap is to create objects of arbitrary
size or of sizes unknown at compile time.


I hoped I haven't rambled too long.  It's been a long day. :-)

	NEVIN ":-)" LIBER  nevin1@ihlpb.ATT.COM  (708) 831-FLYS