Why can't I use "or" here?

[Marnen Laibow-Koser]

Well. it turns out there aren't that many ways in ruby.

I originally tried to do the following:

some_func(ARGV[0] or raise "You must provide an argument")

I wish it worked. But it doesn't. So I changed it to:

some_func(ARGV[0] || raise "You must provide an argument")

It still didn't work. So finally I did:

some_func(ARGV[0] || (raise "You must provide an argument"))

It works. But, I must say, it isn't as beautiful as my original plan. It
doesn't read as English.

Hey, I now see that this works:

some_func((ARGV[0] or raise "You must provide an argument"))

Great. On the other hand, I won't be able to remember this the next time
I need it.

Just use Ruby's rescue syntax instead of trying to be clever.

Best,

 

[Phillip Gawlowski]

My, my, my.

I can do this:

a = 999

and I can do this:

a = (123 if true)

so doens't this mean that wherever I can put "999" I can also put "(123
if true)"?

Note: I'm dumbing this down as much as I can (from my limited
understanding of Ruby internals), so no offense if I treat you like a
child, that's not my intention, and serves to make the issue
understandable.

Since it's an if statement, you probably can. In this case, since 123 is
always true, Ruby can "ignore" the "if true" bit (kinda, sorta).

In other words, why can I do this:

puts 999

But I *can't* do this:

puts (123 if true)

Because puts takes an argument, not a statement (basically).

The problem with computers is that they are stupid. It is obvious, to
you, that you *mean* "output 123, if 123 is true". However, Ruby cannot
understand intent.
It sees "output (123 if true). Wait, I can't handle that, let me tell
the smart guy about that, so that he can explain it really slow for me."

This is an effect of multiple issues: Precedence, optimizations done by
the interpreter (compiler, if you want), and the conflict of statement
vs expression ("if" is a statement, "123 if true" is an expression for
the purpose of this explanation).

So, in a nutshell: Ruby throws up its arms, because it cannot understand
what you want.

That's why "puts 123 if true", "(puts 123) if true" both work, but "puts
(123 if true)" doesn't.

Kinda.

 

[Albert Schlef]

Because puts takes an argument, not a statement (basically).

Then why can I do this?

puts (123 or true)

Are you going to tell me that "123 or true", unlike "123 if true",
*isn't* a statement?

If "123 or true" isn't a statement, then it's a simple expression. And
then I would be able to do:

puts(123 or true) # Note: no space before parentheses

But I can't! So it follows that "123 or true" too is a statement.

Let me sum it up:

puts (123 if true) # Syntax error.

puts (123 or true) # Works.

Although both are "statements".

The problem with computers is that they are stupid. It is obvious, to
you, that you *mean* "output 123, if 123 is true".

No, no, no. By `puts (123 if true)` I mean: output the result of `123 if
true`.

 

[Albert Schlef]

Albert Schlef wrote:

Hey, I now see that this works:

some_func((ARGV[0] or raise "You must provide an argument"))

Great. On the other hand, I won't be able to remember this the next time
I need it.

Just use Ruby's rescue syntax instead of trying to be clever.

What do you mean?

 

[Phillip Gawlowski]

Then why can I do this?

puts (123 or true)

Are you going to tell me that "123 or true", unlike "123 if true",
*isn't* a statement?

I'm afraid I am. It's an evaluation. Boolean evaluation (with "and" /
"or" having lower precedence than && / ||).

If "123 or true" isn't a statement, then it's a simple expression. And
then I would be able to do:

Take a third option: It's an evaluation.


Crash course in Boolean logic:

We have two items A and B.

Case "AND":
return true if, and only if, both "a" *and* "b" are true.

Example:
irb(main):004:0> a, b = true, true
=> [true, true]
irb(main):005:0> a and b
=> true
irb(main):006:0> b = false
=> false
irb(main):007:0> a and b
=> false
irb(main):008:0>

As you see, the evaluation spits back a result: True, if both "a" and
"b" are true, false if only "a" or "b" is true.

Case "OR":
return true if *either* "a" *or* "b" are true

Example:
irb(main):008:0> a, b = false, false
=> [false, false]
irb(main):009:0> a or b
=> false
irb(main):010:0> a = true
=> true
irb(main):011:0> a or b
=> true
irb(main):012:0> b = false
=> false
irb(main):013:0> a or b
=> true

As you can see, if both "a" and "b" are false, the evaluation returns
false ("returns false" meaning "the result is false").
If either "a" *or* "b" are true, the evaluation returns true.
Same if both "a" *and* "b" are true.

No, no, no. By `puts (123 if true)` I mean: output the result of `123 if
true`.

That's what I said, I was just verbose about it.

 

[Robert Klemme]

Note that this is equivalent to "puts nil" followed by "4".

That's significant.

Consider:
irb(main):001:0> x = nil or 4
=> 4
irb(main):002:0> x
=> nil

The grouping is:
(x = nil) or (4)

Or
(puts nil) or (4)


I believe that's precisely the problem -- the precedence of "or" is
low enough that it can't occur inside a method argument.

Compare this with the similar situation in C, where a comma operator
cannot occur inside an argument list for a function, because it's part
of the function-call syntax. So:

valid C:
x = 1, y = 2;

(this performs both assignments, and returns the value of y after the
assignment, which happens to be 2.)

printf("%d\n", x = 1, y = 2);

This probably prints 1, but I think it's undefined behavior because there's
excess arguments to printf. (I'm not sure whether that's permitted or not,
but my guess would be "no, but it probably always works".)

So try:

irb(main):003:0> puts( (nil or 4) )
4
=> nil

Basically, if you really want parentheses (as in the precedence-changing
operator), you need to include them... Not merely put something that can't
go in a method argument list inside the confusingly-similar-looking
() which surround method arguments.

And you can even omit the method brackets as in

irb(main):001:0> puts (nil or 4)
4
=> nil

Kind regards

robert

 

[Phillip Gawlowski]

What do you mean?

Something like this:
PS C:\Scripts> ruby .\unless.rb
we had an argument error
PS C:\Scripts> ruby .\unless.rb arg
arg
PS C:\Scripts> cat .\unless.rb
begin
raise ArgumentError unless ARGV[0]
puts ARGV[0]
rescue ArgumentError
puts "we had an argument error"
end

Basically, the begin/rescue/end tokens (bits that Ruby understands
without being told about by you) allow the programmer to recover from an
error in a graceful way.

If you had a file open, for example, you can make sure it is closed
properly if a so-called exception (Like ArgumentError in the example)
appears.

 

[Bertram Scharpf]

Hi,

Am Donnerstag, 31. Dez 2009, 11:24:26 +0900 schrieb Albert Schlef:

(The problem is in both Ruby 1.8 and Ruby 1.9)

The expression:

puts(nil || 4)

works as expected. It prints '4'.

But this expression:

puts(nil or 4)

fails... it is a syntax error, for some mysterious reason.

Why? I thought the only diference between "or" and "||" is the
precedence.

There's a difference between _grouping_ parentheses (like
begin...end) and _method_ _call_ parentheses:

puts (nil or 4) # vs.
puts( nil or 4)

See:

irb(main):001:0> $-w = true
=> true
irb(main):002:0> puts( nil or 4)
SyntaxError: compile error
(irb):2: syntax error, unexpected kOR, expecting ')'
puts( nil or 4)
^
from (irb):2
irb(main):003:0> puts (nil or 4)
(irb):3: warning: (...) interpreted as grouped expression
4
=> nil


Bertram

 

[Seebs]

so doens't this mean that wherever I can put "999" I can also put "(123
if true)"?

Apparently not.

-s

 

[Marnen Laibow-Koser]

Albert Schlef wrote:

Hey, I now see that this works:

some_func((ARGV[0] or raise "You must provide an argument"))

Great. On the other hand, I won't be able to remember this the next time
I need it.

Just use Ruby's rescue syntax instead of trying to be clever.

What do you mean?

begin

rescue

end

Look it up.

Or is that not what you didn't understand?

Best,

 

[Charles Oliver Nutter]

[...]
=C2=A0 puts(nil or 4)

fails... it is a syntax error, for some mysterious reason.

Why? I thought the only diference between "or" and "||" is the
precedence.

Looks like a genuine bug to me. I can verify that behavior in MRI,
YARV, JRuby, IronRuby and Rubinius (which is not terribly surprising
since they all use the exact same parser).

We do not all use the same parser. At the very least, they're all
written in our local language. We use parsers that were originally
ports of the original parser, and while changing over the years still
match MRI's parser behavior.

If MRI and YARV do it, then we do it because that's what MRI and YARV do.

Minor nitpick

- Charlie

 

[Charles Oliver Nutter]

Well. it turns out there aren't that many ways in ruby.

I originally tried to do the following:

=C2=A0some_func(ARGV[0] or raise "You must provide an argument")

First off, I'd say that this is probably confusing form to use. If I
ever saw this in code I'd write it differently.

I wish it worked. But it doesn't. So I changed it to:

=C2=A0some_func(ARGV[0] || raise "You must provide an argument")

It still didn't work. So finally I did:

=C2=A0some_func(ARGV[0] || (raise "You must provide an argument"))

It works. But, I must say, it isn't as beautiful as my original plan. It
doesn't read as English.

This isn't too bad, for what you want:

some_func ARGV[0] || raise('you must provide an argument')

or:

some_func(ARGV[0] || raise('you must provide an argument')

And if I were to write this, I'd probably choose one of these variants:

ARGV[0] ? some_func(ARGV[0]) : raise 'you must provide an argument'

or

raise 'you must provide an argument' unless ARGV[0]
some_func(ARGV[0])

- Charlie

 

[Albert Schlef]

Bertram Scharpf wrote:
[...]

See:

irb(main):001:0> $-w = true [...]
irb(main):003:0> puts (nil or 4)
(irb):3: warning: (...) interpreted as grouped expression
4

Thanks, I didn't know of this $-w trick.

 

[Albert Schlef]

begin
raise ArgumentError unless ARGV[0]
puts ARGV[0]
rescue ArgumentError
puts "we had an argument error"
end

Basically, the begin/rescue/end tokens (bits that Ruby understands
[...]

Thanks Phillip (and Charles Nutter) for all your help. In my 'raise' I
tried to mimic Perl's "or die" idiom. But I see that your example is
more elegant.

Take a third option: It's an evaluation.

For the time being I'll take the fourth option: The Ruby grammar is
weird in some corners, and we just have to accept it.

 

[Phillip Gawlowski]

Thanks Phillip (and Charles Nutter) for all your help. In my 'raise' I
tried to mimic Perl's "or die" idiom. But I see that your example is
more elegant.

Thank you.

However, my example is a plain by-the-books example of how Ruby does
exceptions.

So, thank Matz for creating something elegant in the first place.

For the time being I'll take the fourth option: The Ruby grammar is
weird in some corners, and we just have to accept it.

It is indeed. The more complex your desires get, the weirder Ruby gets,
IME. Overall, though, it's pretty clean and simple to use, and keeps
weirdness to the edge cases.

That's why I prefer a more verbose, explicit style of programming in
Ruby: It makes it clear to me what I attempt, and thus, hopefully,
Ruby's parser doesn't throw a wrench in my machinations.

 

[David A. Black]

Hi --

I'm afraid I am. It's an evaluation. Boolean evaluation (with "and" / "or"
having lower precedence than && / ||).


Take a third option: It's an evaluation.

Everything evaluates to something (an object) though. Evaluation is
more a process than a special kind of syntactic construct.

That's what I said, I was just verbose about it.

I think you said:

It is obvious, to you, that you *mean* "output 123, if 123 is true".

The code doesn't test for the truth value of 123.


David

--
David A. Black
Senior Developer, Cyrus Innovation Inc.
THE COMPLEAT RUBYIST, Ruby training with Black/Brown/McAnally!
January 22-23, Tampa, Florida
Info and registration at http://www.thecompleatrubyist.com

 

[David A. Black]

Hi --

It works. But, I must say, it isn't as beautiful as my original plan. It
doesn't read as English.

PS C:\Scripts> ruby .\unless.rb
./unless.rb:1: Argument error (RuntimeError)
PS C:\Scripts> ruby .\unless.rb "arg"
PS C:\Scripts> cat .\unless.rb
raise "Argument error" unless ARGV[0]
PS C:\Scripts>

I prefer it that way.

Works in 1.8.6 and 1.9.1, too, to my great relief.

It even works in 1.0:

$ ruby10 -ve 'raise "Argument error" unless ARGV[0]'
ruby - version 1.0-971225 (i686-linux)
-e:1: RuntimeError: Argument error

I wouldn't worry about that idiom ceasing to work


David

--
David A. Black
Senior Developer, Cyrus Innovation Inc.
THE COMPLEAT RUBYIST, Ruby training with Black/Brown/McAnally!
January 22-23, Tampa, Florida
Info and registration at http://www.thecompleatrubyist.com

 

[David A. Black]

Hi --

Well. it turns out there aren't that many ways in ruby.

I originally tried to do the following:

some_func(ARGV[0] or raise "You must provide an argument")

I wish it worked. But it doesn't. So I changed it to:

some_func(ARGV[0] || raise "You must provide an argument")

It still didn't work. So finally I did:

some_func(ARGV[0] || (raise "You must provide an argument"))

It works. But, I must say, it isn't as beautiful as my original plan. It
doesn't read as English.

It's not supposed to; it's supposed to read as Ruby I wouldn't
make too much of the English-likeness. I think of it more as an
emergent thing than as a style guideline.


David

--
David A. Black
Senior Developer, Cyrus Innovation Inc.
THE COMPLEAT RUBYIST, Ruby training with Black/Brown/McAnally!
January 22-23, Tampa, Florida
Info and registration at http://www.thecompleatrubyist.com

 

[Phillip Gawlowski]

I wouldn't worry about that idiom ceasing to work

In open source software (or Free Software), I *do* worry about API
stability, or rather compatibility of version X to version Y.

I've been burned by Linux kernel changes far too often to *not* worry.

Mind, I'm not averse to change, even change that sheds weight and thus
breaks backwards compatibility, but I prefer it to be in a major
release, rather than a minor version.

Very different issue from the OP, though.

 

[David A. Black]

Hi --

In open source software (or Free Software), I *do* worry about API stability,
or rather compatibility of version X to version Y.

So do I, but I think we're safe on this particular one. That's all I
mean.


David

--
David A. Black
Senior Developer, Cyrus Innovation Inc.
THE COMPLEAT RUBYIST, Ruby training with Black/Brown/McAnally!
January 22-23, Tampa, Florida
Info and registration at http://www.thecompleatrubyist.com