Syntax checker wtf?

Mike Cargal 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 Vallner

"David Vallner" <david@vallner.net> wrote in message
news:op.teg4b0gclyznzu@new.chello.sk...

the checker could easily check
based on 'standard' expected syntax and be more helpful about error
location 99% of the time.

That's what a lint style program would do, not the compiler. Compilers
are there to check correctness against the formal language definition,
not to make opinions about your code, and quoting 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.

    That's sufficiently harsh that it's rather unfair.
    Okay, so you fed the interpeter bad input but, you know what? Good
software tells you why your input was bad and the original poster isn't
getting the feedback he was hoping to get. Now, perhaps his expectations
aren't realistic but you can simply tell him why they're not realistic
rather than effectively telling him that he just sucks...

    Personally, I don't think there's anything wrong with protecting code
from human error considering how it's written for humans. Ruby still has
access permissions. If Ruby really trusted the programmer, it wouldn't
bother with public and private methods. If you're not supposed to call
that method, then don't call it! It's that simple. That's what Python
does...

If you think the syntax checking in the compiler could be made better, go
ahead and hack the parser to do it. But I don't recall this topic being
present on the list and complained about any often or so vocally, so I
doubt it's critical that effort be spent from the core Ruby developer
team in that direction.

    Well, it may be true that we have better things to do (I, too, have
never encountered the problems the original poster is having), but he's
simply telling us what he finds important. If enough people complained
about it, I'd imagine work would be done on the problem...

Oh, before I forget: Whining gets you nowhere, and trolling belongs to
slashdot. Cut that out.

    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...

···

On Fri, 18 Aug 2006 09:58:31 +0200, Firstname Surname > <rubyforum@wendlink.com> wrote:

That raises an interesting question (at least for a noob like me). Is
there any (good) lint available for Ruby (and for RoR as a second question)?

/Thomas

David Vallner wrote:

···

On Fri, 18 Aug 2006 09:58:31 +0200, Firstname Surname > <rubyforum@wendlink.com> wrote:

the checker could easily check
based on 'standard' expected syntax and be more helpful about error
location 99% of the time.

That's what a lint style program would do, not the compiler. Compilers
are there to check correctness against the formal language definition,
not to make opinions about your code, and quoting 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.

If you think the syntax checking in the compiler could be made better,
go ahead and hack the parser to do it. But I don't recall this topic
being present on the list and complained about any often or so vocally,
so I doubt it's critical that effort be spent from the core Ruby
developer team in that direction.

Oh, before I forget: Whining gets you nowhere, and trolling belongs to
slashdot. Cut that out.

David Vallner

Austin Ziegler 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.

I think what's most troubling to the original poster is something that I
have such a problem with that I more or less refuse to use it. That is
the pseudo-flexibility offered by having "open syntactic elements"
designate that the next line continues a statement or expression, rather
than forcing an error as older languages did.

In short, if I type

a = (b +

to an interpreter, I want it to complain that I'm missing an operand and
a right paren, *not* go blindly ahead expecting

c) /
sqrt(7**15
) - (olive**oil)

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 "\".

···

On 8/18/06, Firstname Surname <rubyforum@wendlink.com> wrote:

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 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

···

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

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 .

···

--
Posted via http://www.ruby-forum.com/\.

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.

···

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'?

James Edward Gray II wrote:

···

On Aug 18, 2006, at 10:10 AM, Robert Klemme wrote:

Daniel Martin 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.

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. :slight_smile: But the necessary expression termination is still in place, isn't it?

Thanks for the correction, James!

Kind regards

  robert

+1

    robert

···

David Vallner <david@vallner.net> 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.

Ruby does trust the programmer. The privacy screen is very flimsy:

class Foo
private
  def dont_call_me
    puts("I said DON'T CALL ME!")
  end
end

f = Foo.new
f.dont_call_me
# NoMethodError: private method `dont_call_me' called for #<Foo:0x34293c>

f.__send__(:dont_call_me)
# I said DON'T CALL ME!

Paul.

···

On 18/08/06, Just Another Victim of the Ambient Morality <ihatespam@rogers.com> wrote:

    Personally, I don't think there's anything wrong with protecting code
from human error considering how it's written for humans. Ruby still has
access permissions. If Ruby really trusted the programmer, it wouldn't
bother with public and private methods. If you're not supposed to call
that method, then don't call it! It's that simple. That's what Python
does...

"David Vallner" <david@vallner.net> wrote in message
news:op.teg4b0gclyznzu@new.chello.sk...

the checker could easily check
based on 'standard' expected syntax and be more helpful about error
location 99% of the time.

That's what a lint style program would do, not the compiler. Compilers
are there to check correctness against the formal language definition,
not to make opinions about your code, and quoting 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.

    That's sufficiently harsh that it's rather unfair.
    Okay, so you fed the interpeter bad input but, you know what? Good
software tells you why your input was bad and the original poster isn't
getting the feedback he was hoping to get. Now, perhaps his expectations
aren't realistic but you can simply tell him why they're not realistic
rather than effectively telling him that he just sucks...

    Personally, I don't think there's anything wrong with protecting code
from human error considering how it's written for humans. Ruby still has
access permissions. If Ruby really trusted the programmer, it wouldn't
bother with public and private methods. If you're not supposed to call
that method, then don't call it! It's that simple. That's what Python
does...

If you think the syntax checking in the compiler could be made better, go
ahead and hack the parser to do it. But I don't recall this topic being
present on the list and complained about any often or so vocally, so I
doubt it's critical that effort be spent from the core Ruby developer
team in that direction.

    Well, it may be true that we have better things to do (I, too, have
never encountered the problems the original poster is having), but he's
simply telling us what he finds important. If enough people complained
about it, I'd imagine work would be done on the problem...

Oh, before I forget: Whining gets you nowhere, and trolling belongs to
slashdot. Cut that out.

    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...

···

On Fri, 18 Aug 2006 12:30:14 +0200, Just Another Victim of the Ambient Morality <ihatespam@rogers.com> wrote:

On Fri, 18 Aug 2006 09:58:31 +0200, Firstname Surname >> <rubyforum@wendlink.com> wrote:

No. Most people who want to write one tend to lose interest quickly as
they start adopting better practices. :wink:

-austin

···

On 8/18/06, Thomas <notpublic@not.public> wrote:

That raises an interesting question (at least for a noob like me). Is
there any (good) lint available for Ruby (and for RoR as a second question)?

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

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 "\".

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

···

On Aug 18, 2006, at 9:43 AM, M. Edward (Ed) Borasky wrote:

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

···

On 8/18/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> 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 "\".

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

Just Another Victim of the Ambient Morality 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

Matthew Smillie 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.

--
Posted via http://www.ruby-forum.com/\.

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

James Edward Gray II

···

On Aug 19, 2006, at 2:05 AM, Robert Klemme wrote:

James Edward Gray II wrote:

On Aug 18, 2006, at 10:10 AM, Robert Klemme wrote:

Daniel Martin 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.

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. :slight_smile: But the necessary expression termination is still in place, isn't it?

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.

Robert Klemme wrote:

···

David Vallner <david@vallner.net> 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

Matthew Smillie 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.

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

···

From: "inboulder" <rubyforum@wendlink.com>

Mat Schaffer 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 "\".

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.

···

On Aug 18, 2006, at 9:43 AM, M. Edward (Ed) Borasky wrote: