Mike C. wrote:
So, IMHO, the primary cause is the absence of those pesky statement
terminators.
Ruby has a statement terminator, it’s just optional. If this is an issue
for you, feel free to use it.
Feeding the file:
1 class Foo
2
3 def baz
4 puts ‘quux’;
5 end
6
7 def foo
8 puts ‘bar’;
9 return Integer(“10”;
10 end
11
12 def fred
13 puts ‘barney’
14 end
15
16 end
to ruby results in:
foo.rb:9: syntax error
foo.rb:16: syntax error
And the parser fails rather cleanly on the first unclosed paren. It’s
not quite as if the syntax were strict, and I’m sure some things can
slip through, but it’s a help.
Ruby isn’t about enforcing rules and making decisions for you, it’s
about TIMTOWDI and adopting conventions that help you personally from
the options available.
David V.
From: “Hal F.” [email protected]
reached the end of file while parsing the expression that started
on line 1. 
That was, indeed, the very nub of my gist. 
Regards,
John Cleese
good point. I forgot about them being optional. Of course, the example
also proves the point that statement terminators facilitate
better reporting of these types of errors.
Bill K. wrote:
That was, indeed, the very nub of my gist. 
Apparently I’m better at replying than reading.
Hal
Mike C. wrote:
Of course, the example also proves the point that statement
terminators facilitate better reporting of these types of errors.
That they do, but one of the appeals of Ruby at least to me is that the
parser / compiler doesn’t force you to take precautions against errors
that you think don’t bite you.
And this thread has had quite a few people say that they think this
problem is at least for them a non-issue for various reasons - like
typing empty parens or def/end pairs and then filling them in, and / or
adhering to fine-grained modularisation with very short source files
that make syntax errors like this that slip fairly easy to find.
The fact Ruby allows for syntax that is problematic to analyse when
faulty might seem newbie-unfriendly, but a lot of those syntax features
are on the other hand what people with some experience like and prefer.
Making statement terminators compulsory would be facilitating adoption
of the language at the expense of taking away a positive quality of the
language I consider unacceptable.
David V.
My point was not to say that it was a problem for Ruby to not have
statement terminators. I was trying to answer
the question as to why the user was getting his error reported at EOF.
It’s also pertinent because a lot of
discussion has been around the need for “better error messages”. While
I have certainly seen cases where Ruby
error messages could be better, I don’t think a little more work on
error messages is going to correct his issue.
It’s implicit with the lack of statement terminators.
I didn’t mean to imply that means Ruby should force statement
terminators.
David V. [email protected] wrote:
The fact Ruby allows for syntax that is problematic to analyse when
faulty might seem newbie-unfriendly, but a lot of those syntax
features are on the other hand what people with some experience like
and prefer. Making statement terminators compulsory would be
facilitating adoption of the language at the expense of taking away a
positive quality of the language I consider unacceptable.
+1
robert
On 8/21/06, Mike C. [email protected] wrote:
My point was not to say that it was a problem for Ruby to not have
statement terminators. I was trying to answer
the question as to why the user was getting his error reported at EOF.
It’s also pertinent because a lot of
discussion has been around the need for “better error messages”. While
I have certainly seen cases where Ruby
error messages could be better, I don’t think a little more work on
error messages is going to correct his issue.
It’s implicit with the lack of statement terminators.
Just about every language and compiler I’ve run across in 30+ years
has shown some head-scratching syntax errors, usually caused by a
mis-matched pair of somethings. The solution has always been some form
of tool besides the syntax error messages:
The old-fashioned way was for the compiler to produce a listing with
annotations on the side showing nesting levels of things like do/end
procedures/functions and their ends etc.
Proc Do
0 0 Function foo(a,b)
1 0 do while something
1 1 sing(a)
1 1 do something else
1 2 skip(b)
1 1 end
1 1 frobnitz()
1 0 end
0 0 end
Of course that looks ancient to anyone but us old greybeards who cut
our teeth on keypunches instead of vi or emacs.
The more modern way is to eschew listings in favor of editors which
are somewhat knowledgable of the language syntax and can do things
like fold, indent, and find matching items.
Back when I did Lisp, I learned techniques like numbering parentheses
myself:
(a (b c)( (( (d e) f) ) ) ))))))))))
0 1 11234 4 3210
And of course those old Lots of Irritating Silly Parentheses
evaluators would throw away those unneeded closing parens.
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/