[Oberon] Why macros were not implemented in oberon language?
lab.eas at gmail.com
Tue Jul 8 06:42:46 CEST 2014
Let's addreess the OP's repeated claim for 'his perceived need' for macros.
> certain commercial applications can be VERY, VERY time critical!
OK, here's an example:
imagine a <rectangle>: ABCD, which needs it's <corners pulsed>, repeatedly
in a cycle to 10% accuracy:
You use dedicated hardware for this - still.
For a longer time scale, you may be able to inline-machine-code, with
NOPs to pad-out extra delays.
ETHO is not designed for this - nor for slicing bread.
Humanity [as reflected by the market] needs ETHO's facilities.
Eg. when I'm 3 screens into reading my gmail, I shouldn't need to
lose my place and scroll up to the top [or bottom = redundant duplication]
to find the required-function amongst a pile-of garbage.
ETHO has a *CONSISTENT* MenuFrame which is always visible/accessible.
] Ultimately, the basic idea behind every language is that it should serve
] as a means for communication. This means that partners must use and
] understand the same language.
Yes, communication between humans.
The big cost wastes come from human effort to manage spurious complexity,
for which macros/in-line-code have nothing to contribute.
== Chris Glur.
On 7/7/14, Alexander Iljin <ajsoft at yandex.ru> wrote:
> Hi, all!
>> In a high level language, like Oberon, it doesn't make sense to have two
>> constructs with the same semantic, i.e. two equal procedures P and Q
>> (normal and inline) will exhibit the same behaviour in the entire program.
> Also, please keep in mind, everyone, that in the context of dynamically
> loadable (and discardable) modules you really don't want to inline a
> procedure that you've imported from another module. Because if that other
> module happens to change the procedure afterwards, you'll have the old copy
> in your code.
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon