🚀 go-pugleaf

On the subject of "trampolenes" in the implementation of nested functions, this 
presumably means the following appraoch:

Suppose a function g is nested inside a function f; Any pointer to the function
"g" is simply a pointer to a small "trampolene" compiled by function f into it's
own stack frame. The "trampolene" code adds an extra parameter to the parameters
for function "g" and then calls the real body of function "g" which is already
compiled into the code section. The extra parameter point's to f's stack frame
so that g can access "f"s instance variables.

Some people say that they "don't like" trampolenes, but don't seem to give any
reason for it. The main objection I can see is that on some operating systems
you are not allowed to do any run-time code generation. But there again, in 
these architectures there do exist other, addmittedly less efficient workarounds
to this problem, surely.

Other people talk about "bound" functions which presumably means that given an
object a of class A with member function f, then "a.f" can be regarded as a new
function (whose pointer can be taken) with a non member-function signature. The 
only way I can see of using a trampolene appraoch for this situation is to place
the trampolene for the function a.f into the object a itself. This increases
the memory overhead for function a. In fact, the compiler would have to do
this by default for every member function of a, because it won't know in
advance which will be bound (without ghastly extensions to the language). This
surely makes member function closures an impracticable and unworkable addition
to the language?

-- Charles Reindorf