[ruby-core:39858] Re: 2.0 feature questionnaire

On 2011/10/03 16:32, Joshua Ballanco wrote:
> On Monday, October 3, 2011 at 3:01 AM, "Martin J. Dテシrst" wrote:

>> Anyway, if we get to a point where we can say:
>>
>> proc is Proc and does ..., and lambda is ->(){} and does ....
>> (where the '...' parts are extremely simple), then and only then can we
>> say "No confusion now.".
>
> Here is a helpful way to think about it:
>
> A lambda is an anonymous function. Like functions they have strict arity checking (you must pass the number of arguments specified) and they create their own return scope (i.e. return takes you out of the lambda/function).
>
> A proc is a block of code. As with any vanilla do窶ヲend construction in ruby, the number of arguments on the block does not need to match with what is passed to the block. Also, like do窶ヲend, procs do not create their own return scope. You shouldn't return from a proc if you wouldn't return from a do窶ヲend in the same position (i.e. never).
>
> Is that clearer?

Clearer, but not short enough. What about:

proc is Proc is an objectified block, and lambda is ->(){} is an 
anonymous function.

If that's true, then we have indeed made some progress, which is really 
great.

However, now that block arguments (and therefore I assume proc/Proc 
arguments) have defaults and splats and such stuff, is the distinction 
re. argument number (not only for lambdas vs. procs, but also for 
methods vs. blocks) still necessary? We definitely have to consider the 
transition costs/backwards compatibility.

But wouldn't it be easier if we had strict arity checking in both cases? 
If there's a block where that's not desired, it can always be expressed 
in terms of defaults (for missing arguments) and splats (if we want to 
ignore superfluous ones), as it's done today for methods. And sometimes 
it may be helpful to get an error for a missing or additional argument 
even for a block.

I haven't yet thought about the difference in terms of return scope. But 
maybe others have some good ideas on how to get rid of the differences here.

Regards,    Martin.