[Oberon] Clarifying type compatibility in Oberon-07
andreas_pirklbauer at yahoo.com
Sat Oct 7 16:00:30 CEST 2017
> On Thu Oct 5 17:25:20 CEST 2017 Jörg wrote (slightly adapted by AP):
> NW allows assignment of different ARRAY types only in case of
> open arrays. This is reasonable as the formal parameter accepts
> different types.
> 1 PROCEDURE Test(VAR open: ARRAY OF CHAR);
> 2 VAR local: ARRAY 17 OF CHAR;
> 3 BEGIN
> 4 local := open (* exception allowed by report*)
> 5 open := local (* currently not allowed by report*)
> 6 END Test;
It is my impression that the majority of participants in this forum
seems to converge on wanting only name equivalence for arrays, but
not structural equivalence - *so long as* the language report is 100%
unambiguous in this regard and the type rules outlined in the report
also exactly match the implementation. In short, one simply just wants
to know what *exactly* is allowed, and which language features one can
safely rely on, e.g. when doing an implementation.
If this is the case, the question discussed here should be rather easy
to address (namely: pick name equivalence, spell the rule out in the
report, and make the compiler implementation conform with the rule).
Such a decision would leave us with the one remaining question of
which exceptions should in fact be allowed for open arrays. Currently,
in an array assignment only the source can be an open array (line 4),
but not the destination (line 5).
For an array assignment destination := source, Oberon-07..
1) generally allows the source array to be equal or to be shorter
than the destination array, i.e. even if no open arrays are
involved, i.e. the length is always taken from the source.
2) if open arrays are involved in an array assignment, allow either
the source or the destination, or both, to be open arrays.
3) Allow this for multi-dimensional arrays as well.
a) In Oberon-07, only formal procedure parameters can be open
arrays. Dynamic array variables allocated using NEW(p, size)
are not included in the Oberon-07 language report.
b) If an array is passed as an open array parameter to a procedure
or function procedure, its length is always passed on the stack
alongside its address, in accordance with code pattern #10 on p.21
of section 12.2. of the book "Project Oberon (2013 Edition)”. This
makes length checks easy to implement at run time (see point d.).
c) If neither the source nor the destination array are open arrays,
then their lengths are known at compile time. Hence, the check
whether length(source) <= length(destination) can be performed
by the compiler, and no run-time length checks are necessary.
d) If either the source or the destination array, or both, are open
array parameters, then their lengths are available at runtime on
the stack (see point a.). In that case, the length check needed
before the array assignment, can and must be performed at run time.
e) The rules are easy to implement.
f) The resulting assignment rules for arrays would become natural,
therefore also easy to understand and communicate in the report.
g) It would settle this question once and for good, with no chance
of confusion whatsoever (if done and communicated well).
h) As a consequence of such an exact semantic definition of not only
what exactly *is* considered to be part of the language, but also
what is *not* part of it (“what is IN and what is OUT”), any compiler
implementation that decides to go beyond that “minimal rule set” now
automatically becomes identifiable as such, and therefore can be
labeled as implementing an “extension” to the Oberon-07 language -
e.g., a compiler implementing structural equivalence for arrays.
A. Currently only one-dimensional open arrays are handled by the
compiler. Is there any deeper reason for this, or is this
merely an implementation restriction? It seems to me that
with the rules proposed above, it should be easy to include
multi-dimensional arrays. If not, one would need to either add
an additional language rule that restricts this to one-dimensional
arrays, or leave it undefined and make it an implementation
restriction - I dislike both. To be investigated.
B. Strings are of course to be addressed separately (not discussed
here, but easy to add, as discussed earlier in this thread).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon