[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Riddle me this (a question about expressions

Patrick Toomey

9/23/2006 4:47:00 PM

Hello all,
I am new to Ruby and am toying around with the language to get a
feel for the expression ubiquity in ruby. Anyway, explain to me the
following. The below bits of code have no real relevance; they are
merely illustrative of my question. The first declaration works as
expected; the return value is 9. The second declaration doesn't run
at all. I get a "void value expression" error. Is the runtime
looking into my if statement, realizing that there is no ability for
x to get set and failing? Obviously the code is ridiculous, but it
seems odd to me that it would not even run. Why does the interpreter
care that x will never get set if the function will return cleanly
none the less?

def foo()
x = 0
x = if 3 > 4
8
else
9
end
return x
end

def foo()
x = 0
x = if 3 > 4
return 8
else
return 9
end
return x
end
31 Answers

Marcin Mielzynski

9/23/2006 5:16:00 PM

0

Patrick Toomey wrote:
> Hello all,
> I am new to Ruby and am toying around with the language to get a feel
> for the expression ubiquity in ruby. Anyway, explain to me the
> following. The below bits of code have no real relevance; they are
> merely illustrative of my question. The first declaration works as
> expected; the return value is 9. The second declaration doesn't run at
> all. I get a "void value expression" error. Is the runtime looking
> into my if statement, realizing that there is no ability for x to get
> set and failing? Obviously the code is ridiculous, but it seems odd to
> me that it would not even run. Why does the interpreter care that x
> will never get set if the function will return cleanly none the less?
>
> def foo()
> x = 0
> x = if 3 > 4
> 8
> else
> 9
> end
> return x
> end
>
> def foo()
> x = 0
> x = if 3 > 4
> return 8
> else
> return 9
> end
> return x
> end
>

I think the return statement has void context itself

check out this - in fact what you are doing is:

return (return "foo")

lopex

Devin Mullins

9/23/2006 5:21:00 PM

0

Patrick Toomey wrote:
> The second declaration doesn't run at
> all. I get a "void value expression" error. Is the runtime looking
> into my if statement, realizing that there is no ability for x to get
> set and failing?
No. The 'return' keyword is one of the few things in Ruby that isn't an
expression -- it doesn't have a return value. Ruby's complaining 'cause
you're trying to set x to it.

Devin

Frederick Cheung

9/23/2006 10:39:00 PM

0

Patrick Toomey wrote:
> def foo()
> x = 0
> x = if 3 > 4
> return 8
> else
> return 9
> end
> return x
> end

The problem is that you are effectively trying to do this
x = return 9
And that doesn't have a well defined meaning

Fred

--
Posted via http://www.ruby-....

Robert Klemme

9/24/2006 10:41:00 AM

0

Others have commented this already. Just another bit: once you think about
semantics of "return" for a moment it should be immediately clear that it is
not and cannot be an expression simply because it never returns control flow
but instead transfers it to someplace else. The same holds true for "next".

Interestingly enough "raise" does not provoke such a compile error although
I cannot see how it would ever return control flow locally:

>> RUBY_VERSION
=> "1.8.3"
>> def foo() x = raise "Test" end
=> nil

>> RUBY_VERSION
=> "1.8.5"
>> def foo() x = raise "Test" end
=> nil

Kind regards

robert

Pit Capitain

9/24/2006 5:34:00 PM

0

Robert Klemme schrieb:
> Interestingly enough "raise" does not provoke such a compile error
> although I cannot see how it would ever return control flow locally:

def raise *args
"my raise"
end

x = raise NameError
p x # => "my raise"

Don't ask me why it is implemented like this, though.

Regards,
Pit

Patrick Toomey

9/24/2006 6:56:00 PM

0


On Sep 24, 2006, at 5:45 AM, Robert Klemme wrote:

> Others have commented this already. Just another bit: once you
> think about semantics of "return" for a moment it should be
> immediately clear that it is not and cannot be an expression simply
> because it never returns control flow but instead transfers it to
> someplace else. The same holds true for "next".
>
> Interestingly enough "raise" does not provoke such a compile error
> although I cannot see how it would ever return control flow locally:
>
>>> RUBY_VERSION
> => "1.8.3"
>>> def foo() x = raise "Test" end
> => nil
>
>>> RUBY_VERSION
> => "1.8.5"
>>> def foo() x = raise "Test" end
> => nil
>
> Kind regards
>
> robert
>
>

I guess that is what surprises me. I would expect return to work
exactly like raise. It just seems strange to me that I can have a
perfectly good expression such as

if (3 < 4)
return 5
end

and then have that fail when I do

x = if (3 < 4)
return 5
end

Someone else gave the example of simplifying my question down to the
equivalent of trying the following

x = return 9

Why shouldn't this be valid? As shown above, raise seems to return
nil, and return seems like it should return a similar value if there
is no other reasonable return value. Just for my own curiosity, what
implications would returning "nil" have? Anyway, thanks for all your
help. I realize most of this is of academic value, but it really
helps to see how Ruby works underneath.

Patrick

MonkeeSage

9/24/2006 7:42:00 PM

0

Patrick Toomey wrote:
> Someone else gave the example of simplifying my question down to the
> equivalent of trying the following
>
> x = return 9
>
> Why shouldn't this be valid? As shown above, raise seems to return
> nil, and return seems like it should return a similar value if there
> is no other reasonable return value. Just for my own curiosity, what
> implications would returning "nil" have? Anyway, thanks for all your
> help. I realize most of this is of academic value, but it really
> helps to see how Ruby works underneath.

Hi Patrick,

I've no idea what goes on under the hood, but I would think it is
because raise doesn't exit the current stack frame (it can be rescued
and execution continues), so it's more like a method that gets
evaluated and its return (nil) then gets assigned (nb: right hand side
of assignment is always resolved before it is assigned). But return
(and I assume break / next) break out of the current stack frame, so
the assignment is left dangling. That's my guess.

Regards,
Jordan

MonkeeSage

9/24/2006 7:48:00 PM

0


Hmmm. But raise does actually break out of the current frame (and the
whole main loop) if it isn't rescued...mabye raise, since it already
enters to exception handler, shortcircuts the void assignment
exception; or mabye it completes the assignment with nil, then exists
the stack? Like I said, I'm just guessing here...I have no idea what
really happens under the hood.

Regards,
Jordan

Robert Klemme

9/24/2006 8:09:00 PM

0

Patrick Toomey wrote:
> I guess that is what surprises me. I would expect return to work
> exactly like raise.

I on the other hand expect "raise" to work exactly like "return". :-)

