trace

[Jonathan A Rees <JAR@MIT-MC.ARPA>]

    Date: Wednesday, 20 Nov 85 16:52:06 PST
    From: Will Clinger <willc%tekchips%tektronix.csnet at CSNET-RELAY.ARPA>

    A long time ago Jonathan asked what people did to trace
    self-recursive calls to FACT when FACT is defined using the (DEFINE
    (FACT ...) ...) syntax.  It seems to me there are three obvious
    implementations of the trace facility, with three distinct
    semantics:

    1.  Trace the variable.  That is, (TRACE FACT) is a special form
    that turns into something like (SET! FACT (MAKE-TRACED FACT)).  This
    is how most implementations seem to do it, though in some of them
    (e.g. MacScheme) TRACE is a procedure and you have to say (TRACE
    'FACT).

    The disadvantage is that the self-recursive calls are not traced.

    ...

Thanks for your exposition.  I was too lazy to articulate all this when
I sent out my earlier message, but it's what I had in mind.

For alternative 1., note that the procedure MAKE-TRACED could, in
principle, "look inside" the code for the procedure and produce a new
procedure, with new code, whose self-calls were traced.  This still does
not imply a side-effect on the traced procedure or on its code.

I think all three alternatives have their place, but that (1) is
probably the safest and most useful, and if MAKE-TRACED did as I
suggest, I think it would be adequate.  The others are potentially
dangerous, especially when applied to "system" procedures like
WRITE-CHAR.

[Of course this is implementation-specific; I'm certainly not suggesting
that a standard debugging interface should exist.]