On 2005-03-21, Florian Frank <flori / nixe.ping.de> wrote:
> The implementation of call without "call" is another thing: it seems to 
> be rather hackish at the moment. Expressions like f()() for f = {|| {|| 
> 1} } aren't possible, while f()[] is. Perhaps it would be better, to 
> leave this unchanged, and rely only on the #[] method instead. It would 
> be easier to explain, that f() is a call to the bound method f of self, 
> while f[] is a call to the #[] method of object f, which could be a 
> Proc. f could be bound to an object/class with define_method(:f, &f) and 
> then called from this object's context as f or f().

What I don't get: why is the restriction that the "(*) falls back to
#call" thingy works ony for locals? Locals are just the most problematic
case!

5(), {|x| x+x}(), $aaa(), @b()

would unambigously mean a hidden call to #call (I mean, without knowing
of the context). Unlike

abc()

which can now mean both self.abc and abc.call, depending on context.

So, given that this sugaring of #call is introduced, if I made any
restrictions, the first case which I would exculde is applying this
construct to locals!

But, rather, I wouldn't restrict then anything. As I see, upon
evaluating some construct, ruby didn't care about the syntactical form,
only the return value of the given chunk of code. That is, 

5 + case i
    when String; i.to_i
    when Numeric; i
    else 0
    end

works just as fine as 

5 + 4 

or as

5 + i

A kind of duck typing: if it quacks back a foo, then that foo can be
used as validly as a literal foo. (Aka "statements also have return
values").

Now it's pretty violated by this locals-restricted new syntax, and I
don't see the tradeoff behind. What purpose is served by this
restriction?
 
Csaba