Syntax checker wtf?

[Austin Ziegler]

Yes, that's a contrived example, but as far as I'm concerned, if end of
line terminates a "statement", then continuation of a line should
require an *explicit* continuation designator, such as "\".

Um. I'd accept your statement, except that lines *aren't* statements
in Ruby. They're expressions. It does make a bit of a difference to
the whole thing. If an expression is complete on a line, then it's a
complete expression. If it isn't, then it isn't and Ruby keeps
looking. IMO, sensibly.

-austin

 

[darren kirby]

--nextPart12193962.OgB0LmhuRo
Content-Type: text/plain;
charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

quoth the Just Another Victim of the Ambient Morality:

Okay, judging from your examples, I think the problem is that you're
hitting a rather sore spot in the Ruby interpreter. I've done a few
examples and it looks as if the Ruby parser does a lazy evaluation of
parenthesized (and bracketed) things. It just so happens that these are
exactly the kind of mistakes you make so they really seem to bite you.
The only thing I can suggest is that you close all your brackets and
functions before filling them. So, while editing, you'll write things in
this order:

def some_function
end

..and then...

def some_method
@member[]
end

...and finally...

def some_method
@member[@other + 2]
end

Some editors (kate for one) can even do this for you. Type a single or doub=
le=20
quote and it will close it for you, as well as for all manner of=20
braces '(', '{', '['....

I tried used it myself for a while but found it too annoying, as I generall=
y=20
closed my own braces out of habit, and there are those times when you reall=
y=20
do just want opening braces...

=2Dd =20
=2D-=20
darren kirby :: Part of the problem since 1976 :: http://badcomputer.org
"...the number of UNIX installations has grown to 10, with more expected..."
=2D Dennis Ritchie and Ken Thompson, June 1972

--nextPart12193962.OgB0LmhuRo
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBE5gSKwPD5Cr/3CJgRAq2eAKDeP3avuOEHiveHIwROAqqKekfG2QCeJV7W
WGkbpNnTBKfsQKFlMjyHlhM=
=aIMH
-----END PGP SIGNATURE-----

--nextPart12193962.OgB0LmhuRo--

 

[inboulder]

James Britt: Ruby assumes the

developer is a grown-up. If you're newbly enough to make trivial syntax
errors, noone's forcing you to use the language.

Yeah, that guys sounds like a lot of fun at parties.

This seems to me like it would be a simple addition to the ruby
parser, to mention the line number of the thing it's trying to close
when expecting tEND, or ']', or some other nested thing that can go
off the end of the file.

Bingo, that sounds like an awesome idea. I've seen the 'possible runaway
expression' type errors in a bunch of compilers starting with Borland
turbo c++ in '93 that used to say things like 'possible unterminated
string on line x' etc. I understand that ruby doesn't have line
termination and is expressions, but I don't get yet why the compiler
couldn't tell you the line where the unterminated expression started.

IMHO you're greatly underestimating the effor. I guess even for perl it
was not "a simple addition" - and from what I can see a lot more efforts
were put into perl vs. ruby.

Would it really be that difficult to say 'unterminated expression
started on line 10' rather than 'syntax error - last line of file - go
fish'?

I get messages like this occasionally. I've found that a good editor is
the most helpful thing in finding these errors. I use TextMate on my
Mac.

Thanks, this is a big help, it took me awhile to figure out the
keystroke for auto indent in Textmate.

 

[inboulder]

Thanks, this is a big help, it took me awhile to figure out the
keystroke for auto indent in Textmate.

btw - using textmate indent catches missing ], ), but not extra .

 

[Matthew Smillie]

Would it really be that difficult to say 'unterminated expression
started on line 10' rather than 'syntax error - last line of file - go
fish'?

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.

While I usually find "go change it yourself" to be a little
dismissive, in this case it's pretty applicable; delve into the
source and see how errors are handled and it'll give you a little
perspective on the task. I might also recommend a good uni course on
compilers and language design.

matthew smillie.

 

[Hal Fulton]

You could cut him some slack. It's pretty easy to get frustrated with
these stupid machines. A lot of things really should "just work" and it
can get frustrating when they don't, especially after everyone proselytizes
it as the solution to all their problems...

"Everyone"? I don't. And besides, anyone who thinks that ANYTHING is the
solution to all his problems is naive.

