[Oberon] SYSTEM Modules

[Jörg Straube]

All

If I understand your reasoning correctly, you say: I happen to be a low level programmer and am confronted with the fact I have to write a lot of SYSTEM qualifiers in my code. As I don’t like that, lets modify the language.

Now imagine I happen to be a programmer of a GUI and my code is full of Display qualifiers. I could for sure find a similar procedure as your InitClocks with 30 SYSTEM calls where I use 30 calls to Display procedures in a row.
As I don‘t like that, lets modify the language.

In the first case I would propose IMPORT S:=SYSTEM, for the second programmer I would propose IMPORT D := Display

I like the Oberon idea of fully qualified names. The Modula syntax where you dequalify your names during the IMPORT by a list of procedures opens up a lot of confusion while maintaing different sources, with different dequalifying IMPORT lists.

Just my 2cents
Jörg

> Am 11.11.2018 um 05:22 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
> 
> Chris:
> 
> I like your observation that all these VAL, ORD, CHAR, ASR, LSL and ROR are on an equal footing. Why should some of these be SYSTEM, while others not? All of them are meant for some low level manipulation. And we just learned that DIV and MOD can be much the same way.
> 
> I can see that DIV and MOD are primarily related to integer math, and their bit shifting functionality is a byproduct. So here I can see why DIV and MOD are operators and why they belong to the language. But all these other three letter acronyms? Why are they promoted to the language proper?
> 
> And do not forget this LED please! If there is LED then BEEP should also be there. Adding BEEP to the language would not look serious to me. 
> 
> So it would make sense to make a decision that all these three letter things (other than DIV and MOD) belong to SYSTEM rather than just a few of them.
> 
> Wojtek
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon