[Oberon] SYSTEM Modules

[Chris Burrows]

> -----Original Message-----

> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of

> Jörg Straube

> Sent: Sunday, 11 November 2018 6:35 PM

> To: ETH Oberon and related systems

> Subject: Re: [Oberon] SYSTEM Modules

> 

> All

> 

> If I understand your reasoning correctly, you say: I happen to be a

> low level programmer and am confronted with the fact I have to write

> a lot of SYSTEM qualifiers in my code. As I don t like that, lets

> modify the language.

> 

> Now imagine I happen to be a programmer of a GUI and my code is full

> of Display qualifiers. I could for sure find a similar procedure as

> your InitClocks with 30 SYSTEM calls where I use 30 calls to Display

> procedures in a row.

> As I don t like that, lets modify the language.

> 

> In the first case I would propose IMPORT S:=SYSTEM, for the second

> programmer I would propose IMPORT D := Display

> 

> I like the Oberon idea of fully qualified names. The Modula syntax

> where you dequalify your names during the IMPORT by a list of

> procedures opens up a lot of confusion while maintaing different

> sources, with different dequalifying IMPORT lists.

> 

> Just my 2cents 

> J rg

> 

 

Not exactly. I'm questioning why some global built-in procedures have to be qualified whereas others don't. How cumbersome would it be if we had to say GLOBAL.INC(i, 1) or ch := GLOBAL.CHR(i)? The definition of SYSTEM has diminished over time to the point where it is now almost redundant. 

 

Comparing SYSTEM calls to Display calls is like comparing apples to oranges.

 

Global built-in / SYSTEM procedures are very different to procedures contained in library or application modules. You cannot necessarily apply the same rules to both. Built-in procedures have one or more of the following attributes:

 

1.  Variable number of parameters

2.  Implemented as inline code

3.  Bypass normal type-checking code

4.  Bypass normal range-checking code

 

And, above all:

 

5.  They can only be modified / added to by modifying the compiler

 

Whenever I have had a situation where there could be many calls to the same imported module (e.g. Texts, Display) etc, I wouldn’t use aliases just to save typing. 

 

e.g. if I see repetitive code like this

 

      Files.ReadInt(R, data); Out.String("fixP = "); Out.Int(data, 8); Out.Ln();

      Files.ReadInt(R, data); Out.String("fixD = "); Out.Int(data, 8); Out.Ln();

      Files.ReadInt(R, data); Out.String("fixT = "); Out.Int(data, 8); Out.Ln();

      Files.ReadInt(R, data); Out.String("entry = "); Out.Int(data, 8); Out.Ln();

 

I am likely to refactor it to something like this: 

 

     PROCEDURE ShowFixup(r: Files.Rider; label: ARRAY OF CHAR);

     VAR

       data: INTEGER;

     BEGIN

       Files.ReadInt(r, data); Out.String(label); Out.String(" = "); Out.Int(data, 8); Out.Ln();

     END ShowFixup;

 

     ShowFixup(R, "fixP");

     ShowFixup(R, "fixD");

     ShowFixup(R, "fixT");

     ShowFixup(R, "entry");

 

The dozen references to Out are reduced to four.

 

Regards,

Chris Burrows

CFB Software

http://www.astrobe.com

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20181111/c1db1a51/attachment.html>