Extrange behaviour using "if XXX ..." and "XXX if ..."

ruby-talk
1

Hi, note the difference in those both cases:

a)
if a="QWEQWE" : a end
=> "QWEQWE"

b)
a if a="QWEQWE"
NameError: undefined local variable or method `a' for main:Object

I know that the behaviour in a) is no recommended and maybe deprecated in a
future, but why it works in a) and not in b) ?

Thanks.

···

--
Iñaki Baz Castillo

2

Iñaki Baz Castillo wrote:

Hi, note the difference in those both cases:

a)
if a="QWEQWE" : a end
=> "QWEQWE"

b)
a if a="QWEQWE"
NameError: undefined local variable or method `a' for main:Object

I know that the behaviour in a) is no recommended and maybe deprecated in a future, but why it works in a) and not in b) ?

A method call without parentheses and a plain variable look the same, so Ruby tries to determine between the two by looking for an assignment as it parses your script. If it sees you assigning a value to "a", then it knows that "a" is a variable, otherwise it assumes that "a" is a method call. Parsing occurs from the top down and from left to right.

In case (a) the assignment to "a" occurs before any other reference, so Ruby knows it's a variable.

In case (b), there has not yet been an assignment before the reference to a, so Ruby assumes that "a" is a method call, yet there is no definition for a so you get the message.

···

--
RMagick: http://rmagick.rubyforge.org/
RMagick 2: http://rmagick.rubyforge.org/rmagick2.html

3

b)
  a if a="QWEQWE"
  NameError: undefined local variable or method `a' for main:Object

But why the first "a" is interpreted before the "if" stament? Imagine this
example:

  defined?a
  => nil
  a="BLABLA" if 2 == 3
  => nil
  a
  => nil

After this code "a" will remain "nil" (or the previous value it had), so:
  a="BLABLA"
hasn't been interpreted since the "if" stament failed.

Also note this other example:
  
  defined?kk
  => nil
  kk if nil
  => nil

Why in this last case the code doesn't return:
  "undefined local variable or method kk' "
?

I assume the reason: "kk" is not interpreted if the condition fails.
In b) the first "a" is then interpreted AFTER the condition success, so in
that moment "a" has been already declared (into the condition), so it would
exist and not give an error.

Am I not right?

···

El Domingo, 30 de Marzo de 2008, Tim Hunter escribió:

In case (b), there has not yet been an assignment before the reference
to a, so Ruby assumes that "a" is a method call, yet there is no
definition for a so you get the message.

--
Iñaki Baz Castillo

4

Iñaki Baz Castillo wrote:

In case (b), there has not yet been an assignment before the reference
to a, so Ruby assumes that "a" is a method call, yet there is no
definition for a so you get the message.

  b)
  a if a="QWEQWE"
  NameError: undefined local variable or method `a' for main:Object

But why the first "a" is interpreted before the "if" stament? Imagine this example:

  defined?a
  => nil
  a="BLABLA" if 2 == 3
  => nil
  a
  => nil

After this code "a" will remain "nil" (or the previous value it had), so:
  a="BLABLA"
hasn't been interpreted since the "if" stament failed.

Also note this other example:
    defined?kk
  => nil
  kk if nil
  => nil

Why in this last case the code doesn't return:
  "undefined local variable or method kk' "
?

I assume the reason: "kk" is not interpreted if the condition fails.
In b) the first "a" is then interpreted AFTER the condition success, so in that moment "a" has been already declared (into the condition), so it would exist and not give an error.

Am I not right?

You must distinguish between parsing and execution. Ruby parses your program before Ruby executes your program.

Ruby decides how to interpret the reference to a during parsing, before Ruby executes the if statements in your examples. Their success or failure has nothing to do with the decision. In this case

a if a = "qweqwe"

Remember parsing occurs from left to right. Ruby sees the reference to a to the left of the assignment to a. When Ruby first encounters a reference to a it assumes that since it has not yet seen any assigment to a, then a must be a method name.

···

El Domingo, 30 de Marzo de 2008, Tim Hunter escribió:

--
RMagick: http://rmagick.rubyforge.org/
RMagick 2: http://rmagick.rubyforge.org/rmagick2.html

5

Ok, I understand. Thanks a lot.

···

El Domingo, 30 de Marzo de 2008, Tim Hunter escribió:

You must distinguish between parsing and execution. Ruby parses your
program before Ruby executes your program.

Ruby decides how to interpret the reference to a during parsing, before
Ruby executes the if statements in your examples. Their success or
failure has nothing to do with the decision. In this case

a if a = "qweqwe"

Remember parsing occurs from left to right. Ruby sees the reference to a
  to the left of the assignment to a. When Ruby first encounters a
reference to a it assumes that since it has not yet seen any assigment
to a, then a must be a method name.

--
Iñaki Baz Castillo

6

I asked the same question a few months ago, and got some great answers:

<http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/f03e
291e32ea2570/49ca1f19297bece6?lnk=st&q=#49ca1f19297bece6>

Understanding this point has been very useful to me subsequently...! m.

···

Iñaki Baz Castillo <ibc@aliax.net> wrote:

El Domingo, 30 de Marzo de 2008, Tim Hunter escribió:

> You must distinguish between parsing and execution. Ruby parses your
> program before Ruby executes your program.
>
> Ruby decides how to interpret the reference to a during parsing, before
> Ruby executes the if statements in your examples. Their success or
> failure has nothing to do with the decision. In this case
>
> a if a = "qweqwe"
>
> Remember parsing occurs from left to right. Ruby sees the reference to a
> to the left of the assignment to a. When Ruby first encounters a
> reference to a it assumes that since it has not yet seen any assigment
> to a, then a must be a method name.

Ok, I understand. Thanks a lot.

--
matt neuburg, phd = matt@tidbits.com, Matt Neuburg’s Home Page
Leopard - http://www.takecontrolbooks.com/leopard-customizing.html
AppleScript - http://www.amazon.com/gp/product/0596102119
Read TidBITS! It's free and smart. http://www.tidbits.com

7

Thanks for the link matt,it's very useful to understand this "issue".

Regards.

···

El Domingo, 30 de Marzo de 2008, matt neuburg escribió:

I asked the same question a few months ago, and got some great answers:

<http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/f03e
291e32ea2570/49ca1f19297bece6?lnk=st&q=#49ca1f19297bece6>

Understanding this point has been very useful to me subsequently...! m.

--
Iñaki Baz Castillo