parameter type

parameter type

Postby luowy » Sat Dec 02, 2017 2:01 am

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
luowy
 
Posts: 189
Joined: Mon Oct 20, 2014 12:52 pm

Re: parameter type

Postby Josef Templ » Sat Dec 02, 2017 8:14 pm

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
User avatar
Josef Templ
 
Posts: 1952
Joined: Tue Sep 17, 2013 6:50 am

Re: parameter type

Postby cfbsoftware » Sat Dec 02, 2017 10:44 pm

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.
cfbsoftware
 
Posts: 202
Joined: Wed Sep 18, 2013 10:06 pm

Re: parameter type

Postby luowy » Sun Dec 03, 2017 4:37 am

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;
luowy
 
Posts: 189
Joined: Mon Oct 20, 2014 12:52 pm

Re: parameter type

Postby Robert » Mon Dec 10, 2018 4:45 pm

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?
User avatar
Robert
 
Posts: 962
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: parameter type

Postby Josef Templ » Mon Dec 10, 2018 5:42 pm

I don't think that there is any need for a change.

- Josef
User avatar
Josef Templ
 
Posts: 1952
Joined: Tue Sep 17, 2013 6:50 am

Re: parameter type

Postby Zinn » Thu Dec 13, 2018 2:54 pm

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
Zinn
 
Posts: 463
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main

Re: parameter type

Postby Robert » Fri Dec 14, 2018 12:49 pm

I'm moving this topic to "Bugs / Rejected (Bugs)".
User avatar
Robert
 
Posts: 962
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: parameter type

Postby Robert » Tue Dec 18, 2018 7:23 pm

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).
User avatar
Robert
 
Posts: 962
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: parameter type

Postby luowy » Wed Dec 19, 2018 10:33 am

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
luowy
 
Posts: 189
Joined: Mon Oct 20, 2014 12:52 pm

Next

Return to Rejected (Bugs)

Who is online

Users browsing this forum: No registered users and 0 guests

cron