From: André Thieme
Subject: Why does TRACE look like a special form?
Date:
Message-ID: <c4qaug$8l5$1@ulric.tng.de>
I am trying to find out why it is a win for the programmer that TRACE
has its own specific evaluation rule and is not using the standard
evaluation rule.
When I have
(defun foo (func args)
(apply func args))
I will use #' like this:
(foo #'+ '(10 4)) => 14
And not (foo + '(10 4)) or even maybe (foo + (10 4)), without quoting
the second argument to foo.
But I do (trace foo). I could also say (trace #'foo) which I would regard
as "normal". But when I do (setf bar #'foo) then (trace bar) leads to
an error which would not have happened if the creators of (trace) would
have taken care that it accepts only functions which come in the format
(function foo)
So, where lies the advantage that it is the way it is?
Andr�
--
Andr� Thieme <······································@justmail.de> wrote in message news:<············@ulric.tng.de>...
> So, where lies the advantage that it is the way it is?
It's always slightly bugged me. I think that TRACE might want to be
able to expand to something like:
(trace x)
->
(progn
(store-untraced-definition 'x #'x)
(setf (fdefinition 'x) (make-traced-function 'x #'x))
'x)
And to do this, you need access to thing that names the function as
well as the function itself. But I'd have been OK with (trace 'x).
--tim
Andr� Thieme <······································@justmail.de> writes:
> I am trying to find out why it is a win for the programmer that TRACE
> has its own specific evaluation rule and is not using the standard
> evaluation rule.
That's a good question. It *is* quite natrual to write trace
as a macro, and trace macros often let you do more than just
list function names; but if you're wondering whether it's a
*big* win, maybe it isn't. When I wrote an advice system a
while back, I did it as plain functions rather than macros,
though eariler times when I did something like that, I
wrote macros.
> But I do (trace foo). I could also say (trace #'foo) which I would regard
> as "normal".
But (just-a-function-trace #'foo) won't work.
-- jd
In article <············@ulric.tng.de>,
Andr� Thieme <······································@justmail.de>
wrote:
> I am trying to find out why it is a win for the programmer that TRACE
> has its own specific evaluation rule and is not using the standard
> evaluation rule.
I don't think there's any good reason for this. It was done this way in
Maclisp, and Common Lisp simply adopted it as it was.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin wrote:
> I don't think there's any good reason for this. It was done this way in
> Maclisp, and Common Lisp simply adopted it as it was.
In historical times (> 30 years ago) trace was nearly always invoked
interactively by a human typing at some sort of teletype, so it was
convenient to define it as an operator that didn't evaluate its
argument. This allowed the human to type "(trace foo)" rather than
"(trace (quote foo))". Back then the single quote reader macro wasn't
universally defined.
Of course, trace really ought have a functional equivalent so it is
easier to use programmatically. One usual convention for macros with
corresponding function versions would be to name the macro TRACE and
the `equivalent' function TRACE-1.
This or something like it exists in many implementations, but it was
not made a part of the standard. Here is why:
(1) There are two widely different systems by which tracing (and other
function advice) can be implemented: In one, the function binding on
a function name (e.g a symbol) is captued inside a wrapping function,
and that wrapping function becmoes the ner traced definition in the
function binding. In the other, the function object that is the
binding of some function name is itself manipulated by implementation
magic so that the function object itself (not the function binding of the
name of the function) is wrapped with some additional behavior that does
tracing. The ANS did not want to restrict how tracing was implemented,
since tracing is really more a part of the programming environment than
the language itself.
(2) The difference between tracing function-name bindings and tracing
function objects themselves would have to be visible in the definition
of a trace-1. Specifically, would trace-1 take the name of a function,
or a function object itself? Further, if the function is a non-null
closure, does tracing apply to all instances of the closure, or just to
some specific instantiation of the closure? Issues like this almost have
to be left to the implementation and its programming environment. In
a sophisticated programming environment it is nice to allow the human
debugger to make choices abojut these things, but that could hardly be
specified in the ANS.
It would have been just as well if trace had been left out of the ANS,
since (I repeat) it is more a feature of the programming environment
than the programming language. (Has anyone ever used trace in an
application program???) But it's has been in the language about 40
years, and if we freely threw away everything more than 40 years old
I myself would be long gone...