[Oberon] Tidyness of iteration.

[Jörg Straube]

Hi Wojtek

Indeed, the Oberon system has no "shutdown" command.
But you could program one if you want :-)
Oberon allows you to install own tasks in the eternal loop.
So, your program that needs to close files and has to write buffers, could install those tasks in the Oberon loop.

After the task is installed, the Oberon loop will regularly (e.g every second, or every minute, you decide) call your cleanup procedure. BTW the carbage collector freeing unused heap memory in the background uses the same mechanism.

You mentioned the ASSERT command. This command raises a trap, basically it calls a procedure somebody installed as trap handler.
You could program your own trap handler (look at System.Trap to see an example) that calls your cleanup procedure before calling Oberon.Reset.
Oberon.Reset sets the Oberon system back to its starting condition.

br
Jörg

Am 17.11.2016 um 17:45 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:

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