🚀 go-pugleaf

In article <904.24372D43@dawggon.fidonet.org> Pat.Terry@p101.f19.n490.z2.fidonet.org (Pat Terry) writes:
>Bob Hathaway has queried the need for providing "termination" code.  He   
>writes:
>>Why should procedures be called at program termination?  When the program
>>ends all space and resources should be freed anyway.
>
>The sort of situation I have in mind is where a library module opens files, 
>takes over interrupt vectors and so on.  If indeed the implementation is 
>such that the O/S environment is restored to *exactly* what it was when the
>program was set running, then there may be no need to provide this facility.
>Given that many implementations don't seem to do this (especially those on 
>microcomputers, where taking over an interrupt vector and not restoring it
>leads to chaos), some way of doing so seems a good idea.  Since detecting   
>the sort of activity just mentioned (or implementing it) may be done   
>deviously using SYSTEM functions, the need for a programmer to have an easy   
>hook into the termination chain is increased.
>

Ok, I saw termination code at module scope exit as a generalization of this
idea, with program termination code being specified as termination code for
the main program module.


>>I can see invoking termination blocks at module scope exit for abstract 
>>state machines or initialization code for runtime elaboration of Adt 
>>(opaque variable) declarations together with termination code for Adt 
>>scope exits but I don't see any need for termination code at program exit.
>
>I take this to mean you would also like to be able to write, for example
>
>      PROCEDURE x;
>        (*inner*) MODULE y;
>         . . .
>        BEGIN
>          Initialise;
>          SetTerminate(Cleanup)
>        END y;
>      
>        ...
>      END x;
>
>so that whenever x was called "Initialise" was invoked, and whenever x 
>returned "CleanUp" was invoked.  I don't think the WG13 effort has 
>considered this, and perhaps, for completeness, it should.  On the other  
>hand, the problem is solved by placing a call to CleanUp just before the  
>end of x.


Yes, this is what I meant.  However, for top-level modules serving as
abstract state machines there is no means for calling CleanUp just before
the end of x, since no x exists, and an explicit termination code section
is therefore required.  As an alternative, the main program termination code
could call a CleanUp procedure for each top-level module but this would have
an analogous drawback to calling top-level module initialization routines
from the main program instead of from each module initialization block, that
of tightly coupling modules.  Also, leaving initialization and termination
sequences to module clients introduces potential insecurities by not 
guaranteeing these sequences will be performed correctly, so module
initialization and termination blocks provide a simple and safe solution.  

As I remember, Pascal-Plus has something like the following syntax:


      MODULE x;
        MODULE y;
         . . .
        BEGIN (* y *)
          (* y. *)Initialise;
	  ***	      (* A termination block begins after *** *)
          (* y. *)Terminate;
        END y;
	. . .
	BEGIN (* x *)
        (* x. *)Initialise;
	***
        (* x. *)Terminate;
      END x;


Bob Hathaway
rjh@purdue.edu