From: "Jesús Gabriel y Galán" Date: 2008-01-25T01:12:30+09:00 Subject: Re: why must I initialize this variable? On Jan 24, 2008 10:38 AM, 7stud -- wrote: > Jesús Gabriel y Galán wrote: > > On Jan 22, 2008 11:29 PM, matt neuburg wrote: > > >> If you're going to say that 'hi' is undefined, surely it was undefined > >> in line 001. Yet line 001 raised no error. > >> > >> So what's wrong with 002? It cannot be the 'puts "#{hi}"' part - you > >> just proved, with 001, that that part's okay. So apparently it is the > >> assignment part. Evidently a tailgating "if" refuses to auto-instantiate > >> a variable. That is what I'm attempting to get clear on. Is that a bug? > >> Is it expected behavior? m. > > > > Because of how the parser works. It makes a first pass, and one of the > > things it does is decide wheter tokens are methods or variables. The > > way it does that is assuming everything is a method and if it finds an > > assignment, from that point on, it treats it as a variable. The trick > > is in the "from that point on", since for the parser it's just left to > > right as it finds the code, it doesn't take into account evaluation > > order (please anyone correct me if I'm wrong). Check this: > > > > irb(main):001:0> def hi; "hi"; end > > => nil > > irb(main):002:0> puts "#{hi}" if (hi = "hello") > > (irb):2: warning: found = in conditional, should be == > > hi > > => nil > > irb(main):003:0> puts hi > > hello > > => nil > > > > As you can see, I define a method hi. The parser will treat the first > > hi in line 002 as a method, since it hasn't seen an assignment yet. > > That's why line 002 outputs "hi", because the first reference has been > > marked by the parser as a method call. After the hi = "hello", though, > > hi is treated as a variable. That's why line 003 outputs "hello". > > > > Hope this makes it a bit clearer, although I agree that this looks > > confusing. > > > > Jesus. > > So the parser marks hi as a method before the code hi="hello" is parsed, > and thereafter hi is marked as a variable? Then execution evaluates > hi="hello" and thereafter execution moves *backwards* to execute puts > hi? And in order to evaluate hi in the puts statement, execution > checks the parser's values, and at that point in the code hi is a > method, so the hi method executes and the return value is output? Sorry, I don't have enough knowledge to answer your question. What I explained and showed above is my understanding of how this issue works from the functional point of view, but I have no idea of how the parser and the execution internals are in this regard. Maybe some other person might explain it. Jesus.