Just realized that instance_eval yields self as an argument to the associated block (except for a bug in the 1.9.2 version: http://www.ruby-forum.com/topic/189422)
1.9.3p194 :003 > class C;end
1.9.3p194 :004 > C.new.instance_eval {|*a| a}
=> [#<C:0x00000001f99dd0>]
1.9.3p194 :005 >
Is this documented/spec'ed somewhere? Looking at ruby-doc:BasicObject, can't see any block params mentioned.
Is there a reason -apart from some purely historical one- for passing it explicitly when it self is always defined anyway?
The way I was hit by this is:
l = lambda { }
myobj.instance_eval(&l) # barks
This worked fine in 1.8.x (I guess because of block arity wasn't enforced).
Then upgraded to 1.9.2 - and it still worked! That's a strange coincidence as even though lambda block arguments are strictly enforced (so it would have complained for not declaring the argument for self), however due to the bug linked above - the self actually wasn't passed in this version..
Then upgraded to 1.9.3 where that bug got fixed, so it started to throwing the argument error - pretty surprising for a minor version change IMHO.
So one workaround is do declare parameter, or make lambda a block instead:
l = proc { }
myobj.instance_eval(&l) # fine
Just thought to describe the full story to help others avoid wasting time the way I did - until this is properly documented.
Reading Ruby's source code, what I can interpret is:
instance_eval is executing this:
return specific_eval(argc, argv, klass, self)
which in turn runs:
if (rb_block_given_p()) {
if (argc > 0) {
rb_raise(rb_eArgError, "wrong number of arguments (%d for 0)", argc);
}
return yield_under(klass, self, Qundef);
}
You can see they pass Qundef for the VALUES argument.
if (values == Qundef) {
return vm_yield_with_cref(th, 1, &self, cref);
}
In that particular line of code, they set manually argc (argument count) to 1 and the argument as "self". Later on the code that prepares the block sets the arguments to the block to these arguments, hence the first argument = "self" and the rest are nil.
The code that sets up the block arguments is doing :
arg0 = argv[0];
... bunch of code ...
else {
argv[0] = arg0;
}
for (i=argc; i<m; i++) {
argv[i] = Qnil;
}
Resulting in:
1.9.3p194 :006 > instance_eval do |x, y, z, a, b, c, d| x.class end
=> Object
1.9.3p194 :008 > instance_eval do |x, y, z, a, b, c, d| y.class end
=> NilClass
Why ? I have no idea but the code seems to be intentional. Would be nice to ask the question to the implementers and see what they have to say about it.
[Edit]
This probably is like that because the blocks you pass to instance_eval may or may not be crafted for it (code that depends on self being set to the class you want the block to modify), instead they may assume you are going to pass them the instance you want them to modify as an argument and in this way they would work with instance_eval as well.
irb(main):001:0> blk = Proc.new do |x| x.class end
#<Proc:0x007fd2018447b8#(irb):1>
irb(main):002:0> blk.call
NilClass
irb(main):003:0> instance_eval &blk
Object
Of course this is only a theory and without official documentation I can only guess.
I have just dicovered that unlike #instance_eval, which is primarily intended for string evaluation, #instance_exec primarily intended for block evaluation, does not have the described behavior:
o = Object.new
o.instance_exec { |*a| puts "a.size is #{a.size}" }
=> a.size is 0
This is probably an unintended inconsistency, so you might have discovered a bug. Post it on Ruby bugs.
I just asked the same question here: Ruby lambda's proc's and 'instance_eval'
And after reading the answer and working through some code, I think I understand why ruby has this strange (IMHO) inconsistency.
It basically allows Symbol#to_proc to work.
For example ["foo", "bar"].each(&:puts) is short for [...].each { |x| puts x }
NOT
[...].each { self.puts }
So ruby also passes self as the first param to the proc, so basically the proc can either use self or its first param.
Since instance eval does not by definition explicitly pass params this is almost always invisible behavior.
The exception is when the proc is a lambda. This DOES NOT WORK:
2.4.1 :015 > foo = -> { puts 'hi' }
=> #<Proc:0x007fcb578ece78#(irb):15 (lambda)>
2.4.1 :016 > [1, 2, 3].each(&foo)
ArgumentError: wrong number of arguments (given 1, expected 0)
from (irb):15:in `block in irb_binding'
from (irb):16:in `each'
from (irb):16
So I think the only time this becomes a problem is when instance_eval is being used with some unknown value, where you don't know if the proc is a lambda or not. In this case you have to do it like this:
proc_var.lambda? ? instance_exec(&proc_var) : instance_eval(&proc_var)
Weird (to me) that ruby just does not do this under the hood for you.
but I guess you could make it so:
alias original_instance_eval instance_eval
def instance_eval(*args, &block)
block&.lambda? ? instance_exec(&block) : original_instance_eval(*args, &block)
end
Related
I am currently using the following code in a ruby program to evaluate variable length arguments that are passed to a method. The program is running however I'm wondering if there is a short hand way to write this.
Should have been more specific in my original description, trying to rewrite the Inject method for the Array class (hence the witty name...)
Therefore it needs to be able to accept a maximum of two args, and a minimum 0 if a block is given.
array.inject(:+)
array.inject{ |output, num| output + num }
array.inject(arg, :+)
array.inject(arg) { |output, num| output + num }
The most difficult case/s to handle are the first and forth where the 1 arg can be either a Fixnum or a Symbol. As mentioned, the code works, just looking for ways to tidy it up.
class Array
def enjict(*args)
if args.length == 2 && args[0].is_a?(Fixnum) && args[1].is_a?(Symbol)
start, symbol = args
elsif args.length == 1
raise ArgumentError unless args.first.is_a?(Symbol) || args.first.is_a?(Fixnum)
symbol = args.first if args.first.is_a?(Symbol)
start = args.first if args.first.is_a?(Fixnum)
else
raise ArgumentError unless block_given?
end
copiedArray = dup
start = copiedArray.shift unless start
if block_given?
copiedArray.each { |num| start = yield(start, num) }
else
copiedArray.each { |num| start = start.send(symbol, num) }
end
start
end
end
The sad truth is: it's messy, and there's nothing you can do about it. Almost all Ruby implementations implement Enumerable#inject with privileged access to the interpreter internals, including introspection of the arguments. MRI, YARV, MRuby implement it in C, MacRuby and RubyMotion in Objective-C, XRuby and JRuby in Java, Ruby.NET and IronRuby in C#, Topaz in RPython, Cardinal in PIR, and so on.
This is something that is simply not available to Ruby code.
Only Rubinius implements it in Ruby.
You can use a similar trick by (ab)using the fact that the default argument expression for an optional parameter can be any arbitrarily complex Ruby expression and that local variables of those expressions become local variables of the method. This is a common trick for figuring out whether an argument was passed or not:
def inject(initial=(no_initial = true; nil), sym=(no_sym = true; nil))
sym, initial = initial, nil if !block_given && no_sym
# and so on …
end
Judging from the conditions, how about refactoring your method arguments to:
def enjict(start, symbol, *options, &block)
e = proc{ raise ArgumentError if options.length > 0 && !block_given? }
e.call
if start.is_a?(Fixnum) && symbol.is_a?(Symbol)
# do something you want
else
e.call
end
end
Suppose I have a class such as this:
class Test
def test_func
140
end
end
And a proc, which references a member function from Test:
p = ->(x, y) { x + y + test_func } # => #<Proc:0x007fb3143e7f78#(pry):6 (lambda)>
To call p, I bind it to an instance of Test:
test = Test.new # => #<Test:0x007fb3143c5a68>
test.instance_exec(1, 2, &p) # => 143
Now suppose I want to pass just y to p, and always pass x = 1:
curried = p.curry[1] # => #<Proc:0x007fb3142be070 (lambda)>
Ideally I should be able to just instance_exec as before, but instead:
test.instance_exec(2, &curried)
=> NameError: undefined local variable or method `test_func' for main:Object
The proc runs in what seems to be the incorrect binding. What gives?
Yes, I believe this is a bug.
I think it comes down to the fact that curry returns a "C level proc" rather than a normal proc. I don't fully understand the difference between the two (I'm guessing the former is one created by the Ruby C code which is what curry does), but you can tell they're different when you try and take a binding.
p.binding # => #<Binding:0x000000020b4238>
curried.binding # => ArgumentError: Can't create a binding from C level Proc
By looking at the source, this looks like their internal struct representations have different values for the iseq member, which says what kind of instruction sequence this block holds.
This is significant when you call instance_exec, which eventually ends up calling invoke_block_from_c in vm.c, which branches depending on the iseq type:
else if (BUILTIN_TYPE(block->iseq) != T_NODE) {
...
} else {
return vm_yield_with_cfunc(th, block, self, argc, argv, blockptr);
}
The branch I missed out (...) ends up calling vm_push_frame with what looks like some environment where as vm_yield_with_cfunc doesn't.
So my guess would be that because the curried proc is created in C code and ends up of a different 'type' than your first proc, the other branch is taken in the above snippet and the enviornment isn't used.
I should point out that all of this is pretty speculative based on reading the code, I haven't run any tests or tried anything out (and I'm also not all that familiar with internal Ruby anyway!)
this sounds weird doesn't it?
class Dummy
def foo=(value); end
end
Dummy.new.foo = 1 { |x| x } # => syntax error
Dummy.new.foo=(1) { |x| x } # => syntax error
i tried every permutation of blanks, parenthesis, commas; no luck. i'm puzzled. i never suspected methods ending with '=' were special. is it a bug? is it intended? if intended, why? is it documented? where? please share insight.
thanks
ps. ruby is 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.0.1]
The syntax sugar for methods ending in = does make it special. You can still do things like pass multiple arguments to that method, or pass a block, but not in any pretty or convenient manner:
class Foo
def bar=(a,b=nil)
p [a,b]
if block_given?
yield "hi"
else
puts "No block"
end
end
end
f = Foo.new
f.bar = 42
#=> [42, nil]
#=> No block
f.bar = 42, 17
#=> [[42,17], nil]
#=> No block
f.send(:bar=,42,17) do |x|
puts "x is #{x.inspect}"
end
#=> [42, 17]
#=> x is "hi"
Another way in which these methods are special is that when called with the syntax sugar they evaluate to the right hand value, not the return value of the method:
class Foo
def bar=(a)
return 17 # really explicit
end
end
f = Foo.new
x = (f.bar = 42)
p x
#=> 42
x = f.send(:bar=,42)
p x
#=> 17
It's not so much that the methods themselves are special, but more to do with how Ruby deals with assignments (like foo = bar). First the right hand side is evalulated, then the left hand side is evaluated and the appropriate action is taken. If the left hand side is an object attribute, then the appropriate setter method is called.
So in your example:
Dummy.new.foo = 1 { |x| x }
First ruby tries to evalulate 1 { |x| x }, which is what causes the syntax error.
Dummy.new.foo=something doesn't actually mean "call the method named foo=", but actually means something more like "evalualate something, and then determine what `Dummy.new.foo is, and if it looks like an object attribute, add = to the name and call that method". This is why Dummy.new.foo= and Dummy.new.foo = both work the same way.
You can call these methods using send, and can pass a block with this:
Dummy.new.send "foo=", 2 do
puts "HI"
end
This is because with send you can explicitly name the method you want to call.
Of course the end result is that methods ending in = seem to have some "special" behaviour you need to be aware of, but it might be useful to understand what's actually going on.
lambda is used in this example in both the compose and the hydrate methods. What does lambda do here?
def compose *lambdas
if lambdas.empty?
lambda { nil }
elsif lambdas.size == 1
lambdas.first
else
lambda do |n|
lambdas.first.call(compose(*lambdas[1..-1]).call(n))
end
end
end
def hydrate(modulus, printable_form)
i = 0
lambda do |n|
(i = (i + 1) % modulus) == 0 && printable_form || n
end
end
print(((1..100).map
&compose(
hydrate(15, 'Watermelon'),
hydrate(5, 'Melon'),
hydrate(3, 'Water'))).join(' '))
My second question is - what is the need for the ampersand in front of the word compose?
The function compose takes a list of functions and returns a newly allocated function that is the composition of all the functions on the list. It's been written to treat the empty list rather oddly; it may be that the first case should be ignored. (Normally composing the empty list of functions should produce the identity function, but that's not what your example does. I would have expected
lambda do |n| { n }
as the base case.)
It's necessary to use a lambda in order to create a new function You see that in the recursive case in compose: the lambda creates a new function which when given n returns the result of calling the composition of the remaining functions, then finally applies the first function. This is not good code to emulate, as the recursion over the list of functions is repeated every time the composition is called. In the example:
Creating the composition of functions uses constant time and space
Applying the composition of functions costs linear time and space
Whereas if the code were written properly
Creating the composition of functions should cost linear time and space
Applying the composition of functions should cost linear time and should require no allocations (zero space)
Unfortunately I don't know enough Ruby to write for you an example of compose the way it ought to be done. But others will.
As a side note, I don't know where you got this exact code, but it looks like a very lightly altered version of some code from Reginald Braithwaite's blog. (The code was a deliberately over-the-top solution to the FizzBuzz question used in a serious discussion of functional programming in Ruby and functional programming more generally.)
Here are the original posts:
Don't Overthink FizzBuzz
Closures and Higher-Order Functions
Your second question asks what the & is doing.
Looking at The unary ampersand in Ruby, the ampersand converts a proc to a block.
Example:
irb(main):001:0> def meth1
irb(main):002:1> yield "Hello"
irb(main):003:1> end
=> nil
Calling meth1 with a block, works as expected:
irb(main):004:0> meth1 { |s| puts s } # Calling meth1 with a block
Hello
=> nil
Calling with a Proc does not work:
irb(main):005:0> p = Proc.new { |s| puts "In proc: #{s}" }
=> #<Proc:0x13e5d60#(irb):5>
irb(main):006:0> meth1 p
ArgumentError: wrong number of arguments (1 for 0)
from (irb):6
from C:/Ruby19/bin/irb:12:in `<main>'
But it does work if you convert the Proc to a block:
irb(main):007:0> meth1 &p # Convert the proc to a block
In proc: Hello
=> nil
This is the same thing that is happening when you use the following code:
irb(main):001:0> def meth2(&block) # Block is converted to Proc
irb(main):002:1> puts block.class.to_s if block_given?
irb(main):003:1> end
=> nil
irb(main):004:0> meth2 { puts "Hi There" }
Proc
=> nil
irb(main):005:0>
Here is another article on the differences between blocks, block vs lambda vs proc.
I'm new to Ruby, and I'm trying the following:
mySet = numOfCuts.times.map{ rand(seqLength) }
but I get the 'yield called out of block' error. I'm not sure what his means. BTW, this question is part of a more general question I asked here.
The problem is that the times method expects to get a block that it will yield control to. However you haven't passed a block to it. There are two ways to solve this. The first is to not use times:
mySet = (1..numOfCuts).map{ rand(seqLength) }
or else pass a block to it:
mySet = []
numOfCuts.times {mySet.push( rand(seqLength) )}
if "numOfCuts" is an integer,
5.times.foo
is invalid
"times" expects a block.
5.times{ code here }
You're combining functions that don't seem to make sense -- if numOfCuts is an integer, then just using times and a block will run the block that many times (though it only returns the original integer:
irb(main):089:0> 2.times {|x| puts x}
0
1
2
map is a function that works on ranges and arrays and returns an array:
irb(main):092:0> (1..3).map { |x| puts x; x+1 }
1
2
3
[2, 3, 4]
I'm not sure what you're trying to achieve with the code - what are you trying to do? (as opposed to asking specifically about what appears to be invalid syntax)
Bingo, I just found out what this is. Its a JRuby bug.
Under MRI
>> 3.times.map
=> [0, 1, 2]
>>
Under JRuby
irb(main):001:0> 3.times.map
LocalJumpError: yield called out of block
from (irb):2:in `times'
from (irb):2:in `signal_status'
irb(main):002:0>
Now, I don't know if MRI (the standard Ruby implementation) is doing the right thing here. It probably should complain that this does not make sense, but when n.times is called in MRI it returns an Enumerator, whereas Jruby complains that it needs a block.
Integer.times expects a block. The error message means the yield statement inside the times method can not be called because you did not give it a block.
As for your code, I think what you are looking for is a range:
(1..5).map{ do something }
Here is thy rubydoc for the Integer.times and Range.