[Oberon] Oberon for a C++ user.

[chris]

On Thu, 6 Oct 2016 17:05:39 -0500, John R. Strohm wrote:
> Are we hurting ourselves in this discussion by assuming a particular 
> implementation or code generation strategy for a procedure variable?

I don't think so. The problem is independent of the implementation 
details.
 
> When we load a module, we define a number of externally-visible 
> symbols. Some of those may become the right-hand-sides of assignments 
> to procedure variables.

You can also assign not exported procedures to procedure variables. The 
pointers to procedures can be located in any heap object and get passed 
around. You need a full garbage collection scan to find all references.

> Can we finesse the problem by, instead, as part of the module-loading 
> process, loading a set of thunks (for lack of a better term: perhaps 
> you prefer trampolines), one for each externally-visible procedure, 
> that exist to redirect a procedure variable call?  Then, when the 
> module is unloaded, instead of reclaiming the thunks, we make them 
> branch to trap routines instead.  If we then load a new version of 
> the module, the thunks are still around, and can be reconnected to 
> the newly-loaded code.

Of course this can be done, but there is a price. Every procedure call 
via procedure variable now needs an double indirection. That means you 
slow down the common case to make the unloading easier which does not 
happen often and is not time critical.

Greetings, chris