On 8/18/06, Firstname S. [email protected] wrote:
I think the syntax checker could be a little more verbose, and I don’t
think it would take much work.
It’d take more work than you think. See, you’ve actually got several
issues that you keep repeating in your example code, and that could be
the problem. The use of a high-quality editor and good practices will
also help.
Here’s the real trick that you’re forgetting that makes it a bit harder
for Ruby to deal with what you’re talking about: it is not just
line-oriented, it is expression oriented. Expressions may be terminated
either by an unambiguous line ending (that is, it doesn’t end with a
continuation character , comma, period, or an operator that says that
the next item will be on the next line) or semicolons.
This is perfectly legal:
abc .
foo
although it’s really bad style.
Remember, though, that:
abc
foo
is the same thing as
abc; foo
So if you have something that can expect the result of an expression
waiting open, you’ve got a mismatch immediately. More on that in a
moment.
The trouble I had was with a line that had an extra ‘.’ like:
@entry = Entry.find(params[:id].
Note that you’ve got a syntax error on this line without the extra
period. You’re missing a period. What this means very specifically is
that you’re now working on an expression that should ultimately return
something and be closed with a parenthesis. Now, if you had a closing
parenthesis, Ruby would give you a syntax error on a multiline
expression like that for a method call (or so it seems with 1.8.2 on my
as-yet default Tiger install).
It would give you the error at the end of the code:
irb(main):030:0> abc.foo(1
irb(main):031:1> +2
irb(main):032:1> +3
irb(main):033:1> +4)
SyntaxError: compile error
(irb):31: syntax error
(irb):33: syntax error
from (irb):33
So Ruby’s smart enough to tell you what’s going on as best it can. If
you reach an “end” before your parameter list finishes, it’s going to
complain about the “end”, unless it’s matched, like so:
irb(main):039:0> abc.foo(1
irb(main):040:1> end
SyntaxError: compile error
(irb):40: syntax error
from (irb):40
irb(main):041:0> abc.foo(1
irb(main):042:1> if
irb(main):043:2* end
irb(main):044:1> end
SyntaxError: compile error
(irb):42: syntax error
from (irb):44
As you can see, Ruby is quite a bit smarter than you think – but it
can’t tell that that parenthesis is the start of the problem. I don’t
think that a C/C++ compiler could tell that, either.
and another error that i think was just a missing bracket maybe like
@entry = Entry.find(params[:id
Again, [] expects the result of an expression. These two are equivalent:
params[:id]
params.[](id)
I’ve used many different languages with various levels of syntax error
help, but never one this bad.
I personally doubt that. I think that you’re expecting a magic bullet
because you’re hearing a lot of hype about Rails, and it’s not. Believe
me, Ruby’s syntax errors may not be the best, but there are two points
to consider toward making them better:
- There is no compile step as such. Compiling and execution time are
the same. This means that:
- Increasing the amount of data kept around during parsing to report
better syntax errors increases the amount of data that must be kept
in the interpreter for your program and probably not disappear for
the life of your program.
Can they be better? Yes. But for Ruby to keep track of where each
parenthesis was opened (etc.) and report back that value instead of
where the specific ending token was found that Ruby does report on
would require significantly more memory during parsing.
It has been suggested that we might be able to take advantage of a
lint-like tool, but most people who have suggested such have not found
it to be worth the amount of effort as opposed to using a really good
editor with folding and syntax highlighting.
I just wrote a quick script to remove functions from ‘def’ to ‘end’ in
order and check the syntax over, thus quickly finding which function
the error is in.
A good editor would help you with that far more than having to write a
quick script.
This is a lot better than looking through a couple hundred line
controller file.
Your controller may be too large, then.
If I can do this in 10 minutes, I can’t help but think it’s just
laziness on the part of the syntax checker not to provide at least
hints where it thinks the problem might be.
If it doesn’t carry that information around, then it can’t. And it’s not
laziness on the syntax checker’s part. I think you’re misunderstanding
what’s necessary for parsing this sort of error.
I understand that ruby is flexible (I’m not not sure this is a merit
when using for a large web app), but the checker could easily check
based on ‘standard’ expected syntax and be more helpful about error
location 99% of the time.
Not really. The “standard” expected syntax has changed. Remember, both
of these are legal and equivalent:
foo = bar :baz
foo = bar(:baz)
I think you’re expecting more than you’re going to get from any syntax
checker except a lint-like thing.
-austin
