Blocks as Iterators

As mentioned earlier, one of the primary uses of blocks in Ruby is to provide iterators to which a range or list of items can be passed. Many standard classes such as Integer and Array have methods that can supply items over which a block can iterate. For example:

3.times{ |i| puts( i ) }
[1,2,3].each{|i| puts(i) }

You can, of course, create your own iterator methods to provide a series of values to a block. In the iterate1.rb program, I have defined a simple timesRepeat method that executes a block a specified number of times. This is similar to the times method of the Integer class except it begins at index 1 rather than at index 0 (here the variable i is displayed in order to demonstrate this):

iterate1.rb

def timesRepeat( aNum )
    for i in 1..aNum do
        yield i
    end
end

Here is an example of how this method might be called:

timesRepeat( 3 ){  |i| puts("[#{i}] hello world") }

This displays the following:

[1] hello world
[2] hello world
[3] hello world

I’ve also created a timesRepeat2 method to iterate over an array:

def timesRepeat2( aNum, anArray )
    anArray.each{ |anitem|
        yield( anitem )
    }
end

This could be called in this manner:

timesRepeat2( 3, ["hello","good day","how do you do"] ){ |x| puts(x) }

This displays the following:

hello
good day
how do you do

Of course, it would be better (truer to the spirit of object orientation) if an object itself contained its own iterator method. I’ve implemented this in the next example. Here I have created MyArray, a subclass of Array:

class MyArray < Array

It is initialized with an array when a new MyArray object is created:

def initialize( anArray )
    super( anArray )
end

It relies upon its own each method (an object refers to itself as self), which is provided by its ancestor, Array, to iterate over the items in the array, and it uses the times method of Integer to do this a certain number of times. This is the complete class definition:

iterate2.rb

class MyArray < Array
    def initialize( anArray )
        super( anArray )
    end

    def timesRepeat( aNum )
        aNum.times{           # start block 1...
             | num |
             self.each{       # start block 2...
                  | anitem |
                  yield( "[#{num}] :: '#{anitem}'" )
             }                # ...end block 2
        }                     # ...end block 1
    end
end

Notice that, because I have used two iterators (aNum.times and self.each), the timesRepeat method comprises two nested blocks. This is an example of how you might use this:

numarr = MyArray.new( [1,2,3] )
numarr.timesRepeat( 2  ){ |x| puts(x) }

This would output the following:

[0] :: '1'
[0] :: '2'
[0] :: '3'
[1] :: '1'
[1] :: '2'
[1] :: '3'

In iterate3.rb, I have set myself the problem of defining an iterator for an array containing an arbitrary number of subarrays, in which each subarray has the same number of items. In other words, it will be like a table or matrix with a fixed number of rows and a fixed number of columns. Here, for example, is a multidimensional array with three “rows” (subarrays) and four “columns” (items):

iterate3.rb

multiarr =
[ ['one','two','three','four'],
  [1,    2,    3,      4     ],
  [:a,   :b,   :c,    :d     ]
]

I’ve tried three alternative versions of this. The first version suffers from the limitation of only working with a predefined number (here 2 at indexes [0] and [1]) of “rows” so it won’t display the symbols in the third row:

multiarr[0].length.times{|i|
    puts(multiarr[0][i], multiarr[1][i])
}

The second version gets around this limitation by iterating over each element (or “row”) of multiarr and then iterating along each item in that row by obtaining the row length and using the Integer’s times method with that value. As a result, it displays the data from all three rows:

multiarr.each{ |arr|
    multiarr[0].length.times{|i|
        puts(arr[i])
    }
}

The third version reverses these operations: The outer block iterates along the length of row 0, and the inner block obtains the item at index i in each row. Once again, this displays the data from all three rows:

multiarr[0].length.times{|i|
    multiarr.each{ |arr|
        puts(arr[i])
    }
}

However, although versions 2 and 3 work in a similar way, you will find that they iterate through the items in a different order. Version 2 iterates through each complete row one at a time. Version 3 iterates down the items in each column. Run the program to verify that. You could try creating your own subclass of Array and adding iterator methods like this—one method to iterate through the rows in sequence and one to iterate through the columns.

Digging Deeper

Here we look at important differences between block scoping in Ruby 1.8 and 1.9 and also learn about returning blocks from methods.

Returning Blocks from Methods

Earlier, I explained that blocks in Ruby may act as closures. A closure may be said to enclose the “environment” in which it is declared. Or, to put it another way, it carries the values of local variables from its original scope into a different scope. The example I gave previously showed how the block named ablock captures the value of the local variable x:

