I would love this. it seem a slight variation on the theme found here

I’ve wanted this for some time. I’ve found that the #call method is kind of embarrassing to explain to new Rubyists, because on one hand I say that Ruby supports first-class functions, and on the other hand I say that you can invoke them directly… This would be awesome.

f = lambda{ "yea baybe" }
p f

p f()

class Klass
  attr_reader :f
  def initialize
    f = lambda{ "yea baybe" }
  end
  def m
    "yea baybe" 
  end
end

o = Klass.new
p o.m            # => "yea baybe" 
p o.f.call       # => "yea baybe" 

# Now using the new idea, can we do this?
p o.f()          # => Does this work?
p o.f            # => does this return the function or the return value of the function?
p o.method(:m)   # and this?
p o.method(:m)() # ???

f = lambda{ lambda{|i| p i} }
f(3)   # who gets the '3' argument?

Personally, I’m happy with the f[3] syntax.

This seems too magic…

I like it. I especially like the idea that Matz tried this before and couldn’t reconcile the behavior. It’s satisfying to revisit an idea and find a simpler answer. Read that first paragraph and sense his elation. It’s cool. Go for it.

Gab, 1.9 procs can take blocks.

Dan, here are the answers:

f = lambda{ "yea baybe" }
p f   # no call happen without parens

p f() # execute f.call due to explicite parens

p o.f()          # 'o.f' is not a local variable
p o.f            # this returns the function
p o.method(:m)   # plain method object
p o.method(:m)() # 'o.method(:m)' is not a local variable

f = lambda{ lambda{|i| p i} }
f(3)   # who gets the '3' argument?
# outer lambda, and since it does not take argument,
# error will be raised.

Personally I would be against this. To be honest, I don’t find myself using .call an extreme amount. I do however, call tons of methods without using brackets, ala x = y.z. In my opinion you would be sacrificing a commonly used convience for a small teaspoon of syntactical sugar.

Of course, that’s just what I think (And perhaps I’ve misunderstood you)—it’s your language, and a beautiful one, I might add, so do as you see fit!

Wow. Talk about quick feedback (and from the source!). Thanks, matz!

I understand now. Essentially only local variables that refer to a function will feel the change. Parans are necessary for the call to be made. Gotcha.

Although it would be nice for all variables that refer to a function to be treated this new way. It too much to ask, I know :( Oh, yea, and allowing objects to define a ‘()’ operator…whoops, didn’t say it. Move along.

you can0t see me but I’m dancing the mud monkey dance, whatever that is :)

the mud monkey dance? isn’t that just the roger rabbit except you fly out of a saxophone and land in the year 2121? no wonder i can’t see you.

Names flying here… :) greetz @ matz + why j/k… :))

Dan, I’m afraid that your prefered way is python/scheme way after all, which I don’t want.

I like the parens-optional normal syntax and don’t mind the mandatory parens for this purpose. It’s much better than #call, anyway.

But can we override operator()? :)

I don’t strongly oppose this, but I really don’t see why it’s necessary. Are there any situations where this would really make a large difference?

What if you invert this?

produces a callable object. def g ; end does, but it doesn’t return a Method object, it just makes g callable. Maybe allow ::f and ::g to refer to the objects and f and g be calls with no args? Then you can have ::f() be a call with no args, also. We have a convention, but not enforced that :: is used in the construction of paths to objects and Class.x or instance.x is a call to a method.

Present whitespace rules mean that x.y is x .y and is x. y, otherwise we could have .x as the explicit method call syntax. Actually, it seems that the same whitespace rules apply to :: as to . Interesting.

Final thought: would .do be [50%] better than .call?

As some others, I’m really wondering why you would want this. What is the problem about call? And if you really implement calling procs with parentheses, what is the essential difference between procs and methods now?