Re: Issue: TRACE-FUNCTION-ONLY

[kempf%hplabsz@hplabs.HP.COM]

SF> This doesn't really respond to the objection I raised.  I didn't suggest
SF> that :BREAK was not worthwhile.  I said that there are two distinct
SF> issues here: whether to extend TRACE to work for methods and setf
SF> functions, and whether to extend trace to do all sorts of other neat
SF> things.  The former is probably not controversial, and I could
SF> support a proposal that contains just this.

I understand. I was trying to address both issues, but, as you've pointed
out, the :BREAK issue is somewhat more complex. I will rewrite the trace
proposal to remove the reference to :BREAK, redo the syntax to conform
to that currently in CLtL, and leave it up to someone else (who could
possibly be me at a later date) to deal with the break issue.

JK> While we're discussing this issue, another part of the proposal was to
JK> include a generic function, called TRACE-EXECUTION, which took as an
JK> argument an object representing an executable entity, like a method object,
JK> generic function, function, symbol, etc. An implementation specific method
JK> would run to arrange for tracing code to be inserted. Similar to
JK> PRINT-OBJECT, all implementations would have to implement tracing using
JK> this generic function. The advantage of this is that if someone extends
JK> CLOS/CL by including a new funcallable object, like, for example, a
JK> remote procedure call, debugging becomes extensible as well.

SF> This is going to be a fairly hairy proposal, I think, since you have to
SF> trace function names and not functions (unless you want to force
SF> implementors to do surgery on compiled function objects).  I'd be
SF> interested in seeing the details of this proposal.

The intent of the proposal was to provide a system level interface for
extending debugging capability and for supporting current debugging
technology. Thus, since most current debuggers go through function names,
the method for implementing debugging on ordinary functions would
discriminate on symbols and would use the function wrapping technique
which most Lisps currently use for tracing. For tracing methods, the
debugging method would discriminate on a method object, and would wrap
the method function itself, since one way of implementing method 
dispatch is to have the generic function use the method function directly
(in fact, this is how the PCL implementation works). More advanced Lisp 
implementation technologies might make it possible to debug the invocation 
of a function through the function definition object (fundef object), as
you've pointed out. By using a generic function, the usual advantages of 
object oriented programming, in terms of system extensibility, would 
be available, since the generic function would provide a portable interface
which each implementation could customize with the particular capibilities
that it can support.

Below is a copy of the proposal I submitted to the objects committee in
September. Note that it does not appear in the current draft of the Object
System specification, pending disposition of where, precisely, it belongs.
I'd appreciate hearing what you think of it.

		jak

-------------------------------------------------------------------------------

Font note: UPPERCASE indicates bold, _this_ indicates italic.

TRACE-EXECUTION _object_ &KEY :ENVIRONMENT   _[Generic Function]_

TRACE-EXECUTION discriminates on _object_ to select an implementation
specific method that arranges for the executable entity associated
with _object_ to be traced. The :ENVIRONMENT keyword parameter is for 
those implementations which require environmental information to
arrange for tracing to occur. Implementations are required to provide
TRACE-EXECUTION as the system level entry point for implementing TRACE
functionality.

The exact nature and number of methods associated with TRACE-EXECUTION
will differ, depending on what executable entities can be specified
by TRACE, but every implementation needs to support methods which 
dispatch on objects having the following classes:

SYMBOL-The function indicated by the symbol will be traced when invoked
in the environment. 

METHOD-The method function is traced when invoked.

GENERIC-FUNCTION-The generic function is traced when the discriminator
code is invoked.

Implementations are encouraged to provide as many methods as the
implementation technology can support.