Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!.POSTED!nerds-end From: glen herrmannsfeldt Newsgroups: comp.compilers Subject: Re: Is multi-level function return possible? Date: Fri, 14 Mar 2014 20:27:01 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 84 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-03-034@comp.compilers> References: <14-03-020@comp.compilers> <14-03-022@comp.compilers> <14-03-025@comp.compilers> <14-03-027@comp.compilers> <14-03-029@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: miucha.iecc.com 1394829423 62041 2001:470:1f07:1126:0:676f:7373:6970 (14 Mar 2014 20:37:03 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Fri, 14 Mar 2014 20:37:03 +0000 (UTC) Keywords: code, history, comment Posted-Date: 14 Mar 2014 16:37:03 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:1156 Ivan Godard wrote: > On 3/13/2014 10:05 AM, Anton Ertl wrote: >> 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. Integration routines and minimization routines go back to at least Fortran II, when FUNCTION and SUBROUTINE were added. (Fortran I used ASSIGN and assigned GOTO as a sort-of internal subroutine call, along with "extended range of the DO" so you could use it inside DO loops.) > 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. Reasonably often you don't need to pass any other data to the called routine, but in Fortran you use COMMON (or, in newer Fortran, module variables). The other possiblity is for the integration (or other) routine to pass data, such as a pointer, through to the called routine. That seems to be rare. PL/I internal procedures can be passed in this way, and reference data from the procedure that they are internal to. This ability has, I believe been added to Fortran in the 2008 standard. (Internal procedures were added earlier, but couldn't be used this way.) As I understand it, this isn't quite what closure allows, but works most of the time in practical use. The other place this is commonly needed is in sort programs, such as C's qsort(). I did it once using a C file scope (static) variable. > 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. I am not so sure what you mean by "static" here. The Fortran COMMON or module variable are static allocated, and so will fail when reentrant code is needed, such as recursion. The PL/I version is designed to work properly in the case of recursion, such that data from the appropriate instance is seen by the called routine. As I understand it, most of the PL/I language was defined before anyone tried writing a compiler for it. Getting this right may have complicated the implementation. Otherwise, is hard to see why it took until 2008 for Fortran to allow it. (and still maybe not implemented in any compilers.) > 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. I am still not sure how this works in the case of recursion. > 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. -- glen [Closures are dandy, but they need a garbage collected heap of stack frames. In many environments, e.g., embedded devices, that's too slow or takes too much space. -John]