Re: Trigger action at exit?

[John Trammell]

On Mon, Mar 3, 2008 at 3:40 PM, Ludovic Courtès <address@hidden> wrote:
>  No, you would want to enclose the body of your code in `catch', i.e.,
>
>   (catch 'quit
>      (lambda ()
>        ;; your code
>        ...)
>      (lambda (key . args)
>        ...))
>
>  Anyway, this isn't good, because if your code doesn't call `exit', then
>  the `quit' exception is never raised.
>
>  `dynamic-wind' provides a better solution, since the "handler" is called
>  whenever the dynamic extent of the body is left:
>
>   (dynamic-wind
>     (lambda ()
>       ;; nothing to do here
>       #t)
>     (lambda ()
>       ;; the code body
>       ;; ...
>       )
>     (lambda ()
>       ;; the "exit guard" or "handler", which gets called whenever the
>       ;; body's extent is left, including via an `exit' call
>       ))
>
>  If your code uses C code that may exit in other ways (e.g., C code that
>  calls `exit(3)' or similar), then you need an `atexit' similar to what
>  Neil described.

Thanks, this conversation is really clarifying things for me.
Unfortunately as written neither solution is really what I'm looking
for; since I haven't been too clear I'll try to explain.

Perl uses a unit testing framework written around the "Test Anything
Protocol" aka. "TAP" (see www.testanything.org).  At its simplest, TAP
consists of a header describing the number of tests to run (the
"plan"), then the results of the tests as they are run.  One option is
to tell the test framework you don't know how many tests you'll be
running, and have it display the number at the end of the run ("no
plan").  Here's some working code that generates TAP output:

(use-modules (test TAP estry))
(load-from-path "atom_p.scm")
(plan 4)
(ok (atom? 'abc))
(is (atom? 'abc) #t)
(isnt (atom? '()) #t)
(isnt (atom? '(foo)) #t)

The contents of test/TAP/estry.scm are about what you'd expect--some
local state, plus exporting the helper functions (plan, ok, is, isnt,
...) to the caller.

I'd like to be able to replace "(plan 4)" with "(no-plan)" and have
the module register some handler to be run at script exit (or object
destruction, or something else) that would check state, see we need to
output a terminal plan, and do so.  I'm not too keen on cluttering up
the script with a lot of extra code.

Alternatively, we could go OO if I can hook in a handler to the guile
object destruction process.  Is that an option?