[Oberon] [EXT] Re: Potential New Approach to Implement Instance-Centered OOP in Oberon-07

[Andreas Pirklbauer]

It is perhaps worth noting that, during compilation, the compiler's symbol table is built while processing declarations, whereas symbol files are written at the end of the compilation process, when all forward references have been resolved in the symbol table.

One possible approach, therefore - which is in fact already implemented in Project Oberon 2013 - is to structure the symbol file such that each unique type reference always precedes its corresponding type description. This arrangement is possible even in the presence of forward or cyclic dependencies. The principle is that the linear description of an enclosing object P may open a "parenthesis" enclosing the complete description of a component object R (such as a record referenced by a pointer type, a record field within a record, or a parameter of a procedure type). Once the parenthesis is closed, the description of P resumes. Importantly, if the description of R in turn refers back to P, the reference number assigned to P is used, thereby resolving the cyclic dependency without fixups.

For example, the forward pointer declaration

  TYPE P = POINTER TO R;
     R = RECORD x, y: P END

can by linearized in the symbol file as follows:

  TYP [#14 P form = PTR [#15 R form = REC [^9] lev = 0 size = 8 {y [^14] off = 4 x [^14] off = 0}]]

Here, the pointer declaration P is assigned reference number #14, which precedes its actual type description, while the record declaration R, with reference number #15, is *embedded* in the linear description of P. This eliminates the need for fixups within symbol files. R refers back to the description of P using reference number #14.

As a result, all type references in symbol files inherently take the form of *backward* references.

The same technique can of course be applied if the record is anonymous, as in

  TYPE P = POINTER TO RECORD x, y: P END

The only difference is that no object node for R is written to the symbol file. The underlying principle, however, remains the same.

For further details, see the EOS documentation. There, however, pointers must always point to named types. Having to declare R as a separate type may be considered somewhat inconvenient, but seems acceptable.


> On 04.11.2026, at 06:21, Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote:
> 
> > On 2026-10-13 02:03, Chris Burrows wrote:
> >> His reply dated 13 Mar 2017 was:
> >> 
> >> "You are right. The identifier R0 in
> >> 
> >>       RECORD (R0) a, b: INTEGER END.
> >> 
> >> must be a record type, and cannot be a pointer type.
> >> 
> >> I had "simplified" this some long time ago, because pointer types in 
> >> this position caused severe troubles in combination with import/export., 
> >> And I think this "restriction" iis quite sensible. Unfortunately, the 
> >> diagnostic message is a bit obscure."
> >
> > OK, thank you for sharing the clarification. I still wonder what the 
> > severe trouble is.
> >
> > /August
> 
> I guess it's related to the problem of generating a symbol file in a single pass in the case of pointers that are forward references. You can read more in the Compiler Construction book or An Oberon Compiler for the ARM Processor (chapter 24. Import and Export), that you linked before. In the latter Wirth goes a bit deeper about it.
> 
> Regarding what he replied to Chris, I guess with *pointer types in this position* Wirth meant using a pointer (that is a forward reference) as a base record in the record declaration. Maybe he was talking about this pathological case below:
> 
> TYPE
>   P0 = POINTER TO T0;
> 
>   P1 = POINTER TO RECORD (P0) ... END;
>   ...
>   T0 = RECORD ... END;
> 
> (Of course we are always talking about doing everything in a single pass.)
> 
> -- 
>   Diego Sardina

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20261104/7ee44af6/attachment.html>