This is the same in all Oberon compilers that support forward declarations.
It follows from the name equivalence rule.
You would have to introduce a named type for any parameter that needs name
equivalence.
An open ARRAY uses structure equivalence and is kind of an exception.
It is not just an issue related to forward declarations. The most recent Oberon compilers report a compilation error for *any* procedure that has an anonymous type as a parameter e.g.:
PROCEDURE Add (x: ARRAY 32 OF CHAR);
because it is unusable.
Such a procedure is also unusable in Component Pascal but compiles without an error. An error is only reported when the procedure is actually called, e.g. given:
VAR
x: ARRAY 32 OF CHAR;
the statement Add(x) results in an 'incompatible assignment' error.
10 The formal parameter lists of the forward declaration and the actual declaration must be identical [not just match].
10.2 The formal parameter lists of both declarations [the type-bound procedure and its forward declaration] must be identical.
I guess with identical they meant textually identical. However removing "must match" with a reference to the Appendix A excludes the fact that they must be type checked.
I'm against to put new language features to a stable language, but it would be nice to improve Component Pascal in clarity and coherence (type checking of forward references doesn't make sense).
Robert wrote:Although it's correct that IN x: ARRAY 32 OF CHAR is not usable because of name equivalence, forward references shouldn't be type checked.
This problem was already issued and corrected in Oberon-2 in the last change (during 1996):
" forward references shouldn't be type checked." it is easy to do: Follow the language definition and accept
a parameter with an anonymous array type,
but the question is: is it valuable? most of our active members tend to fixup true bugs rather than trivial. our group is maintainer, Keep old components workable is most important.