[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
trace, language vs. implementation
>>> TRACE cleary implies a side effect since the behaviour
>>> of some procedure changes.
>> This is not obvious to me. TRACE reports on an activity in the
>> system. The action of the traced procedure is unchanged. Just to
>> be extreme, TRACE might be implemented with external hardware,
>> something like a really smart logic analyzer.
> The values returned by the traced procedure are the same (hopefully),
> but there is certainly a change in behaviour in the procedure. It
> prints (writes?) some stuff which it was not printing before, so its
> behaviour has changed, irrelevant of whether you implement the TRACE
> facility by modifying the procedure (closure, code, or variable), or
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 seem to be unwilling to consider the behavior of TRACE separate
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.
I find this comparison unconvincing. First, SET-CAR! is a construct of
the language; TRACE is a command to the programming environment. My
guess would be that you do not make this distinction; though, I think it
would be a mistake not to. Second, SET-CAR! is defined to have a side
effect, TRACE can be specified without resorting to side effects:
"After issuing (TRACE <proc>) the procedure trace facility with report
calls to and returns from <proc>." I note that you wrote "TRACE", not
"TRACE!". I think there is more to what I am saying than word games.
Your example demonstrates that the semantics of "side-effect" can be
implemented without apparent side effect; the reverse is also possible
(you can implement FP in C).
- From: Bill Rozas <JINX%MIT-OZ@MIT-MC.ARPA>