[Oberon] Procedure variables and local procedures

[chris]

Hello Paul,

> Of course, it is possible to debate these kind of things until the cows
> come home, and a lot of it in the end comes down to personal taste (more
> than people sometimes admit).

Indeed. That may be the case.

> But from my own personal experience with many languages over many years,
> in commerce and academia (more the former) I would have to say that I am
> interested in anything which reduces the number of places you have to
> look, to understand someone else's code.

Ok. From my experience local procedures are often small pieces of code 
that are factorized from the enclosing procedure. Probably 10 or 20 
lines of code with the local variables from the enclosing procedure 
just above in the text.

What I consider as strange is, that this breaks the analogy of lexical 
and logical scoping in the code. That's the way the module works and 
procedures should not be different for variables while types are 
accessible in the local procedure. That's too much irregularity for my 
taste.
I would be happier if local procedures would be removed at all. What 
use is left there other than hiding their name from the global scope?

> Prof. Wirth has, more than any other language designer I know, worked
> tirelessly to reduce both the "fanciness" of language tools, and also the
> number of things that go "clunk" behind the scenes.   I think he caters
> well to the experienced engineer who likes to carry only a small bag of
> tools, and for those who need to produce convincing and reliable
> implementations.

I agree in principle.
 
> As a good example of this reduction principle, but applied in reverse, is
> the tiny amount of implementation code required to add the BYTE data type
> to Oberon-07.  I was amazed by this, mainly because I didn't twig the
> difference between the type of a variable and its range.

I think I do not really get this. I had to read up about the  BYTE type 
which is not mentioned in the "Difference between Oberon-07 and Oberon" 
paper and not in the original language report Oberon-07 (2008).

 Oberon-07 (2015) says on BYTE:

"BYTE the integers between 0 and 255"
"The type BYTE is compatible with the type INTEGER, and vice-versa."

Very terse. How does it work in the reverse case. 

VAR b : BYTE; i : INTEGER;
	i := 1000; b := i;

Does it trap for overflow?

> And also multiple RETURN points from a function procedure!  This
> inscrutability prevented me from using Coco/R for a project (but I think
> it was there in a previous incarnation, I don't think Prof. Moessenboeck
> is to blame there!)  Like LOOP (with its multiple EXITs, handy for writing
> code but not for reading it), I again am very happy such features have
> been removed for Oberon-07.

I am not so happy, but in these two cases I can understand the argument 
of control flow with no hidden goto or several exit points from a 
procedure. This are indeed problems that are more than a matter of 
taste. In the end it's still a matter of taste if one accepts such 
problems in favor of convenience in the language or not.

Btw. another issue I see with Oberon-07 ist the removal of dynamic 
arrays. I cannot imagine how to write for example a string library or 
something like that without.

> Just my two cents, as my US friends would say!
> Paul

Thanks for your thoughts.

chris