On Aug 6, 2005, at 1:57 AM, Yukihiro Matsumoto wrote:
> They are all different for good reasons, but I do want to keep them
> all quack like ducks.  They all can be invoked by "call".  They all
> can tell numbers of their arguments by using "arity".  They all can be
> supplied as block arguments prefixing '&'.

Excellent on the quacking front. Does the following summary  
describing the intended future? (I suspect it has holes...I'd like to  
fill in the right details, so that I can understand fully the  
intended future, and explain the rationale to my friends.)

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- 
_-_-_-_-_-_-_

Ruby2 will have distinct objects for Methods, Blocks, and anonymous,  
first-class functions ("Lambdas").

Each of the three will have a different syntax for defining them.

All three are sections of code that take arguments and return one or  
more values (aka functions).

All three support specifying default values for some or all arguments.

All three support can report the number of defined arguments ("arity").

All three can be passed to each other as a 'block', which may be  
invoked using #yield inside the code.

It is possible to invoke all three in an arbitrary scope (where  
'self' and instance variables refer to a specific, runtime-chosen  
instance of any class) by passing them as a block to a special  
#instance_eval type method. (?Not true for 1.8...true for 2?)


It is possible to get a reference to a method and assign it to a  
variable.

A method reference is tied to a specific instance. 'self' and  
instance variables refer to that instance. It is possible to invoke a  
method reference in the scope of the instance to which it is tied  
without supplying the instance as a receiver.

It is possible to bind a method reference to a new instance. (?By  
unbinding it and rebinding the UnboundMethod to the new instance?)

Passing too many or too few arguments to a method will result in a  
runtime error.

Methods are not closures.


It is possible to get a reference to a Lambda and assign it to a  
variable.

Lambdas are not associated with any specific instance. 'self' and  
instance variables inside a lambda refer to the scope in which it was  
defined. (?Except when passed to #instance_eval?)

A reference to a lambda can be invoked. (?What scope?)

Passing too many or too few arguments to a lambda will result in a  
runtime error.

Lambdas are closures.


It is possible to get a reference to a block and assign it to a  
variable.

Blocks are associated with the instance that is the receiver of the  
method to which they are passed. 'self' and instance variables refer  
to that instance.

A reference to a block can be invoked. (#yield supplies the current  
scope? What about #call?)

Passing too many or too few arguments to a block will result in a  
runtime error.

Blocks are closures.

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- 
_-_-_-_-_-_-_


If the above is correct, then the future differences will simply be:
1) Methods are not closures; Lambdas and Blocks are.
2) Methods and Lambdas require specific arguments; Blocks do not.
3) Methods are associated with an instance; Lambdas and blocks are not.
4) All three have different syntaxes.