From: Paul Lutus <nospam@...>
Date: 2006-11-25T04:48:52+09:00
Subject: Re: [OT] Bug in ruby?

Leslie Viljoen wrote:

> On 11/22/06, David Vallner <david@vallner.net> wrote:
>> Leslie Viljoen wrote:
>> > It's very annoying to try and guess which could be the offending
>> > variable in a complex expression, and it wastes a lot of time. It
>> > would surely be very easy for Ruby to say which variable was nil.
>>
>> Meet my good friends, local variable, and return value checking. You'll
>> get along great once you get to know each other.
>>
>> Also, see previous post. At any given point in time, there's several
>> variables that point to nil in the interpreter, and the culprit is also
>> usually an expression. Finding the possible expressions that returned a
>> nil would require tracing back to the literal in the stack frames, and
>> even then the last one wouldn't have to be the cause of the problem. I
>> stand by my point that this is not the job of a core language runtime,
>> but of manual or automated code review.
> 
> It just seems like it would be easier than that, since Ruby is an
> interpreter. Doesn't the last sub-expression get stored in a string
> somewhere as the expression is parsed?

Remember in modern interpreted languages that interpretation and execution
are separate phases. The bug this thread is about was a runtime bug, not
one of interpretation. Once runtime begins in earnest, such niceties as
variable identities and even sometimes line numbers are lost in the name of
efficiency.

> Anyway, I am just now noticing that 5+nil and nil+5 return different
> error messages. As long as an operator is unique in an expression, it
> should be easy to figure out which is nil.

In this case, some simple, focused testing strategies needed to be applied.
Notwithstanding the OP's insistence that he tried everything, there was an
obvious test he didn't apply.

-- 
Paul Lutus
http://www.arachnoid.com