[Oberon] SYSTEM Modules

Frans-Pieter Vonck fp at vonck.nl
Mon Nov 12 10:44:51 CET 2018

A suggestion:


ADR, BIT, SIZE, PUT COPY GET can only be called in the module Kernel.Mod 
(Oberon system) and SYSTEM.Mod (embedded oberon)


Chris Burrows schreef op 2018-11-12 08:53:
>> -----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 ...
> 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
> 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
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related 
> systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon

More information about the Oberon mailing list