Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!DG-RTP.DG.COM!langley
From: langley@DG-RTP.DG.COM (Mark L Langley)
Newsgroups: comp.lang.icon
Subject: Re: lifetime of variables
Message-ID: <9005041354.AA17493@bigbird.rtp.dg.com>
Date: 4 May 90 13:54:50 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 35

Richard Goerwitz III asks
> 
> Why is it that a procedure like
> 
>   procedure return_table()
>     tbl := table()
>     return tbl
>   end
> 
> works.  I guess I never really thought about it before (I don't
> mentally transfer Icon into equivalent constructions in other
> languages).  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."
> 

Ah, this is one of the great things about Icon -- Memory management
is done for you.  Dynamic storage allocation is the trick.  Imagine
two ways of using your office, playroom, or kitchen counter.

Static Storage Allocation: 
	Take something out, put it back, Take it out, put it back...
Dynamic Storage Allocation:
	Take things out, put them back when you need the space.

To make a long story short, the Icon garbage collector is responsible 
for collecting things that you no longer need.  The interpreter doles 
out memory as needed.  When it runs out, it finds all the objects that 
could still be referenced and moves them together.  This writes over all 
the objects that cannot be reached anymore, leaving space at the end.  
Between this and saying "Mother may I have some more?" to the operating 
system, it usually avoids running out of memory.

Mark