> Someone else gave the example of simplifying my question down to the
> equivalent of trying the following
>
> x = return 9
>
> Why shouldn't this be valid?

Because "return" never returns. (Uh, this starts sounding like Zen...)

> As shown above, raise seems to return nil,

No, "raise" does neither return nil nor anything else. It does not
return in the same way as "return" never returns. The whole point of
the two is that they do *not* behave like an expression but transfer
control flow up the call stack.

> and return seems like it should return a similar value if there is no
> other reasonable return value. Just for my own curiosity, what
> implications would returning "nil" have?

It does not work. Please take the time and meditate about this.

> Anyway, thanks for all your
> help. I realize most of this is of academic value, but it really helps
> to see how Ruby works underneath.

In this case I'd rather say, you hit behavior that is common to *all*
programming languages that know "return". But I get the feeling that
you still not fully understood the difference between an arbitrary
expression and a return statement...

Kind regards

robert

Logan Capaldo

9/24/2006 8:33:00 PM

0

On Mon, Sep 25, 2006 at 05:10:18AM +0900, Robert Klemme wrote:
> Patrick Toomey wrote:
> >I guess that is what surprises me. I would expect return to work
> >exactly like raise.
>
> I on the other hand expect "raise" to work exactly like "return". :-)
>
> >Someone else gave the example of simplifying my question down to the
> >equivalent of trying the following
> >
> >x = return 9
> >
> >Why shouldn't this be valid?
>
> Because "return" never returns. (Uh, this starts sounding like Zen...)
>
> > As shown above, raise seems to return nil,
>
> No, "raise" does neither return nil nor anything else. It does not
> return in the same way as "return" never returns. The whole point of
> the two is that they do *not* behave like an expression but transfer
> control flow up the call stack.
>
Regardless of whether or not it makes logical sense to say a = return b,
I think the confusion is that
x = raise b is _not_ a syntax error while
x = return b _is_ a syntax error.
Frankly, I think this is probably either a) an oversight in the grammar
or b) the need to handle the super weird edge case of
a = raise 'error' rescue nil

Either a = raise b should be a syntax error, or a = return b should not.
I'd lean towards the former, if it were up to me.
> >and return seems like it should return a similar value if there is no
> >other reasonable return value. Just for my own curiosity, what
> >implications would returning "nil" have?
>
> It does not work. Please take the time and meditate about this.
>
> > Anyway, thanks for all your
> >help. I realize most of this is of academic value, but it really helps
> >to see how Ruby works underneath.
>
> In this case I'd rather say, you hit behavior that is common to *all*
> programming languages that know "return". But I get the feeling that
> you still not fully understood the difference between an arbitrary
> expression and a return statement...
>
> Kind regards
>
> robert