[Oberon] SYSTEM Modules

[Jörg Straube]

Yes, safe/unsafe is the definition with the very prominent exception of ORD.

The whole topic around „string, CHAR, CHR, ORD“ is - for me at least - not as elegant and simple as we would expect from NW.
If NW wants to restrict CHAR to ASCII then he should have mention it in the report. But just leave it to the implementation and provide an implementation-dependet function like ORD unqualified is „not nice“...

Jörg

> Am 11.11.2018 um 15:42 schrieb Richard Hable <informujo at aon.at>:
> 
>> On 11.11.18 12:03, Chris Burrows wrote:
>> 
>> I'm questioning why some global built-in procedures have to be 
>> qualified whereas others don't.
> 
> Isn't the distinction simple?
> 
> Un-qualified built-in procedures (e.g. INC) provide safe functionality;
> qualified build-in procedures (e.g. SYSTEM.PUT) provide unsafe and
> potentially unportable functionality—which should be visible as such
> within the source code and be avoided if possible.
> 
>> The definition of SYSTEM has diminished over time to the point where
>> it is now almost redundant.
> 
> If this has happened, we should try to make the distinction clear again...
> 
>> Global built-in / SYSTEM procedures are very different to procedures 
>> contained in library or application modules.
> 
> Of course they are! They are part of the language: an elegant solution
> to keep the syntax simple. Compare, for example, the simplicity of
> INC(x) and INC(x,7) to the strange C syntax of x++, ++x, and x+=7.
> 
> Richard
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon