Issue: TRACE-FUNCTION-ONLY

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

(Kempf should probably be in on his discussion, but I don't have a
usable return address for him.)

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.  OK, we put TRACE into the
manual, and this has the benficial effect that in a new implementation
you know that the thing called TRACE is what you want to find out about
when you need this facility.  But we should not try to constrain it any
further.

My second reaction was that I'd really like any implementaiton I use to
support tracing of generic functions, methods, and (if we adopt the
SETF-function proposal) these new function-spec forms.  For that matter,
if we get deeper into the function-spec game, TRACE should follow.  So
maybe putting this requirement into the standard is not so bad after all
-- it's one way of goading companies that might be slow to react
otherwise because their own people aren't deeply into CLOS yet.

So I'd be willing to go along with that part of the proposal.  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".

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

-- Scott