From: Hugh Sasse <hgs@...>
Date: 2006-11-23T19:24:33+09:00
Subject: Re: [RANT] Error messages - was: [OT] Bug in ruby?

On Thu, 23 Nov 2006, David Vallner wrote:

> Hugh Sasse wrote:
> > 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:
> 
> You might want to look up the definition of evidence, this is stretching
> the word way, WAY too far.

Are we talking evidence for civil or criminal cases here?  :-)
I have provided evidence for diagnostic messages pointing to the point
in the line where the error occurs.  I concede that usually this is
for syntax errors.  See below.
> 
> 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

They generally are, I agree.  I can't assert "always", and no, I
can't provide a counter example.

> 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.

There are reasons for not throwing that information away in an
interpreter.
> 
> > 
> > So it looks like Ruby does this occasionally itself.
> >         [...]
> > 
> 
> 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

I don't tend to keep things with errors like this in lying around, 
and can't remember off the top of my head.

> statement, which is that I can't recall a language that does that for
> runtime errors, specifically of the dangling pointer class of errors.

We are not discussing pointers.  We are discussing method calls on
objects that don't support them, and stating where in the computation
this occurred.
> 
> 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.

Just because nobody does it yet, it doesn't mean it can't be done.
        [...]
> 
> 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

If it has the AST, it shouldn't have to be probabilistic.  I'm
specifically not saying this is easy, I'm saying it is desirable,
and that I accept constraints.

        [...]
> to losing interpreter runtime efficiency (from keeping full program
> source code intact in memory, for example) to provide heuristic diagnostics.

For heuristic (guesswork), I'd agree. For sufficient exactitude, then
under control of an option (like -w) I'd be in favour.
> 
> >> 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.
> > 
> 
> 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.

I don't see how one could do that for something internal to the interpreter.
> 
> 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.

It's that 'statement of the reason why' I'd like improved.
Obviously there are trade-offs, and it is up to Matz.  I'm simply
adding my voice to those that wish for improved diagnostics.  If it
is impossible, or not practical at this time, or some other
sufficient constraint to prevent this, then fine.  But if it is not
being done because there is no apparent desire for this, then I'd
like to say there is some desire for this.  I fully accept that
this may run counter to other desirable attributes, such as speed
of execution, and a decision may not go in favour of better diagnostics
as a result.  But to quote an early version of the Ruby Newsgroup FAQ:
http://www.rubycentral.com/faq/ruby_newsgroup_faq.txt
'You could characterize the Ruby philosophy as "there's a better way
to do it" (TABWTDI).' 

        Hugh