Debugging, statics.

[alan geller]

In article <421 at aber-cs.UUCP>, pcg at aber-cs.UUCP (Piercarlo Grandi) writes:
> In article <9174 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn ) writes:
> ... a discussion of debugging by assertion versus by debugger ...
> ... then starting to talk about generators ...
> The moral is that
> by using statics (whether local or global) you can only write single instance
> generators, and that this single instance is indeed not reusable if you dont'
> refresh it.
> ...
> The real solution would be to have the state of the generator in a struct,
> explicitly identified as such. It would then be easy to convert it, as
> necessary, from relying on fork() to create new instances and refresh them,
> to instead doing it with low overhead program logic, as needed.
> In this way one could have as many independent instances of the generator as
> you want.  ...

Essentially, this amounts to creating what LISP programmers know as
a 'function closure', or 'closure' for short:  an object that consists
of a procedure, plus an associated execution environment (usually the
values of some procedure parameters).

It is indeed true that closures provide a useful, general-purpose
facility for defining things like multi-instance generators.  Also,
if you extend the data in the associated execution environment to
include some notion of 'program counter' and the local variables
of the procedure, then closures become a natural way to view coroutines
or process threads.

Unfortunately, LISP (and its relatives) is the only language I know
of that supports explicitly the notion of a closure (please, no flames
just to prove my ignorance here).  It is possible to provide such a
mechanism in C, but usually only for a specific special case -- in order
to provide a general-purpose function closure mechanism for C, you'd
have to monkey around a lot with either the operating system or the
run-time environment.

Alan Geller
Bellcore
...!{rutgers|princeton}!bcr!asg