[Oberon] Why macros were not implemented in oberon language?
nyaaa at nyaaa.de
nyaaa at nyaaa.de
Sun Jul 6 01:14:39 CEST 2014
> you are right that the term "procedure inlining" describes my problem
> precisely than the word "macros" (although I feel there is some
> 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
> language is that it should serve as a means for communication."
> That probably means that source code should be in its most possible
> readable/understandable form to be able to communicate it to others. I
> fully with this.
> But I hope he did not also mean by it that it should occur at the
> 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
> was a mention of some procedure inlining in oberon compiler.
> Therefore I think there is neither manual nor automatic procedure
> in oberon compiler.
> And as there are also no macros in oberon it means that when a
> a time critical application he has no other choices left than to write
> commands every time he needs to use them.
> And that makes at the end his source code less human
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
> commercial applications can be VERY, VERY time critical!
> For example every application for autonomous vehicles is a time
> If I would be at some company writing software for autonomous cars I
> probably for this reason not think of oberon as language of first
> 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.
More information about the Oberon