[Oberon] *****SPAM***** Re: *****SPAM***** Re: Oberon-2 type bound procedure scope

[werner.heiz at gmail.com]

Yes, it is a question of restricting accesses the parser would naturally allow.

>From a compiler implementation point of view, banning access to intermediate variables does make a lot of sense, because it is expensive (static link!) and rarely used, while accessing types, constants and procedures are cheap.

>From a conceptional point of view, it is not so clean that certain intermediate scope accesses are allowed and others not. That may be the reason to ban also these (with the exception of calling the procedure itself).

Werner

-----Ursprüngliche Nachricht-----
Von: Oberon <oberon-bounces at lists.inf.ethz.ch> Im Auftrag von Joerg
Gesendet: Mittwoch, 13. Dezember 2023 20:55
An: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Betreff: Re: [Oberon] *****SPAM***** Re: *****SPAM***** Re: Oberon-2 type bound procedure scope

In addition to August‘s example with TYPE, NW’s compiler accepts this:

PROCEDURE P;
  CONST max = 100;
  PROCEDURE Q;
    BEGIN Out.Int(max, 0); Out.Ln END Q;
  END P;

The parser nicely nests the scopes.
The parser finds the variables in the intermediate scopes but the generator has the access restrictions to them.

br
Jörg

> Am 12.12.2023 um 22:46 schrieb werner.heiz at gmail.com:
> 
> Sorry, if I missed something, but if this local/global rule is 
> strictly applied without exception, recursive calls like this would not be allowed:
> 
> PROCEDURE P;  (*P is at scope level 0 = global scope *)
> 
>  PROCEDURE Q(n: INTEGER);  (* Q is at scope level 1 (local to P); n is 
> at scope level 2 (local to Q) *)  BEGIN
>    IF n > 0 THEN DEC(n); Q(n) END;   (* not allowed if rule strictly
> applied as Q (scope level 1) is called from scope level 2 *)  END Q;
> 
> BEGIN (*P*)
>  Q(10);
> END P;
> 
> I'm currently working on an Oberon compiler just for fun, and I think 
> this should be allowed.
> 
> Werner Heiz
> 
> -----Ursprüngliche Nachricht-----
> Von: Oberon <oberon-bounces at lists.inf.ethz.ch> Im Auftrag von August 
> Karlstrom
> Gesendet: Mittwoch, 13. Dezember 2023 10:27
> An: oberon at lists.inf.ethz.ch
> Betreff: Re: [Oberon] *****SPAM***** Re: *****SPAM***** Re: Oberon-2 
> type bound procedure scope
> 
> On 2023-12-12 10:02, Diego Sardina wrote:
> [...]
>> ...however since then only strictly local and strictly global objects 
>> are
> available to a procedure.
> 
> Indeed, this has been confirmed by Niklaus Wirth. For instance I asked 
> him about the validity of the following procedure:
> 
>    PROCEDURE P;
>       TYPE T = INTEGER;
> 
>       PROCEDURE Q(x: T): T;
>       RETURN 0
>       END Q;
>    END P;
> 
> His reply was "You are right. Your procedure Q should be diagnosed in 
> error."
> 
> As mentioned before, the Project Oberon 2013 compiler does not fully 
> conform to the language report. I don't know if it's due to lack of 
> time to make the changes to the compiler or if he want's the implementation to be different.
> 
> 
> August
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related 
> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related 
> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon