Re: Better introspection for Frames, Thread, and enhancing binding.

On Dec 3, 2007 1:49 AM, Charles Oliver Nutter <[e-mail]>
wrote:

> ...
> The point is, if user code can expect to grab a frame object at any
> time, you have to be prepared to present one and manage its lifecycle
> along with userspace objects.


There may some misunderstanding of what I was suggesting. First of all,
there *always* is a frame in the program. That is the information I'm
suggesting get returned. And this information once copied to a variable need
not be dynamically updated as the program runs, so this life-cycle
management is no more complicated than what happens normally.

It's not so bad or complicated as you seem to make it out to be. Consider
what happens when I debug C code with inlined functions.  I ask the debugger
where am I and it says I'm in one of the calling functions rather than the
inline function that I believe I am at. Maybe it looks a little odd, so I
either arrange to turn off optimization for that part or I deal with it.
(Having a disassembler or assembly listing can be helpful here.)

Having a way to ask for frame information doesn't stop a friendly or helpful
interpreter from providing a way to undo its frame-elimination
transformations as best as it can - either on request or under some sort of
switches. However it doesn't *require* it either.

Previously, I mentioned caller() in the context of Perl, but it is a Ruby
function as well. One of its uses in Perl is to be able to write an error
message routine (carp) that reports an error based on the place of the
caller rather than itself. That is, you do not want to say you were in
"carp" when you got this error but rather in the function that called
"carp".

So the complication with optimizers "inlining" calls exists right now and
has existed ever since caller() has been in Ruby. A inline-aware carp would
probably test to see if caller(0) is "carp" as expected. If it is it could
go back a frame or carp(1); if not, it could use the caller(0) information.
The information associated with caller(0) might not strictly be the
immediate caller, but for purposes of indicating where the program was when
an error occurred, would still be more helpful. Definitely more helpful than
if Ruby did not having caller().