If I compile this module with Niklaus Wirth's PO2013 compiler I get
"level error, not accessible":

MODULE M;

VAR x: INTEGER;

PROCEDURE P;
VAR x: INTEGER;

PROCEDURE Q;
BEGIN
x := 0
END Q;
END P;

END M.

Without the local declaration of x it compiles. I find this strange as
the compiler should only search the (strictly) local and the global
scope for identifier declarations. Can this restriction be found in the language report?

-- August

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2018-02-07 12:34, August Karlstrom wrote:

I find this strange, as the compiler should only search the (strictly)
local and the global scope for identifier declarations.

NW's PO2013 compiler apparently only disallows access to *variables*
declared in intermediate scopes. I was under the impression that no
objects (constants, types, variables or procedures) declared in an
intermediate scope is accessible. The language report says:

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

It doesn't say that non-variable objects from intermediate scopes are
visible in a procedure.

-- August

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Thursday, February 8, 2018 at 10:55:13 AM UTC-6, August Karlstrom wrote:

It doesn't say that non-variable objects from intermediate scopes are
visible in a procedure.

Why wouldn't they be?

AFAIK, the main advantage to this restriction (re: variables) is only simplified stack management.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Wednesday, February 7, 2018 at 5:34:12 AM UTC-6, August Karlstrom wrote:

Without the local declaration of x it compiles. I find this strange as
the compiler should only search the (strictly) local and the global
scope for identifier declarations. Can this restriction be found in the language report?

So you're not surprised it only handles strictly local or global.
You're just wondering why it even notices such a variable that
isn't accessible? So you want it to ignore it and not error out?

Who knows, maybe that is for better error-checking of old (presumably
Oberon-2) code being updated.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, February 10, 2018 at 3:18:12 AM UTC+10:30, rug...@gmail.com wrote:

Hi,

On Thursday, February 8, 2018 at 10:55:13 AM UTC-6, August Karlstrom wrote:

It doesn't say that non-variable objects from intermediate scopes are visible in a procedure.

Why wouldn't they be?

AFAIK, the main advantage to this restriction (re: variables) is only simplified stack management.

FYI the original question has since been reposted and a subsequent discussion resulted on the ETH Oberon Mailing list:

http://lists.inf.ethz.ch/pipermail/oberon/2018/011549.html

Regards,
Chris Burrows
CFB Software
http://www.astrobe.com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2018-02-09 17:45, rugxulo@gmail.com wrote:

Who knows, maybe that is for better error-checking of old (presumably Oberon-2) code being updated.

Maybe, but still it should compile. The alternative is to prevent object shadowing altogether and require unique names, as done for instance in
Eiffel.


-- August

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)