[Oberon] Intermediate scopes in Oberon-07

[Chris Burrows]

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> August Karlstrom
> Sent: Sunday, 11 February 2018 1:57 AM
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] Intermediate scopes in Oberon-07
> 
> On 2018-02-10 12:35, Chris Burrows wrote:
> > I can't think of any genuine use for an intermediate TYPE if
> intermediate variables of that type are inaccessible.
> 
> Or the types themselves (see below).
> 
> > Can you refer me to an existing real-world practical Oberon example
> where an intermediate type is accessed in a nested procedure?
> 
> Let's say we have a generic list data type which exports an abstract
> element type which can be extended in a client module. Suppose it
> also defines an Apply procedure which receives a procedure and an
> accumulator and applies the procedure on each element in the list and
> updates the
> accumulator:

Let's say ...?
Suppose ...?

That's as may be but what I want to know is if a real-world practical
example exists, not can someone dream up a hypothetical example. 

When examining Project Oberon I found one actual case where a local TYPE
*is* used out of 850 possible situations where it *could* have been used.
That one example is the Fonts module. The whole module is only 115 lines of
code and contains 4 procedures (including one nested) and one local TYPE
declaration. Unless I'm missing something the advantages of having those as
local rather than global (AND private) seems to me to be negligible. 

What I am really interested in is seeing some other existing code examples
where the advantage of having a local TYPE is much more obvious and an
alternative solution is not feasible.

> 
> A procedure P in a client module may make use of List and Apply to
> implement an algorithm. Let's say that the list contains integers and
> that the applicator is a simple Add procedure:
> 
> 
> The procedure P is not valid since IntegerElem and IntegerAcc cannot
> be accessed from the Add procedure. Therefore they have to be
> declared globally. This breaks the rule that each identifier should
> have the smallest possible scope.
> 

Given the information you have provided I would instinctively have
implemented PROCEDURE P as MODULE P. If that were the case then it is a
non-issue. I would not dream of using a nested procedure for this scenario.

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