Ruby conditionals subtlety?
in [Ruby]
|
Prev: DXF Writer?
Next: System handling of undef_method
From: Farhad Farzaneh on 18 Feb 2010 14:49 Hi, Anyone know why thse two forms of "unless" behave differently? > irb irb(main):001:0> foo = true unless defined?(foo) => nil irb(main):002:0> unless defined?(fooo) ; fooo = true ; end => true thx -- Posted via http://www.ruby-forum.com/.
From: Glen Holcomb on 18 Feb 2010 15:02 On Thu, Feb 18, 2010 at 12:49 PM, Farhad Farzaneh <ff(a)onebeat.com> wrote: > Hi, > > Anyone know why thse two forms of "unless" behave differently? > > > irb > irb(main):001:0> foo = true unless defined?(foo) > => nil > irb(main):002:0> unless defined?(fooo) ; fooo = true ; end > => true > > thx > -- > Posted via http://www.ruby-forum.com/. > > From playing around it doesn't look like unless is "behaving differently" Ruby has created a label for foo since it thinks it is going to be assigning it something (dynamic language) For example >> foo = true unless defined?(foo) => nil >> unless defined?(fooo); fooo = true; end => true >> foo => nil >> fooo => true >> foo = true unless defined?(foom) => true >> foo => true Basically it looks like foo appears to exist but it doesn't really exist yet so the first unless "acts" oddly. This is very interesting though. Perhaps someone who knows what they are talking about can tell us why it appears to behave this way. -- "Hey brother Christian with your high and mighty errand, Your actions speak so loud, I cant hear a word youre saying." -Greg Graffin (Bad Religion)
From: Ryan Davis on 18 Feb 2010 16:30 On Feb 18, 2010, at 11:49 , Farhad Farzaneh wrote: > Hi, > > Anyone know why thse two forms of "unless" behave differently? > >> irb > irb(main):001:0> foo = true unless defined?(foo) > => nil > irb(main):002:0> unless defined?(fooo) ; fooo = true ; end > => true oddity in the way the code is parsed: % echo "foo = true unless defined?(foo)" | parse_tree_show s(:if, s(:defined, s(:lvar, :foo)), nil, s(:lasgn, :foo, s(:true))) % echo "unless defined?(fooo) ; fooo = true ; end" | parse_tree_show s(:if, s(:defined, s(:call, nil, :fooo, s(:arglist))), nil, s(:lasgn, :fooo, s(:true)))
From: Farhad Farzaneh on 18 Feb 2010 16:44 Ryan Davis wrote: > On Feb 18, 2010, at 11:49 , Farhad Farzaneh wrote: > >> Hi, >> >> Anyone know why thse two forms of "unless" behave differently? >> >>> irb >> irb(main):001:0> foo = true unless defined?(foo) >> => nil >> irb(main):002:0> unless defined?(fooo) ; fooo = true ; end >> => true > > oddity in the way the code is parsed: > > % echo "foo = true unless defined?(foo)" | parse_tree_show > s(:if, s(:defined, s(:lvar, :foo)), nil, s(:lasgn, :foo, s(:true))) > > % echo "unless defined?(fooo) ; fooo = true ; end" | parse_tree_show > s(:if, s(:defined, s(:call, nil, :fooo, s(:arglist))), nil, s(:lasgn, > :fooo, s(:true))) Cool, any chance you could give a short description for those of us that have never really thought about the parser or used parse_tree_show? thx -- Posted via http://www.ruby-forum.com/.
From: Ryan Davis on 18 Feb 2010 18:18
On Feb 18, 2010, at 13:44 , Farhad Farzaneh wrote: > Ryan Davis wrote: >> On Feb 18, 2010, at 11:49 , Farhad Farzaneh wrote: >> >>> Hi, >>> >>> Anyone know why thse two forms of "unless" behave differently? >>> >>>> irb >>> irb(main):001:0> foo = true unless defined?(foo) >>> => nil >>> irb(main):002:0> unless defined?(fooo) ; fooo = true ; end >>> => true >> >> oddity in the way the code is parsed: >> >> % echo "foo = true unless defined?(foo)" | parse_tree_show >> s(:if, s(:defined, s(:lvar, :foo)), nil, s(:lasgn, :foo, s(:true))) >> >> % echo "unless defined?(fooo) ; fooo = true ; end" | parse_tree_show >> s(:if, s(:defined, s(:call, nil, :fooo, s(:arglist))), nil, s(:lasgn, >> :fooo, s(:true))) > > Cool, any chance you could give a short description for those of us that > have never really thought about the parser or used parse_tree_show? Your latter code snippet treats "fooo" in defined? as a method call. This is because the assignment inside the conditional hasn't been parsed yet, and hasn't affected the lookup tables. The former doesn't have this problem because the body of the conditional is parsed first. |