block_closure.rb

x = "hello world"
ablock = Proc.new { puts( x ) }

It is then able to “carry” that variable into a different scope. Here, for example, ablock is passed to aMethod. When ablock is called inside that method, it runs the code puts( x ). This displays “hello world” and not “goodbye”:

def aMethod( aBlockArg )
    x = "goodbye"
    aBlockArg.call            #=> "hello world"
end

In this particular example, this behavior may seem like a curiosity of no great interest. In fact, block/closures can be used more creatively.

For example, instead of creating a block and sending it to a method, you could create a block inside a method and return that block to the calling code. If the method in which the block is created happens to take an argument, the block could be initialized with that argument.

This gives you a simple way of creating multiple blocks from the same “block template,” each instance of which is initialized with different data. Here, for example, I have created two blocks and assigned them to the variables salesTax and vat, each of which calculates results based on different values (0.10) and (0.175):

block_closure2.rb

def calcTax( taxRate )
    return lambda{
        |subtotal|
            subtotal * taxRate
    }
end

salesTax = calcTax( 0.10 )
vat = calcTax( 0.175 )

print( "Tax due on book = ")
print( salesTax.call( 10 ) )       #=> 1.0

print( "\nVat due on DVD = ")
print( vat.call( 10 ) )            #=> 1.75

Blocks and Instance Variables

One of the less obvious features of blocks is the way in which they use variables. If a block may truly be regarded as a nameless function or method, then, logically, it should be able to contain its own local variables and have access to the instance variables of the object to which the block belongs.

Let’s look first at instance variables. Load the closures1.rb program. This provides another illustration of a block acting as a closure—by capturing the values of the local variables in the scope in which it was created. Here I have created a block using the lambda method:

closures1.rb

aClos = lambda{
    @hello << " yikes!"
}

This block appends the string “ yikes!” to the instance variable @hello. Notice that at this stage in the proceedings, no value has previously been assigned to @hello. I have, however, created a separate method, aFunc, which does assign a value to a variable called @hello:

def aFunc( aClosure )
    @hello = "hello world"
    aClosure.call
end

When I pass my block (the aClosure argument) to the aFunc method, the method brings @hello into being. I can now execute the code inside the block using the call method. And sure enough, the @hello variable contains the “hello world” string. The same variable can also be used by calling the block outside of the method. Indeed, now, by repeatedly calling the block, I will end up repeatedly appending the string “ yikes!” to @hello:

aFunc(aClos)      #<= @hello = "hello world yikes!"
aClos.call        #<= @hello = "hello world yikes! yikes!"
aClos.call        #<= @hello = "hello world yikes! yikes! yikes!"
aClos.call        # ...and so on

If you think about it, this is not too surprising. After all, @hello is an instance variable, so it exists within the scope of an object. When you run a Ruby program, an object called main is automatically created. So, you should expect any instance variable created within that object (the program) to be available to everything inside it.

The question now arises: What would happen if you were to send the block to a method of some other object? If that object has its own instance variable, @hello, which variable will the block use—the @hello from the scope in which the block was created or the @hello from the scope of the object in which the block is called? Let’s try that. You’ll use the same block as before, except this time it will display a bit of information about the object to which the block belongs and the value of @hello:

aClos = lambda{
    @hello << " yikes!"
    puts("in #{self} object of class #{self.class}, @hello = #{@hello}")
}

Now, create a new object from a new class (X), and give it a method that will receive the block b and call the block:

class X
    def y( b )
        @hello = "I say, I say, I say!!!"
        puts( "   [In X.y]" )
        puts("in #{self} object of class #{self.class}, @hello = #{@hello}")
        puts( "   [In X.y] when block is called..." )
        b.call
    end
end

x = X.new

To test it, just pass the block aClos to the y method of x:

x.y( aClos )

And this is what is displayed:

[In X.y]
in #<X:0x32a6e64> object of class X, @hello = I say, I say, I say!!!
    [In X.y] when block is called...
in main object of class Object, @hello = hello world yikes! yikes! yikes!
 yikes! yikes! yikes!

So, it is clear that the block executes in the scope of the object in which it was created (main) and retains the instance variable from that object even though the object in whose scope the block is called has an instance variable with the same name and a different value.

Blocks and Local Variables

Now let’s see how a block/closure deals with local variables. In the closures2.rb program, I declare a variable, x, which is local to the context of the program:

closures2.rb

x = 3000

