[Oberon] Oberon for a C++ user.

[Peter Froehlich]

Hi Douglas,

On Mon, Oct 3, 2016 at 5:01 PM, Douglas G. Danforth
<danforth at greenwoodfarm.com> wrote:
> You've got the problem backwards.
> A.proc knows nothing about B, C, ...
> So unloading B, C, ... doesn't affect A
> EXCEPT that A.proc points to one of
> (or all if a list of assignments is kept in A).
> Unloading B, C, ... has to transmit that fact
> back to A so that its internal pointer(s) are
> set to NIL.

What you suggest means that Oberon will grow the same wart C has had
for years: variables that change their value for a reason *other* than
an assignment instruction being executed. Wirth always seemed to try
hard to use basic axiomatic semantics to justify his language
constructs. A variable suddenly becoming NIL without any (visible to
the programmer) code having been executed goes against that *very*
strongly.

I do believe that I understand the scenario. Which is why I suggested
doing this in the garbage collector, the only place that could
*possibly* make the decision that freeing the memory for a module is
"safe" because no (outside) references to it exist anymore. Anything
else you do will either lead to "dangling procedure variables" or to
"magic NIL" approaches and the like.

Of course one doesn't have to care whether some operation is safe or
not, that's another technique C has been successful with for years. I
just always looked at Oberon a bit differently I guess.

Cheers,
Peter