And this is curious: The mental model preforms my understanding of the languages internal workings. And as I want to understand how the metaprogramming capabilities of Ruby work, choosing the right model is essential.

But what is the “right model”?

And this is curious: The mental model preforms my understanding of the languages internal workings. And as I want to understand how the metaprogramming capabilities of Ruby work, choosing the right model is essential.

But what is the “right model”?

There's an open bug in 1.8.x in which changing the metaclass of the Proc produces a different Proc across method boundaries, but this is (a) fixed in 1.9, and (b) not a bug in Rubinius and JRuby.

I say it's a bug because if you read the actual C code, you can see the mistake (a use of CLASS_OF without rb_class_real).
In implementations without this bug, you can modify the metaclass of a Proc and it will persist across method boundaries. Additionally, this is *actually* the implementation in Rubinius.

Also, this model doesn't neatly handle the case of & where the object itself is not a Proc. In all implementations, &foo calls to_proc on foo, and the returned Proc is passed to the method. In order to understand this behavior using the “reified block” model, you need to also posit that the block is extracted from the returned Proc and then reattached later. This step is entirely unneeded to explain what is happening.

Since it *is not* always happening in practice (for instance, in Rubinius), and the step is unneeded to explain the observed phenomenon, why should we add it to our model of the phenomenon?

It just seems to me that you are trying to describe your platonic ideal as THE shared mental model that Ruby coders should keep in mind – and that's going to bite people unless and until you are able to convince Ruby implementors that your described semantics are the ones they should strive to preserve. If that's what you're trying to do here – put forward a semantic model you think *should* be the common mental baseline for Ruby implementors – then just say so. But I don't think it's accurate yet to say that this model is the one that all implementors are already keeping in mind as they build their runtimes.

I don't think yours is a *bad* model, but I don't see what makes it more valid than any other. The fact that one implementation of Ruby chose this model doesn't convince me, especially since I suspect MRI did not go this route (I haven't had time to check the source to confirm that).

Here's the thing. My imagination reflects reality, while the standard does not. So while it's true that “the standards reflect reality no more than my imagination”, they certainly reflect reality less than my imagination.

I think a very good touchstone for reality is how Rubinius thinks of the world, since much of it is implemented in Ruby. Consider the following code:

def bar(&block) block end
foo = proc { 1 }
bar(&foo)

In Rubinius, foo is passed directly to bar, because, in Rubinius, &foo means “get the Proc from foo and and send the result to the method”.

This view of the world clearly explains why sending a block across multiple methods retains object identity, while the Proc.new approach in the spec, in addition to being provably false (as you demonstrated) does not explain it.

When choosing between two competing descriptions of the same phenomenon, we tend to choose the description that most fits with the phenomenon being described, not a “platonic ideal” of what we wish we were seeing.

I tested it on ruby 1.9.1, jruby and rubinius, none of them print the line “in Proc.new”, so I am certain it is a spec issue

rvm ruby test.rb :

jruby-1.4.0: jruby 1.4.0 (ruby 1.8.7 patchlevel 174) (2009-11-02 69fbfa3) (Java HotSpot(TM) Client VM 1.6.0_15) [i386-java]

in foo
in bar
in block

rbx-1.0.0-rc2: rubinius 1.0.0-rc2 (1.8.7 release 2010-01-04 JI) [i686-pc-linux-gnu]

in foo
in bar
in block

ree-1.8.7-2010.01: ruby 1.8.7 (2009-12-24 patchlevel 248) [i686-linux], MBARI 0×8770, Ruby Enterprise Edition 2010.01

in foo
in bar
in block

ruby-1.8.7-p249: ruby 1.8.7 (2010-01-10 patchlevel 249) [i686-linux]

in foo
in bar
in block

ruby-1.9.1-p378: ruby 1.9.1p378 (2010-01-10 revision 26273) [i686-linux]

in foo
in bar
in block

I think Yehuda is right and the specs should be changed, but what *I* think is not important
You should send a small mail to mailing-list.