The first block/closure is called c1. Each time I call this block, it picks up the value of x defined outside the block (3,000) and returns x + 100:

c1 = proc{
    x + 100
}

Incidentally, even though this returns a value (in ordinary Ruby methods, the default value is the result of the last expression to be evaluated), in Ruby 1.9 you cannot explicitly use the return statement here like this:

return x + 1

If you do this, Ruby 1.9 throws a LocalJumpError exception. Ruby 1.8, on the other hand, does not throw an exception.

This block has no block parameters (that is, there are no “block-local” variables between upright bars), so when it is called with a variable, someval, that variable is discarded, unused. In other words, c1.call(someval) has the same effect as c1.call().

So, when you call the block c1, it returns x+100 (that is, 3,100); this value is then assigned to someval. When you call c1 a second time, the same thing happens all over again, so once again someval is assigned 3,100:

someval=1000
someval=c1.call(someval); puts(someval)    #<= someval is now 3100
someval=c1.call(someval); puts(someval)    #<= someval is now 3100

Note

Instead of repeating the call to c1, as shown earlier, you could place the call inside a block and pass this to the times method of Integer like this:

2.times{ someval=c1.call(someval); puts(someval) }

However, because it can be hard enough to work out what just one block is up to (such as the c1 block here), I’ve deliberately avoided using any more blocks than are absolutely necessary in this program!

The second block is named c2. This declares the “block parameter” z. This too returns a value:

c2 = proc{
    |z|
    z + 100
}

However, this time the returned value can be reused since the block parameter acts like an incoming argument to a method—so when the value of someval is changed after it is assigned the return value of c2, this changed value is subsequently passed as an argument:

someval=1000
someval=c2.call(someval); puts(someval)      #<= someval is now 1100
someval=c2.call(someval); puts(someval)      #<= someval is now 1200

The third block, c3, looks, at first sight, pretty much the same as the second block, c2. In fact, the only difference is that its block parameter is called x instead of z:

c3 = proc{
    |x|
    x + 100
}

The name of the block parameter has no effect on the return value. As before, someval is first assigned the value 1,100 (that is, its original value, 1,000, plus the 100 added inside the block). Then, when the block is called a second time, someval is assigned the value 1,200 (its previous value, 1,100, plus 100 assigned inside the block).

But now look at what happens to the value of the local variable x. This was assigned 3,000 at the top of the unit. Remember that, in Ruby 1.8, an assignment to a block parameter can change the value of a variable with the same name in its surrounding context. In Ruby 1.8, then the local variable x changes when the block parameter x is changed. It now has the value, 1,100—that is, the value that the block parameter, x, last had when the c3 block was called:

x = 3000
someval=1000
someval=c3.call(someval); puts(someval)    #=> 1100
someval=c3.call(someval); puts(someval)    #=> 1200
puts( x ) # Ruby 1.8, x = 1100. Ruby 1.9, x = 3000

Incidentally, even though block-local variables and block parameters can affect similarly named local variables outside the block in Ruby 1.8, the block variables themselves have no “existence” outside the block. You can verify this using the defined? keyword to attempt to display the type of variable if it is, indeed, defined:

print("x=[#{defined?(x)}],z=[#{defined?(z)}]")

This demonstrates that only x, and not the block variable z, is defined in the main scope:

x=[local-variable], z=[]

Matz, the creator of Ruby, has described the scoping of local variables within a block as “regrettable.” Although Ruby 1.9 has addressed some issues, it is worth noting that one other curious feature of block scoping remains: Namely, local variables within a block are invisible to the method containing that block. This may be changed in future versions. For an example of this, look at this code:

local_var_scope.rb

def foo
    a = 100
    [1,2,3].each do |b|
        c = b
        a = b
        print("a=#{a}, b=#{b}, c=#{c}\n")
    end
    print("Outside block: a=#{a}\n")    # Can't print #{b} and #{c} here!!!
end

Here, the block parameter, b, and the block-local variable, c, are both visible only when inside the block. The block has access to both these variables and to the variable a (local to the foo method). However, outside of the block, b and c are inaccessible, and only a is visible.

Just to add to the confusion, whereas the block-local variable, c, and the block parameter, b, are both inaccessible outside the block in the previous example, they are accessible when you iterate a block with for, as in the following example:

def foo2
    a = 100
    for b in [1,2,3] do
        c = b
        a = b
        print("a=#{a}, b=#{b}, c=#{c}\n")
    end
    print("Outside block: a=#{a}, b=#{b}, c=#{b}\n")
end