[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Wild ideas: Finding a missing 'end'

Mat Schaffer

7/29/2006 1:09:00 AM

I was just reading a nuby question from the rails list and I had this
thought:

class MyClass
def foo
if true
end
end

This code generates a parse error at the last line. Now most
languages do this, so it's not a big deal. But how frickin cool
would it be if a future version of ruby looked at the indenting and
made a guess as to where the missing end/} might be.

Like:
test.rb:5: parse error, unexpected $, expecting kEND. Did you miss
an "end" on line 4?

Maybe people have thought about this already. I'm just thinking out
loud here, really.
-Mat
6 Answers

S Wayne

7/29/2006 6:18:00 AM

0

Yes, it has been considered. Unfortunately allowing the
interpreter/compiler figure this out only works in the extremely
simple case

Consider:

a=[1,2,3]
for i in a
begin
if i > 1
x = 3*i
end
end
puts x

Obviously there is a missing end statement. However, where we put it
makes a big difference. If we put it before the puts x, we get a very
different output then if we put it after puts x. This is a simple
example as well, even more complex examples will show that it gets
very dangerous to let the interpreter figure out what you meant.

Using indentation is dangerous, because indentation doesn't mean
anything in ruby normally, and trying to figure out the right thing
would mean that we start having to be careful with indentation levels,
and code works in strange ways because we don't know ruby is 'helping'
us out. It can make for very hard to find bugs.

dblack

7/29/2006 11:54:00 AM

0

Marc Heiler

7/29/2006 12:18:00 PM

0


unknown wrote:
> Hi --
>
> On Sat, 29 Jul 2006, N Okia wrote:
>
>> x = 3*i
>> Using indentation is dangerous, because indentation doesn't mean
>> anything in ruby normally, and trying to figure out the right thing
>> would mean that we start having to be careful with indentation levels,
>> and code works in strange ways because we don't know ruby is 'helping'
>> us out. It can make for very hard to find bugs.
>
> But surely just a warning can't be harmful, even if it mentions what
> turns out to be the wrong line -- ?
>
>
> David



I agree as far as giving the coder the exact error line in a better way
than currently, yes. That would help more than scanning the code for the
missing end. :-)

--
Posted via http://www.ruby-....

Dr Nic

7/29/2006 12:32:00 PM

0

>> Using indentation is dangerous, because indentation doesn't mean
>> anything in ruby normally, and trying to figure out the right thing
>> would mean that we start having to be careful with indentation levels,
>> and code works in strange ways because we don't know ruby is 'helping'
>> us out. It can make for very hard to find bugs.

I think its better for it to guess than to just return the last line of
the file each time. Perhaps return multiple guesses.

Cheers
Nic

--
Posted via http://www.ruby-....

dblack

7/29/2006 4:54:00 PM

0

Paul Battley

7/29/2006 5:46:00 PM

0

On 29/07/06, Mat Schaffer <schapht@gmail.com> wrote:
> This code generates a parse error at the last line. Now most
> languages do this, so it's not a big deal. But how frickin cool
> would it be if a future version of ruby looked at the indenting and
> made a guess as to where the missing end/} might be.

Like this?

---

def error_line(code)
File.open('tmp.rb', 'w') do |io|
io << code
end
s = `ruby -c tmp.rb 2>&1`
if (s =~ /parse error/)
return s[/\d+/].to_i
else
return false
end
end

code = File.read(ARGV[0])

exit unless error_line(code)

lines = code.split(/\n/)

x = lines.length / 2
xmin = 0
xmax = lines.length

while l = error_line(code)
if l < x
xmax = x
elsif l > x
xmin = x
else
break
end
x = xmin + (xmax - xmin)/2
code = (lines[0,x] + ['end'] + lines[x..-1]).join("\n")
end

puts("Error around line #{x+1}")

----

This is pretty rough code that I just threw together without much
thought, but it seems to work. Its temporary file handling leaves a
lot to be desired.

Paul.