Bug in ruby?

[AliasX Neo]

Well, I've spent the last hour or so debugging one of the stupidest
errors I have encountered with Ruby.

Let's see my code first:

def parse(string, starting, ending)
istart = string.index(starting) + starting.length
iend = string.index(ending, istart)
return string.slice(istart, iend - istart)
end

This function is called about 13 times in my entire script. It breaks on
the last one with this error:

undefined method `+' for nil:NilClass

Now, I have debugged the living hell out of this application. It's
breaking on the first line, stating that starting.length is a nil object
and that it can't perform a + operator in a nil object. The string
that's getting passed into starting is:

buy_item.phtml?

I debugged the application and put a mark on the first line to examine
it in the following code:

def parse(string, starting, ending)
length = starting.length
istart = string.index(starting) + length
iend = string.index(ending, istart)
return string.slice(istart, iend - istart)
end

And the debugger said that length was an int with the value of 15. Guess
what still happened? Got the exact same error with the + operator on a
nil object. Except that completely contradicts the fact that it's not
nil but it's an int with the value of 15.

I have spent the last hour trying hundreds of different forms of this
code and am getting the same exact error every time. I've come to the
conclusion that this must be some kind of bug in Ruby, I can not pull on
piece of logical evidence out of this.

So my last resort is you guru's here, what am I doing wrong? Is there
some kind of magical law I broke? This application needs to get done
tonight, and I really can't afford anymore time on this tiny little bug.
Thanks in advanced.

~ Alias

 

[brabuhr]

Well, I've spent the last hour or so debugging one of the stupidest
errors I have encountered with Ruby.

Let's see my code first:

def parse(string, starting, ending)
istart = string.index(starting) + starting.length
iend = string.index(ending, istart)
return string.slice(istart, iend - istart)
end

This function is called about 13 times in my entire script. It breaks on
the last one with this error:

undefined method `+' for nil:NilClass

Now, I have debugged the living hell out of this application. It's
breaking on the first line, stating that starting.length is a nil object
and that it can't perform a + operator in a nil object. The string
that's getting passed into starting is:

Wouldn't it be string.index() that is Nil here:

string.index(starting).+(starting.length)

starting.length is a parameter to the '+' method being called on the
result of index().

 

[Justin Collins]

Well, I've spent the last hour or so debugging one of the stupidest
errors I have encountered with Ruby.

I debugged the application and put a mark on the first line to examine
it in the following code:

def parse(string, starting, ending)
length = starting.length
istart = string.index(starting) + length
iend = string.index(ending, istart)
return string.slice(istart, iend - istart)
end

And the debugger said that length was an int with the value of 15. Guess
what still happened? Got the exact same error with the + operator on a
nil object. Except that completely contradicts the fact that it's not
nil but it's an int with the value of 15.

+ is being called on string.index(starting) not length. I'd check to
make sure you aren't getting nil from that:

def parse(string, starting, ending)
p string.index(starting)
istart = string.index(starting) + length
iend = string.index(ending, istart)
return string.slice(istart, iend - istart)
end

Hope that helps.

-Justin

 

[David Vallner]

--------------enigA22C6AD12A9F315A34DABA54
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This is a subject line that's mildly infuriating. I wonder if I can
recall more than three threads of that name that actually were a bug in
Ruby after all in the past year, and the one that's in living memory was
from Ara, and (unsurprisingly) a very subtle issue where it took me
three reads to find out why it's wrong behaviour in the first place, not
a "method not working at all" issue.

If you're not a syntax lawyer, and / or haven't checked the
documentation for what you're using a code snippet in the first place,
I'd say odds are good it's a bug in your code due to some (maybe not
really) gotcha you overlooked. And in that case it would be better to
present a problem as such, and providing a more informative subject line
to boot.

Also:

def parse(string, start, ending)
string.match(/#{Regexp.escape(start)}.*(?=3D#{Regexp.escape(ending)}/)[0=
]
end

David Vallner


--------------enigA22C6AD12A9F315A34DABA54
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFY0h9y6MhrS8astoRAqNMAJ9g6k2hcMDwQrkuq05MkuwIcC5THQCfVYDZ
+cw08/DT2YWa2gnQMEZlRIo=
=bibf
-----END PGP SIGNATURE-----

--------------enigA22C6AD12A9F315A34DABA54--

 

[Charles D Hixson]

