Re: Issue: TRACE-FUNCTION-ONLY

[kempf%hplabsz@hplabs.HP.COM]

Scott:

	Larry forwarded your message. My address is: kempf@hplabs.hp.com.

> My first reaction to this proposal was that TRACE is part of each
> implementation's environment, and that since it does not affect portable
> code, it should not be part of the spec.  

This was my first reaction also.

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

> If you add :BREAK in the way you propose, you are introducing a
> gratuitous incompatibility with the syntax in CLtL, since now TRACE only
> takes a single symbol or function-spec.  An alternative is the scheme
> used in CMU Common Lisp:

> (trace [trace-form]*)

> where the trace form is either a symbol naming a function or a list
> whose car is a function-name symbol and whose CDR contains the options
> to be used in tracing that function: :BREAK, :BREAK-AFTER, :WHEREIN,
> etc. 

I originally proposed something like this and the concensus of the objects
committee seemed to be that a cleaner syntax would be to limit TRACE
to a single function specification, and add the keyword as a keyword
argument. The committee seemed to feel that including the keyword as
part of a list containing a function specification could become confusing
when the function specification was more than just a symbol.

As to the incompatibility with current Common Lisp, as you pointed out
in your note, TRACE is, to a large extent, part of the environment,
Changing the interface would probably have less effect than changing 
something like, say, MAKE-ARRAY, since people tend to use TRACE interactively.

> I think that we got this extended syntax from Maclisp and that lots of
> other Common Lisp implementations follow it as well.  I would like any
> proposal for extensions to TRACE to be compatible with this extended
> syntax, which I think is better than requiring a separate call to TRACE
> for each named function.  It might be ambiguous to allow arbitrary
> function-specs to appear as trace forms -- do you want to trace the SETF
> function of some symbol or SETF itself? -- but it would not be a problem
> to allow an arbitrary function spec to appear in the car of a
> trace-form, with implementation-specific keyword options allowed in the
> CDR.

If you feel strongly about it (and nobody else feels strongly in the other
direction), I can resubmit the proposal with the interface as you've
requested.

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.

I originally did not submit this to the Cleanup-committee because it
seemed to be a CLOS exclusive issue (being a generic function) but maybe
I should have?

		Jim Kempf	kempf@hplabs.hp.com