[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trace

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

There may be no good answer. My point was that if I write

 (define (foo x)
    ... (foo x) ...
    ... (bar x) ...  )

 (define (bar x)
    ... (foo x) ...
    ... (bar x) ... )

that I am going to see calls from FOO to BAR, and from BAR to FOO,
but not from FOO to FOO, or from BAR to BAR.  I find this property of 
this variant of DEFINE strange.  At least is this version:

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

there are two different variables named FACT apparent in the code the
user wrote.

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

Great!  Here are some possible trace facilities (specified in terms
of the language):

(1) Trace all calls to the procedure which is the value of a given
    variable (what you said).  "trace the closure"

(2) Trace all evaluations of a particular combination (specify 
    a call in a particular piece of source).  "trace the source"

(3) Trace all evaluations of all combinations where the procedure in the
    combination was obtained by evaluating a given variable.
    "trace the variable"

(4) Trace all evaluations of all combinations where the procedure is
    a value that resulted from the evaluation of a given lambda-expression.
    (You choose how to specify the lambda). "trace the code"

Given that we decided that some or all of these were useful, we might
discuss the relative difficulty of implementing them; or perhaps, 
how these might or might not be supported in the presence of an
optimizing compiler.  This was the point of my first message.

I do not think that TRACE merrits  all this discussion.  I do think
there is an important issue at hand: how to implement a language that
is both efficient and easy to debug.   Perhaps a change in the focus
of this discussion would show up some interesting differences in 
Scheme implementation philosophies.