brian ford wrote:
> On Fri, Aug 21, 2009 at 6:39 PM, caleb clausen<redmine / ruby-lang.org> wrote:
>>  p = p m %(2)
[snip]
>>
>> In this variation of the expression, %(2) is a string, as I would expect:
>>
>>  p m %(2)
> 
> Could you elaborate on what you get with Rubinius? I get 'nil' for the
> first example (assuming I'm typing this in right) and NoMethodError
> for 'm' in the second. Could you give a screen dump or something?

These examples were cut down to an absolute minimum needed to show the 
syntax problem; I should really have included a definition of the m 
method for exhibiting it properly. So, one should really prepend this to 
both:
   def m x; p x end

Both snippets, when run alone, should, so far as I can see, have the 
same output. Without the definition of m, both examples should raise 
NoMethodError on m. With it, both should print "2" and then nil. I can't 
reproduce the parser crash I reported initially; it's possible I 
misspoke, or that rubinius has changed in this area since when I 
initially tested this.

I'm getting this output from rubinius:
[calebc@ruby-versions ~]$ rbx -e 'def m x; p x end; p = p m %(2)'
[calebc@ruby-versions ~]$ rbx -e 'def m x; p x end; p m %(2)'
"2"
nil
[calebc@ruby-versions ~]$ rbx -e 'p = p m %(2)'
[calebc@ruby-versions ~]$ rbx -e 'p m %(2)'
An exception occurred evaluating command line code
     No method 'm' on an instance of Object. (NoMethodError)

Backtrace:
   Kernel(Object)#m (method_missing) at kernel/delta/kernel.rb:47
                  Object# (__eval__) at (eval):1
       Kernel(Rubinius::Loader)#eval at kernel/common/eval.rb:85
           Rubinius::Loader#evals {} at kernel/loader.rb:295
                          Array#each at kernel/bootstrap/array.rb:152
              Rubinius::Loader#evals at kernel/loader.rb:294
               Rubinius::Loader#main at kernel/loader.rb:396
                   Object#__script__ at kernel/loader.rb:445
[calebc@ruby-versions ~]$ rbx -v
rubinius 0.11.0-dev (ruby 1.8.6) (8307757ba 12/31/2009) [i686-pc-linux-gnu]

(Thunderbird is wrapping that last line for me, sorry...)

So, it looks like we're seeing the same behavior.

(It's interesting that rubinius reports its (build?) date as december 
31, 2009, since that's in the future at the moment.)