🚀 go-pugleaf

In article <1993Jan22.081555.12027@us-es.sel.de> reindorf@us-es.sel.de (Charles Reindorf) writes:
>On the subject of "trampolenes" in the implementation of nested functions, this 
>presumably means the following appraoch:

> [code generation into stack frame, which works.]
> ... The main objection I can see is that on some operating systems
>you are not allowed to do any run-time code generation.

One workaround is to keep a cache of trampolines, which in this case
are pairs of code+data, where each piece of code is compiled to
reference a particular piece of data.  Some run-time code generation
must still occur.  In the limit case (the least flexible OSes) a
different calling convention must be used for all function calls.

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

Actually, you could "new" them.  Just allocate the functions on the
"heap", and free them when you are done.  Or, we could take a flying
leap at the slippery slope and add garbage collection.

>This surely makes member function closures an impracticable and
>unworkable addition to the language?

I think the answer is another question: "compared to what?"  I'm
really looking forward to run-time instantiation of templates.

David Chase
Sun