> perhaps having an attribute of the object actually called scope would be of
> interest?
>   
> class Foo
>         def bar
>                 self  #--> instance of Foo
>                 scope  #--> instance of Foo's bar method
>         end
> end
> 
> thus local variables such as:
> 
>         x = 1
> 
> are in effect:
> 
>         scope.x = 1

Then it seems that your 'scope' object is really just the (implicit) stack
frame created while 'bar' is executing.

Having it as an explicit object would make it dynamic, which again increases
overhead. For example, with

  x = 100
  y = 200

the interpreter can (at compile time) decide that 'x' and 'y' are at fixed
offsets in the stack frame. I don't know if it actually does, but it could.
In which case, it might become something internally like

  stack_frame[0] = 100
  stack_frame[1] = 200

A dynamic stack frame means that it would have to be accessed by method or
instance variable name, which would mean a hash lookup for the strings "x"
and "y".

As far as I can tell, it's assigned statically. For example:

  x = 5
  eval "y = 6"
  puts y

fails with "undefined local variable or method `y'" (as long as this is run
as a script, not within irb)

I guess the interpreter sees 'puts y' without a previous assignment to local
variable y, so compiles it as a method call: 'puts self.y'. Yep, dynamically
add a method called 'y' and it works:

  x = 5
  eval "module Foo; def y; 6; end; end; self.extend Foo"
  puts y

or

  x = 5
  eval "class <<self; def y; 6; end; end"
  puts y

Regards,

Brian.