[Oberon] Clarifying type compatibility in Oberon-07

[Andreas Pirklbauer]

> 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).

PROPOSAL:

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.

RATIONALE:

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.

COMMENTS:

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).

Any thoughts?

-AP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171007/23efe021/attachment.html>