Eli Bendersky’s website  » Blog Archive   » Understanding Ruby blocks, Procs and methods
Archives
« Prev: Interesting scientific facts
» Next: Longest Increasing Subsequence
Understanding Ruby blocks, Procs and methods
April 18th, 2006 at 7:06 am
Introduction
Ruby provides the programmer with a set of very powerful features borrowed from the domain of functional programming, namely closures, high-order functions and first-class functions [1]. These features are implemented in Ruby by means of code blocks, Proc objects and methods (that are also objects) - concepts that are closely related and yet differ in subtle ways. In fact I found myself quite confused about this topic, having a difficulty to understand the difference between blocks, procs and methods and unsure about the best practices of using them. Additionally, having some background in Lisp and years of Perl experience, I was unsure of how the Ruby concepts map to similar idioms from other programming languages, like Lisp’s functions and Perl’s subroutines. Sifting through hundreds of newsgroup posts, I saw that I’m not the only one with this problem, and in fact quite a lot of “Ruby Nubies” struggle with the same ideas.
In this article I lay out my understanding of this facet of Ruby, which comes as a result of extensive research of Ruby books, documentation and comp.lang.ruby, in sincere hope that other people will find it useful as well.
Procs
Shamelessly ripping from the Ruby documentation, Procs are defined as follows: Proc objects are blocks of code that have been bound to a set of local variables. Once bound, the code may be called in different contexts and still access those variables.
A useful example is also provided:
def gen_times(factor)
return Proc.new {|n| n*factor }
end
times3 = gen_times(3)
times5 = gen_times(5)
times3.call(12)               #=> 36
times5.call(5)                #=> 25
times3.call(times5.call(4))   #=> 60
Procs play the role of functions in Ruby. It is more accurate to call them function objects, since like everything in Ruby they are objects. Such objects have a name in the folklore - functors. A functor is defined as an object to be invoked or called as if it were an ordinary function, usually with the same syntax, which is exactly what a Proc is.
From the example and the definition above, it is obvious that Ruby Procs can also act as closures. On Wikipedia, a closure is defined as a function that refers to free variables in its lexical context. Note how closely it maps to the Ruby definition blocks of code that have been bound to a set of local variables.
More on Procs
Procs in Ruby are first-class objects, since they can be created during runtime, stored in data structures, passed as arguments to other functions and returned as the value of other functions. Actually, the gen_times example demonstrates all of these criteria, except for “passed as arguments to other functions”. This one can be presented as follows:
def foo (a, b)
a.call(b)
end
putser = Proc.new {|x| puts x}
foo(putser, 34)
There is also a shorthand notation for creating Procs - the Kernel method lambda [2] (we’ll come to methods shortly, but for now assume that a Kernel method is something akin to a global function, which can be called from anywhere in the code). Using lambda the Proc object creation from the previous example can be rewritten as:
putser = lambda {|x| puts x}
Actually, there are two slight differences between lambda and Proc.new. First, argument checking. The Ruby documentation for lambda states: Equivalent to Proc.new, except the resulting Proc objects check the number of parameters passed when called.. Here is an example to demonstrate this:
lamb = lambda {|x, y| puts x + y}
pnew = Proc.new {|x, y| puts x + y}
# works fine, printing 6
pnew.call(2, 4, 11)
# throws an ArgumentError
lamb.call(2, 4, 11)
Second, there is a difference in the way returns are handled from the Proc. A return from Proc.new returns from the enclosing method (acting just like a return from a block, more on this later):
def try_ret_procnew
ret = Proc.new { return "Baaam" }
ret.call
"This is not reached"
end
# prints "Baaam"
puts try_ret_procnew
While return from lambda acts more conventionally, returning to its caller:
def try_ret_lambda
ret = lambda { return "Baaam" }
ret.call
"This is printed"
end
# prints "This is printed"
puts try_ret_lambda
With this in light, I would recommend using lambda instead of Proc.new, unless the behavior of the latter is strictly required. In addition to being way cooler a whopping two characters shorter, its behavior is less surprising.
Methods
Simply put, a method is also a block of code. However, unlike Procs, methods are not bound to the local variables around them. Rather, they are bound to some object and have access to its instance variables [3]:
class Boogy
def initialize
@dix = 15
end
def arbo
puts "#{@dix} ha\n"
end
end
# initializes an instance of Boogy
b = Boogy.new
# prints "15 ha"
b.arbo
A useful idiom when thinking about methods is sending messages. Given a receiver - an object that has some method defined, we can send it a message - by calling the method, optionally providing some arguments. In the example above, calling arbo is akin to sending a message “arbo”, without arguments. Ruby supports the message sending idiom more directly, by including the send method in class Object (which is the parent of all objects in Ruby). So the following two lines are equivalent to the arbo method call:
# method/message name is given as a string
b.send("arbo")
# method/message name is given as a symbol
b.send(:arbo)
Note that methods can also be defined in the “top-level” scope, not inside any class. For example:
def say (something)
puts something
end
say "Hello"
While it seems that say is “free-standing”, it is not. When methods such as this are defined, Ruby silently tucks them into the Object class. But this doesn’t really matter, and for all practical purposes say can be seen as an independent method. Which is, by the way, just what’s called a “function” in some languages (like C and Perl). The following Proc is, in many ways similar:
say = lambda {|something| puts something}
say.call("Hello")
# same effect
say["Hello"]
The [] construct is a synonym to call in the context of Proc [4]. Methods, however, are more versatile than procs and support a very important feature of Ruby, which I will present right after explaining what blocks are.
Blocks
Blocks are so powerfully related to Procs that it gives many newbies a headache trying to decipher how they actually differ. I will try to ease on comprehension with a (hopefully not too corny) metaphor. Blocks, as I see them, are unborn Procs. Blocks are the larvae, Procs are the insects. A block does not live on its own - it prepares the code for when it will actually become alive, and only when it is bound and converted to a Proc, it starts living:
# a naked block can't live in Ruby
# this is a compilation error !
{puts "hello"}
# now it's alive, having been converted
# to a Proc !
pr = lambda {puts "hello"}
pr.call
Is that it, is that what all the fuss is about, then ? No, not at all. The designer of Ruby, Matz saw that while passing Procs to methods (and other Procs) is nice and allows high-level functions and all kinds of fancy functional stuff, there is one common case that stands high above all other cases - passing a single block of code to a method that makes something useful out of it, for example iteration. And as a very talented designer, Matz decided that it is worthwhile to emphasize this special case, and make it both simpler and more efficient.
Passing a block to a method
No doubt that any programmer who has spent at least a couple of hours with Ruby has been shown the following examples of Ruby glory (or something very similar):
10.times do |i|
print "#{i} "
end
numbers = [1, 2, 5, 6, 9, 21]
numbers.each do |x|
puts "#{x} is " + (x >= 3 ? "many" : "few")
end
squares = numbers.map {|x| x * x}
(Note that do |x| ... end is equivalent to { |x| ... } )
Such code is IMHO part of what makes Ruby the clean, readable and wonderful language it is. What happens here behind the scenes is quite simple, or at least may be depicted in a very simple way. Perhaps Ruby doesn’t implement it exactly the way I’m going to describe it, since there are optimization considerations surely playing their role - but it is definitely close enough to the truth to serve as a metaphor for understanding.
Whenever a block is appended to a method call, Ruby automatically converts it to a Proc object, but one without an explicit name. The method, however, has a way to access this Proc, by means of the yield statement. See the following example for clarification:
def do_twice
yield
yield
end
do_twice {puts "Hola"}
The method do_twice is defined and called with an attached block. Although the method didn’t explicitly ask for the block in its arguments list, the yield can call the block. This can be implemented in a more explicit way, using a Proc argument:
def do_twice(what)
what.call
what.call
end
do_twice lambda {puts "Hola"}
This is equivalent to the previous example, but using blocks with yield is cleaner, and better optimized since only one block is passed to the method, for sure. Using the Proc approach, any amount of code blocks can be passed:
def do_twice(what1, what2, what3)
2.times do
what1.call
what2.call
what3.call
end
end
do_twice(   lambda {print "Hola, "},
lambda {print "querido "},
lambda {print "amigo\n"})
It is important to note that many people frown at passing blocks, and prefer explicit Procs instead. Their rationale is that a block argument is implicit, and one has to look through the whole code of the method to see if there are any calls to yield there, while a Proc is explicit and can be immediately spotted in the argument list. While it’s simply a matter of taste, understanding both approaches is vital.
The ampersand (&)
The ampersand operator can be used to explicitly convert between blocks and Procs in a couple of esoteric cases. It is worthy to understand how these work.
Remember how I said that although an attached block is converted to a Proc under the hood, it is not acessible as a Proc from inside the method ? Well, if an ampersand is prepended to the last argument in the argument list of a method, the block attached to this method is converted to a Proc object and gets assigned to that last argument:
def contrived(a, &f)
# the block can be accessed through f
f.call(a)
# but yield also works !
yield(a)
end
# this works
contrived(25) {|x| puts x}
# this doesn't (ArgumentError), because &f
# isn't really an argument - it's only there
# to convert a block
contrived(25, lambda {|x| puts x})
Another (IMHO far more efficacious) use of the ampersand is the other-way conversion - converting a Proc into a block. This is very useful because many of Ruby’s great built-ins, and especially the iterators, expect to receive a block as an argument, and sometimes it’s much more convenient to pass them a Proc. The following example is taken right from the excellent “Programming Ruby” book by the pragmatic programmers:
print "(t)imes or (p)lus: "
times = gets
print "number: "
number = Integer(gets)
if times =~ /^t/
calc = lambda {|n| n*number }
else
calc = lambda {|n| n+number }
end
puts((1..10).collect(&calc).join(", "))
The collect method expects a block, but in this case it is very convenient to provide it with a Proc, since the Proc is constructed using knowledge gained from the user. The ampersand preceding calc makes sure that the Proc object calc is turned into a code block and is passed to collect as an attached block.
The ampersand also allows the implementation of a very common idiom among Ruby programmers: passing method names into iterators. Assume that I want to convert all words in an Array to upper case. I could do it like this:
words = %w(Jane, aara, multiko)
upcase_words = words.map {|x| x.upcase}
p upcase_words
This is nice, and it works, but I feel it’s a little bit too verbose. The upcase method itself should be given to map, without the need for a separate block and the apparently superfluous x argument. Fortunately, as we saw before, Ruby supports the idiom of sending messages to objects, and methods can be referred to by their names, which are implemented as Ruby Symbols. For example:
p "Erik".send(:upcase)
This, quite literally, says send the message/method upcase to the object “Erik”. This feature can be utilized to implement the map {|x| x.upcase} in an elegant manner, and we’re going to use the ampersand for this ! As I said, when the ampersand is prepended to some Proc in a method call, it converts the Proc to a block. But what if we prepend it not to a Proc, but to another object ? Then, Ruby’s implicit type conversion rules kick in, and the to_proc method is called on the object to try and make a Proc out of it. We can use this to implement to_proc for Symbol and achieve what we want:
class Symbol
# A generalized conversion of a method name
# to a proc that runs this method.
#
def to_proc
lambda {|x, *args| x.send(self, *args)}
end
end
# Viola !
words = %w(Jane, aara, multiko)
upcase_words = words.map(&:upcase)
Conclusion
Ruby doesn’t really have functions. Rather, it has two slightly different concepts - methods and Procs (which are, as we have seen, simply what other languages call function objects, or functors). Both are blocks of code - methods are bound to Objects, and Procs are bound to the local variables in scope. Their uses are quite different.
Methods are the cornerstone of object-oriented programming, and since Ruby is a pure-OO language (everything is an object), methods are inherent to the nature of Ruby. Methods are the actions Ruby objects do - the messages they receive, if you prefer the message sending idiom.
Procs make powerful functional programming paradigms possible, turning code into a first-class object of Ruby allowing to implement high-order functions. They are very close kin to Lisp’s lambda forms (there’s little doubt about the origin of Ruby’s Proc constructor lambda)
The construct of a block may at first be confusing, but it turns out to be quite simple. A block is, as my metaphor goes, an unborn Proc - it is a Proc in an intermediate state, not bound to anything yet. I think that the simplest way to think about blocks in Ruby, without losing any comprehension, would be to think that blocks are really a form of Procs, and not a separate concept. The only time when we have to think of blocks as slighly different from Procs is the special case when they are passed as the last argument to a method which may then access them using yield.
That’s about it, I guess. I know for sure that the research I conducted for this article cleared many misunderstandings I had about the concepts presented here. I hope others will learn from it as well. If you see anything you don’t agree with - from glaring errors to nitpicky inaccuracies, feel free to comment - I’ll be happy to discuss any remarks and fix my mistakes.
Notes
[1] It seems that in the pure, theoretical interpretation what Ruby has isn’t first-class functions per se. However, as this article demonstrates, Ruby is perfectly capable of fulfilling most of the requirements for first-class functions, namely that functions can be created during the execution of a program, stored in data structures, passed as arguments to other functions, and returned as the values of other functions.
[2] lambda has a synonym - proc, which is considered ‘mildly deprecated’ (mainly because proc and Proc.new are slightly different, which is confusing). In other words, just use lambda.
[3] These are ‘instance methods’. Ruby also supports ‘class methods’, and ‘class variables’, but that is not what this article is about.
[4] Or more accurately, call and [] both refer to the same method of class Proc. Yes, Proc objects themselves have methods !
This entry was posted
on Tuesday, April 18th, 2006 at 7:06 am                                                and is filed under Articles,  Ruby.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
34 Responses to “Understanding Ruby blocks, Procs and methods”
Darkman Says:
April 18th, 2006 at 8:32 am
Nice.
What about converting between Method objects and Proc objects with to_proc ?
Simen Says:
April 18th, 2006 at 2:46 pm
Ruby also has a (admittely not in widespread use) method method which returns a Method object. Watch:
def some_method( arg )
rand(10).times{ puts arg }
end
m = method :some_method
m.arity #=> 1
m.call( 10 ) # => calls the method
Also, class methods can be seen as instance methods on classes:
class Test
@var = 10
def self.var
@var
end
end
Test.var # => 10
Test::var # => 10
Test.new.var # => NoMethodError: undefined method `var' for #<Test:0xb7d6cbb4>
Class variables, on the other hand, are a different concept since they can be accessed both from an instance method and a class method.
eliben Says:
April 18th, 2006 at 4:00 pm
Thanks for the insights.
In fact, there are a few things I haven’t yet covered - more advanced stuff like to_proc for methods, arity and so on. Maybe I’ll write a more advanced Article later, and will include your suggestions.
traanf Says:
April 18th, 2006 at 4:04 pm
Thanks for your good article! It cleared a lot of my doubts about this issue.
t.w. Says:
April 18th, 2006 at 4:47 pm
Thanks for taking the time to write this article. I thought I knew most of what procs and blocks did, how they did it, and what they had to offer….I was mistaken.  Of particular interest was the generalized conversion utilizing to_proc*.   Thanks again.
*A minor suggestion: new users might not be familiar with modifying existing classes in the manner shown for the change to Symbol#to_proc.  Perhaps a footnote?
Justin Says:
April 18th, 2006 at 5:20 pm
Good article. You really hit the high points and covered them well. I only have two suggestions:
1) Avoid some of the terminology early on (such as closure) or at least define it more explicitly when introduced.
2) Show output in your example code.
Thanks for putting this up!
D.H. Says:
April 18th, 2006 at 5:36 pm
good article. You need to add a comment somewhere on how to use blocks/procs recursively. It isn’t completely obvious if you are new to the concept of blocks. Especially if you have learned blocks but not procs, since most introductory tutorials and such talk a lot about blocks but not much about procs.
Reuben Grinberg Says:
April 18th, 2006 at 6:34 pm
Your symbol to_proc construction seems to be extremely slow:
a = (”@”..”ALLL”).to_a; nil
n = 10
Benchmark.bm(”map strong composed”.length) do |x|
x.report(”map weak composed”) { n.times do ; a.map { |e| e.upcase}.map {|e| e.chop}.map {|e| e.succ } ; end}
x.report(”map strong composed”) { n.times do ; a.map { |e| e.upcase.chop.succ } ; end}
x.report(”weak proc”) { n.times do ; a.map(&:upcase).map(&:chop).map(&:succ) ; end }
end
user     system      total        real
map weak composed    3.770000   0.150000   3.920000 (  4.233502)
map strong composed  2.890000   0.080000   2.970000 (  3.204170)
weak proc           12.260000   0.340000  12.600000 ( 13.474930)
The method you suggest is 3-4 times slower! Sometimes this is ok. Let me suggest a better alternative for a terse map:
class Array
def >(sym)
map { |e| e.__send__(syms) }
end
end
So now, you can say:
a = %w(I am a sandwich)
a>:upcase>:chop>:succ     (=>[”", “B”, “”, “SANDWID”])
It’s still slow, but not as slow as the Proc version:
user     system      total        real
a>:upcase>:chop>:succ    4.480000   0.150000   4.630000 (  4.959586)
map weak composed    3.770000   0.150000   3.920000 (  4.233502)
map strong composed  2.890000   0.080000   2.970000 (  3.204170)
weak proc           12.260000   0.340000  12.600000 ( 13.474930)
Cheers,
Reuben
Rafael Says:
April 18th, 2006 at 6:51 pm
Great article for quasi-newbies like me! I liked the way you explained ‘yield’ using explicit ruby code. I am collecting snippets like this, that explain ruby high level code using runnable ruby protocode. You mentioned that all methods at ‘top-level’ scope get tucked into the Object class. I tried to find  them listed in Object.constants, they are not there? I couldn’t find either where ‘top-level’ variables are kept.
Valters Vingolds Says:
April 18th, 2006 at 7:16 pm
Eli,
Would you consider donating your article to Ruby wikibook project? I think it is really helpful, and makes a great tutorial towards understanding how Ruby works.
We are working on Ruby book over here:
http://en.wikibooks.org/wiki/Programming:Ruby
vinbarnes Says:
April 18th, 2006 at 9:57 pm
Rafael,
You can access any classes methods using the methods method. (Uh, I’m sure there’s a better way to word that!)
irb(main):004:0> Object.methods.size
=> 73
irb(main):005:0> def say; puts ‘hello’; end
=> nil
irb(main):006:0> Object.methods.size
=> 74
Reuben Grinberg Says:
April 18th, 2006 at 10:06 pm
Just saw that there’s a typo in what I wrote above. The code should be:
class Array
def >(sym)
map { |e| e.__send__(sym) }
end
end
(I wrote syms instead of sym to as the argument to __send__)
roberthahn Says:
April 19th, 2006 at 1:50 am
Eli, this is a great article, but I’m still left with questions. I hope you’ll be able to write a followup article addressing this one:  Excepting iterators (mostly) and methods, it’s not really clear to me what kinds of problems exist that these solutions would be good for. If I could see some good examples (I’m not quite seeing the point of the examples you used, despite how good they are at clarifying what’s what), then I think that will help a *lot* when I sit down to write ruby scripts on my own.
Kartik Vaddadi Says:
April 19th, 2006 at 6:48 am
I still don’t see the need for Procs. Matz could have made blocks first-class objects so that they can be assigned to variables or passed as parameters without having to convert them into something else (or use the & operator). Why have this subtle distinction?
eliben Says:
April 19th, 2006 at 7:41 am
Reuben:
You’re absolutely right. This is another place (among many others !) where Ruby can optimize. The best way would be to have a builtin way to do the to_proc conversion on a symbol. There is no reason whatsoever that it shouldn’t run as fast as the “weak composed” version.
Rafael:
They are ‘private’ members of Object, so you can’t access them via Object.
Valters:
I’ll be glad to contribute.
roberthahn:
Iterators are indeed the best and most popular use of higher order functions. The Visitor pattern is another. Dispatch tables another. There are a few books on the subject, like “Higher order Perl”, and about any Lisp book you can think of, that will show you how powerful functional techniques can be.
Kartik:
As I said, the easiest way to think about blocks is: there’s no such thing. It’s just a name for an unfinished Proc, mainly for optimization. One can write good Ruby code without blocks at all.
Alex Says:
April 19th, 2006 at 9:22 am
Good stuff Eli, please give us more
Valters Vingolds Says:
April 19th, 2006 at 11:32 am
Eli,
I added your article to http://en.wikibooks.org/wiki/Programming:Ruby_Method_Calls chapter, and will work on incorporating some changes as suggested here in comments, and also will work on changing some “IMHO” statements to make it look more like a book article
Dan Bernier Says:
April 19th, 2006 at 6:31 pm
“The ampersand operator can be used to explicitly convert between blocks and Procs in a couple of isoteric cases.”
I think you meant “esoteric”.
That aside, thanks for the excellent article.  I think strictly-OO programmers coming to Ruby (like me) are looking for this kind of info.  Functional programming is all new to me, so this is a good find.
eliben Says:
April 19th, 2006 at 6:59 pm
Dan:
Thanks I fixed the typo.
Daniel Says:
August 1st, 2006 at 10:07 pm
Great article! this was remendously helpful!
I also just came across this Joel on Software article which expounds on the virtues of anonymous functions: http://www.joelonsoftware.com/items/2006/08/01.html
Ben Kittrell Says:
August 29th, 2006 at 6:28 pm
Thanks for a great article.  It really clears the block vs. proc confusion up for me.
J. Erik Heinz Says:
September 2nd, 2006 at 1:05 pm
This was exacly the article I search! Helped me a lot.
As I tried the code-parts in irb, I found out there is a small difference about do |x| … end and { |x| … }. So it seems they are not in all parts equivalent:
# This will not work
contrived 25 {|x| puts x}
# This works
contrived 25 do |x| puts x end
Cheers — Erik
N00b Says:
September 4th, 2006 at 2:17 pm
Thank you, this has helped me a lot. What about begin .. end blocks?
Tsela Says:
December 13th, 2006 at 1:40 pm
Erik,
this is only a difference in operator precedence: {} binds tighter than do… end.
In other words, contrived 25 {|x| puts x} is interpreted as:
contrived(25 {|x| puts x})
while contrived 25 do |x| puts x end is interpreted as:
contrived(25) do |x| puts x end
There are similar operator differences between similarly identical constructions in Ruby, like for instance with and and &&, and or and ||, with here again the symbolic version binding tighter than the keyword one. All of this is well documented in the Pickaxe.
bluemonk Says:
February 12th, 2007 at 1:43 am
Excellent article. It actually gave me a new way to get this result:
if response.header.truncated? and not ignore_truncated?
@logger.warn “Packet truncated, retrying using TCP”
self.use_tcp = true
temp = send(argument,type,cls)
self.use_tcp = false
return temp
end
###################
if response.header.truncated? and not ignore_truncated?
@logger.warn “Packet truncated, retrying using TCP”
self.use_tcp = true
begin
return send(argument,type,cls)
ensure
self.use_tcp = false
end
end
###################
if response.header.truncated? and not ignore_truncated?
@logger.warn “Packet truncated, retrying using TCP”
self.use_tcp = true
lambda {return send(argument,type,cls)}.call
self.use_tcp = false
end
Which one do you prefer?
Jonah Burke Says:
February 22nd, 2007 at 4:15 am
Great article.  Cleared many things up for me.
kybernetikos Says:
March 20th, 2007 at 1:49 pm
I like ruby so far, but procs and lambda seem like a hack to allow functional programming.  What happened to the principle of least surprise?  Why can’t I do (which I tried immediately)
func = do |x|
x+5
end
func(2)
So I read your page and try
func = lambda {|x| x+5 }
func(2)
And that still doesn’t work.  Why on earth would I want to do func.call(2)?  Putting square brackets after something calls the [] method, why doesn’t putting () brackets after something call the call method?   I would say that although you are able to program in a functional style in ruby, it makes it hard for you.  It’s a piece of nonorthogonality that is ugly.  There should be no need for wrapping blocks in procs.
Tarmo Says:
April 3rd, 2007 at 1:27 am
kybernetikos, the reason neither of your examples could work is that ruby has to be able to differentiate between methods and local variables as methods can be called without parentheses. And the way ruby does it is this: if a local variable for some name “x” is not defined then “x” is the same as “x()”, meaning a method call; but when a local variable “x” is defined then “x” refers to the variable not the method and “x()” still refers to the method. In your example you are creating a local variable “func” in which case “func(2)” is the only way to refer to a method named “func” as opposed to a variable named “func”.
What you are trying to do is quite similiar to what is described here: http://www.thekode.net/ruby/techniques/DefiningMethodsWithClosures.html but with the downside of not being able to do this in a global context, define_method can only be called for a class or a module.
Leet Geezer Says:
May 13th, 2007 at 10:15 am
Thanks for great article. Clarified alot.
Coffee_fan Says:
November 3rd, 2007 at 4:17 am
Eli, this is a very nice article. On a side-note, I also found quite enlightening  that the control directives ‘next’, ‘break’ do work in the context of codeblocks in an intuitive way. As such it is possible to replace most loop iterations by an iterator with a codeblock with little or no modification to the control logic.
elliottcable Says:
November 27th, 2007 at 11:44 pm
In addition to being way cooler a whopping two characters shorter
Or, if you’re really awesomely cool, you could do this instead:
module Kernel
alias 位 proc # (U+03BB)
end
padd = 位 {|x, y| puts x + y}
padd.call
cks2k2 Says:
December 10th, 2007 at 8:10 am
# this doesn’t (ArgumentError), because &f
# isn’t really an argument - it’s only there
# to convert a block
contrived(25, lambda {|x| puts x})
I tried this on 1.8.6-25 but getting an ArgumentError(2 for 1).
Or am I the only getting this error?
I’ve tried contrived( 25, Proc.new {|x| puts x}) but it’s still not working.
shining Says:
December 28th, 2007 at 4:36 pm
Nice and concise!
Deepak Gole Says:
January 15th, 2008 at 9:28 am
Hello If I want pass arguments to method (&:center), then how to send it
class Symbol
# A generalized conversion of a method name
# to a proc that runs this method.
#
def to_proc
lambda {|x, *args| x.send(self, *args)}
end
end
# Viola !
words = %w(Jane, aara, multiko)
upcase_words = words.map(&:center)
Leave a Reply
Name (required)
Mail (will not be published) (required)
Website
ANTI SPAM CHALLENGE: please write the number 4 into this box before clicking `Submit Comment`
Eli Bendersky’s website is powered by
WordPress
Entries (RSS)
and Comments (RSS).