When to use lambda, when to use Proc.new?

Question

In Ruby 1.8, there are subtle differences between proc/lambda on the one hand, and Proc.new on the other.

• What are those differences?
• Can you give guidelines on how to decide which one to choose?
• In Ruby 1.9, proc and lambda are different. What's the deal?

Answer 1

Closures in Ruby is a good overview for how blocks, lambda and proc work in Ruby, with Ruby.

Answer 2

To provide further clarification:

Joey says that the return behavior of Proc.new is surprising. However when you consider that Proc.new behaves like a block this is not surprising as that is exactly how blocks behave. lambas on the other hand behave more like methods.

This actually explains why Procs are flexible when it comes to arity (number of arguments) whereas lambdas are not. Blocks don't require all their arguments to be provided but methods do (unless a default is provided). While providing lambda argument default is not an option in Ruby 1.8, it is now supported in Ruby 1.9 with the alternative lambda syntax (as noted by webmat):

concat = ->(a, b=2){ "#{a}#{b}" }
concat.call(4,5) # => "45"
concat.call(1)   # => "12"

And Michiel de Mare (the OP) is incorrect about the Procs and lambda behaving the same with arity in Ruby 1.9. I have verified that they still maintain the behavior from 1.8 as specified above.

break statements don't actually make much sense in either Procs or lambdas. In Procs, the break would return you from Proc.new which has already been completed. And it doesn't make any sense to break from a lambda since it's essentially a method, and you would never break from the top level of a method.

next, redo, and raise behave the same in both Procs and lambdas. Whereas retry is not allowed in either and will raise an exception.

And finally, the proc method should never be used as it is inconsistent and has unexpected behavior. In Ruby 1.8 it actually returns a lambda! In Ruby 1.9 this has been fixed and it returns a Proc. If you want to create a Proc, stick with Proc.new.

For more information, I highly recommend O'Reilly's The Ruby Programming Language which is my source for most of this information.

Answer 3

Proc is older, but the semantics of return are highly counterintuitive to me (at least when I was learning the language) because:

1. If you are using proc, you are most likely using some kind of functional paradigm.
2. Proc can return out of the enclosing scope (see previous responses), which is a goto basically, and highly non-functional in nature.

Lambda is functionally safer and easier to reason about - I always use it instead of proc.

Answer 4

I didn't notice any comments on the third method in the queston, "proc" which is deprecated, but handled differently in 1.8 and 1.9.

Here's a fairly verbose example that makes it easy to see the differences between the three similar calls:

def meth1
  puts "method start"

  pr = lambda { return }
  pr.call

  puts "method end"  
end

def meth2
  puts "method start"

  pr = Proc.new { return }
  pr.call

  puts "method end"  
end

def meth3
  puts "method start"

  pr = proc { return }
  pr.call

  puts "method end"  
end

puts "Using lambda"
meth1
puts "--------"
puts "using Proc.new"
meth2
puts "--------"
puts "using proc"
meth3

Answer 5

Understanding Ruby Blocks, Procs and Lambdas by Robert Sosinski clearly explains these programming concepts and reinforces the explanations with example code. Method objects are related and covered as well.

Answer 6

It's worth emphasizing that return in a proc returns from the lexically enclosing method, i.e. the method where the proc was created, not the method that called the proc. This is a consequence of the closure property of procs. So the following code outputs nothing:

def foo
  proc = Proc.new{return}
  foobar(proc)
  puts 'foo'
end

def foobar(proc)
  proc.call
  puts 'foobar'
end

foo

Although the proc executes in foobar, it was created in foo and so the return exits foo, not just foobar. As Charles Caldwell wrote above, it has a GOTO feel to it. In my opinion, return is fine in a block that is executed in its lexical context, but is much less intuitive when used in a proc that is executed in a different context.