> irb should also treat symbols that way -- and not halfway interpret
> them as operators. (I say "halfway" because on the one hand it waits
> for the next line, as it would with a dangling operator; but on the
> other hand, it then just throws away the symbol and evaluates the next
> line as if it stood alone.)
No. It does not discard it; it's simply the effect of syntax. Consider this:
ruby -e 'p eval(":-; 1")'
There are two expressions evaled here, ":-" and "1".
ruby -e 'p eval(":-\n1")'
Just as above, there are two expressions. IRB *does not strip
newlines*; and when evaling some code, only the result of last
expresion is returned.
The only bug here (or, IMO, a lack of feature) is that IRB does not
parse the code at all; it simply checks if the line ends with an
operator, a dot or a backslash, and in this case does not eval code
immediately, but joins it with next line of input.
-- Matma Rex
So, if I'm reading you correctly, in your opinion, the real lacking
feature of IRB might be stated by demonstrating that, due to the fact
that IRB doesn't parse the code, the following fails:
1.9.2p290 :001 > "Hello world"
=> "Hello world"
1.9.2p290 :002 > .gsub(/Hello/, "Goodbye")
SyntaxError: (irb):2: syntax error, unexpected '.'
from /Users/kendall/.rvm/rubies/ruby-1.9.2-p290/bin/irb:16:in `<main>'
1.9.2p290 :003 >
Whereas the follow works in ruby:
$ ruby <<EOF
(no output is printed, of course, but no error is raised either).
With, of course, IRB trying to be a little helpful with some
simplistic line-parsing rules in place (as opposed to full language
parsing) which is the cause of some of the "weird" behavior that's
been pointed out (and it is "weird" to have a language environment
provided REPL tool *appear* to silently ignore lines of code since it
doesn't print out the "ignored" statement's value)
That said, it's good to understand now that it may be necessary, for
specific code statements in IRB, to explicitly terminate some lines of
1.9.2p290 :001 > :- ;
1.9.2p290 :002 >
1.9.2p290 :003 >
Oops! IRB just ignored my explicit semi-colon???
2012/3/1 Bartosz Dziewoński <firstname.lastname@example.org>
2012/3/1 Eric Christopherson <email@example.com>: