[Oberon] SYSTEM Modules

[Frans-Pieter Vonck]

A suggestion:

Rule:

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

Greets,
F.P.





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 ...
> 
> 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
> 
> 
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related 
> systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon