[Oberon] SYSTEM Modules
chris at cfbsoftware.com
Sun Nov 11 00:17:59 CET 2018
> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Paul Reed
> Sent: Saturday, 10 November 2018 10:03 PM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] SYSTEM Modules
> I thought as a halfway-house and keeping with the spirit of the
> language you might use WITH SYSTEM DO... but based on experience with
> Delphi I'm not overly enamoured with WITH anyway, I wrote about that
Delphi's WITH is scoped to a RECORD. It doesn't need to be that fine-grained
in the case of SYSTEM. I believe that module scope is sufficient.
Also the WITH syntax lends itself to be used with any IMPORT. I would want
it to be restricted to SYSTEM - any other relaxation of the module qualifier
rules sounds nice in theory but becomes a maintenance nightmare. E.g. in
Project Oberon you can search for Files.Write and the results won't include
Texts.Write. When you're maintaining an application with 100,000s lines of
code composed of several hundred modules you really appreciate
I would argue that unqualified SYSTEM references are a special case. The
distinction between built-in procedures like ORD and SYSTEM procedures like
VAL, has become more blurred. Now that CHAR is implementation-defined, ORD
is now implementation-dependent. Should that now be a SYSTEM function?
> Given that you are losing a lot of safety when using SYSTEM anyway,
> I'm wondering if removing the requirement for SYSTEM is a step in the
> wrong direction. I'd like to see some of the code you think has
> readability problems, bearing in mind that readability is in the eye
> of the beholder.
Have a look at:
Now I think about it, perhaps all I need to do is make the new bitfield
procedures BFI and UBF built-in procedures rather than SYSTEM functions.
After all they are no more unsafe or less portable than ASR, LSL and ROR?
More information about the Oberon