blocks, procs, and bears, oh my!

[Larry Siden]

Last night I watched a video interview with Matz on InfoQ.  Matz mentioned procs and blocks and then I began to ask myself, why does Ruby need both?  First there are scoping issues with blocks that I don't think crop up with procs or lambda.  But my biggest concern is that having both just makes the language more complicated than it needs to be.  

In particular, is there anything I can do with a block that I can't do with a proc or a lambda?  If functions are first class objects, then I should be able to pass a proc or lambda along with it's closure to another function, and execute it in that function.  Then there would be no need for a special "yield" operator.  It's true that the block syntax allows for some syntax-sugar like:

get '/foo' do

  ...

end

but the contents of the 'do' could just as well be treated as a lambda, with it's own scope and closure etc.  Just give it a default name in get(), like 'the_proc' or whatever and invoke it like any other function if it's not nil.

Am I the only one who's asked this question?

Larry Siden, 734-926-9614, http://umich.edu/~lsiden

The United States is a nation of laws, badly written and randomly enforced.
--Frank Zappa 1940-1993

[Patrick Hurley]

On Fri, Jan 29, 2010 at 2:11 PM, Larry Siden <lsi...@gmail.com> wrote:
> In particular, is there anything I can do with a block that I can't do with
> a proc or a lambda?

The only significant difference is that return statements in blocks
exit the defining scope, where return statements in lambdas exit the
lambda.

> Am I the only one who's asked this question?

No, it is primarily syntax sugar, but it is sweet :-) A lot of the
Ruby language design philosophy is about syntax, blocks are part of
that.

pth