------ art_3629_19981719.1196681443840 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Dec 3, 2007 1:49 AM, Charles Oliver Nutter <charles.nutter / sun.com> 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(). ------ art_3629_19981719.1196681443840 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Dec 3, 2007 1:49 AM, Charles Oliver Nutter <<a href ailto:charles.nutter / sun.com">charles.nutter / sun.com</a>> wrote:<br><div class mail_quote"><blockquote class mail_quote" style order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div class j3C7c">...<br></div></div>The point is, if user code can expect to grab a frame object at any<br>time, you have to be prepared to present one and manage its lifecycle<br>along with userspace objects. </blockquote><div><br>There may some misunderstanding of what I was suggesting. First of all, there <i>always</i> 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. <br><br>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.) <br><br>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 <i>require</i> it either.<br><br>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". <br><br>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(). <br></div></div><br> ------ art_3629_19981719.1196681443840--