Syntax checker wtf?

[Mike Cargal]

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.

 

[David Vallner]

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 Vallner

 

[Robert Klemme]

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

 

[Mike Cargal]

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.

 

[Rick DeNatale]

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.