[Oberon] Procedure variables and local procedures
chris at gcjd.org
Fri Sep 29 20:51:24 CEST 2017
> 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
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
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!
Thanks for your thoughts.
More information about the Oberon