Re: Issue: TRACE-FUNCTION-ONLY

[kempf%hplabsz@hplabs.HP.COM]

> I'd like to see added to the discussion section that there are
> additional features of TRACE not being discussed at this time but being
> included in other proposals. I think we also need to say that we
> understand that TRACE is part of the environment rather than the
> language and as such there are different criteria for evaluating
> compliance. (E.g.,  we might want to define a level of acceptability for
> embedded systems which includes all of>  the language but none of the
> environment, e.g.,  system intended to be imbedded in an office
> machines.)

I can't seem to find the draft of Version 3 which I sent off yesterday,
probably because I posted it to cl-cleanup only and didn't include myself.
Since I'm not on the cl-cleanup list, I didn't get a copy. Larry, could
you either send me a copy back, or fold these commments into Version 4 
yourself? Thanks in advance.

> Finally, maybe I'm feeling grumpy today, but I've little enthusiasm for
> this. Frankly, all of the programming environment features one might
> standardize, TRACE is one of the most useless; I don't think I've TRACEd
> anything for the last 6 months. Adding breakpoints, yes, TRACE, no; the
> information printed is either too much or not enough.

I pretty much agree with these sentiments, however, I think that, since
most implementors have already extended TRACE to include breakpoints,
they will probably fold those extensions into the extended TRACE. This
will, of course, mean that the break extensions will remain nonstandard,
but until everyone can agree on what extensions are correct, I think that's
the best we can hope for.

I'm more concerned about a lack of an extensible interface at the system
level. This is what TRACE-EXECUTION is supposed to be, along with a
generic function like PRINT-TRACE. The read-eval-print loop debugging
which the TRACE macro was designed for is becoming obsolete rapidly,
as people move to more sophisticated environments. It would be nice to
have a set of portable interface "plugs", into which people could plug
their experimental debugging interfaces. Without plug-compatible system
level interfaces, porting debugging extensions will require extensive
source access, which some implementors have been reluctant to give.

		jak