[ruby-core:21335] Re: Proc-as-Binding is out again?

Ken Bloom wrote:
> A use case for mutable bindings with Proc#binding was presented in the 
> Reference class in http://onestepback.org/index.cgi/Tech/Ruby/
> RubyBindings.rdoc/style/print and ruby-talk:321138
> 
> At least from a theoretical standpoint, it's pretty compelling.

I don't find swapping variable values from within the callee to be 
particularly compelling case, and in the end example he's explicitly 
indicating that he wants the variables to be referenced from outside of 
this scope. If that were codified into the language, you'd have exactly 
the same effect without the global penalty that always-mutable captured 
scopes brings along.

I understand your use case; you want to be able to mutate the caller's 
scope. But I see the problems of that mutability as being more 
problematic than the benefits:

- It opens up the possibility that any block-receiving call can violate 
my expectations about variable mutation (proc-as-binding)
- It opens up the possibility that any method at all can violate my 
expectations about variable mutation (Binding.of_caller)
- It reduces my trust in code I've written, since I can't know by 
looking at it that a variable will have the same value before and after 
an unrelated call.

If those aren't compelling enough, there's 
logistical/implementation/design concerns:

- It limits static optimization of how variables are stored, in the case 
of proc-as-binding.

When we know variables aren't going to be accessed outside a given 
scope, they can be put on the stack or ideally, into registers. Both of 
these would be faster than variables on the heap, as in MRI and YARV today.

- It makes stack or register-based optimization of variables nearly 
impossible, in the case of Binding.of_caller

Binding.of_caller is an absolute worst case, since not only can we not 
optimize methods that don't eval or use closures, we can't optimize 
methods that do *any calls at all*, since any one of those calls might 
expect to gain access to our local scope.

No, I don't think implementation and performance concerns alone should 
motivate the design of Ruby. But coupled with the other issues above, 
it's pretty compelling. :)

And for the record, I've made my case against proc-as-binding before, 
and neither then nor now do I seriously expect it will go away. But it 
sure would be nice, and the performance gains that would result are 
*very* real.

- Charlie