TRACE Proposal (Version 2)

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

Several questions and comments:

1. Common Lisp does not currently require implementations to perform a
trace if the function in question has been "open coded", which category
may include compiled self-calls that do not go through the
symbol-function cell, etc.  It should be made clear that this
modificaiton does not alter that provision.

2. It should be made clear that what is being traced in the case of a
macro is the call to the macro-expansion function, and not the execution
of the resulting code.  Trace would print the calling form going in and
the expanded form being returned.  I found the wording in the proposal a
bit confusing on this point.  An example would help.  Also make clear
that if macro-memoizing is going on, subsequent execution of the same
expansion code will not be traced.

    Current practice:

    There is currently no way to trace SETF functions, aside from
    macroexpanding a SETF form and using the resulting name in a
    TRACE macro invocation. There is currently no way to trace macroexpansion
    functions when they are invoked through their global names, except through
    complicated use of *MACROEXPAND-HOOK*.

Make that "no way that is standard across all implementations".  Some
implementations do provide some of these services.

    Adoption Cost:

    The proposed syntax is upwardly compatible with the current Common Lisp
    syntax. It will require the addition of function specification parsing
    and wrapper code to trace SETF function executions and macrofunction
    executions. When the Common Lisp Object System is fully implemented,
    wrapper code for tracing method execution will also be required.

Can we assume that the Xerox people will put the necessary hooks into
the method-dispatching machinery?  This would considerably reduce the
implementation cost for those of us who are using PCL as the basis for
our CLOS implementations.

    Cost of non-adoption:

    Programmers will have to continue using a complicated set of Lisp
    commands to arrange for SETF function and macrofunction tracing.
    When the Common Lisp Object System is fully implemented, programmers
    will have to use metaobject protocol functions to arrange for tracing.

This is wrong, I think.  The real cost is that implementations will
provide this functionality in varying forms and to varying degress, thus
making it harder for users to move between one Common Lisp system and
another.  A few implementations may blow this off altogether, in which
case their users will be screwed as described above.

    Benefits:

    Allow programmers to obtain information on individual method
    invocations, and on SETF function and macrofunction invocations.

... in a uniform way across all implemenations.

    Conversion Cost:

    Minor re-write of the TRACE and UNTRACE macros, and supporting wrapper
    generating functions.

It is possible that some implementations have made extensions to TRACE
that are incompatible with this proposal.  The only problem I can see
for those of us who currently allow a list of a function name and
options in place of simple symbols is that now it would be ambiguous if
someone wanted to trace invocations fo the SETF macro.  We'll just
declare that illegal, since it would probably blow up on you anyway.