trace

[Bill Rozas <JINX%MIT-OZ@MIT-MC.ARPA>]

Some comments about your TRACE implementation classification:

I do not think that the disadvantage you point out for option 2 is
undesirable.  TRACE cleary implies a side effect since the behaviour
of some procedure changes.  The point you make is no worse than the
fact that if A and B have the same (eq?) pair as their value, the
effect of SET-CAR! on one will be observed on the other also.  Note
also that an optimizing compiler may decide to invoke FACT on
self-recursive calls bypassing the closure (by directly branching to
the entry point, for example), so this implementation is not
guaranteed to work on self-recursive calls either.

3 is not unreasonable either.  There are situations in which this is
the desired behaviour.  Consider the case of a procedure that returns
procedures, so there may be many instances of these procedures around.
This is common in message passing situations.  It is occasionally
useful to be able to observe the invocations of all these procedures,
rather than the particular one we have a handle on.  A TRACE option
which modifies the code would accomplish this task under most
circumstances.

In the presence of "hairy" enough compilers all implementations lose.
A compiler may decide, for example, to have 27 entry points to a given
procedure, each used by something else, and the TRACE facility would
have to know a fair amount about the actual code generated to be able
to "trap" all possible paths.  Even worse if it decides to open code
the procedure in some places.  The only possible solution in the worst
case is modifying the source code, recompiling and re-generating the
running environment, but even this may not work if the runtime
behaviour depended on events which cannot be duplicated.

MIT-Scheme has switched back and fourth between implementations 2 and
3.  As far as I know it has never used implementation 1.  I like
implementation 2 better, but there are occasions when 3 is desirable,
and the current implementation is implementation 3.  It is also more
likely (though not without problems) that we can make this work even
in the case of compiled code.