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.

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Reply via email to