On Wed, 22 Nov 2006, David Vallner wrote:

> Charles D Hixson wrote:
> > 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.

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