Bill Kelly wrote:
> From: "inboulder" <rubyforum / wendlink.com>
> 
>> Matthew Smillie wrote:
>>
>>>
>>> Actually yes.  Error identification and recovery in parsing is a
>>> difficult task to begin with, engineering it into an existing system
>>> is far from trivial.
>>>
>>
>> The compiler throws away the line # of the start of the expression it 
>> is trying to evaluate? Keeping this # around and printing it out would 
>> be a great step in improving the debug info.
> 
> 
> I wonder...
> 
> 0001: class Foo
> 0002:
> 0003:   def initialize
> 0004:     # whatever
> 0005:   end
> 0006:
> [...]
> 0347:   def bar
> 0348:     if @gargle
> 0349:       puts "glug!"
> 0350:     #end  (missing end for if)
> 0360:   end
> [...]
> 0415:
> 0416: end    # of class Foo
> 
> Now, the error message we'd like is that the 'end' is missing for the 'if'
> expression starting on line 348.
> 
> But the parser did find an 'end' that paired up with the 'if', at line 360.
> And it found an 'end' for the 'def' at line 416.  Ultimately, it reaches 
> the
> end of the file, and is missing an 'end' for 'class Foo'.
> 
> So, would "unexpected EOF, missing kEND from line 1" really be all
> that helpful?
> 
> It seems like a missing 'end' would probably tend to be reported for
> whatever line the outermost class or module being compiled started
> on... (?)

This is sort of an interesting idea, discussed before. I wonder what
Matz thinks about it. It's not like "enforcing" indentation, it's just
using it to "guess" about a syntax error.

Of course, the way it works now, it DOES find an 'end' for the 'if'...
it's on line 360. :)  What it doesn't find is an end for the class...

So unless it was whitespace-sensitive, it would tell you that it
reached the end of file while parsing the expression that started
on line 1.  :)


Cheers,
Hal