[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: kempf%hplabsz@HPLABS.HP.COM
- Subject: Issue: TRACE-FUNCTION-ONLY
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Sun, 25 Oct 1987 17:31 EST
- Cc: cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: Msg of 23 Oct 1987 11:25-EDT from kempf%hplabsz at hplabs.HP.COM
- Sender: FAHLMAN@C.CS.CMU.EDU
> 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
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
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.