[ruby-core:32391] Re: Making custom_lambda() work

On Sep 14, 2010, at 12:11 PM, Magnus Holm wrote:

> Of course, if you read the proposal again, you'll see that it doesn't
> even mention the word "lambda". I'm talking about changing the meaning
> of "foo()" where foo is a local variable. So in this example:
> 
> a = [1,2,3]
> s = "Hello World!"
> h = { :color => :red }
> 
> a()
> s()
> h()
> 
> That would actually run "a.call()", "s.call()" and "h.call()". There's
> no special case for lambda.

I think you are still stuck with an ambiguity that can't be resolved
at parse time. The problem is that 'x()' already has a meaning to the
parser when x is a local variable. You can't re-write this to
x.call() at parse time because that would bypass the method call to 'x'.
The best you could do would be to restart the call as x.call() when 'x'
isn't found.

I'm still against it because of the special casing, and the complexity
of interacting with method_missing:

	search for method 'x' and invoke if found
	search for method 'x.call' and invoke if found
	search for method_missing and invoke if found
	search for 'x.method_missing' and invoke if found 

I'm not even sure if that would be the 'correct' order for handling
method_missing.

I just don't see why #call should have special syntax especially when
you can already get pretty darn close with #[]:

	some_proc_like_reference[1,2,3]

Gary Wright