Path: utzoo!attcan!uunet!mcvax!cernvax!ethz!aplusl
From: aplusl@ethz.UUCP (Albert Meier)
Newsgroups: comp.lang.modula2
Subject: Termination of program
Summary: How M2 programs could be properly terminated
Message-ID: <492@ethz.UUCP>
Date: 1 Jul 88 17:22:48 GMT
Organization: ETH Zuerich
Lines: 123

Expires: 
References: <491@ethz.UUCP>
Sender: 
Reply-To: aplusl@bernina.UUCP (Albert Meier)
Followup-To: 
Distribution: 
Organization: ETH Zuerich, Switzerland
Keywords: 

Together with the mail today came another document from Pat Terry about
Termination of Programs. We think it is interesting enough to be
published because it shows an easy way. For further ideas refer to the
paper from John Gough for the Nice meeting. There has not been any
discussion in our Swiss committee nor in our technical group so this is
just a document from SA.

To:   Persons interested in termination code in Modula-2
 
From: Pat Terry, Computer Science, Rhodes University, GRAHAMSTOWN 6140
 
_______________________________________________________________________________________________________________
 
 
Although an IMPLEMENTATION MODULE makes provision for "hidden"
initialisation code in Modula-2 programs, there is no simple
standardised way of providing termination code.  In UCSD Pascal, 
and in Pascal-Plus this could be done as follows
 
 
         BEGIN  (*main code of unit, envelope or whatever*)
           Initialise;
           ***;
           Terminate
         END.
 
Here the *** essentially stands for "execute all the code of the 
client". 
 
This is very useful, especially for such obvious tasks as 
closing scratch files, restoring interrupt vectors and so on.
 
One could not introduce exactly the same effect into Modula-2 
without a syntactic change of a fairly radical nature.  However,
one could achieve a useful compromise on the lines of the 
following:
 
 
        DEFINITION MODULE Somewhere;
          
          PROCEDURE TERMINATE (P : PROC);
          (* Hook P into the chain of procedures to be called later
             when a client program terminates for any reason - normal 
             termination, execution of HALT, or run-time error *)
 
        END Somewhere.
 
The way in which this could be used is exemplified by the 
following:
 
        IMPLEMENTATION MODULE Gizmo;
 
          IMPORT Somewhere;
 
          PROCEDURE CleanUp;
            BEGIN
              (* Termination code *)
            END CleanUp;
 
          (* rest of module *)
 
          BEGIN (*Gizmo*)
            Initialise;
            Somewhere.TERMINATE(CleanUp)
          END Gizmo.
 
 
Various systems already provide something on these lines.  For 
example, the following micro-computer implementations known to 
me provide:
 
MacMeth                    System.TermProcedure (term : PROC;
                                                 VAR done : BOOLEAN);
 
Logitech Modula-2/86       System.TermProcedure (P : PROC)
 
Logitech Modula-2 ver 3    RTSMain.InstallTermProc (P : PROC)
 
JPI Modula-2               Lib.Terminate (P : PROC; VAR Q : PROC)
 
Volition Modula-2          Program.SetEnvelope (init, term : PROC; 
                                                mode : EnvMode);
 
FTL Modula-2               Termite.TermiAnt (P : PROC);
 
 
These are not all equivalent, however.
 
It would seem that such routines cannot easily be written without 
some measure of compiler support, or at least the ability to get 
to a lower level than normally possible from user programs.  One 
important point is that the routines linked in this way should be 
called (so far as possible) no matter how a program terminates.
The qualifier "so far as is possible" arises from the fact that 
some errors might leave the system in a situation from which it 
could not recover adequately to handle the list of termination
procedures.  Since one is not required to use HALT explicitly - 
in some systems it is regarded as equivalent to a run-time error 
to do so - this sort of effect becomes difficult to achieve for 
oneself. 
 
This might suggest that something like TERMINATE (P : PROC) 
should be one of the standard pervasive identifiers. 
 
Finally, it should be noted that what is being suggested is a 
"minimal" facility.  It does not attempt to cover the more 
difficult subject of exception handling, which is receiving more 
detailed analysis elsewhere. 
 
 SSS   N   N  V   V      SNV       SWISS STANDARDIZATION BODY
S      NN  N  V   V      149/UK2   Programming Languages
 SSS   N N N  V   V      Chairman  Albert Meier, CH-8906 Bonstetten
    S  N  NN   V V       . E-mail  aplusl@ifi.ethz.(ch/UUCP)
 SSS   N   N    V                  ...mcvax!cernvax!ethz!aplusl