Pat.Terry@p101.f19.n490.z2.fidonet.org (Pat Terry) (04/07/89)
In article <6380@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes >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. One way of looking at it, certainly "self consistent". >>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. >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. No, but x has to be "called", and so its "body" can call CleanUp each time this call is made, just before it "returns"? >As I remember, Pascal-Plus has something like the following syntax: Something like, certainly. But in Pascal Plus the "envelopes" are much more like "classes", and act as "templates" of which one then creates instances, as many as one likes/needs. The Modula-2 MODULE can't be replicated in quite the same nice way (which I take to be what you would really need for abstract state machines) The SetTermination proposal is in line with lots of M-2 - find a simple way of handling 90% of the cases with 10% of the effort needed for a larger language (and does not require a syntactic addition to the language as the Pascal-Plus *** statement would be). -- uucp: {mcvax!uunet,tektronix,sun!nosun}!oresoft!dawggon!2!490!19.101!Pat.Terry Internet: Pat.Terry@p101.f19.n490.z2.fidonet.org
rjh@cs.purdue.EDU (Bob Hathaway) (04/08/89)
In article <945.243C1EDF@dawggon.fidonet.org> Pat.Terry@p101.f19.n490.z2.fidonet.org (Pat Terry) writes: >In article <6380@medusa.cs.purdue.edu> >rjh@cs.purdue.EDU (Bob Hathaway) writes >>>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. > >>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. > >No, but x has to be "called", and so its "body" can call CleanUp each time >this call is made, just before it "returns"? Um, top-level modules are of the form: 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; x is a top-level module, y is a nested module and since the lifetime of a module is the lifetime of its surrounding environment, x's lifetime is the lifetime of the program and y's lifetime is the lifetime of x and transitively the lifetime of the program. If there is no termination code construct in modules, x.Terminate would have to be called at program termination by the main program and y.Terminate would have to be called by x.Terminate, all of which can be eliminated by a termination construct similar to the *** construct in Pascal-Plus and as shown above. The earlier example only applied to modules nested within procedures. >>As I remember, Pascal-Plus has something like the following syntax: > >Something like, certainly. But in Pascal Plus the "envelopes" are much >more like "classes", and act as "templates" of which one then creates >instances, as many as one likes/needs. The Modula-2 MODULE can't be >replicated in quite the same nice way (which I take to be what you would >really need for abstract state machines) The SetTermination proposal is in >line with lots of M-2 - find a simple way of handling 90% of the cases with >10% of the effort needed for a larger language (and does not require a >syntactic addition to the language as the Pascal-Plus *** statement would >be). I've implemented a class construct with initialization code, and termination code would be a trivial addition. I don't see why Modula modules are any different, the initialization code is invoked at program entry for top-level modules (with elaborate pragmas:-)) and at scope entry for nested modules and an anlogous sequence would occur for termination code. This is easier than invoking code for class instances on scope entry and exit because only a single module construct needs to be initialized and terminated and there is one less environment contour, that is there is no contour for each class instance. So, I think Modula-2 module termination code can "be replicated in quite the same nice way" as classes for abstract state machines, even easier. Bob Hathaway rjh@purdue.edu
Pat.Terry@p101.f19.n490.z2.fidonet.org (Pat Terry) (04/16/89)
In <6466@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes > Um, top-level modules are of the form: > > 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; > > x is a top-level module, y is a nested module and since the lifetime of > a module is the lifetime of its surrounding environment, x's lifetime > is the lifetime of the program and y's lifetime is the lifetime of x > and transitively the lifetime of the program. If there is no > termination code construct in modules, x.Terminate would have to be > called at program termination by the main program and y.Terminate > would have to be called by x.Terminate, all of which can be eliminated > by a termination construct similar to the *** construct in Pascal-Plus > and as shown above. But this can also be achieved - for these top level modules - by the suggestion that WG13 are now making, and which started this whole discussion. We seem to be talking in circles now or am I still missing something (sorry to appear dim)? > I've implemented a class construct with initialization code, and > termination code would be a trivial addition. I don't see why Modula > modules are any different, the initialization code is invoked at > program entry for top-level modules (with elaborate pragmas:-)) How elaborate? Do you/Can you do this all in standard modula-2 without compiler support, SYSTEM.fiddles and so on? -- uucp: {mcvax!uunet,tektronix,sun!nosun}!oresoft!dawggon!2!490!19.101!Pat.Terry Internet: Pat.Terry@p101.f19.n490.z2.fidonet.org