[plt-dev] mzlib/trace better prefixes

From: Jon Rafkind (rafkind at cs.utah.edu)
Date: Wed Sep 16 23:56:01 EDT 2009

Philippe Meunier wrote:
> Jon Rafkind wrote:
>   
>> Attached is a patch that changes the prefixes that mzlib/trace prints  
>> depending on whether a function call is occuring or if a result is being  
>> returned. "<" is a function call and ">" is a return value.
>>     
>
> That looks backward to me: the trace library represents the stack of
> function calls horizontally from left to right, so for a function call
> I would expect it to use ">" to point in the direction in which the
> stack grows...  I don't see anything wrong with using "|" anyway (if
> it's used the right way, see below).
>
>   

Eli pointed the same out to me so I'll change it to >.
>> I find this is easier to read than the current ambiguous "|".
>>     
>
> I agree that the current output:
>
> |(fact 5)
> | (fact 4)
> | |(fact 3)
> | | (fact 2)
> | | |(fact 1)
> | | | (fact 0)
> | | | 1
> | | |1
> | | 2
> | |6
> | 24
> |120
> 120
>
> could be better.  I understand why 120 appears twice but I find it a
> bit confusing, and I also think it would be better to use "|" to
> symbolize actual stack frames rather than just use it along with " "
> for vertical alignment purposes, even if that means using twice the
> amount of horizontal space to represent the stack.  Something like
> this:
>
>   

The output already shows you the number of stack frames. The number of 
stack frames is basically the amount of space before the input/output. 
Only one | is printed for every two stack frames, I guess to make the 
output look nicer.
> (fact 5)
> | (fact 4)
> | | (fact 3)
> | | | (fact 2)
> | | | | (fact 1)
> | | | | | (fact 0)
> | | | | | 1
> | | | | 1
> | | | 2
> | | 6
> | 24
> 120
>
> or like this, if you imagine that (fact 2) is somehow a tail call:
>
> (fact 5)
> | (fact 4)
> | | (fact 3)
> | | (fact 2)
> | | | (fact 1)
> | | | | (fact 0)
> | | | | 1
> | | | 1
> | | 6
> | 24
> 120
>
>   

I think you mean (fact 3) is a tail call, but yes the trace output does 
that too (condense tail calls so they take up the same amount of output).


Posted on the dev mailing list.