🚀 go-pugleaf

In the Oberon Operating System, much use is made of the controlled exit
facility of the HALT statement.  A HALT forces execution of the current
command to stop, resets the stack and returns to the Operating System
Command Loop (as well as opening a viewer containing a symbolic stack dump),
but does not affect the global state of loaded modules.  The module
containing the HALT instruction, as well as all other modules, will stay
loaded and its global variables will stay intact.  A new command may
then be executed.

Oberon abandons the notion of a PROGRAM altogether.  Any module may
export COMMANDS, parameterless procedures, which may be executed
directly from the operating system interface.  These Commands take their
parameters from global variables of the OS, which include such items as the
viewer containing the insertion point and a time-stamped list of text
selections.

Granularity of these commands is quite fine.  Typical commands display
the directory of a storage device, increase the font size of the text
last selected or compile the contents of the active window.  A user may
execute commands in any sequence, and may thus be working on completely
different problems in different windows at the same time (One-process
Multitasking).  No difference is made between Commands offered by the OS
and User Commands, which are thought of as extending the basic system. 

In this environment, the safe exit via HALT is of course ideal.  A HALT
will just terminate the current command; after taking some actions,
the user may try to execute the command again.  A typical application
might be a floppy disk driver - if no disk is inserted, it is quite
cumbersome passing up this information to the module originally instructed
to display a disk directory.  In Oberon, the disk driver module would
output an error message and execute a controlled halt.  The user may
then insert a floppy disk into the drive and retry the command.

-- Michael

Michael Franz   Computersysteme   ETH Zurich   Switzerland   franz@inf.ethz.ch