🚀 go-pugleaf

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.

>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.


         


--  
uucp: {mcvax!uunet,tektronix,sun!nosun}!oresoft!dawggon!2!490!19.101!Pat.Terry
Internet: Pat.Terry@p101.f19.n490.z2.fidonet.org