Re: TRACE Proposal (Version 1)

[kempf%hplabsz@hplabs.HP.COM]

>     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

A definition type would certainly be a nicer way of handling this. It
would unify how to indicate that a particular definition is wanted. 

>     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 > e> asier 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.

An alternative would be to introduce a BREAK macro:

	BREAK &REST {function-spec or definition}*	[Macro]

having the obvious functionality. Such a "functional" interface would 
avoid having to try indicating everything through one operation. I
just suggested the :BREAK option because this similar to how we currently
do it.

>     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.

As is usual in CLOS, the idea here was to split trace functionality into
two pieces a) a programmer interface (TRACE) b) a system level or
metaclass protocol function (TRACE-EXECUTION). 

With reference to your example, certain implementations may support the 
ability to modify function definition objects directly to allow trace 
information to be inserted. Thus the FUNCALL in the example could be 
traceable. As the base note suggested, these implementations could then 
have a function spec (or definition type) for indicating that the function 
should be trace through the fundef object rather than through the symbol. 
Other implementations may only be able to trace though a wrapper on the 
function symbol. The function spec or definition type would be used for
indicating to TRACE what to do, a corresponding TRACE-EXECUTION method
would contain the implementation dependent code to do it.

As to why go to the trouble of having an extra layer, consider a user
who wants to write a method or generic function class for remote procedure
calls. This user would like some way of handling debugging, and a generic
function in the metaclass protocol seems like the right way to do it.
A generic function would provide the system level interface for other
kinds of debugging functionality.


				jak