trace

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

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

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.

    .. is undesirable that the effect depends on the form of the DEFINE.  I
    also think it is confusing to have indirect recursions appear in the
    TRACE output, when the self recursions are ommitted.  

What do you mean by indirect recursions?  I think you are too harsh on
DEFINE.  It seems from your message that you would be upset if in the
following

(define (fact n)
  (if (= n 0)
      1
      (* n (fact (-1+ n)))))

self recursive calls were not displayed, but you would be perfectly willing 
to tolerate that behaviour in 

(define fact
  (letrec ((fact (lambda (n)
		   (if (= n 0)
		       1
		       (* n (fact (-1+ n)))))))
	  fact))

.  I see no difference.  As far as I'm concerned, I would like to see
all instances where the object which FOO is bound to (eq? problems
again) is (conceptually) invoked.  This obviously presupposes a
particular model of evaluation, but that is probably true of each
user.

I don't think that we will be able to agree on what the "right"
behaviour is since the "right" behaviour depends on the situation, and
there are probably cases which we have not included in our
classification where any of them will not do exactly what we want.