This is a subject line that's mildly infuriating. I wonder if I can
recall more than three threads of that name that actually were a bug in
Ruby after all in the past year, and the one that's in living memory was
from Ara, and (unsurprisingly) a very subtle issue where it took me
three reads to find out why it's wrong behaviour in the first place, not
a "method not working at all" issue.

If you're not a syntax lawyer, and / or haven't checked the
documentation for what you're using a code snippet in the first place,
I'd say odds are good it's a bug in your code due to some (maybe not
really) gotcha you overlooked. And in that case it would be better to
present a problem as such, and providing a more informative subject line
to boot.

Also:

def parse(string, start, ending)
string.match(/#{Regexp.escape(start)}.*(?=#{Regexp.escape(ending)}/)[0]
end

David Vallner

There have been many that I thought were "bugs in Ruby", though mainly
in the error message produced rather than that the code should have done
what the person objecting thought it should have done.

I'll grant that good error messages are a hard problem, but I frequently
find them totally exasperating. E.g., if a loop isn't properly closed,
the error message should point to where it started rather than several
lines after the end of the program. (Well, perhaps this one's been
fixed. I don't remember encountering it recently. But if it hasn't
been, I consider it a bug in Ruby.)

In this case the bug was in the message not stating which variable had a
nil value. You may not think of it as serious, but he reports spending
several hours on it, and I'd call that a bug.

Remember, Ruby is being recommended to total neophytes as a good
language to start with. That means that good diagnostic error messages
are essential!

 

[Leslie Viljoen]

This is a subject line that's mildly infuriating. I wonder if I can
recall more than three threads of that name that actually were a bug in
Ruby after all in the past year, and the one that's in living memory was
from Ara, and (unsurprisingly) a very subtle issue where it took me
three reads to find out why it's wrong behaviour in the first place, not
a "method not working at all" issue.

If you're not a syntax lawyer, and / or haven't checked the
documentation for what you're using a code snippet in the first place,
I'd say odds are good it's a bug in your code due to some (maybe not
really) gotcha you overlooked. And in that case it would be better to
present a problem as such, and providing a more informative subject line
to boot.

Also:

def parse(string, start, ending)
string.match(/#{Regexp.escape(start)}.*(?=#{Regexp.escape(ending)}/)[0]
end

David Vallner

There have been many that I thought were "bugs in Ruby", though mainly
in the error message produced rather than that the code should have done
what the person objecting thought it should have done.

I'll grant that good error messages are a hard problem, but I frequently
find them totally exasperating. E.g., if a loop isn't properly closed,
the error message should point to where it started rather than several
lines after the end of the program. (Well, perhaps this one's been
fixed. I don't remember encountering it recently. But if it hasn't
been, I consider it a bug in Ruby.)

In this case the bug was in the message not stating which variable had a
nil value. You may not think of it as serious, but he reports spending
several hours on it, and I'd call that a bug.

Remember, Ruby is being recommended to total neophytes as a good
language to start with. That means that good diagnostic error messages
are essential!

I have also previously requested that this get fixed in a future Ruby.
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.

In some of my latest scripts I have this:

def preventNil(*args)
args.each_with_index do |arg, i|
raise ArgumentError.new("argument #{i} cannot be nil") if arg.nil?
end
end

class StatSaver
def initialize(vehicle, column, dataSet, log)

preventNil(vehicle, column, dataSet, log)

@vehicleID = vehicle.VehicleID
@column = column
@dataSet = dataSet
@log = log
end

...

...as a kind of firebreak contract to prevent nil's from failures in
completely unrelated places causing other code to fall over. You don't
always realise that a certain method might return nil.

I'd be interested to hear if there are nicer solutions to this problem.

Les

 

[Jim Cochrane]

AliasX Neo wrote:

...


Famous last words.

So, how'd it go? Was it finished in time and under budget?

--

 

[David Vallner]

--------------enig5F9F2435D66B717CB6ECCC13
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In this case the bug was in the message not stating which variable had = a
nil value. You may not think of it as serious, but he reports spending=

several hours on it, and I'd call that a bug.
=20

I'm not aware of a programming language that DOES report this. Remember
that a nil value can come out of a fairly complex expression instead of
a single variable, and that nil can have many variables bound to it at a
given moment. The bug was in the OP's code, plain and simple, it's not
the responsibility of the programming language to do in-depth diagnosis
of dangling pointer problems.

Also, in the OP, the error message was consistent to Ruby's semantics -
a NoMethodError on nil usually significates what a NPE in Java,
NullRefError in C#, or segfault in C would be. Since the undefined
method was #+, the culprit was the expression that a method of that name
was called on in that code snippet.

Ruby reported what happened consistently with its computation model
(failed method lookup, nil being a regular object), and where it
happened (with no less detail than any other programming language I've
worked with reports on null pointers).

Further diagnostics (why it could have possibly happened) is the role of
a static code analysis tool; since it's sooner or later guesswork it's
not the task of the interpreter itself.

Coding defensively and using sanity checks on the return value of #index
and other methods that may return nil would also have helped.

Remember, Ruby is being recommended to total neophytes as a good
language to start with. That means that good diagnostic error messages=

are essential!

As is learning the syntax rules and how to read the error messages.

Also, whoever makes that recommendation is a fool, and I'm not
responsible for him making that wrong recommendation. AFAIK, the Ruby
language presumes the programmer is a grownup, and there's a LOT of
running with scissors involved. The simplicity makes it easy to pickup,
but in my opinion it gets very difficult to hobble along with only basic
knowledge and get something working done as the emergent behaviours
"noone tells you about" bite you if you don't either delve deeper into
how stuff works to avoid those errors, or get a broader overview of
what's available to end up writing less code (e.g. replacing futzing
around with substrings with a RE.)

David Vallner


--------------enig5F9F2435D66B717CB6ECCC13
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFY6M0y6MhrS8astoRAiF3AJ9vvDIKyGkSrz9L/aTLvpeYv3jO9gCeIb7B
+0wvx2EFK2EHrxRr0qMoeWU=
=ynJm
-----END PGP SIGNATURE-----

--------------enig5F9F2435D66B717CB6ECCC13--

 

[David Vallner]

--------------enig2AE4673C523F1A1434A02A91
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.

David Vallner


--------------enig2AE4673C523F1A1434A02A91
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFY6ROy6MhrS8astoRAqlHAJ918cvfNYdoVcFjhRgfzUnPVpQWcwCfQ0Jy
9eNwpxXQrqCTIALyDRXY2co=
=hS+h
-----END PGP SIGNATURE-----

--------------enig2AE4673C523F1A1434A02A91--

 

[Jim Cochrane]

I think the OP is a student, in any case someone who isn't that into
programming as recreation.

Yes, that's pretty apparent - I was being jocular, or perhaps,
facetious.

Professionals don't conceptualize program flaws as "this tiny little bug".

You would hope not, but from what I've seen in the industry, I'd not be
surprised to hear about such a statement.

There is no such thing. All the tiny little bugs that weren't so tiny ...
the one that disabled a US Navy destroyer running NT (after someone entered
a zero into a user-level application and precipitated a divide-by-zero
error that brought down the entire network), which then drifted out of
control as the sailor geeks tried to restart the network. The bug that
caused the Airbus to fly into the trees during an air show low pass
(passengers on board).

The microcode bug that caused Intel processors to produce incorrect math
results, and damaged their reputation for a while.

Yep - famous bugs.

The bug that cause Mars Polar Explorer to prematurely shut down its engine
and fall the last 100 meters to the surface of Mars, never to be heard from
again.

Due to a missing or incorrect unit conversion, right?!

"Tiny little bug." No such thing.

Or how about the Ariane 5 (
http://www.around.com/ariane.html
). I don't remember ever hearing a description of the defect (or
defects) that caused the DIA baggage sysgtem to fail (
http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html
).

