Daniel M. wrote:
I’ll note that perl has a similarly flexible syntax,
I don’t think so. For example, you must terminate statements with a “;”
(or did that change in the latest version?) and you cannot omit
parentheses. That makes up for a significant difference in flexibility
of the two languages.
yet I don’t hear
people new to perl complaining about this. Perhaps this is because
perl has more to complain about, from a newbie perspective, but I
think it’s also because perl gives better syntax error messages. For
example, if you get a runaway unclosed string or regexp (//) operator,
the perl interpreter will, in the syntax error, also say something
like “possible runaway string beginning line NN”.
I know that perl does this and I liked that at the time when I used
perl. But:
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.
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.
Kind regards
robert
On 8/18/06, Daniel M. [email protected] wrote:
when expecting tEND, or ‘]’, or some other nested thing that can go
off the end of the file.
Perl also has a separate compile step. (It may not seem like it, but
it does, internally.)
-austin
On 8/18/06, M. Edward (Ed) Borasky [email protected] wrote:
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
quoth the Just Another Victim of the Ambient M.:
def some_function
def some_method
@member[@other + 2]
end
Some editors (kate for one) can even do this for you. Type a single or
double
quote and it will close it for you, as well as for all manner of
braces ‘(’, ‘{’, ‘[’…
I tried used it myself for a while but found it too annoying, as I
generally
closed my own braces out of habit, and there are those times when you
really
do just want opening braces…
-d
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.
btw - using textmate indent catches missing ], ), but not extra .
James B.: 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.
Daniel M. wrote:
Robert K. [email protected] writes:
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.
Just Another Victim of the Ambient M. wrote:
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
On Aug 18, 2006, at 21:08, inboulder wrote:
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’?
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.
Matthew S. wrote:
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.
matthew smillie.
Bill K. wrote:
The compiler throws away the line # of the start of the expression it
0005: end
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
From: “inboulder” [email protected]
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
Firstname S. a écrit :
Robert K. schrieb:
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/
–
Lionel T.
Personal web site: http://users.skynet.be/lthiry/
Mat S. wrote:
-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.
M. Edward (Ed) Borasky wrote:
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
From: Hal F. [mailto:[email protected]]
Bill K. wrote:
> 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.
is it possible for ruby to return list of end pairs pretty printed
(think folding)?
Error: unexpected EOF, missing kEND from line 1.
Listing end pairs encountered:
0001: class Foo
0003: def initialize
0005: end
0347: def bar
0348: if @gargle
0360: end
0416: end # of class Foo
<— missing end here
an intelligent editor may then possibly associate the end pairs with the
actual code, like so (pls forgive the crude ascii art),
0001: class Foo ------------------------- 0001: class Foo
0003: def initialize … 0002:
0005: end … '… 0003: def initialize
0347: def bar -----------------… | 0004: # whatever
0348: if @gargle … | '… 0005: end
0360: end … | | 0006:
0416: end # of class Foo | | |
<–| missing end here | | |… 0347: def bar
| | |… 0348: if @gargle
| | 0349: puts “glug!”
| | 0350: #end
| |… 0360: end
|
| 0415:
|… 0416: end # of class Foo
i think this could be a good ruby quiz/challenge.
kind regards -botp
James Edward G. II wrote:
$ perl -we ‘print(“Hello world!\n”)’
Hello world!
$ perl -we ‘print “Hello world!\n”’
Hello world!
James Edward G. 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
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.
On Aug 19, 2006, at 2:05 AM, Robert K. wrote:
Hello world!
$ perl -we ‘print “Hello world!\n”’
Hello world!
James Edward G. 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 G. II
Robert K. wrote:
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.
M. Edward (Ed) Borasky wrote:
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 V.