[Oberon] Oberon for a C++ user.

[Peter Fröhlich]

Hi Andreas,

On Tue, Oct 4, 2016 at 11:21 PM, Andreas Pirklbauer
<andreas_pirklbauer at yahoo.com> wrote:
> It is true that procedure variables are just memory addresses, i.e.
> "pointers" to code. However, they are not part of the type descriptor for a
> record that may contain such procedure variables (for details, see
> ORG.FindPtrFields which covers only “true” pointers, records or arrays, but
> not procedure variables - which have typ.form = ORB.Proc).

I understand that, what I was suggesting is that you need to (a) add
the offsets for procedure variable fields (in addition to those for
POINTER TO some kind of record) and (b) give procedures their own
"type descriptor" of sorts (or find some other way, address ranges
maybe, I don't know whether code for a module is contiguous) to link
them back to the module they come from. Then, when the GC realizes
that (for a given, already "unloaded" but "still around for safety"
module) no more references to its procedures exist, it can actually
(finally, for real) "free" the module.

> So one must extend the definition of the type descriptor to cover procedure
> variables also if one wants to implement the ability to verify whether a
> heap object contains a procedure variable or not. This is exactly what I did
> in the Ceres-Oberon implementation (at the time I more or less copied the
> "method table" approach implemented in Object Oberon and Oberon-2 - but
> without the language change).

Sorry, but the type-descriptor extensions for Object Oberon or
Oberon-2 serve a completely different purpose. First (they are called
"type-bound" procedures, right?) the entries there are *fixed*
addresses, one for each type-bound procedure. These addresses cannot
change for a given type-descriptor, unless you rearrange the module
and somehow "reload" it. Procedure *variables* don't need fixed
addresses, so there's nothing to store in a Oberon-2-like type
descriptor. If you want the GC to "mark" procedures "in use" in some
procedure variable, you need just the offset for each procedure
variable and a way to "mark" the procedure (and the module it came
from). Neither of these shows up in the Oberon-2 "method table"
approach. So if you previous work was trying to GC procedures and
modules, then I don't see how it could have worked when the design was
based on "method tables".

(It may well be that we are both saying the same thing, just not
talking in the exactly "correct" language for the other person to
understand. If that's the case, I apologize for being dense.)

> Regarding your second point: Whether a procedure is currently running or not
> is not really a problem, because in Oberon 2013 the garbage collector is
> still only run between commands - just like in the original version of
> Oberon on Ceres.

That's a bonus, makes the rest a lot easier! :-)

Best,
Peter