[Oberon] Tidyness of iteration.

[Skulski, Wojciech]

> the one that never ends

The one that never ends should eventually end when one is shutting down the system. The files need to get closed, the buffers need to get written to disk, the network connections need to get closed. How is this accomplished in a design which never ends?

REPEAT
…
  IF (shutting_down) THEN 
    (*clean up the system*)
    HALT;
  END;
UNTIL FALSE

I checked in the Oberon-07 Report. HALT was eliminated. (How nice.) OK, then use ASSERT (FALSE). ASSERT should generally display a trap viewer. Shutting down the system by throwing the trap viewer? OK, in order to avoid seeing the trap we can turn off the display first. We will end up with a blank screen rather than the one saying "Goodbye, see you again." Is it not ugly? 

  IF (shutting_down) THEN 
    (*turn off the display and hide the trap from being seen!*)
    ASSERT (FALSE); 
  END;

Is there a way to gracefully shut down the system without the gimmicks? Shutting down is one of regular conditions and it needs to be supported in a regular and elegant way.

Wojtek
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Jörg [joerg.straube at iaeth.ch]
Sent: Wednesday, November 16, 2016 6:43 AM
To: 'ETH Oberon and related systems'
Subject: Re: [Oberon] Tidyness of iteration.

LOOP: R.I.P

Even the main Oberon loop (you know, the one that never ends :-) is programmed with
REPEAT
…
UNTIL FALSE

Jörg

From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Bob Walkden
Sent: Montag, 14. November 2016 20:35
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Tidyness of iteration.

(One must wonder about discarding REPEAT and WHILE and retaining LOOP with

strictly one EXIT.)

Er, definitely not. The read-ahead technique is very valuable in structuring the software to match the structure of the input stream. It's a key technique in Jackson Structured Programming, for example. It makes code a lot easier both to write and, perhaps more importantly, to read and understand. I can't tell you the number of programs over the years that I've had to deal with where the programmer didn't understand this and consequently ended up with a buggy, difficult-to-maintain mess.

The programming language RPGIII, at least when I used it in the 90s, had by default an automatic outer loop structure and you determined your position in the structure by means of bit-flags. It led to some really messy code, which although quick to write (partly because of in-built DB2) was difficult to support. Especially at 3:30 on a Sunday morning over a telephone dial-up.

If any of those are to be discarded, let it be LOOP, which encourages badly-structured code.

B