Looking for clarification: local procedures cannot call local procedures, right?

[kevinhely]

Hi,

The following code:

Code: Select all

PROCEDURE P;

  PROCEDURE Q; (*local*)
    ...
  END Q;

  PROCEDURE R; (*local*)
  BEGIN
    ...
    Q
    ...
  END R;

END P;

is disallowed by the definition of Oberon07, that is, local procedure R cannot call local procedure Q, since the identifier Q is not local to R and not global. Is that correct? (The definition seems to suggest it is.)

Regards

[cfbsoftware]

Good question. Your example is currently allowed in both the Astrobe compilers and the Project Oberon compiler. However, the jury is out on this one. See the related discussion, Intermediate scopes in Oberon-07 in the ETH Oberon mailing List.

[kevinhely]

Ok, thanks for that. An interesting discussion. I need to get on that list!

[cfbsoftware]

Yes - I think you'd find it very interesting. There's nearly 20 year's worth of discussions in the archives:

http://lists.inf.ethz.ch/pipermail/oberon/

[cfbsoftware]

Having read that 2018 discussion again, one point that stands out is the statement from the preface of the Project Oberon 2013 book:

4. Objects declared in a procedure P are not accessible within a procedure Q that is itself local to P. That is, objects must be either strictly local or global in order to be accessible.

That statement predates the latest version of the Oberon Language Report but if it is still true then it confirms to me that your initial assertion is correct. Any Oberon programmer should keep that rule in mind if they want to ensure that their code is as portable as possible.

As far as I know, although the Astrobe compilers don't enforce that rule, none of the source code supplied with Astrobe breaks that rule. In fact I can't even think of any case where we have used nested procedures.

For further insights related to these issues refer to Chapter 12 Procedures and the Concept of Locality in Wirth's Compiler Construction book.

[kevinhely]

Thanks for that. Yes, from the latest revision of the report:

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

agrees with the quote you gave from PO2013, if the phrase "locally declared objects" means "objects declared local to the procedure". I think the preceding para:

All constants, variables, types, and procedures declared within a procedure body are local to the
procedure...

supports that meaning. (The quoted line from PO2013 is more direct, though!)

I agree with the point (I think you made in the discussion list) that the module concept more or less addresses what local procedures were good for. They are still nice to use occasionally, but I find that "overnesting" makes code harder to read.