Good point about incrementing the carplevel instead of setting it, that would be a more clever way to go about it.

But im a little confused about your other comments. Maybe a post to meditations about what you've found out? I for one would appreciate it, especially as I have used carplevel a number of times with good results (or else I wouldnt have brought it up eh?). I understand from gschwern that there is a new version (written by you perhaps?) of Carp expected for 5.7 (or something) that corrects at least one bug in it that I know of (that being the fact that when overloading stringify in objects it will use this stringification instead of printing the underlying string value of the reference, which can cause big problems (sometimes deep recursion).

Nonetheless these are the type of things that I would really like to see a meditation on, so if you've got a few minutes... :-)

Its funny though but I was just working on some code that does something similar in Benchmark. Benchmark wants to know its original callers package so that it can run its benchmarks inside of that lexical space. As I have rewritten Benchmark in an OO form the routine is no longer at the same depth in the call stack, nor is it called in the same way, and it will be being from various subclasses with their own call stack issues, accordingly I had to hack the routine to ignore any packages in the Benchmark heirarchy. Wasn't my preferred solution and makes me think that maybe this type of 'figure out the outside caller' routine needs to be carefully coded in a reusable form. In fact on that line, I would be willing to put some effort into that if you have some code or ideas to contribute. ...oO(Hmm, maybe a meditation in of itself)

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)