Issue: TRACE-FUNCTION-ONLY

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

    > However,
    > I think that the :BREAK stuff does not belong here.  If you want to
    > propose that as a required extension, you should do it in a separate
    > proposal and try to provide a better justification than "some
    > implementations do this, so I've randomly tossed it in with the other
    > stuff".

    I've found being able to introduce a break after the printing of tracing
    information in our Lisp to be an invaluable debugging tool, as have
    other developers here. At the moment, they are beating my door down
    for the same capability (along with simple tracing) for individual
    methods, in the portable CLOS implementation. I can add this justification
    to the proposal.

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

If you insist upon extending the standard to include :BREAK, we ought to
go all the way and specify exactly what an extended-form trace ought to
handle.  In addition to :BREAK, we probably want :BREAK-AFTER, :WHEREIN,
:PRINT, :PRINT-AFTER, and maybe some other things.  We want a syntax
that will handle all this, plus function specs, and that still will allow
you to say (TRACE A B C) when you have a bunch of functions you want to
look at in the usual way.

So I oppose the current proposal that includes only :BREAK and that
adopts a more restrictive syntax for TRACE for no good reason.
It might make sense to propose a comprehensive package of TRACE
extensions that we would all follow, though getting agreement at this
late date might take some negotiation among the N divergent
implementations. 

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

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

-- Scott