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