Proc#== behaviour (from Ruby-Core)

[Adam Prescott]

[Note: parts of this message were removed to make it a legal post.]

I did ask this question on Ruby-Core a few days ago, but no-one has replied
back, so I thought it might get more love here. (Perhaps I'm being stupid.)

I'll just copy it verbatim from there. If cross-posting it is wholly
objectional, I'm happy to wait, although this problem is holding up some of
my code.

--

I've encountered a problem when using Proc#== (with both lambdas and procs)
in my code, where the result does not match up with what the documentation
says. 1.9.2 differs from 1.8.7 in result and in the source code, so that
suggests attention has been given to the method, at least. It was suggested
that ruby-core was the place to go for this.

Here's a paste of the problem, with full RUBY_DESCRIPTIONs:
https://gist.github.com/899026

I've included lambda, proc, and Proc.new variants just for completion, even
though I realise proc is an alias for lambda or Proc.new, depending.

At the very least, perhaps someone could explain why this is by design, if
it's not a bug. Apologies if there's an open issue for this on redmine; the
site is currently not working for me (again), and I couldn't find anything
online mentioning this.

 

[Adam Prescott]

[Note: parts of this message were removed to make it a legal post.]

I decided to just do what I should've done in the first place, and open an
issue on Redmine: http://redmine.ruby-lang.org/issues/4559

 

[Gary Wright]

I've encountered a problem when using Proc#=3D=3D (with both lambdas = and procs)
in my code, where the result does not match up with what the = documentation
says. 1.9.2 differs from 1.8.7 in result and in the source code, so = that
suggests attention has been given to the method, at least. It was = suggested
that ruby-core was the place to go for this.

I've run into this issue in the past. One of the issues is that the =
binding associated with a proc can be different even if the 'source' of =
the binding is the same. I think that is enough to ensure that the =
proc's won't be considered equal via =3D=3D.

You can dup or clone a proc in 1.9.2 to get equivalent procs even though =
the bindings still aren't equal:

l1 =3Druby-1.9.2-p180 > l1 =3D lambda { 1 + 1 }
=3D> #<Proc:0x8aa8a4@(irb):1 (lambda)>=20
ruby-1.9.2-p180 > l2 =3D lambda { 1 + 1 }
=3D> #<Proc:0x87a848@(irb):2 (lambda)>=20
ruby-1.9.2-p180 > l1 =3D=3D l2
=3D> false=20
ruby-1.9.2-p180 > l3 =3D l1.clone
=3D> #<Proc:0x8759ec@(irb):1 (lambda)>=20
ruby-1.9.2-p180 > l1 =3D=3D l3
=3D> true=20
ruby-1.9.2-p180 > l1.binding =3D=3D l3.binding
=3D> false=20


I don't really have a conclusion, just wanted to point out the binding =
issue and the dup/clone behavior.

Gary Wright=

 

[7stud --]

In case you didn't know, procs and lambdas in ruby are a mess.

 

[Adam Prescott]

[Note: parts of this message were removed to make it a legal post.]

In case you didn't know, procs and lambdas in ruby are a mess.

I knew, at least, ever since I read
http://innig.net/software/ruby/closures-in-ruby.rb

I didn't think something like equality would be broken though...

 

[Gary Wright]

=20
=20
I knew, at least, ever since I read
http://innig.net/software/ruby/closures-in-ruby.rb

Interesting read but it seems like the author creates a bit more =
confusion than is necessary.

That article repeats the common inaccuracy of treating blocks as =
instances of Proc, but this is a category error. The two things are =
related but not the same thing at all. I think it clarifies things to =
view the term 'block' as a describing a syntactic element of a method =
call and not as an instance of Proc. The syntactic element can get =
reified into in a instance of Proc (or not) but the syntactic =
representation is not itself an instance of Proc.

An analogy would be the difference between a literal integer and a =
fixnum instance:

f1 =3D 16
f2 =3D 0xf
f3 =3D 0b10000

Here are three different syntactic representations of a single fixnum =
reference. The sequence of characters '16' is not an instance of =
Fixnum, nor is '0xf' or '0b10000'. The literals cause the runtime to =
produce a reference to an instance of Fixnum but the syntactical =
elements are not themselves objects.

Similarly for blocks:

3.times { puts 'hip, hip, hooray!' }
3.times do puts 'hip, hip, horray! }

The blocks are syntactically part of the method call to times and are =
not themselves instances of Proc. And in the following:

proc { #block }
lambda { #block }
Proc.new { #block}

The 'magic' is happening in the method calls themselves and not in the =
syntactic structure of the method calls, which is completely standard.

In the referenced article, the author starts off with:

But then I found out that a
function can't accept multiple blocks -- violating the principle that = closures
can be passed around freely as values.

The author's terminology is creating more complexity and perhaps =
confusion than is warranted. It is true that a method call can only =
have a single block in the same way that a method call can only have a =
single argument list. They are both syntactical constructs of a method =
call (blocks and argument lists).

It is not true that a method can not manipulate multiple closures =
(instances of a Proc):

def compose(f1, f2, arg)
f1.call(f2.call(arg))
end

puts compose( lambda {|x| x * 2 }, lambda { |y| y + 1 }, 10 )

Ruby happens to provide a special syntax for creating and passing a =
single closure to a method (i.e. the block syntax) but that doesn't =
prevent you from creating and passing multiple closures to a method if =
that is what is desired.

The key point I'm trying to make is that it clarifies things to think of =
'block' as a syntactical term and to think of 'closure' or 'instance of =
a Proc' as the actual object that is being manipulated (i.e. passed =
around, called, queried and so on).

When you look at a method that explicitly captures a block:

def iterate(a1, a2, &b)
[a1,a2].each(&b)
end

It is again important to think of '&' as a syntactical construct in the =
same way that the parens and commas are part of the syntax of the formal =
argument list or of an actual method call. The & isn't some strange =
operator that converts or manipulates the proc instances referenced by =
b, it is simply a syntactical marker for the block element of the method =
syntax.

Gary Wright=

 

[Gary Wright]

[Note: parts of this message were removed to make it a legal post.]

3.times { puts 'hip, hip, hooray!' }
3.times do puts 'hip, hip, horray! }

-----------------------------------------------^^^^^

That should have been 'end' not '}'

Gary Wright