> you are right that the term "procedure inlining" describes my problem
more
> precisely than the word "macros" (although I feel there is some
overlapping in
> the meaning/usage/definition of those two terms).
Technically, these are different things. Also, you did not say what you
mean by "macros". C-style text substitution macros are very different
from Lisp-style macros.
> Also p. Wirth is right when he writes "Ultimately, the basic idea
behind every
> language is that it should serve as a means for communication."
> That probably means that source code should be in its most possible
human
> readable/understandable form to be able to communicate it to others. I
agree
> fully with this.
> But I hope he did not also mean by it that it should occur at the
expense of
> speed/space optimisation.
You could build a compiler that inlines your procedures. This would
increase their size in memory though. The Oberon Report leaves open,
which optimizations are built into compilers by their writers. Oberon
was also designed as a teaching language. You can only allow a certain
number of optimizations before their implementation details would start
to obfuscate the compiler's source code.
> >From all of the ETH oberon documents I have read so far I cannot
remember there
> was a mention of some procedure inlining in oberon compiler.
> Therefore I think there is neither manual nor automatic procedure
inlining built
> in oberon compiler.
> And as there are also no macros in oberon it means that when a
programmer writes
> a time critical application he has no other choices left than to write
repeating
> commands every time he needs to use them.
> And that makes at the end his source code less human
readable/understandable.
If you want procedure inlining so badly, you could modify the compiler's
source code to address this. It has less than 3000 lines of code, if I
remember correctly. You could introduce a special kind of comment like
(*<pragma inline>*) as a directive to have it generating corresponding
code, if you really consider the effort worthwhile.
> I do not know about the whole commercial sector but I am 100% sure
that certain
> commercial applications can be VERY, VERY time critical!
> For example every application for autonomous vehicles is a time
critical
> algorithm.
> If I would be at some company writing software for autonomous cars I
would
> probably for this reason not think of oberon as language of first
choice.
> And that's a pity because otherwise oberon is very good language.
That sounds ridiculous. Just don't write your routine in a high level
language, if it is so time critical. A faster CPU to run it would also
help. Most likely though, a fast implementation of a high level language
will do the job. And the Oberon Report doesn't prevent one from being
written. Or use a language that was designed with such applications in
mind, like Ada, which is syntactically very similar to Oberon.
