Path: utzoo!attcan!uunet!microsoft!bobatk
From: bobatk@microsoft.UUCP (Bob ATKINSON)
Newsgroups: comp.object
Subject: Re: code blocks (aka closures)
Message-ID: <55700@microsoft.UUCP>
Date: 6 Jul 90 22:15:31 GMT
References: <5305@stpstn.UUCP> <11002@alice.UUCP> <DEUTSCH.90Jul2150016@atlantic.parcplace.com> <1990Jul3.143743.22901@cbnewsc.att.com>
Reply-To: bobatk@microsoft.UUCP (Bob ATKINSON)
Organization: Microsoft Corp., Redmond WA
Lines: 32


>Peter Deutsch writes:
>> [paraphrased by rga] "C today lets us take pointers to local variables,
>> even though they are `dangerous'.  One can imagine a similar form of 
>> `dangerous' closures".


Then lawrence.g.mayka writes:
>A closure which remains valid *even after the return of its
>enclosing function* is qualitatively different from the current C
>and C++ treatment of pointers to local variables.

I believe this mis-interprets what Peter said.


>>However, I can imagine using a scheme (:-)) like this for Lisp.
>
>Common Lisp supports closures with indefinite lifetimes, and which
>are therefore garbage-collected.

One can imagine an implemenation of Lisp in which the actual allocation
of a garbage collected closure object does not occur at the time the 
closure is created, but rather when the activation record of its outer
scope returns.  In the iterim, the closure could live on the stack, as
Peter described.  If it doesn't outlive its outer scope, no garbage
collected object need occur.  

Of course, all this depends on the internals of your Lisp.


	Bob Atkinson
	Microsoft