I'm having issue in calling ruby lambda as below.
I'm having a function which accepts a Proc. And lambda definition as below.
def call_proc_with_arg(&b)
b.call(1)
end
lam = -> (a) { puts "printing the argument #{a}"}
And when I try to pass the lambda to function as,
call_proc_with_arg(lam)
I'm getting the error,
Traceback (most recent call last):
6: from /usr/bin/irb:23:in <main>' 5: from /usr/bin/irb:23:in load'
4: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in <top (required)>' 3: from (irb):118 2: from (irb):118:in rescue in irb_binding'
1: from (irb):52:in `call_block'
ArgumentError (wrong number of arguments (given 1, expected 0))
Whereas the function works with block,
call_proc_with_arg {|a| puts "printing the argument #{a}"}
What am I missing with lambda?
You need to use the following syntax to call the method passing the block, as you defined b as block in the method signature:
call_proc_with_arg(&lam)
The only way you could use call_proc_with_arg(lam) is if you treat the argument not as a method block, but as a first-class argument:
def call_proc_with_arg(b)
b.call(1)
end
call_proc_with_arg(lam)
Each syntax has its own advantage/disadvantage, and it depends on the use case. If you want to leverage blocks, then the first one is the most common one. In such case, you can also use a more common yield syntax:
def call_proc_with_arg(&b)
yield 1
end
instead of referencing the block b variable directly.
The second one would be necessary if you want to pass more than one lambda as parameter, as a single method cannot take multiple blocks.
You can call it different ways
lam = -> (a) { puts "printing the argument #{a}"}
# method with parameter as lambda
def call_proc_with_arg(b)
b.call(1)
end
call_proc_with_arg(lam)
# method without parameters
def call_proc_with_arg
yield 1
end
call_proc_with_arg(&lam)
# method without parameters with named block
def call_proc_with_arg(&b)
b.call(1)
end
call_proc_with_arg(&lam)
Related
I have a method inside of a method. The interior method depends on a variable loop that is being run. Is that a bad idea?
UPDATE: Since this answer seems to have gotten some interest lately, I wanted to point out that there is discussion on the Ruby issue tracker to remove the feature discussed here, namely to forbid having method definitions inside a method body.
No, Ruby doesn't have nested methods.
You can do something like this:
class Test1
def meth1
def meth2
puts "Yay"
end
meth2
end
end
Test1.new.meth1
But that is not a nested method. I repeat: Ruby does not have nested methods.
What this is, is a dynamic method definition. When you run meth1, the body of meth1 will be executed. The body just happens to define a method named meth2, which is why after running meth1 once, you can call meth2.
But where is meth2 defined? Well, it's obviously not defined as a nested method, since there are no nested methods in Ruby. It's defined as an instance method of Test1:
Test1.new.meth2
# Yay
Also, it will obviously be redefined every time you run meth1:
Test1.new.meth1
# Yay
Test1.new.meth1
# test1.rb:3: warning: method redefined; discarding old meth2
# test1.rb:3: warning: previous definition of meth2 was here
# Yay
In short: no, Ruby does not support nested methods.
Note also that in Ruby, method bodies cannot be closures, only block bodies can. This pretty much eliminates the major use case for nested methods, since even if Ruby supported nested methods, you couldn't use the outer method's variables in the nested method.
UPDATE CONTINUED: at a later stage, then, this syntax might be re-used for adding nested methods to Ruby, which would behave the way I described: they would be scoped to their containing method, i.e. invisible and inaccessible outside of their containing method body. And possibly, they would have access to their containing method's lexical scope. However, if you read the discussion I linked above, you can observe that matz is heavily against nested methods (but still for removing nested method definitions).
Actually it's possible. You can use procs/lambda for this.
def test(value)
inner = ->() {
value * value
}
inner.call()
end
No, no, Ruby does have nested methods. Check this:
def outer_method(arg)
outer_variable = "y"
inner_method = lambda {
puts arg
puts outer_variable
}
inner_method[]
end
outer_method "x" # prints "x", "y"
The Ruby way is to fake it with confusing hacks that will have some users wondering "How in the fuck does this even work?", while the less curious will simply memorize the syntax needed to use the thing. If you've ever used Rake or Rails, you've seen this kind of thing.
Here is such a hack:
def mlet(name,func)
my_class = (Class.new do
def initialize(name,func)
#name=name
#func=func
end
def method_missing(methname, *args)
puts "method_missing called on #{methname}"
if methname == #name
puts "Calling function #{#func}"
#func.call(*args)
else
raise NoMethodError.new "Undefined method `#{methname}' in mlet"
end
end
end)
yield my_class.new(name,func)
end
What that does is define a top-level method that creates a class and passes it to a block. The class uses method_missing to pretend that it has a method with the name you chose. It "implements" the method by calling the lambda you must provide. By naming the object with a one-letter name, you can minimize the amount of extra typing that it requires (which is the same thing that Rails does in its schema.rb). mlet is named after the Common Lisp form flet, except where f stands for "function", m stands for "method".
You use it like this:
def outer
mlet :inner, ->(x) { x*2 } do |c|
c.inner 12
end
end
It is possible to make a similar contraption that allows for multiple inner functions to be defined without additional nesting, but that requires an even uglier hack of the sort you might find in Rake's or Rspec's implementation. Figuring out how Rspec's let! works would get you a long way towards being able to create such a horrible abomination.
You can do something like this
module Methods
define_method :outer do
outer_var = 1
define_method :inner do
puts "defining inner"
inner_var = outer_var +1
end
outer_var
end
extend self
end
Methods.outer
#=> defining inner
#=> 1
Methods.inner
#=> 2
This is useful when you're doing things like writing DSLs which require sharing of scope between methods. But otherwise, you're much better off doing anything else, because as the other answers said, inner is redefined whenever outer is invoked. If you want this behavior, and you sometimes might, this is a good way to get it.
There are no nested methods. All are instance methods are only defined as instance methods after running the method above them
irb(main):001:0>
irb(main):002:1* class Test1
irb(main):003:2* def meth1
irb(main):004:3* def meth2
irb(main):005:3* puts "Yay"
irb(main):006:2* end
irb(main):007:3* def meth3
irb(main):009:4* def meth3_3
irb(main):010:4* puts "Third level indented method"
irb(main):012:2* end
irb(main):013:1* end
irb(main):014:0> end
=> :meth1
irb(main):015:0> Test1.new.meth3_3
Traceback (most recent call last):
4: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `<main>'
3: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `load'
2: from /home/khal/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/irb-1.2.3/exe/irb:11:in `<top (required)>'
1: from (irb):15
NoMethodError (undefined method `meth3_3' for #<Test1:0x0000562ae163ce48>)
Did you mean? meth1
irb(main):016:0> Test1.new.meth3
Traceback (most recent call last):
5: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `<main>'
4: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `load'
3: from /home/khal/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/irb-1.2.3/exe/irb:11:in `<top (required)>'
2: from (irb):15
1: from (irb):16:in `rescue in irb_binding'
NoMethodError (undefined method `meth3' for #<Test1:0x0000562ae1328658>)
Did you mean? meth1
method
irb(main):017:0> Test1.new.meth2
Traceback (most recent call last):
5: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `<main>'
4: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `load'
3: from /home/khal/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/irb-1.2.3/exe/irb:11:in `<top (required)>'
2: from (irb):16
1: from (irb):17:in `rescue in irb_binding'
NoMethodError (undefined method `meth2' for #<Test1:0x0000562ae163df78>)
Did you mean? meth1
method
irb(main):018:0> Test1.new.meth1
=> :meth3
irb(main):019:0> Test1.new.meth3_3
Traceback (most recent call last):
4: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `<main>'
3: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `load'
2: from /home/khal/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/irb-1.2.3/exe/irb:11:in `<top (required)>'
1: from (irb):19
NoMethodError (undefined method `meth3_3' for #<Test1:0x0000562ae2568688>)
Did you mean? meth3
irb(main):020:0> Test1.new.meth3
Method Drei
=> :meth3_3
irb(main):021:0> Test1.new.meth3_3
Third level indented method
=> nil
irb(main):022:0>
initialy if your check the instance methods, you get:
irb(main):019:0> Test1.instance_methods
=> [:meth1, :dup, ...]
After running them in steps:
> Test1.instance_methods
=> [:meth3_3, :meth3, :meth1, :meth2,...]
:-D
Ruby has nested methods, only they don't do what you'd expect them to
1.9.3p484 :001 > def kme; 'kme'; def foo; 'foo'; end; end
=> nil
1.9.3p484 :003 > self.methods.include? :kme
=> true
1.9.3p484 :004 > self.methods.include? :foo
=> false
1.9.3p484 :005 > kme
=> nil
1.9.3p484 :006 > self.methods.include? :foo
=> true
1.9.3p484 :007 > foo
=> "foo"
def method1(&proc)
proc.call(1,2,3)
end
method1{ |x,y,z,a| puts a}
Doesn't throw any error and outputs nil.
Why doesn't it check for the arguments? What's the logic behind it?
Proc's do no care about validating the right number of arguments but lambda's do...
def method1(&proc)
proc.call(1,2,3)
end
method1 { |x,y,z,a| puts a}
method1 lambda { |x,y,z,a| puts a }
Results in:
lambda.rb:1:in `method1': wrong number of arguments (given 1, expected 0) (ArgumentError)
from lambda.rb:6:in `<main>'
From the ruby docs:
For procs created using lambda or ->() an error is generated if the wrong number of parameters are passed to a Proc with multiple parameters. For procs created using Proc.new or Kernel.proc, extra parameters are silently discarded.
I'm trying to assign a function to a variable, it feels so natural to do this:
def myfunction(num=3)
num
end
varfunc = myfunction
puts varfunc # it outputs 3 here, as expected
But it's not that easy...
puts varfunc(12)
Gives me this console Error:
test.rb:8:in `<main>': undefined method `varfunc'
for main:Object (NoMethodError)
How can arguments be passed then? Many thanks.
I'm trying to assign a function to a variable, it feels so natural to do this:
def myfunction(num=3)
num
end
varfunc = myfunction
puts varfunc # it outputs 3 here, as expected
There are several things wrong with this.
First, myfunction is not a function, it's a method. Methods aren't objects in Ruby. You can only assign objects to variables, so, since methods aren't objects, you cannot assign them to variables.
Second, you are not assigning the method myfunction to the variable varfunc, because, as I explained above, you cannot do that. You are calling the method myfunction and assigning its return value to the variable varfunc. In Ruby, parentheses are optional for method calls.
Thirdly, even if this did work as you expect it to, i.e. if methods were objects (which they aren't), then the code you showed still shouldn't work the way you see it. If varfunc were a function, then the code would not "output 3 here, as expected", because you would expect varfunc to be a function, not an integer, and it should output something like
#<Function:0xdeadbeef4815162342>
So, the fact that it does output 3 is not expected, and in fact clearly tells you that your expectations are wrong.
Your logic is inconsistent: on line 5, you assume that leaving off the parentheses will not call myfunction, but instead reference it, on line 7, you assume that leaving off the parentheses will will not reference varfunc, but instead call it. That makes no sense.
But it's not that easy...
puts varfunc(12)
Gives me this console Error:
test.rb:8:in `<main>': undefined method `varfunc'
for main:Object (NoMethodError)
How can arguments be passed then? Many thanks.
varfunc is a variable, not a method. You can only pass arguments to methods, not to variables. You need to make varfunc a method.
There are two ways to approach this. One way would be to make myfunction a Proc object, which is the closest equivalent Ruby has to a "function":
myfunction = -> (num=3) { num }
varfunc = myfunction
puts varfunc
# #<Proc:0x007f909285f640#(irb):1 (lambda)>
# *This* is the output you would expect from `puts`ing a "function"
puts varfunc.()
# 3
puts varfunc.(12)
# 12
The other possibility would be to use reflection to obtain a Method wrapper object for the myfunction method, using the Object#method method:
def myfunction(num=3) num end
varfunc = method(:myfunction)
puts varfunc
# #<Method: Object#myfunction>
puts varfunc.()
# 3
puts varfunc.(12)
# 12
I tried this, but it does notwork.
def n_times(thing)
lambda {|n| thing * n }
end
def other(counter,thing)
com = counter(thing)
return com
end
com = other(n_times,10)
com.call("what ")
error :
test.rb:1:in `n_times': wrong number of arguments (0 for 1) (ArgumentError)
from test.rb:10:in `<main>'
n_times is a method requiring one argument, you are calling it as the first argument passed to other, but without an argument. That's the error you are getting. You want to pass method(:n_times) which converts it to a Proc rather than calling it.
Secondly you have counter(thing) inside the other method. This is calling the method called 'counter', rather than using the object called 'counter' which is passed as an argument. You want to change that to counter[thing].
Lastly, you are passing 10 to n_times and calling the resulting lambda with "what", but that evaluates 10 * "what" which is a NoMethodError. You need to reverse those arguments.
All together:
def n_times(thing)
lambda { |n| thing * n }
end
def other(counter, thing)
counter[thing]
end
other(method(:n_times), "what").call(10)
# "whatwhatwhatwhatwhatwhatwhatwhatwhatwhat"
I have a method inside of a method. The interior method depends on a variable loop that is being run. Is that a bad idea?
UPDATE: Since this answer seems to have gotten some interest lately, I wanted to point out that there is discussion on the Ruby issue tracker to remove the feature discussed here, namely to forbid having method definitions inside a method body.
No, Ruby doesn't have nested methods.
You can do something like this:
class Test1
def meth1
def meth2
puts "Yay"
end
meth2
end
end
Test1.new.meth1
But that is not a nested method. I repeat: Ruby does not have nested methods.
What this is, is a dynamic method definition. When you run meth1, the body of meth1 will be executed. The body just happens to define a method named meth2, which is why after running meth1 once, you can call meth2.
But where is meth2 defined? Well, it's obviously not defined as a nested method, since there are no nested methods in Ruby. It's defined as an instance method of Test1:
Test1.new.meth2
# Yay
Also, it will obviously be redefined every time you run meth1:
Test1.new.meth1
# Yay
Test1.new.meth1
# test1.rb:3: warning: method redefined; discarding old meth2
# test1.rb:3: warning: previous definition of meth2 was here
# Yay
In short: no, Ruby does not support nested methods.
Note also that in Ruby, method bodies cannot be closures, only block bodies can. This pretty much eliminates the major use case for nested methods, since even if Ruby supported nested methods, you couldn't use the outer method's variables in the nested method.
UPDATE CONTINUED: at a later stage, then, this syntax might be re-used for adding nested methods to Ruby, which would behave the way I described: they would be scoped to their containing method, i.e. invisible and inaccessible outside of their containing method body. And possibly, they would have access to their containing method's lexical scope. However, if you read the discussion I linked above, you can observe that matz is heavily against nested methods (but still for removing nested method definitions).
Actually it's possible. You can use procs/lambda for this.
def test(value)
inner = ->() {
value * value
}
inner.call()
end
No, no, Ruby does have nested methods. Check this:
def outer_method(arg)
outer_variable = "y"
inner_method = lambda {
puts arg
puts outer_variable
}
inner_method[]
end
outer_method "x" # prints "x", "y"
The Ruby way is to fake it with confusing hacks that will have some users wondering "How in the fuck does this even work?", while the less curious will simply memorize the syntax needed to use the thing. If you've ever used Rake or Rails, you've seen this kind of thing.
Here is such a hack:
def mlet(name,func)
my_class = (Class.new do
def initialize(name,func)
#name=name
#func=func
end
def method_missing(methname, *args)
puts "method_missing called on #{methname}"
if methname == #name
puts "Calling function #{#func}"
#func.call(*args)
else
raise NoMethodError.new "Undefined method `#{methname}' in mlet"
end
end
end)
yield my_class.new(name,func)
end
What that does is define a top-level method that creates a class and passes it to a block. The class uses method_missing to pretend that it has a method with the name you chose. It "implements" the method by calling the lambda you must provide. By naming the object with a one-letter name, you can minimize the amount of extra typing that it requires (which is the same thing that Rails does in its schema.rb). mlet is named after the Common Lisp form flet, except where f stands for "function", m stands for "method".
You use it like this:
def outer
mlet :inner, ->(x) { x*2 } do |c|
c.inner 12
end
end
It is possible to make a similar contraption that allows for multiple inner functions to be defined without additional nesting, but that requires an even uglier hack of the sort you might find in Rake's or Rspec's implementation. Figuring out how Rspec's let! works would get you a long way towards being able to create such a horrible abomination.
You can do something like this
module Methods
define_method :outer do
outer_var = 1
define_method :inner do
puts "defining inner"
inner_var = outer_var +1
end
outer_var
end
extend self
end
Methods.outer
#=> defining inner
#=> 1
Methods.inner
#=> 2
This is useful when you're doing things like writing DSLs which require sharing of scope between methods. But otherwise, you're much better off doing anything else, because as the other answers said, inner is redefined whenever outer is invoked. If you want this behavior, and you sometimes might, this is a good way to get it.
There are no nested methods. All are instance methods are only defined as instance methods after running the method above them
irb(main):001:0>
irb(main):002:1* class Test1
irb(main):003:2* def meth1
irb(main):004:3* def meth2
irb(main):005:3* puts "Yay"
irb(main):006:2* end
irb(main):007:3* def meth3
irb(main):009:4* def meth3_3
irb(main):010:4* puts "Third level indented method"
irb(main):012:2* end
irb(main):013:1* end
irb(main):014:0> end
=> :meth1
irb(main):015:0> Test1.new.meth3_3
Traceback (most recent call last):
4: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `<main>'
3: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `load'
2: from /home/khal/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/irb-1.2.3/exe/irb:11:in `<top (required)>'
1: from (irb):15
NoMethodError (undefined method `meth3_3' for #<Test1:0x0000562ae163ce48>)
Did you mean? meth1
irb(main):016:0> Test1.new.meth3
Traceback (most recent call last):
5: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `<main>'
4: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `load'
3: from /home/khal/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/irb-1.2.3/exe/irb:11:in `<top (required)>'
2: from (irb):15
1: from (irb):16:in `rescue in irb_binding'
NoMethodError (undefined method `meth3' for #<Test1:0x0000562ae1328658>)
Did you mean? meth1
method
irb(main):017:0> Test1.new.meth2
Traceback (most recent call last):
5: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `<main>'
4: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `load'
3: from /home/khal/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/irb-1.2.3/exe/irb:11:in `<top (required)>'
2: from (irb):16
1: from (irb):17:in `rescue in irb_binding'
NoMethodError (undefined method `meth2' for #<Test1:0x0000562ae163df78>)
Did you mean? meth1
method
irb(main):018:0> Test1.new.meth1
=> :meth3
irb(main):019:0> Test1.new.meth3_3
Traceback (most recent call last):
4: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `<main>'
3: from /home/khal/.rbenv/versions/2.7.1/bin/irb:23:in `load'
2: from /home/khal/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/irb-1.2.3/exe/irb:11:in `<top (required)>'
1: from (irb):19
NoMethodError (undefined method `meth3_3' for #<Test1:0x0000562ae2568688>)
Did you mean? meth3
irb(main):020:0> Test1.new.meth3
Method Drei
=> :meth3_3
irb(main):021:0> Test1.new.meth3_3
Third level indented method
=> nil
irb(main):022:0>
initialy if your check the instance methods, you get:
irb(main):019:0> Test1.instance_methods
=> [:meth1, :dup, ...]
After running them in steps:
> Test1.instance_methods
=> [:meth3_3, :meth3, :meth1, :meth2,...]
:-D
Ruby has nested methods, only they don't do what you'd expect them to
1.9.3p484 :001 > def kme; 'kme'; def foo; 'foo'; end; end
=> nil
1.9.3p484 :003 > self.methods.include? :kme
=> true
1.9.3p484 :004 > self.methods.include? :foo
=> false
1.9.3p484 :005 > kme
=> nil
1.9.3p484 :006 > self.methods.include? :foo
=> true
1.9.3p484 :007 > foo
=> "foo"