Nested procedures

[hansklaver]

Intermediate objects are items which are listed in CONST, TYPE, VAR and PROCEDURE declarations in a procedure which also contains a nested procedure.

Intermediate variables are items which are listed in a VAR declaration in a procedure which also contains a nested procedure.

The objects and variables are strictly local when referenced in the procedure in which they are declared but they are intermediate local objects when referenced in the nested procedure.

Thank you, now things are much clearer to me.

I suspect things would be much clearer to readers of the Language Report if "non-global" would be added to the following paragraph:

10. Procedure declarations
...
In addition to its formal parameters and locally declared objects, the objects declared in the
environment of the procedure are also visible in the procedure (with the exception of non-global variables and
of those objects that have the same name as an object declared locally).
...

Regards,
Hans Klaver

[cfbsoftware]

I suspect things would be much clearer to readers of the Language Report if "non-global" would be added to the following paragraph:

Revision 1.10.2013 of the Language Report now says:

All constants, variables, types, and procedures declared within a procedure body are local to the procedure. The values of local variables are undefined upon entry to the procedure. Since procedures may be declared as local objects too, procedure declarations may be nested.

In addition to its formal parameters and locally declared objects, the objects declared globally are also visible in the procedure.

[cfbsoftware]

We are testing how removing the visibility of intermediate local objects affects the earlier examples. The example that started this discussion now reports the error messages: undefined identifier for the references to x in the latest Oberon compiler being developed:

Code: Select all

MODULE Nested;

  PROCEDURE P; 
    VAR
      x: INTEGER;
      
    PROCEDURE N;
    BEGIN
      x := x + 1;
    END N;
       
  BEGIN
  END P;  

END Nested.

See the comments for the errors in this example:

Code: Select all

MODULE Nested;

TYPE
  T = ARRAY 10 OF REAL;
VAR
  v: INTEGER;
  vt: T;
  
  PROCEDURE Level1;
    TYPE
      T = ARRAY 20 OF BOOLEAN; (* local type hides global with the same name in Level1*)
    VAR
      vt: T; (* local variable hides global with the same name in Level1*)

    PROCEDURE Level2;
    VAR
      vt1: T; (* T is the global REAL array. Level1 T is not visible*)
    BEGIN (* Level2 *)
      v := 99;       (* Global variable is OK *)
      vt[0] := TRUE; (* Error: Incompatible assignment. Global vt is a REAL array *)
      vt1[0] := TRUE (* Error: Incompatible assignment. Local vt1 is a REAL array  *)
    END Level2;
  
  BEGIN (* Level1 *)
    v := 99;      (* Global variable is OK *)
    vt[0] := TRUE (* Local level1 variable is a BOOLEAN array *)
  END Level1;    
  
BEGIN
  v := 99;        (* Global INTEGER variable *)
  vt[0] := 99.0;  (* Global REAL array *)
END Nested.

[Stefano]

Langugae report is now much clear. I think new compiler should also report an error when

Code: Select all

MODULE Nested;

  PROCEDURE Level1;
   
     PROCEDURE Level2A;
     BEGIN
     END Level2A;

     PROCEDURE Level2B;
     (* open a new scope here: only local, formal parameters and global objects  are visible *)
     BEGIN
       Level2A                    (* compiler should report an error: Level2A is not in Level2B scope*)
     END Level2B;
     
  END Level1;

END Nested;

[cfbsoftware]

Yes - the new compiler reports the error undefined identifier for your example the same as it does for any other object that is not visible in its scope.

[kevinhely]

Langugae report is now much clear

Hmm. I think the report should say:

In addition to its formal parameters and locally declared objects, the objects declared globally are also visible in the procedure (except objects whose identifiers coincide with those of locally declared objects).

[dsar]

Then we've lost the ability to make mutually recursive procedures if both of them are nested?

[cfbsoftware]

Mutually recursive procedures are still possible. The following compiles OK. P1 is a global procedure so it can be called from P2. P2 is local to P1 so it can be called from P1:

Code: Select all

MODULE Mutual;

  PROCEDURE P1;

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

END Mutual.

However you do not need to use nested procedures in order to implement mutual recursion. You can use procedure variables as in this example:

Code: Select all

MODULE Mutual2;

TYPE
  Proc = PROCEDURE;
VAR
  p1, p2: Proc;
   
  PROCEDURE P1;
  BEGIN
    p2
  END P1;
  
  PROCEDURE P2;
  BEGIN
    p1
  END P2;

BEGIN
  p1 := P1;
  p2 := P2
END Mutual2.

Personally I prefer this technique as it gives a better impression of the symmetry/equality of both procedures.

[augustk]

My last message seems to have disappeared. Anyway, to me it's not clear why all access to objects from intermediate scopes are disallowed when variables are the only objects which may cause trouble.

[cfbsoftware]

Sorry - I accidentally edited your message instead of replying to it

I can think of several good reasons: minimal usefulness, uniformity / consistency / regularity (look at the confusion caused when variables were an exceptional case), simplification of the compiler, better performance (intermediate namespaces do not need to be scanned).

Personally I no longer have any need to use nested procedures. The benefits that they had in the days of original single-source-file Pascal were virtually made redundant when Modula-2 arrived on the scene with its ability to use separate modules for selective information hiding. If it was my decision to make I would need to hear some really good arguments to prevent me from removing them from the language altogether.