🚀 go-pugleaf

Tomas <mcvax!cernvax!ethz!jungfrau!marvin@UUNET.UU.NET> (5 feb) writes:

>...
>       In Oberon you can have so-called 'public projections'. This means
>you can have a partial definition of a record type in the definition
>part and the full definition of it in the implementation part (for
>details see the last paragraphs of the section "Type extension" from the
>paper "From Modula to Oberon"). This feature might be quite nice, but it
>introduces serious problems for the compiler. If the public projection
>(i.e. the declaration in the definition part) has a size smaller than
>the actual declaration in the implementation part, the compiler looks at
>the symbol file, and __patches__ it in order to have the size of the
>record fixed ! To avoid this, the portable Oberon compiler will have a
>slight modification to the language: you have to add a compiler hint in
>the definition part. It will then look like this (referring to the
>example in the paper):
>
>TYPE    Viewer = RECORD
>                   width, height : INTEGER;
>                   [8]
>                 END;
>
>The number indicates the size of the record as it will be in the
>implementation part. It's not quite clear to me if it is possible to
>give any size, even if it is bigger then the actual size in the
>implementation part. I hope It will be clear in their report.
>
>- Tomas
>

This is indeed a problem; Wirth already mentioned it in article [1] together
with the solution of a compiler hint denoting the size of an object, in the
definition part. The problem is that a client module, that is being compiled,
must know the size of an object (storage for variables, parameter passing) in
order to produce correct object code.
I don't think the solution with a compiler hint is an efficient one, however.
When you define the record too large, this would e.g. result in too many pops
and pushes in modules that pass the object as a value parameter. And what
happens if the size is too small (e.g. when you're extending the record more
than you expected when you wrote the definition) ? The implementation shouldn't
compile then, and what do you do ? Increase the [size] in the definition part
(I call this a patch !!), recompile it and compile the implementation again ...
a lot of trouble !
I think that the patch, together with an update of the version number (to be
sure that all modules import the type with the correct size !), in the symbol
file (compiled definition part) is the best solution. You can do a perfectly
portable patch by simply copying the symbol file to a new symbol file.
And even if this patching is not portable, let that be the Oberon implementor's
problem (he is spared enough already). This kind of thing should not be part
of the syntax of Oberon. This [size] is non-portable too: should it denote
bytes, words ? Furthermore, the size of an integer or real etc. in whatever
storage unit is very hardware/operating-system dependant as Gernot Heiser also
pointed out recently.

Bye, Eric.

Literature
----------
1. Wirth, N. 1988.  Type Extensions.  ACM Transactions on Programming Languages
      and Systems 10(2): 204-214.

bitnet address: wiors12@hdetud1
uucp address: mcvax!dutrun!dutrex!wiors12
real address: Julianalaan 132    TWI/SSOR
              2628 BL Delft, The Netherlands