[Oberon] SYSTEM Modules

[Chris Burrows]

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Richard Hable
> Sent: Monday, 12 November 2018 1:13 AM
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] SYSTEM Modules
> 
> > 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...
> 

Agreed. If SYSTEM is restricted to unsafe and not just non-portable then the distinction is somewhat clearer.

1. PUT and COPY are undeniably unsafe.

2. ADR and GET are readonly so they are not inherently unsafe. However, they are required for PUT and COPY to be effective so they are unsafe by association.

3. VAL falls into the category of it depends ...

SYSTEM.VAL(SET, intval), SYSTEM.VAL(CHAR, intval), SYSTEM.VAL(INTEGER, charval) are as harmless as ORD and CHR. All are inherently non-portable however.

On the other hand, SYSTEM.VAL(INTEGER, pointerVal) is as unsafe as ADR.

4. BIT and SIZE I'm not so sure about. They are both readonly so I can't see how you could corrupt a system with their use.

5. BYTE used to be SYSTEM.BYTE but has now been promoted to be unqualified.

6. ASH used to be unqualified at the same time as ROT and LSL were SYSTEM procedures. I always thought that was somewhat inconsistent. They are now replaced with ASR, ROR and LSL. None of which need to be qualified by SYSTEM.
 
Considering all of that I believe that the BFI and UBF bitfield procedures I am proposing to introduce are no more unsafe than ASR, ROR and LSL. Consequently they should not need to be qualified with SYSTEM.

Now the language report explicitly accepts that 'individual implementations may include in their module SYSTEM additional definitions'. So adding these is not considered 'changing the language'. What I am not so sure about is whether the inclusion of additional non-system built-in procedures like BFI, UBF, BITS (i.e. SYSTEM.VAL(SET, intval)) would be considered to be 'changing the language'.

However, as the language report freely admits that the RISC5 compiler includes the addition non-SYSTEM functions UML, SBC, ADC and LED that leads me to assume it that it is OK for others to do so as well - presumably as long as they are clearly documented as 'implementation-specific extensions'.

Regards,
Chris Burrows
CFB Software
http://www.astrobe.com