Maybe a more severe word than "bug" needs to be invented.

--

 

[Bill Kelly]

I'll grant that good error messages are a hard problem, but I frequently
find them totally exasperating. E.g., if a loop isn't properly closed,
the error message should point to where it started rather than several
lines after the end of the program. (Well, perhaps this one's been
fixed. I don't remember encountering it recently. But if it hasn't
been, I consider it a bug in Ruby.)

Have you thought through how this might work? It seems the obvious
solution may not generate useful information. See for ex:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/209336



Regards,

Bill

 

[Charles D Hixson]

Have you thought through how this might work? It seems the obvious
solution may not generate useful information. See for ex:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/209336



Regards,

Bill

I admitted it was a hard problem ... but, well,...

if functions are defined, and begins/ends balance within them, it
probably happened before or after that. Not guaranteed, as there might
be internal functions, but probable. If it's an end that is missing
(usual case) start parsing from inner constructs out. Etc.

(FWIW, I normally comment my ends thusly:
end # initialize
for just this reason. With Ruby syntax it is a REALLY hard problem.
When this has occurred a few times I start really agreeing with the
languages that do things like "end if" or "end def".)

OTOH, it's also true that by compiling every time I enter a new
definition I can generally handle this error with minimal problems ....
but it would be a lot easier to include sufficient context markers to
ensure localization of errors.

 

