FORCE breaks when traced

[Jonathan A Rees <JAR@MIT-MC.ARPA>]

    Date: Thu, 4 Oct 84 15:46:11 EDT
    From: Larry Hunter <Hunter at YALE.ARPA>

	> (set baz (delay 'foo))
	[Binding BAZ] #{Delayed 280}
	> (force baz)
	FOO
	> (set baz (delay 'foo))
	#{Delayed 281}
	> (trace force)

	FORCE traced.
	> (force baz)

	;0 Calling FORCE with arguments (#{Delayed 281})
	;0 Returned from FORCE with value #{Delayed 281}
	#{Delayed 281}
	> (untrace force)

	#{Operation 278 FORCE} untraced.
	> (force baz)
	FOO

    Is this true of all operations?  Why?  Is there a fix?

Good question.  The reason is that operation dispatch is done using EQ?,
comparing the operation that was called against the value of various
variables that the object being operated on was closed over.  TRACE is
not a side effect, so the traced operation is not EQ to the original
untraced one.  The trace package tries to compensate for this by forcing
the dispatch to use the traced operation in the dispatch, and this works
if the variable whose value the object is using for dispatch is itself
the traced operation.  E.g. if you define your operations in environment
FOO, and your objects are closed in environment FOO, then things should
work out just fine.  Unfortunately, the fact that the T implementation
environment is disjoint from the user's scratch environment causes
problems here.  When you say (TRACE FORCE), the value of FORCE in your
environment changes, but the value in the implementation environment
doesn't change.  During the dispatch the two are compared to each other,
they turn out to be different, and the dispatch fails.  (The default
method for FORCE simply returns the object.)

I'm not sure how this can be fixed.  It's an unwanted side-effect of the
general way in which operation dispatch happens.  Suggestions will be
entertained.  An earlier version of T (2.5-, perhaps) implemented
operation tracing as a side effect, so that the operation itself was
advised to print trace info, but I think that lost for a different
reason.

Of course, in the case of FORCE, which is not advertised to be an
operation at all, this behavior is certainly buggy.  The user shouldn't
have to (probably shouldn't even be able to) know that some system
procedures are in fact implemented as operations.

Jonathan