用lambda创建的procs和用Proc.new创建的procs之间另一个重要但微妙的区别是它们如何处理return语句:

在lambda创建的proc中，return语句只从proc本身返回 在proc .new创建的proc中，return语句有点令人惊讶:它不仅从proc中返回控制，而且还从包围proc的方法中返回控制!

这是lambda创建的proc的返回操作。它的行为方式可能和你预期的一样:

def whowouldwin

  mylambda = lambda {return "Freddy"}
  mylambda.call

  # mylambda gets called and returns "Freddy", and execution
  # continues on the next line

  return "Jason"

end


whowouldwin
#=> "Jason"

这里是proc。new-created的proc的返回，做同样的事情。您将看到Ruby打破了被大肆吹嘘的最小惊喜原则的一个案例:

def whowouldwin2

  myproc = Proc.new {return "Freddy"}
  myproc.call

  # myproc gets called and returns "Freddy", 
  # but also returns control from whowhouldwin2!
  # The line below *never* gets executed.

  return "Jason"

end


whowouldwin2         
#=> "Freddy"

由于这种令人惊讶的行为(以及更少的输入)，在创建procs时，我倾向于使用lambda而不是Proc.new。

我找到了这个页面，它展示了Proc.new和lambda之间的区别。根据该页面，唯一的区别是lambda严格限制它接受的参数数量，而Proc.new将缺失的参数转换为nil。下面是一个IRB会话示例，说明了两者的区别:

irb(main):001:0> l = lambda { |x, y| x + y }
=> #<Proc:0x00007fc605ec0748@(irb):1>
irb(main):002:0> p = Proc.new { |x, y| x + y }
=> #<Proc:0x00007fc605ea8698@(irb):2>
irb(main):003:0> l.call "hello", "world"
=> "helloworld"
irb(main):004:0> p.call "hello", "world"
=> "helloworld"
irb(main):005:0> l.call "hello"
ArgumentError: wrong number of arguments (1 for 2)
    from (irb):1
    from (irb):5:in `call'
    from (irb):5
    from :0
irb(main):006:0> p.call "hello"
TypeError: can't convert nil into String
    from (irb):2:in `+'
    from (irb):2
    from (irb):6:in `call'
    from (irb):6
    from :0

该页面还建议使用lambda，除非您特别想要容错行为。我同意这种观点。使用lambda似乎更简洁一点，而且差异如此微不足道，在一般情况下，它似乎是更好的选择。

至于Ruby 1.9，抱歉，我还没有研究过1.9，但我不认为他们会有那么大的变化(不过不要相信我的话，似乎你已经听说了一些变化，所以我可能错了)。

用lambda创建的procs和用Proc.new创建的procs之间另一个重要但微妙的区别是它们如何处理return语句:

在lambda创建的proc中，return语句只从proc本身返回 在proc .new创建的proc中，return语句有点令人惊讶:它不仅从proc中返回控制，而且还从包围proc的方法中返回控制!

这是lambda创建的proc的返回操作。它的行为方式可能和你预期的一样:

def whowouldwin

  mylambda = lambda {return "Freddy"}
  mylambda.call

  # mylambda gets called and returns "Freddy", and execution
  # continues on the next line

  return "Jason"

end


whowouldwin
#=> "Jason"

这里是proc。new-created的proc的返回，做同样的事情。您将看到Ruby打破了被大肆吹嘘的最小惊喜原则的一个案例:

def whowouldwin2

  myproc = Proc.new {return "Freddy"}
  myproc.call

  # myproc gets called and returns "Freddy", 
  # but also returns control from whowhouldwin2!
  # The line below *never* gets executed.

  return "Jason"

end


whowouldwin2         
#=> "Freddy"

由于这种令人惊讶的行为(以及更少的输入)，在创建procs时，我倾向于使用lambda而不是Proc.new。

在我看来，这两者之间最重要的区别是回报行为上的差异。我也更喜欢lambda，因为它的类型比Proc.new少:-)

为了进一步澄清:

Joey说Proc.new的返回行为令人惊讶。然而，当你认为Proc.new的行为就像一个块，这并不奇怪，因为这正是块的行为。另一方面，Lambas的行为更像方法。

这实际上解释了为什么Procs在涉及到arity(参数数量)时很灵活，而lambdas则不是。block不需要提供它们的所有参数，但方法需要(除非提供默认值)。虽然在Ruby 1.8中没有提供lambda参数default的选项，但现在Ruby 1.9支持它，并提供了另一种lambda语法(如webmat所述):

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

Michiel de Mare (OP)关于proc和lambda在Ruby 1.9中的行为与arity相同的说法是不正确的。我已经验证了它们仍然保持上面指定的1.8的行为。

break语句实际上在Procs或lambdas中都没有多大意义。在Procs中，break将从已经完成的Proc.new返回。从lambda中拆分没有任何意义，因为它本质上是一个方法，你永远不会从一个方法的顶层拆分。

next、redo和raise在Procs和lambdas中表现相同。然而重试在这两个中都是不允许的，并且会引发异常。

最后，不应该使用proc方法，因为它是不一致的，并且有意想不到的行为。在Ruby 1.8中，它实际上返回一个lambda!在Ruby 1.9中，这个问题已经修复，它会返回一个Proc。如果你想创建一个Proc，请坚持使用Proc.new。

要了解更多信息，我强烈推荐O'Reilly的《Ruby编程语言》，这是我大部分信息的来源。

我没有注意到问题中的第三个方法“proc”有任何注释，它已弃用，但在1.8和1.9中处理方式不同。

下面是一个相当详细的例子，可以很容易地看出三个类似调用之间的差异:

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