[Leslie Viljoen]

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?

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.

 

[Just Another Victim of the Ambient Morality]

Well, I've spent the last hour or so debugging one of the stupidest
errors I have encountered with Ruby.

Let's see my code first:

def parse(string, starting, ending)
istart = string.index(starting) + starting.length
iend = string.index(ending, istart)
return string.slice(istart, iend - istart)
end

This function is called about 13 times in my entire script. It breaks on
the last one with this error:

undefined method `+' for nil:NilClass

Just out of wild curiosity, did you ever figure this thing out? We're
very eager to learn of bugs in Ruby so they may be fixed although it really
looks like this was your error. Surely, it's not outrageous to think that
string.index(starting) can return nil. Was this the case for you?
Thank you...

 

[Robert Klemme]

Frankly, in this case I would attribute that to the bug searcher and not
the language. The message is pretty clear, it gives a line number and
an easy explanation. With that, you can immediately spot where it goes
wrong - even if you are unsure whether to look at the right or left side
of the "+".

I have also previously requested that this get fixed in a future Ruby.
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.

Actually I am not sure about this. The reason is this: the fact that
the method does not exist in the receiver is not detected prior to
runtime. And the object in question could potentially be referenced via
any number of variables (including being part of an Array). As such the
interpreter would have to remember several variable names per thread per
object to actually be able to resolve this properly. Or it would have
to go back to the source to determine this. And what do you do in this
case where it is the result of a method call? As you see, it is not
that easy and can incur some overhead you might not want to pay either.

Having said that, nobody forces you to create complex expressions. You
can help readability and maintainability a lot if you break those down -
which in turn makes debugging easier.

In some of my latest scripts I have this:

def preventNil(*args)
args.each_with_index do |arg, i|
raise ArgumentError.new("argument #{i} cannot be nil") if arg.nil?
end
end

I'd be interested to hear if there are nicer solutions to this problem.

The problem I see here is that the fact it's not nil does not tell you
that it is actually a proper value. So at best you only catch some
errors with this approach.

Kind regards

robert

 

[Justin Collins]

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?

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.

The thing is, Ruby is not returning "nil" error messages, it's returning
error messages which are consistent across all NoMethodError and
TypeError exceptions (in these cases). More generally, nil is not
getting any kind of special treatment. I think this is kind of nice,
personally.

-Justin

 

[Hugh Sasse]

This is one of the things I find irritating as well. Normally Ruby
is rightly praised for not getting in the way of productivity, but
this really does force one to program to meet constraints which are
not actually part of the language as such.

I'm not aware of a programming language that DOES report this. Remember

Some other languages report things differently....
[...]

NullRefError in C#, or segfault in C would be. Since the undefined
method was #+, the culprit was the expression that a method of that name
was called on in that code snippet.

...but in many conventionally constructed arithmetic expressions there
will be more than one plus sign. Some languages use an arrow

y = (a * x**3) + (b * x * x) + (c * x) + d
^
|
-----------------------+

or similar. Evidence? The %p construct in vim errorformats
in compiler files for handling error messages, which uses
the arrow to pick up the column:

/usr/local/share/vim/vim70/compiler/ant.vim: \%A\ %#[%.%#]\ %f:%l:\ %m,%-Z\ %#[%.%#]\ %p^,%C\ %#[%.%#]\ %#%m
/usr/local/share/vim/vim70/compiler/bdf.vim: \%-Z%p^,
/usr/local/share/vim/vim70/compiler/eruby.vim: \%-Z%p^,
/usr/local/share/vim/vim70/compiler/fortran_cv.vim: \%-Z%p%^%.%#,
/usr/local/share/vim/vim70/compiler/fortran_elf90.vim: \%C%p\|,
/usr/local/share/vim/vim70/compiler/fortran_g77.vim: \%-C\ \ \ %p%*[0123456789^]%.%#,
/usr/local/share/vim/vim70/compiler/hp_acc.vim: \%Z\ \ \ \ %p^%.%#,
/usr/local/share/vim/vim70/compiler/icc.vim:CompilerSet errorformat=%-Z%p^,%f(%l):\ remark\ #%n:%m,%f(%l)\ :\ (col.\ %c)\ remark:\ %m,%E%f(%l):\ error:\ %m,%E%f(%l):\ error:\ #%n:\ %m,%W%f(%l):\ warning\ #%n:\ %m,%W%f(%l):\ warning:\ %m,%-C%.%#
/usr/local/share/vim/vim70/compiler/intel.vim: \%-Z\ \ %p^,
/usr/local/share/vim/vim70/compiler/irix5_c.vim: \%-Z\ %p^,
/usr/local/share/vim/vim70/compiler/irix5_cpp.vim: \%-Z\ \ %p%^,
/usr/local/share/vim/vim70/compiler/javac.vim:CompilerSet errorformat=%E%f:%l:\ %m,%-Z%p^,%-C%.%#,%-G%.%#
/usr/local/share/vim/vim70/compiler/mips_c.vim: \%-Z\ \ %p^,
/usr/local/share/vim/vim70/compiler/mipspro_c89.vim: \%-Z%p%^,
/usr/local/share/vim/vim70/compiler/mipspro_cpp.vim: \%-Z\ \ %p^,
/usr/local/share/vim/vim70/compiler/ruby.vim: \%-Z%p^,
/usr/local/share/vim/vim70/compiler/xmllint.vim: \%-Z%p^,

So it looks like Ruby does this occasionally itself.

[...]


Further diagnostics (why it could have possibly happened) is the role of
a static code analysis tool; since it's sooner or later guesswork it's

Which doesn't apply in dynamic languages like Ruby where method creation
on the fly is the norm (attr_accessor, method_missing, and more).

not the task of the interpreter itself.

Coding defensively and using sanity checks on the return value of #index
and other methods that may return nil would also have helped.

This doesn't mean that is is undesirable that Ruby do more. This is
shifting the burden from the developers of ruby to the many users
of it. Not to suggest that the developers have all the time in the
world, but to say that more people are affected by not having this than
are affected by having to implement it.

Now, I would be the first to say that writing parsers is not easy.
I have tried on a number of occasions, and frankly, I am rubbish at
it. Given the constraints imposed by YACC on the future of the
language (see other threads in the past) I suspect that moving to
some other parser may be helpful. But the point of this post is
that there is evidence from other languages that it is possible for
Ruby to be more helpful, there is a desire among its users that it
be more helpful. The next question, which I can't answer given my
weaknesses in this area, is: how can this be improved? Or,
conversely, can it be shown that improving it would be detrimental
to Ruby in some important way?

We know Ruby is excellent. That's why we'd like it to be even better.

Hugh

 

[David Vallner]

--------------enigAE0DCD69AD8736E4596C0D0E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=20
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?
=20

Probably not, to my best knowledge, a source file is always tokenized
and parsed into an AST before interpreting. The interpreter would have
to do extra work to reconstruct the last expression, which might not
really be helpful always, or even in most cases. (Someone with more
information on the interpreter's internals could say this with more
authority.)

David Vallner


--------------enigAE0DCD69AD8736E4596C0D0E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFZC8ty6MhrS8astoRAj7uAJ44DC10DF24CgOgMwA6Uluu4OrVmgCfa3ry
Dh309YxFA1UKzYSz12i59fg=
=Amwm
-----END PGP SIGNATURE-----

--------------enigAE0DCD69AD8736E4596C0D0E--

 

[Martin DeMello]

istart = string.index(starting) + starting.length [...]

undefined method `+' for nil:NilClass

