Comments on Electric Sheep Blog: Ruby blocks gotchas

I know it's been a while since this post was f...

2011-06-05T19:10:31.552+05:30

I know it's been a while since this post was first published, but since people are still commenting on it and noone's suggested possibly the most awesome solution to this, here goes.

I know that the point of the post wasn't to implement a profiling/benchmarking framework, but what you're trying to achieve could be implemented using a trivial DTrace script => rb_functime.d. Since you're on OSX, you should already have libdrace (as well as its dtrace frontend utility), but if you insist on going ruby all the way, there's always ruby-dtrace.

On a more interesting note, DTrace probes for Ruby were released just a few months before your blog post! :P

2011-06-05T18:57:54.626+05:30

This comment has been removed by the author.

Thanks for the post! I've also written an arti...

2011-05-05T18:41:07.132+05:30

Thanks for the post! I've also written an article about Ruby blocks and closures with code examples.

Still some useful info in this post and comments. ...

2011-01-25T19:29:36.493+05:30

Still some useful info in this post and comments. Was fighting a similar problem and this helped.

In 1.8.7, this was working:

... do |*a, &blk|
...
send meth, *a, &blk

But 1.8.6 didn't like this syntax.
After much playing around, I found I needed a "passthrough block" :

... do |*a| ...
send meth, *a { yield }

Hope this comment saves someone else some time.

This is 3 years after your original post hehe...an...

2010-11-07T05:35:36.578+05:30

This is 3 years after your original post hehe...anyway..

I don't believe this behaviour is an inconsistency. It is a result of blocks being captured by closures and so the 'yield' instead invokes any extant block in the enclosing context.

See here: http://banisterfiend.wordpress.com/2010/11/06/behavior-of-yield-in-define_method/

I really don't think it can get any simpler th...

2008-07-31T04:53:00.000+05:30

I really don't think it can get any simpler than this:

x = lambda do
puts 'hello'
yield
end

x.call { puts 'world' }

And the above example still doesn't work with ruby 1.9.0 (2008-07-31 revision 18282) [x86_64-linux].

hello
test.rb:3:in `block in <main>': no block given (yield) (LocalJumpError)
from test.rb:6:in `call'
from test.rb:6:in `<main>'

So as far as I can see, no, Ruby 1.9 most definitely does not (yet) allow me to IMPLICITLY pass a block to another block, unless we are going to argue that lambdas are some kind of special case.

A new thing Ruby 1.9 can do is allow me to EXPLICITLY pass a block. This works in Ruby 1.9 (but didn't work in 1.8)

x = lambda do |&block|
puts 'hello'
block.call
end

x.call { puts 'world' }

Functionally, this is good enough. But the whole business with |&block| is ugly and inconsistent with the use of yield inside methods. Wouldn't allowing the use of yield inside a lambda be nicer? Or am I missing something here?

Kudos on tackling a tricky subject with this post....

2008-06-30T00:38:00.000+05:30

Kudos on tackling a tricky subject with this post. I'd like to offer a couple of "clarifications" which hopefully will help people.

The reason the implicit version is faster is because you are repeatedly constructing the Proc every time in the explicit version.

If you never access the Proc directly, why add the overhead of constructing an object? This way, you only pay for what you need.

I don't really see how this violates the "everything is an object" rule, since as soon as you try to access it, the block becomes an object. :)

Also: the problem with passing blocks to blocks is not due to define_method, just blocks. A similar difference exists with default arguments. Method arguments and block arguments will operate the same way (I think) in Ruby 1.9.

IMHO, the biggest inconsistency with blocks, especially post 1.9, is one you haven't alluded to here, which is that return behaves differently between Proc.new and lambda.

See:
http://tinyurl.com/29a28d

When returning from blocks, passed explicitly or implicitly, return takes you all the way out of the calling method. That is, they behave like Proc.new (which makes sense), not lambda.

This is arguably necessary to support the POLS when dealing with inline blocks (say, with #each). You don't expect return to just pop you out of the block, you expect to return from the method. Not sure if that changes in 1.9?

Anyway, thanks again for the interesting article!

Why are you handrolling your own dubious benchmark...

2008-06-29T15:38:00.000+05:30

Why are you handrolling your own dubious benchmarking class?

Looks like this post is still alive and people rea...

2008-03-15T22:50:00.000+05:30

Looks like this post is still alive and people read it.. A post that clarifies a lot more things about blocks, closures, procs in ruby is here http://innig.net/software/ruby/closures-in-ruby.rb

I see four problems with blocks in Ruby 1.8:

2008-01-02T21:15:00.000+05:30
I see four problems with blocks in Ruby 1.8:

1. Can't pass a block to a block, thus causing problems with define_method and similar.

2. The differences between Proc.new, proc, lambda, and implicit blocks. I have a hard time keeping the differences straight, and try to use only lambda and implicit blocks.

3. The performance difference between explicit and implicit block-passing.

4. The only way to pass more than one block to a method is to pass (all but one of) them as explicit procs/lambdas.

Of these, the first one is definitely fixed in Ruby 1.9, and I think the second one is as well. The third is a quirk of MRI, and it would be worth running some benchmarks in other Ruby implementations (JRuby, Rubinius, IronRuby...). The fourth comes up rarely enough that I have a hard time suggesting a more convenient syntax, even though it annoys me on occasion.

In addition, an implicit block can be captured into a Proc object:

def foo
Proc.new
end

bar = foo { |arg| puts "You called me with #{arg}" }
bar.call(22)
bar.call(99)

I might argue that the implicit block and yield construct in Ruby is a mistake to begin with, but it improves the readability of iteration methods. That one case may or may not justify the complication of two parallel block-passing constructs, however.

You're right, I've been investigating something si...

2007-11-30T00:46:00.000+05:30

You're right, I've been investigating something similar and I stumble upon the same caveats that you did. If someone knows some little known black magic here would be great.

re: Blocks violate the 'everything is an object' r...

2007-11-27T15:35:00.000+05:30

re: Blocks violate the 'everything is an object' rule in Ruby for performance reasons. They only become objects when bound to a variable.

I don't think this is correct. Two reasons: 1 - I have read that ruby blocks are not first class objects due to not wanting to expose the implementation to allow for future change. 2 - I'm an old Smalltalk'er. Blocks are first class objects in Smalltalk and a Smalltalk VM of 15 years ago in most cases outperforms a Ruby interpreter of today; including dynamic block dispatches. enjoy!!!

@anonymous #1 - you're right, it is clearer...

2007-11-26T23:50:00.000+05:30

@anonymous #1 - you're right, it is clearer your way. Thanks!

@anonymous #2 - thanks, for the tip, that's worthy of an update to the post.

@anonymous #3 - I didn't read it anywhere. What I did read was 'pure OO' and 'everything is an object'. Nothing mentioned exceptions to these rules.

I really dont think anyone ever wrote anything abo...

2007-11-26T22:08:00.000+05:30

I really dont think anyone ever wrote anything about blocks being objects. Where did you read that?

Ruby 1.9 block will accept a block as a parameter....

2007-11-26T14:41:00.000+05:30

Ruby 1.9 block will accept a block as a parameter.

def foo(*args)
blk = args.delete_at(-1) # We k...

2007-11-25T21:59:00.000+05:30

def foo(*args)
blk = args.delete_at(-1) # We know that the last argument
# is the bound block
blk.call(args.join(' '))
end

looks unnecessary clumsy. Why not:

def foo(blk, *args)
blk.call(args.join(' '))
end