Path: utzoo!attcan!uunet!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!rutgers!att!cbnewsc!lgm From: lgm@cbnewsc.att.com (lawrence.g.mayka) Newsgroups: comp.object Subject: Re: code blocks (aka closures) Message-ID: <1990Jul3.143743.22901@cbnewsc.att.com> Date: 3 Jul 90 14:37:43 GMT References: <5305@stpstn.UUCP> <11002@alice.UUCP> Organization: AT&T Bell Laboratories Lines: 33 In article deutsch@parcplace.com (Peter Deutsch) writes: >C and C++ already take the point of view that one can create, and freely >pass around, pointers to locally allocated variables, despite the fact that >these pointers become invalid when one leaves the dynamic scope in which >the variable was allocated. Adding closures would not create qualitatively >new problems of this kind: they would simply be another case of an existing >problem. If the former problem isn't sufficient to motivate a requirement >for a garbage collector, I don't think the latter is either. 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. A better analog would be C and C++ malloc and new , which generally require explicit free and delete , respectively. >PARC; at least, that's where I remember first hearing it. The >representation of a closure is a pointer to a small block of code stored in >the enclosing stack frame. This code pushes an extra argument -- the Such a closure would remain valid only as long as the enclosing stack frame remains valid. >However, I can imagine using a scheme (:-)) like this for Lisp. Common Lisp supports closures with indefinite lifetimes, and which are therefore garbage-collected. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.