We’ve already seen Proc.new used in some of the previous examples in this chapter. This is the normal new method that most classes support, and it’s the most obvious way to create a new instance of the Proc class. Proc.new expects no arguments, and returns a Proc object that is a proc (not a lambda). When you invoke Proc.new with an associated block, it returns a proc that represents the block. For example:

p = Proc.new {|x,y| x+y }

If Proc.new is invoked without a block from within a method that does have an associated block, then it returns a proc representing the block associated with the containing method. Using Proc.new in this way provides an alternative to using an ampersand-prefixed block argument in a method definition. The following two methods are equivalent, for example:

def invoke(&b)     def invoke
  b.call             Proc.new.call
end                end

Another technique for creating Proc objects is with the lambda method. lambda is a method of the Kernel module, so it behaves like a global function. As its name suggests, the Proc object returned by this method is a lambda rather than a proc. lambda expects no arguments, but there must be a block associated with the invocation:

is_positive = lambda {|x| x > 0 }

In Ruby 1.8, the global proc method is a synonym for lambda. Despite its name, it returns a lambda, not a proc. Ruby 1.9 fixes this; in that version of the language, proc is a synonym for Proc.new.

Because of this ambiguity, you should never use proc in Ruby 1.8 code. The behavior of your code might change if the interpreter was upgraded to a newer version. If you are using Ruby 1.9 code and are confident that it will never be run with a Ruby 1.8 interpreter, you can safely use proc as a more elegant shorthand for Proc.new.

Ruby 1.9 supports an entirely new syntax for defining lambdas as literals. We’ll begin with a Ruby 1.8 lambda, created with the lambda method:

succ = lambda {|x| x+1}

In Ruby 1.9, we can convert this to a literal as follows:

With these changes, we get a Ruby 1.9 lambda literal:

succ = ->(x){ x+1 }

succ now holds a Proc object, which we can use just like any other:

succ.call(2)    # => 3

The introduction of this syntax into Ruby was controversial, and it takes some getting used to. Note that the arrow characters -> are different from those used in hash literals. If you squint at the arrow, you may be able to convince yourself that the greater-than sign is the Greek letter lambda (λ) with its right-hand leg chopped off, turned into a hyphen and moved to the left!

As with blocks in Ruby 1.9, the argument list of a lambda literal may include the declaration of block-local variables that are guaranteed not to overwrite variables with the same name in the enclosing scope. Simply follow the parameter list with a semicolon and a list of local variables:

# This lambda takes 2 args and declares 3 local vars
f = ->(x,y; i,j,k) { ... }

Lambda literals can be declared with argument defaults, just as methods can:

zoom = ->(x,y,factor=2) { [x*factor, y*factor] }

The parentheses around the argument list of a lambda literal are only required if the argument list includes a semicolon and block-local variable names. Otherwise parentheses may be omitted, resulting in a more compact syntax:

succ = ->x { x+1 }
zoom = ->x,y,factor=2 { [x*factor, y*factor] }

If the argument list of a lambda literal has parentheses around it, there must not be a space between the -> and the open parenthesis.

Lambda parameters and local variables are optional, of course, and a lambda literal can omit this altogether. The minimal lambda, which takes no arguments and returns nil, is the following:

->{}

One benefit of this new syntax is its succinctness. It can be helpful when you want to pass a lambda as an argument to a method or to another lambda:

def compose(f,g)            # Compose 2 lambdas 
  ->(x) { f.call(g.call(x)) }
end
succOfSquare = compose(->x{x+1}, ->x{x*x})
succOfSquare.call(4)        # => 17: Computes (4*4)+1

Lambda literals create Proc objects and are not the same thing as blocks. If you want to pass a lambda literal to a method that expects a block, prefix the literal with &, just as you would with any other Proc object. Here is how we might sort an array of numbers into descending order using both a block and a lambda literal:

data.sort {|a,b| b-a }   # The block version
data.sort &->(a,b){ b-a } # The lambda literal version

In this case, as you can see, regular block syntax is simpler.

Recall from Chapter 5 that the return statement returns from the lexically enclosing method, even when the statement is contained within a block. The return statement in a block does not just return from the block to the invoking iterator, it returns from the method that invoked the iterator. For example:

def test
  puts "entering method"
  1.times { puts "entering block"; return }  # Makes test method return
  puts "exiting method"  # This line is never executed
end
test

A proc is like a block, so if you call a proc that executes a return statement, it attempts to return from the method that encloses the block that was converted to the proc. For example:

def test
  puts "entering method"
  p = Proc.new { puts "entering proc"; return } 
  p.call                 # Invoking the proc makes method return
  puts "exiting method"  # This line is never executed
end
test

Using a return statement in a proc is tricky, however, because procs are often passed around between methods. By the time a proc is invoked, the lexically enclosing method may already have returned:

def procBuilder(message)            # Create and return a proc
  Proc.new { puts message; return } # return returns from procBuilder
  # but procBuilder has already returned here!
end

def test
  puts "entering method"
  p = procBuilder("entering proc")
  p.call                 # Prints "entering proc" and raises LocalJumpError!
  puts "exiting method"  # This line is never executed
end
test

By converting a block into an object, we are able to pass that object around and use it “out of context.” If we do this, we run the risk of returning from a method that has already returned, as was the case here. When this happens, Ruby raises a LocalJumpError.

The fix for this contrived example is to remove the unnecessary return statement, of course. But a return statement is not always unnecessary, and another fix is to use a lambda instead of a proc. As we said earlier, lambdas work more like methods than blocks. A return statement in a lambda, therefore, returns from the lambda itself, not from the method that surrounds the creation site of the lambda:

def test
  puts "entering method"
  p = lambda { puts "entering lambda"; return } 
  p.call                 # Invoking the lambda does not make the method return
  puts "exiting method"  # This line *is* executed now
end
test

The fact that return in a lambda only returns from the lambda itself means that we never have to worry about LocalJumpError:

def lambdaBuilder(message)        # Create and return a lambda
  lambda { puts message; return } # return returns from the lambda
end

def test
  puts "entering method"
  l = lambdaBuilder("entering lambda")
  l.call                 # Prints "entering lambda" 
  puts "exiting method"  # This line is executed
end
test

Figure 5-3 illustrated the behavior of the break statement in a block; it causes the block to return to its iterator and the iterator to return to the method that invoked it. Because procs work like blocks, we expect break to do the same thing in a proc. We can’t easily test this, however. When we create a proc with Proc.new, Proc.new is the iterator that break would return from. And by the time we can invoke the proc object, the iterator has already returned. So it never makes sense to have a top-level break statement in a proc created with Proc.new:

def test
  puts "entering test method"
  proc = Proc.new { puts "entering proc"; break }
  proc.call                    # LocalJumpError: iterator has already returned
  puts "exiting test method"
end
test

If we create a proc object with an & argument to the iterator method, then we can invoke it and make the iterator return:

def iterator(&proc)
  puts "entering iterator"
  proc.call  # invoke the proc
  puts "exiting iterator"   # Never executed if the proc breaks
end

def test
  iterator { puts "entering proc"; break }
end
test

Lambdas are method-like, so putting a break statement at the top-level of a lambda, without an enclosing loop or iteration to break out of, doesn’t actually make any sense! We might expect the following code to fail because there is nothing to break out of in the lambda. In fact, the top-level break just acts like a return:

def test
  puts "entering test method"
  lambda = lambda { puts "entering lambda"; break; puts "exiting lambda" }
  lambda.call  
  puts "exiting test method"
end
test

A top-level next statement works the same in a block, proc, or lambda: it causes the yield statement or call method that invoked the block, proc, or lambda to return. If next is followed by an expression, then the value of that expression becomes the return value of the block, proc, or lambda.

redo also works the same in procs and lambdas: it transfers control back to the beginning of the proc or lambda.

retry is never allowed in procs or lambdas: using it always results in a LocalJumpError.

raise behaves the same in blocks, procs, and lambdas. Exceptions always propagate up the call stack. If a block, proc, or lambda raises an exception and there is no local rescue clause, the exception first propagates to the method that invoked the block with yield or that invoked the proc or lambda with call.

Invoking a block with yield is similar to, but not the same as, invoking a method. There are differences in the way argument values in the invocation are assigned to the argument variables declared in the block or method. The yield statement uses yield semantics, whereas method invocation uses invocation semantics. Yield semantics are similar to parallel assignment and are described in Passing Arguments to a Block. As you might expect, invoking a proc uses yield semantics and invoking a lambda uses invocation semantics:

p = Proc.new {|x,y| print x,y }
p.call(1)       # x,y=1:     nil used for missing rvalue:  Prints 1nil
p.call(1,2)     # x,y=1,2:   2 lvalues, 2 rvalues:         Prints 12
p.call(1,2,3)   # x,y=1,2,3: extra rvalue discarded:       Prints 12
p.call([1,2])   # x,y=[1,2]: array automatically unpacked: Prints 12

This code demonstrates that the call method of a proc handles the arguments it receives flexibly: silently discarding extras, silently adding nil for omitted arguments, and even unpacking arrays. (Or, not demonstrated here, packing multiple arguments into a single array when the proc expects only a single argument.)

Lambdas are not flexible in this way; like methods, they must be invoked with precisely the number of arguments they are declared with:

l = lambda {|x,y| print x,y }
l.call(1,2)     # This works
l.call(1)       # Wrong number of arguments
l.call(1,2,3)   # Wrong number of arguments
l.call([1,2])   # Wrong number of arguments
l.call(*[1,2])  # Works: explicit splat to unpack the array