Nested procedures

[Stefano]

According to Oberon 2007 report 2011 revision

4. Declarations and scope rules
...
The scope extends textually from the point of the declaration to the end
of the block (procedure or module) to which the declaration belongs and hence to which the object
is local.
...

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 variables and
of those objects that have the same name as an object declared locally).
...

the global or strictly local access for nested procedures is relaxed

In following code Astrobe raise Error: non-local not accessible when trying to access the x variable

Is that correct?

Code: Select all

MODULE Nested;

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

[cfbsoftware]

... In following code Astrobe raise Error: non-local not accessible when trying to access the x variable

Is that correct?

Yes. That is what it is designed to do.

the global or strictly local access for nested procedures is relaxed

Why do you say that? As far as I can see just the opposite is true. In the Oberon Report Revision 1.12.2007 it states:

... the objects declared in the environment of the procedure are also visible in the procedure (with the exception of those
objects that have the same name as an object declared locally).

Your example would have worked according to this definition. However, a restriction on access to local variables that are not strictly local was introduced later. The earliest relevant copy of the report that I have is Revision 27.6.2008:

... the objects declared in the environment of the procedure are also visible in the procedure (with the exception of variables and
of those objects that have the same name as an object declared locally).

This restriction remains in Revision 22.9.2011 which is currently implemented in Astrobe.
For the reasoning behind this restriction refer to the document by Niklaus Wirth titled: On Programming Styles

[kevinhely]

Hi

... the objects declared in the environment of the procedure are also visible in the procedure (with the exception of variables and
of those objects that have the same name as an object declared locally).

Does this formulation not rule out access to global variables?

K

[cfbsoftware]

If you read the Language Report in isolation you could indeed come to that conclusion. You might even be able to get away with implementing a version of Oberon with that restriction and claim that it conformed to the report. However, I doubt that it would be very popular - even though I did make a similar proposal to Wirth some time ago!

Read the report in conjunction with the associated documentation (see the reference in my previous post) for an insight into the intention behind this restriction. Also, if you reread that paragraph in the context of the most recent subject mentioned in the previous paragraph of the report i.e. nested procedures you might come to a different conclusion.

[kevinhely]

Oh, I've read the associated documentation and I certainly don't think it would make sense to implement local-only access to variables. I can live with the strictly-global-or-strictly-local restriction but, once again, the wording of the report leaves a lot to be desired.

Thanks,
K

[kevinhely]

Hi,

I contacted Prof. Wirth and he stated that the report does not restrict variables to strictly-local-or-strictly-global access:

In Oberon-7 "intermediate level" objects are permitted. However, in my new implementation they cannot be accessed, except from the level in which they are declared.

Regards,
K.

[dsar]

I contacted Prof. Wirth and he stated that the report does not restrict variables to strictly-local-or-strictly-global access:

In Oberon-7 "intermediate level" objects are permitted. However, in my new implementation they cannot be accessed, except from the level in which they are declared.

Uhm, I'm confused then, because I was convinced of the fact that the new Oberon report had this restriction.
Also in the paper On Programming Styles there is: "We have introduced the same restriction in the revision of the language Oberon in 2007."
He talks about language description, not compiler implementation

[cfbsoftware]

I was convinced of the fact that the new Oberon report had this restriction

I am also convinced that is what is specified in the report titled "The Programming Language Oberon" Revision 22.9.2011 that is currently supplied with Astrobe.

Astrobe v4 Oberon currently does allow access to "intermediate level" objects. It does not allow access to "intermediate level" variables. I believe that they are specifically excluded in Revision 22.9.2011 of the report.

What you can be sure of is that Astrobe v4 Oberon only allows access to variables that are either "strictly global" or "strictly local".

We might reconsider that behavior if a future version of the report removes the additional qualification "of variables and" from the phrase "(with the exception of variables and of those objects that have the same name as an object declared locally)".

[hansklaver]

(...) Astrobe v4 Oberon currently does allow access to "intermediate level" objects. It does not allow access to "intermediate level" variables. I believe that they are specifically excluded in Revision 22.9.2011 of the report.

What you can be sure of is that Astrobe v4 Oberon only allows access to variables that are either "strictly global" or "strictly local".

We might reconsider that behavior if a future version of the report removes the additional qualification "of variables and" from the phrase "(with the exception of variables and of those objects that have the same name as an object declared locally)".

I'm puzzled by the term "intermediate level" in this context. Could anyone give code examples of an "intermediate level" object and of an "intermediate level" variable?

To find out what Wirth could have meant by this term I looked through some code that he wrote and published relatively recently (2007 and later). I noticed that even Wirth cannot avoid entirely the use of global variables that are changed locally within procedures. E.g. in his description of An Oberon Compiler for the ARM Processor on p. 33 he shows "a rudimentary handler for the ARM’s IRQ interrupt. It merely increments a global counter":

Code: Select all

MODULE M; 
  IMPORT SYSTEM;
  CONST IntVec = 18H; StkOrg = 800H;    
  VAR count: INTEGER;

  PROCEDURE Handle [4];
  BEGIN INC(count)
  END Handle;

BEGIN count := 0;
  SYSTEM.PUT(18H, (SYSTEM.ADR(Handle) - IntVec - 8) DIV 4 + 0EA000000H); 
  SYSTEM.LDPSR(0, 0D2H); SYSTEM.SP := StkOrg; (*set stack pointer*) 
  SYSTEM.LDPSR(0, 53H); (*enable IRQ interrupt*)
  .....
END M.

Other examples of the extensive use by Wirth himself of global variables that are accessed from within procedures can be found in the Oberon modules for the Oberon-0 compiler described in the 2011 version of his book on Compiler Construction (OSP.Mod, OSG.Mod, OSS.Mod). To be fair this code was written before the times of Oberon-07, but to presume that Wirth has always used a coding style that avoided the use of global variables is not entirely accurate.

IMHO it is good programming style to try and avoid the use of global variables, but to preclude their use entirely is probably too restrictive.
I wonder whether the code for the Astrobe Oberon compiler avoids the use of global variables or not?

Regards,

Hans Klaver

[cfbsoftware]

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.

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 *)
    VAR
      vt: T; (* local variable hides global with the same name *)

    PROCEDURE Level2;
    VAR
      vt1: T; (* Strictly local variable declared using an intermediate local type is OK *)
    BEGIN
      v := 99;       (* Global variable is OK *)
      vt[0] := TRUE; (* Intermediate local is NOT OK *)
      vt1[0] := TRUE (* Strictly local level2 variable is OK *)
    END Level2;
  
  BEGIN (* Level1 *)
    v := 99;      (* Global variable is OK *)
    vt[0] := TRUE (* strictly local level1 variable is OK *)
  END Level1;    
  
  
BEGIN
  v := 99;        (* Global variable is OK *)
  vt[0] := 99.0;
END Nested.

The implementation of globals in the Oberon compiler used in Astrobe conforms to Revision 22.9.2011 of The Programming Language Oberon report.

i.e. Astrobe allows full read/write access to all global variables in the module in which they are declared.

Structured global variables (e.g. ARRAYS and RECORDS) cannot be exported from the module in which they are declared; scalar global variables (e.g. INTEGERs, BOOLEANs etc.) can only be exported in read-only mode.

If you want to modify a global variable which is declared in another module you can only do it via a procedure which is exported from that module.