Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end From: Ivan Godard Newsgroups: comp.compilers Subject: Re: Is multi-level function return possible? Date: Thu, 13 Mar 2014 18:32:41 -0700 Organization: A noiseless patient Spider Lines: 43 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-03-029@comp.compilers> References: <14-03-020@comp.compilers> <14-03-022@comp.compilers> <14-03-025@comp.compilers> <14-03-027@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: miucha.iecc.com 1394818559 22012 2001:470:1f07:1126:0:676f:7373:6970 (14 Mar 2014 17:35:59 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Fri, 14 Mar 2014 17:35:59 +0000 (UTC) Keywords: code, design Posted-Date: 14 Mar 2014 13:35:59 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1151 On 3/13/2014 10:05 AM, Anton Ertl wrote: > From what I remember it's truly lexically scoped (and the mechanism > to implement it is the same as for local variables), but if you want > to make sure, you can read the spec. > > But thinking about it makes me wonder: Can you come up with an > example that shows the difference? And can you come up with a useful > example where there is a difference? The standard practical example is an integration package which takes an argument function to integrate over the range. The argument function is not in the scope of the integration package. It may not even be in the scope of the caller of the integration routine. Consequently it must use either a closure (so it can be a lambda) or the function-pointer format must contain a static link pointer as well as a code pointer. A display doesn't help this. True closures are more powerful than static nesting, because a closure can be invoked even when the scope in which it was created has exited, which cannot be done with static nesting. However this means that the representation of a closure has unbounded size (and so must use the heap), whereas static nesting has bounded size, e.g. two pointers. It also has unbounded lifetime, so it requires garbage collection. As an alternative, some languages define a poor-man's-lambda that cannot escape its scope of creation. That lets the PML be allocated on the stack (an alloca) and requires neither heap nor garbage collection, but is less powerful than true closures. In addition, one can create an unbounded number of closures with different bindings, whereas the number of statically nested functions is statically bound. In effect, a statically bound function receives its bindings as global (to it) variables passed by reference, whereas a closure receives its bindings as arguments passed by value. Thus statically nested functions have all the well-known issues of passing arguments via global data, while closures avoid that. The C++ approach of creating a temporary class to hold the bindings and then using operator() to invoke the result is a syntactic variant of a closure rather than of statically nested functions. However, the temporary class is a nuisance to write, so recent C++ has provided more convenient syntax to create lambda/closures.