TRACE Proposal (Version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 31 Jul 87 12:07:37 MST
    From: kempf%hplabsz@hplabs.HP.COM

    As promised, here is an initial draft of a proposal for modifying the
    TRACE macro (CLtL, pp. 440-441) to better support object-oriented
    programming....

This looks interesting.  I have a couple of comments to offer right now.

    A function-spec is either a symbol naming a function (i.e. a symbol
    whose global function cell is bound to a function definition object)
    or a list whose first element is a function specification type, and 
    whose tail indicates which particular function of that type should 
    be traced. 

The Cleanup subcommittee of X3J13 were discussing something similar
a while back, starting from a different point.  The DOCUMENTATION function
of Common Lisp introduces the concept of "definition types", and this
concept could be useful in other operations.  For instance, it would be
nice to be able to remove any definition (function, variable, type, setf)
through a uniform interface.  "Definition type" and "function spec type"
are not the same concept, however there seems to be enough overlap here
that some coordination is probably called for.

I don't remember for sure, but I think Larry Masinter volunteered to make
a proposal for "definition types" when he got time.

    ....
    Note: Another useful enhancement would be to support a :BREAK flag, like
    this:

	    (:METHOD <spec>  :BREAK)

    indicating that a break loop should be entered before and after the
    function executes.

Here you see a conflict between lists as function-specs and lists as
lists of options, in the arguments to TRACE.  Because of this your proposal
for TRACE is not compatible with what Symbolics currently does, but I don't
think that's too important for us.  We say that a list is a list of options,
and if you want to trace a function whose name is a list, you have to do
(TRACE (:function <function-spec> <options>...)).  But all this really
shows is that the syntax of TRACE is ridiculous.  I usually ignore the TRACE
function and trace things through a command interface.  Anyway, for your
proposal you have to decide between lists as function specs and lists as
options; I don't think you can mix them freely as you proposed.  Of course
it would be a lot easier if TRACE only traced one function at a time,
then the rest of the form could be used for options.  That would be a bit
incompatible with CLtL.

    TRACE-EXECUTION object &OPTIONAL env		[Generic Function]

I didn't completely understand this.  It looks like there is some
incoherence about whether TRACE is an operation on functions or on
places in which you can store a function definition.  In other words,
does tracing a function redefine the function or alter the object that
is the function's definition?  In other words, does
  (defun foo () ...)
  (setq f #'foo)
  (trace foo)
  (funcall f)
generate trace-output or not?  We have to decide one way or the other.
CLtL is obscure on this point.