Kent Dahl wrote: > > Bob Sidebotham wrote: > > > > I'm a bit puzzled whether there is any semantic difference between the > > two code fragments, below: > ... > > yield i1 > ... > > fibUpTo(1000) { |f| print f, " " } > > > VS. > AFAIK, the second creates an object (of type Proc), something the first > version doesn't do. So a Proc object is a little extra wrapping around a bare block in order to make the block more generally available? And the method-with-block syntax plus yield is really intended to make things more efficient by restricting the ability to call the block to just the invoked method? So we're really talking the difference between static vs. dynamic blocks? > I tend to use the > def fibUpTo( max, &blk ) > version to remove the need for the caller to know that its an explicit > Proc object, unless I need several of them. I hadn't understood that section of Programming Ruby. I see now that the example from PR: bStart = JukeboxButton.new("Start") { songList.start } is exactly the same (I think) as: bStart = JukeboxButton.new("Start", proc { songList.start }) but lets you write what (I'm assuming) is a less efficient call using the same syntax as the more efficient block-only. And this implies a third variant of the fibonacci function: # Another modified example from Programming Ruby def fibUpTo(max, &blk) i1, i2 = 1, 1 # parallel assignment while i1 <= max blk.call i1 i1, i2 = i2, i1+i2 end end fibUpTo(1000) { |f| print f, " " } Assuming that my understanding of all of this is correct, I think it would make it easier if the documentation (eg. Programming Ruby) could define yield in terms of call and closure (or at least discuss this). If it's really the same thing, then it makes it easier (for me, anyway) to understand flow-of-control, scoping, returning results, parameters, etc., simply because it makes it less magical. It's also clear (if all of the above is correct!) that the original example from PR should be the most efficient implementation of the three. Thanks, Bob