trace, language vs. implementation

[Bill Rozas <JINX%MIT-OZ@MIT-MC.ARPA>]

When I said

>>>> TRACE cleary implies a side effect since the behaviour
>>>> of some procedure changes.  

I did not mean to imply that the side effect was done on the procedure
(variable, etc.)  but that a side effect was done somewhere.  In
particular, APPLY can be changed to take care of TRACE.

>There is no requirement that the procedure print the message.  My
>analogy to a logic analyzer still holds.  Something external to the
>procedure could be report on the activity of the procedure. 

You've moved the side effect one level out.  Conceptually SOMETHING,
SOMEWHERE, is taking some action which it would not have taken before.
I do not know what you call this if it is not a side effect.

1>You seem to be unwilling to consider the behavior of TRACE separate
1>from its implementation.  

>> What you say is similar to saying that SET-CAR! does not really change
>> the appropriate pair, but rather changes the CAR procedure so that if
>> it sees that its argument is the "modified" pair, it gives the new
>> "car" as its answer, as opposed to the "real" car.  Sorry, but I think
>> you are just playing word games.

2>I find this comparison unconvincing.  First, SET-CAR!  is a construct of
2>the language; TRACE is a command to the programming environment.  My
2>guess would be that you do not make this distinction; though, I think it
2>would be a mistake not to.  Second, SET-CAR! is defined to have a side
2>effect, TRACE can be specified without resorting to side effects:
2>"After issuing (TRACE <proc>) the procedure trace facility with report
2>calls to and returns from <proc>."  I note that you wrote "TRACE", not
2>"TRACE!".  I think there is more to what I am saying than word games.  

Please be consistent.  Either TRACE is a part of the language (vs. "the
programming environment") or it isn't.  If it is part of the
programming environment we should not worry about semantics since no
portable code will (hopefully) depend on its behaviour.  Its
implementation is the only interesting part.  If it is part of the
language my analogy holds and we lose anyway since it involves a
side effect (which was my original point).

I agree with JAR in that we should not attempt to agree on debugging
tools, since debugging is a highly personal activity, and we would be
asking people to support models which do not necessarily agree with
their own.  In other words, TRACE is part of the programming system
and we should not constrain it in any way in the same way that we do
not ask people to use a particular editor.  There is too much personal
taste involved.