Other people have said this, but just to put it explicitly:

Ruby has a message-passing object model - every operation consists of
a message sent to an object. Thus, there are no symmetrical operations
- even binary operations like + translate internally to one object
being sent to the other as part of a "+" message. Indeed, you could
even write the above as

istart = string.index.starting.+(starting.length)

to make it explicit that there's a method call going on under the hood.

One consequence of this is that when an exception or error is thrown,
it is thrown from the context of the receiving object. Thus "undefined
method `+' for nil:NilClass" means you have attempted to call
nil.+(something), not something.+(nil). That should help greatly in
debugging stuff.

martin

 

[David Vallner]

--------------enigD62F977933D999B110F27AC5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=20
This is one of the things I find irritating as well. Normally Ruby=20
is rightly praised for not getting in the way of productivity, but
this really does force one to program to meet constraints which are
not actually part of the language as such.

I'm not aware of a programming language that DOES report this. Remembe=

r
=20
Some other languages report things differently....
[...]

NullRefError in C#, or segfault in C would be. Since the undefined
method was #+, the culprit was the expression that a method of that na= me
was called on in that code snippet.

=20
...but in many conventionally constructed arithmetic expressions there
will be more than one plus sign. Some languages use an arrow
=20
y =3D (a * x**3) + (b * x * x) + (c * x) + d
^
|
-----------------------+
=20
or similar. Evidence? The %p construct in vim errorformats
in compiler files for handling error messages, which uses
the arrow to pick up the column:[/QUOTE]

You might want to look up the definition of evidence, this is stretching
the word way, WAY too far.

I haven't been able to get either .NET/C# or Java to show me where on a
line a NRE/NRE occured.

The arrows you mention are probably for compile-time errors. Read: while
the source code is being read, is present in it's textual
representation, and the errors detected are ones that can be determined
from the structure of the source code. A NPE is a *runtime* error, long
after the textual form of the code is under green pastures.

=20
So it looks like Ruby does this occasionally itself.
[...]
=20

Probably for parse-time errors.

It is completely irrelevant if some languages detect some classes of
errors with precise source code locations, or that Ruby does this sort
of diagnostics at parse-time for other classes of errors than the one at
hand, when you can't bring a specific, valid counterexample to my
statement, which is that I can't recall a language that does that for
runtime errors, specifically of the dangling pointer class of errors.

Provide me with an example where a runtime problem in a complex
expression like the one you mentioned gives you exact source code
position, preferrably in a programming language I've actually heard of
before (there's enough of those), and I'll concede this point.

=20
Which doesn't apply in dynamic languages like Ruby where method creatio= n
on the fly is the norm (attr_accessor, method_missing, and more).
=20

That's a price you pay for using a dynamic language with relatively
little mainstream penetration, those tools are harder to develop, have
to rely on less conclusive heuristics, there's a smaller market for them
and little chance of someone implementing them without a market because
they'd end up solving problems a lot of people consider a non-issue. If
you want tool support, Java beckons, otherwise wait until Ruby
equivalents emerge. It's also unrelated to the issue at hand.

Specifically, it doesn't imply (except in wishful thinking) that it
should be the job of the interpreter to provide possibly (probably)
unrelated "this -might- have gone wrong" type of information. The Ruby
interpreter's behaviour as it is is in my opinion correct and complete -
it provides the programmer with all the information it has at the time
from the information it needs to run the program. I am strongly opposed
to losing interpreter runtime efficiency (from keeping full program
source code intact in memory, for example) to provide heuristic diagnosti=
cs.

=20
This doesn't mean that is is undesirable that Ruby do more. This is=20
shifting the burden from the developers of ruby to the many users
of it. Not to suggest that the developers have all the time in the
world, but to say that more people are affected by not having this than=

are affected by having to implement it.
=20

For me, it is undesirable. If it's a problem that can be solved within
the standard library by providing a set of DbC -ish metaprogramming
features, be it so. Same if it's a missing feature that can be
implemented without ambiguous output.

And for features that are clearly in the domain of code analysis tools,
I'm clearly against. Yes, such tools are absent in the Ruby domain. This
however doesn't imply the core interpreter should become one. I don't
want it to become a full-blown development tool, or any other form of
bloated monstrosity, the core responsibility of the interpreter is to
run Ruby code, and say when it can't stating the immediate reason why.

Now, I would be the first to say that writing parsers is not easy.
I have tried on a number of occasions, and frankly, I am rubbish at
it. Given the constraints imposed by YACC on the future of the
language (see other threads in the past) I suspect that moving to
some other parser may be helpful. But the point of this post is
that there is evidence from other languages that it is possible for
Ruby to be more helpful, there is a desire among its users that it
be more helpful.

I'll repeat that I haven't seen evidence that this class of errors is
diagnosed with the level of detail you'd like in a language with a
computation model similar to Ruby from you.


David Vallner


--------------enigD62F977933D999B110F27AC5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFZM9Ey6MhrS8astoRAiwTAJ9+f1EyGMSC+E1p5dzd1Z8iAQAWXQCfYD/i
YF7xu02eYAmP7jdagl5SToU=
=RSPk
-----END PGP SIGNATURE-----

--------------enigD62F977933D999B110F27AC5--