Page 1 of 2

parameter type

Posted: Sat Dec 02, 2017 2:01 am
by luowy

Code: Select all

MODULE Mod;
   PROCEDURE ^ Add (IN x: ARRAY 32 OF CHAR);
   PROCEDURE Add (IN x: ARRAY 32 OF CHAR);   (* X parameter does not match *)
   BEGIN
   END Add;
END Mod.
report by
https://forum.oberoncore.ru/viewtopic.php?f=131&t=6183

Re: parameter type

Posted: Sat Dec 02, 2017 8:14 pm
by Josef Templ
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.

- Josef

Re: parameter type

Posted: Sat Dec 02, 2017 10:44 pm
by cfbsoftware
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.

Re: parameter type

Posted: Sun Dec 03, 2017 4:37 am
by luowy
I know it, I prefer add a line code In DevCPT.EqualType to release this strict rule;

Code: Select all

OR ((x.form = ProcTyp) & (y.form = ProcTyp))
				(*>>*)OR((x.comp = Array)&(y.comp = Array)& (x.sysflag = y.sysflag)&(x.n = y.n))(*<<*))
if it has some side effect except language rule, please tell me;for me, it is convenient;

Re: parameter type

Posted: Mon Dec 10, 2018 4:45 pm
by Robert
I have a couple of questions:

- Is this proposed change consistent with the Language Report?

- Should I move this topic to Dormant or Rejected, or should we raise an issue to include this change?

Anyone have any opinions?

Re: parameter type

Posted: Mon Dec 10, 2018 5:42 pm
by Josef Templ
I don't think that there is any need for a change.

- Josef

Re: parameter type

Posted: Thu Dec 13, 2018 2:54 pm
by Zinn
luowy wrote:I know it, I prefer add a line code In DevCPT.EqualType to release this strict rule;

Code: Select all

OR ((x.form = ProcTyp) & (y.form = ProcTyp))
				(*>>*)OR((x.comp = Array)&(y.comp = Array)& (x.sysflag = y.sysflag)&(x.n = y.n))(*<<*))
if it has some side effect except language rule, please tell me;for me, it is convenient;
You find the side effect here: viewtopic.php?f=34&t=605

The sample there will be passed with your patch, but it should not.
In my opinion it is better not to add this patch.
- Helmut

Re: parameter type

Posted: Fri Dec 14, 2018 12:49 pm
by Robert
I'm moving this topic to "Bugs / Rejected (Bugs)".

Re: parameter type

Posted: Tue Dec 18, 2018 7:23 pm
by Robert
I have received the following contribution from member dsar (memberlist.php?mode=viewprofile&u=109):
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):

ftp://ftp.ssw.uni-linz.ac.at/pub/Oberon ... eList.Text

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

Re: parameter type

Posted: Wed Dec 19, 2018 10:33 am
by luowy
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):

ftp://ftp.ssw.uni-linz.ac.at/pub/Oberon ... eList.Text
" 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.

So I think this change is not necessary.

luowy