Re: Is multi-level function return possible?

Ivan Godard <ivan@ootbcomp.com> wrote:
> On 3/13/2014 10:05 AM, Anton Ertl wrote:
<snip>


>> 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]

Return to the comp.compilers page.
Search the comp.compilers archives again.