Having said that: I do think the parser's errors could stand some
improvement. But writing parsers is hard, and Ruby's is harder
than most. (Just ask anyone who's tried to reproduce the parser.)

By all means, let's improve the messages if we can. But I don't that
it's trivial.


Hal

 

[inboulder]

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.

 

[Bill Kelly]

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... (?)


Regards,

Bill

 

[Lionel Thiry]

Firstname Surname a écrit :

I think the syntax checker could be a little more verbose, and I don't
think it would take much work.

http://rubyforge.org/projects/rubygrammar/

http://rubyforge.org/pipermail/rubygrammar-grammarians/

 

[Hal Fulton]

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

 

[M. Edward (Ed) Borasky]

But then you open up the reverse problem with an example like

if (very long condition that hangs off the end of the page)
|| (another condition)

Raising a syntax error that you have to go back and add a \ to. I don't
know if you can say for sure which is the lesser of two evils.
Requiring ;'s to terminate statements or requiring \'s to continue
them. So ruby just avoids them both by having really flexible syntax.

As for my opinion/idea on the topic, what about adding some lint
checking when you use ruby -c ? That way a regular app wouldn't incur
the memory, but you could still get the job done without requiring an
external lint program. Obviously someone would have to write this, and
it's not gonna be me. Just trying to get ideas circulating.

-Mat

I guess the *real* answer is that every multi-lingual programmer evolves
a programming style that allows (somewhat) rapid switching between
languages and allows *easy* reading of the source by the programmer and
any colleagues that might need to do so. I started with macro assembler
and FORTRAN, so a one-line statement with a continuation required is
"natural" to me.

For a long time, when I migrated from Perl to R, I put in lots of extra
semicolons in the R code to make it easier for me to remember them when
I went back to Perl. And if I find a huge expression or condition, I try
to factor it into meaningful functions/methods/procedures. So I would
write (in R):

valid-date <- function(x) {
x$date <="2006-08-01" & x$date >= "2006-05-01";
}

valid-utilization <- function(x) {
x$util < 104.0;
}

valid-data <- function(x) {
valid-date(x) & valid-utilization(x);
}

...

qx <- subset(qz, valid-data(q));

...


Now R is a functional language with (two kinds of) objects, not an
"object-oriented language". But I think I'd write the same way in Ruby.

 

[Robert Klemme]

Both Perl and Ruby allow parenthesis to be dropped in most cases:

$ perl -we 'print("Hello world!\n")'
Hello world!
$ perl -we 'print "Hello world!\n"'
Hello world!

James Edward Gray II

There you can see how long it is that I've used Perl. But the
necessary expression termination is still in place, isn't it?

Thanks for the correction, James!

Kind regards

robert

 

[Robert Klemme]

Now R is a functional language with (two kinds of) objects, not an
"object-oriented language". But I think I'd write the same way in Ruby.

Proper modularization helps readability and understanding in *every*
programming language regardless of the idiom.

Kind regards

robert

 

[James Edward Gray II]

There you can see how long it is that I've used Perl. But the
necessary expression termination is still in place, isn't it?

Yes, Perl requires most lines to end with a semi-colon.

James Edward Gray II

 

[Mike Cargal]

Ever wonder why so many languages have explicit statement termination
characters (frequently ";")? This is one of the
main reasons. I wrote a scripting language myself and, in the process,
realized I could write a perfectly good
grammar without those statement termination characters. As we started
using it though, we started encountering many
situations like you describe. When something is left out, the parser
just keeps looking, and looking, and looking, trying to
make sense of the input stream, and eventually runs out of input and has
to report an error at the current location (EOF).
However, as soon as a added a ";" to the grammar as a statement
termination, the parser had better places to stop trying to
make sense of the input stream. (If it encountered a ";" and did not
have a valid statement, it could report the error, then and
there, reset it's state and continue parsing.)

So, IMHO, the primary cause is the absence of those pesky statement
terminators.

 

[M. Edward (Ed) Borasky]

Proper modularization helps readability and understanding in *every*
programming language regardless of the idiom.

Kind regards

robert

Exactly! Which is why Ruby can "get away with" a loose syntax, duck
typing, open syntactic elements as continuations, etc. So old
programmers like me who are new to Ruby are free to use semicolons and
curly braces the same way we do in C and Perl in R or Ruby just to
facilitate our thinking when we switch among languages.

For someone new to programming who choses to learn starting with Ruby,
though, perhaps our introductory "textbooks" ought to emphasize a coding
style that promotes factoring and readability at an equal or even
greater level than the basics of how to construct classes, objects,
methods, expressions and the other semantic elements of the language.

 

[David Vallner]

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 Vallner

 

[David Vallner]

For someone new to programming who choses to learn starting with Ruby,
though, perhaps our introductory "textbooks" ought to emphasize a coding
style that promotes factoring and readability at an equal or even
greater level than the basics of how to construct classes, objects,
methods, expressions and the other semantic elements of the language.

The introductory textbooks are supposed to teach someone to code ruby,
not to proselytize the virtues of clean design. And for what it's worth,
the code examples in those (and all books) almost always are very short,
without convoluted methods with three levels of nesting like you always
end up with when you get someone else's code to maintain *sulk*.

Putting actual emphasis on those would be beyond the scope of said
books, even if mentioning the gotchas of the loose syntax in the
appropriate parts of the book wouldn't be out of place. The problem is
the appropriate parts tend to be towards the end of the books in the
boring grammar treatises where people new to programming actually get to.

Also, readability is in the eye of the observer, I'm sure there's people
with macho-programmer nerve-twitches aplenty that would find guides like
that personally insulting. I know I met a lot... (C# partial classes
fanboys in specific.)

David Vallner

 

[Bill Kelly]

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.

That was, indeed, the very nub of my gist.



Regards,

John Cleese

 

[Hal Fulton]

That was, indeed, the very nub of my gist.

Apparently I'm better at replying than reading.


Hal