Declare-before-use and Use-before-declaration

[trijezdci]

I ran into the following pathological scenario while working on the symbol table for M2C ...

PROCEDURE Outer;
VAR foo : CARDINAL;

PROCEDURE Inner;
BEGIN
foo := 0;
bar := 0;
...
END Inner;

...

VAR bar : INTEGER;
...
BEGIN
...
END Outer;

Apparently this is not strictly illegal in PIM.

At the point where variable bar is first used within procedure Inner, it has not been declared yet which means it is not present in the symbol table and the symbol table lookup then returns an unknown symbol response. If the above scenario is to be supported, it will complicate scope management because by the time variable bar is declared, scope Inner has already been closed. I discard scopes when closing them.

I found that I can get around this by first collecting all non-procedure declarations before proceeding with all the procedure declarations and do so in every scope.

However, I am not sure this is desirable. Clearly, such practise significantly diminishes the readability of the source code.

Can anyone think of any use cases that could justify this being allowed?

The only two use cases I can think of where use-before-declaration is desirable are:

(1) a type declaration with a reference to another type

TYPE T1 = POINTER TO T2;

TYPE T2 = ... ;

(2) a procedure referencing another procedure (either assignment or call) within its body.

PROCEDURE P1;
BEGIN
...
P2;
...
END P1;

PROCEDURE P2;

Any other scenarios of use-before-declaration do not seem to make sense to me.

Can anyone think of any other useful use cases where use-before-declaration semantics are desirable?

thanks in advance

[Xin Wang]

Post by trijezdci
I ran into the following pathological scenario while working on the symbol table for M2C ...
PROCEDURE Outer;
VAR foo : CARDINAL;
PROCEDURE Inner;
BEGIN
foo := 0;
bar := 0;
...
END Inner;
...
VAR bar : INTEGER;
...
BEGIN
...
END Outer;
Apparently this is not strictly illegal in PIM.
At the point where variable bar is first used within procedure Inner, it has not been declared yet which means it is not present in the symbol table and the symbol table lookup then returns an unknown symbol response. If the above scenario is to be supported, it will complicate scope management because by the time variable bar is declared, scope Inner has already been closed. I discard scopes when closing them.
I found that I can get around this by first collecting all non-procedure declarations before proceeding with all the procedure declarations and do so in every scope.
However, I am not sure this is desirable. Clearly, such practise significantly diminishes the readability of the source code.
Can anyone think of any use cases that could justify this being allowed?
(1) a type declaration with a reference to another type
TYPE T1 = POINTER TO T2;
TYPE T2 = ... ;
(2) a procedure referencing another procedure (either assignment or call) within its body.
PROCEDURE P1;
BEGIN
...
P2;
...
END P1;
PROCEDURE P2;
Any other scenarios of use-before-declaration do not seem to make sense to me.
Can anyone think of any other useful use cases where use-before-declaration semantics are desirable?
thanks in advance

I think mutual recursion[1] data structures and procedures are valid use cases. Rosetta Code[2] have some examples about how other languages deal with this problem.

[1] https://en.wikipedia.org/wiki/Mutual_recursion
[2] http://rosettacode.org/wiki/Mutual_recursion

[trijezdci]

Post by Xin Wang
I think mutual recursion[1] data structures and procedures are valid use cases. Rosetta Code[2] have some examples about how other languages deal with this problem.
[1] https://en.wikipedia.org/wiki/Mutual_recursion
[2] http://rosettacode.org/wiki/Mutual_recursion

Thanks, but those are the two use cases I had already listed. I was looking for additional use cases to gauge whether there is any justification for supporting more.

It would also be of interest if anyone knows of any examples in PIM based Modula-2 books (in particular from Wirth, but also others) for which use-before-declaration semantics are required, other than the two use cases I had already listed.