[gclist] Finalizer history

[Charles Fiterman]

About 1972 I built a multitasking forth variant for
machine control. Every control block was allowed
an always block to clean up after it. An inner
block could issue an exit to leave or continue
some distant outer block. Tasks could be terminated.

When a block started it was guaranteed that its
always block would be executed. This guaranteed
things cleaning up after themselves which often
meant turning off motors.

The system had no malloc equivalent, all storage
was either static or stack. Stack space for each
possible task was allocated staticly. Programs
were in EPROM.

When I think about finalizers needing to be run
promptly and surely this is what is in the back of
my mind.

I'm interested in the notion of execution frames
being objects on the heap. By objects I mean able
to accept a variety of messages such as resume.
Function definition could include the kinds of
messages an execution frame could take. This notion
seems to greatly expand the flexability of a
programming language.

I call the messages an execution frame can accept
export parms. After the frame is built but before
it is executed its export parms become visable
by name to the parser. Messages to the execution
frame can be seen and sent. After the pre execution
export parms are sent the execution frame is executed
and then the post execution export parms are sent.

So in this scheme an execution frame is so elaborate
an object that it might as well be collectible to.