GHCi debugger status

[Daniil Elovkov]

Peter Hercek wrote:
> Daniil Elovkov wrote:
>> A refinement of :tracelocal could be :tracedirect (or something) that 
>> would save the history not anywhere within the given function but only 
>> within parents, so to say. For example,
> 
> This looks like what I thought of as searching for values in dynamic 
> stack (explained in my response to Pepe Iborra in this thread).

Yes, first when I saw that your message I also thought "Hey, Peter has already suggested it!" :)

But now I see that we're talking about slightly different things. Consider

fun x y =
   let f1 = ... (f2 x) ...   -- f1 calls f2
       f2 = exp_f2
   in ...

Now, if we're at exp_f2 then 'dynamic stack' in your terminology includes (f2 x) since it's the caller and all f1 as well.

On the other hand, :tracedirect that I suggested would not include f1, as it's not a direct ancestor. And for the purpose of binding variables which are syntactically in scope, it is indeed not needed. :tracedirect would be sufficient.

Also, I think that :tracedirect can be easily implemented based only on simple syntactic inclusion relation.


> I just did not ask for it with a new ticket since:
> * I think it is already requested by some other ticket
> * if you compile with -Wall then :tracelocal should have the same
>   information and only rarely name collision happens so automatic
>   tracelocal trace search should return what you are looking for
>   too and when needed it reruns more ... that is if the function
>   is short enough to fit in the tracelocal history queue
> 
> The ticket actually has two almost independent parts:
> * Adding tracelocal trace.
> * Adding the automatic search for symbols in the trace and
>   the trace in the search could be also some other kind of
>   trace like (e.g. dynamic stack). This would not be that
>   useful though since the names at higher levels in stack
>   are typically different. So to make it good it would
>   require matching formal arguments to expressions on
>   higher level and evaluating them, not that easy to do
>   as simple tracelocal search which is just based on stupid
>   string comparison.