I understand that there are different situations in which Procs and lambdas should be used (lambda checks number of arguments, etc.), but do they take up different amounts of memory? If so, which one is more efficient?
There are several differences between Lambdas and Procs.
Lambdas have what are known as "diminutive returns". What that means is that a Lambda will return flow to the function that called it, while a Proc will return out of the function that called it.
def proc_demo
Proc.new { return "return value from Proc" }.call
"return value from method"
end
def lambda_demo
lambda { return "return value from lambda" }.call
"return value from method"
end
proc_demo #=> "return value from Proc"
lambda_demo #=> "return value from method"
Lambdas check the number of parameters passed into them, while Procs do not. For example:
lambda { |a, b| [a, b] }.call(:foo)
#=> #<ArgumentError: wrong number of arguments (1 for 2)>
Proc.new { |a, b| [a, b] }.call(:foo)
#=> [:foo, nil]
The Ruby Language Specification does not prescribe any particular implementation strategy for procs and lambdas, therefore any implementation is free to choose any strategy it wants, ergo any implementation may (or may not) take up completely different amounts of memory. Actually, this isn't just true for lambdas and procs, but for every kind of object. The Ruby Language Specification only prescribes the behavior of the objects, it does not prescribe any particular implementation or representation.
However, since there is only one class to represent both lambdas and procs, it is very likely that they take up the exact same amount of memory, regardless of how they are implemented and represented.
The differences between Proc and lambda are mostly behavior related, and are answered better by Abraham and is also found here
The old answer talked about how Block is faster than lambda as explained and shown at Ruby Monk:Ascent
Related
As far as I can tell, there are essentially three different kinds of closure in Ruby; methods, procs and lambdas. I know that there are differences between them, but could we not just get away having one type that accommodates all possible use-cases?
Methods can already be passed around like procs and lambdas by calling self.method(method_name), and the only significant differences that I'm aware of between procs and lambdas is that lambdas check arity and procs do crazy things when you try to use return. So couldn't we just merge them all into one and be done with it?
As far as I can tell, there are essentially three different kinds of closure in Ruby; methods, procs and lambdas.
No, there are two: methods aren't closures, only procs and lambdas are. (Or at least can be, most of them aren't.)
There are two ways of packaging up a piece of executable code for reuse in Ruby: methods and blocks. Strictly speaking, blocks aren't necessary, you can get by with just methods. But blocks are meant to be extremely light-weight, conceptually, semantically and syntactically. That's not true for methods.
Because they are meant to be light-weight and easy to use, blocks behave different from methods in some respects, e.g. how arguments are bound to parameters. Block parameters are bound more like the left-hand side of an assignment than like method parameters.
Examples:
Passing a single array to multiple parameters:
def foo(a, b) end
foo([1, 2, 3]) # ArgumentError: wrong number of arguments (1 for 2)
a, b = [1, 2, 3]
# a == 1; b == 2
[[1, 2, 3]].each {|a, b| puts "a == #{a}; b == #{b}" }
# a == 1; b ==2
Passing less arguments than parameters:
def foo(a, b, c) end
foo(1, 2) # ArgumentError
a, b, c = 1, 2
# a == 1; b == 2; c == nil
[[1, 2]].each {|a, b, c| puts "a == #{a}; b == #{b}; c == #{c}" }
# a == 1; b == 2; c ==
Passing more arguments than parameters:
def foo(a, b) end
foo(1, 2, 3) # ArgumentError: wrong number of arguments (3 for 2)
a, b = 1, 2, 3
# a == 1; b == 2
[[1, 2, 3]].each {|a, b| puts "a == #{a}; b == #{b}" }
# a == 1; b == 2
[By the way: none of the blocks above are closures.]
This allows, for example, the Enumerable protocol which always yields a single element to the block to work with Hashes: you just make the single element an Array of [key, value] and rely on the implicit array destructuring of the block:
{one: 1, two: 2}.each {|k, v| puts "#{key} is assigned to #{value}" }
is much easier to understand than what you would have to otherwise write:
{one: 1, two: 2}.each {|el| puts "#{el.first} is assigned to #{el.last}" }
Another difference between blocks and methods is that methods use the return keyword to return a value whereas blocks use the next keyword.
If you agree that it makes sense to have both methods and blocks in the language, then it is just a small step to also accept the existence of both procs and lambdas, because they behave like blocks and methods, respectively:
procs return from the enclosing method (just like blocks) and they bind arguments exactly like blocks do
lambdas return from themselves (just like methods) and they bind arguments exactly like methods do.
IOW: the proc/lambda dichotomy just mirrors the block/method dichotomy.
Note that there are actually quite a lot more cases to consider. For example, what does self mean? Does it mean
whatever self was at the point the block was written
whatever self is at the point the block is run
the block itself
And what about return? Does it mean
return from the method the block is written in
return from the method the block is run in
return from the block itself?
This already gives you nine possibilities, even without taking into account the Ruby-specific peculiarities of parameter binding.
Now, for reasons of encapsulation, #2 above are really bad ideas, so that reduces our choices somewhat.
As always, it's a matter of taste of the language designer. There are other such redundancies in Ruby as well: why do you need both instance variables and local variables? If lexical scopes were objects, then local variables would just be instance variables of the lexical scope and you wouldn't need local variables. And why do you need both instance variables and methods? One of them is enough: a getter/setter pair of methods can replace an instance variable (see Newspeak for an example of such a language) and first-class procedures assigned to instance variables can replace methods (see Self, Python, JavaScript). Why do you need both classes and modules? If you allow classes to be mixed-in, then you can get rid of modules and use classes both as classes and mixins. And why do you need mixins at all? If everything is a method call, classes automatically become mixins anyway (again, see Newspeak for an example). And of course, if you allow inheritance directly between objects you don't need classes at all (see Self, Io, Ioke, Seph, JavaScript)
Some pretty good explanation http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/ but i am guessing you want a bit more deeply philosophical explanation...
I believe the answer to "but could we not just get away having one type that accommodates all possible use-cases?", is that you can get away using just one.
The reason they exist is that ruby is trying to make the developer as productive as possible using expressions from both functional and object oriented paradigms, which makes the different types of closure "syntactic sugar".
I can write a short example that verifies that to_a of Enumerable calls each internally. Here it is:
class MyFooClass
include Enumerable
def initialize
#members = [1, 2, 3]
end
def each
puts "each is now called"
#members.each{ |m| yield(m) }
end
end
a = MyFooClass.new
puts "let us convert to array"
g = a.to_a
The output is:
let us convert to array
each is now called
Note that each is not member of Enumerable, but to_a is. Also, if I remove the definition of each from my class, then code crashes with the following message:
in `to_a': undefined method `each' for #<MyFooClass:0x997c1ac #members=[1, 2, 3]> (NoMethodError)
I am wondering whether there is Ruby official documentation about this, that would document the fact that to_a (which is member of Enumerable) goes through each method in your class. Please, do not direct me to source code of to_a. I do not consider this an answer.
From the fine manual:
The Enumerable mixin provides collection classes with several traversal and searching methods, and with the ability to sort. The class must provide a method each, which yields successive members of the collection.
Emphasis mine. So all of the iterative behavior of Enumerable is based on the class's each method; the ordering parts of the Enumerable interface (min, max, sort) use <=> but that's not important here.
The supplied each method is the only defined way that Enumerable has to interact with the class that mixes it in. Enumerable supplies a to_a method so it must use each to implement it.
As an aside, Enumerable does its best not to call to_a unless it has to, it tries to keep everything as an Enumerable to avoid having to exhaust the enumeration to build an Array that could be expensive in both time and space. The answer that Yossi pointed out is more about when Enumerable calls to_a rather than how (but that answer is interesting reading nonetheless ;).
Note the id_each in the code of #to_a:
static VALUE
enum_to_a(int argc, VALUE *argv, VALUE obj)
{
VALUE ary = rb_ary_new();
rb_block_call(obj, id_each, argc, argv, collect_all, ary);
OBJ_INFECT(ary, obj);
return ary;
}
For deeper explanation see this question.
Besides the ascetic explanation in the manual which mu pointed to, there is following passage in Pickaxe book as well, which is defacto king of Ruby introductory books:
Well, your classes can support all these neat-o features, thanks to
the magic of mixins and module Enumerable. All you have to do is write
an iterator called each, which returns the elements of your collection
in turn. Mix in Enumerable, and suddenly your class supports things
such as map, include?, and find_all?.
Ruby has differences between Procs created via Proc.new and lambda (or the ->() operator in 1.9). It appears that non-lambda Procs will splat an array passed in across the block arguments; Procs created via lambda do not.
p = Proc.new { |a,b| a + b}
p[[1,2]] # => 3
l = lambda { |a,b| a + b }
l[[1,2]] # => ArgumentError: wrong number of arguments (1 for 2)
Does anyone have any insight into the motivations behind this behavior?
There are two main differences between lambdas and non-lambda Procs:
Just like methods, lambdas return from themselves, whereas non-lambda Procs return from the enclosing method, just like blocks.
Just like methods, lambdas have strict argument checking, whereas non-lambda Procs have loose argument checking, just like blocks.
Or, in short: lambdas behave like methods, non-lambda Procs behave like blocks.
What you are seeing there is an instance of #2. Try it with a block and a method in addition to a non-lambda Proc and a lambda, and you'll see. (Without this behavior, Hash#each would be a real PITA to use, since it does yield an array with two-elements, but you pretty much always want to treat it as two arguments.)
I am trying to understand why do we really need lambda or proc in ruby (or any other language for that matter)?
#method
def add a,b
c = a+b
end
#using proc
def add_proc a,b
f = Proc.new {|x,y| x + y }
f.call a,b
end
#using lambda function
def add_lambda a,b
f = lambda {|x,y| x + y}
f.call a,b
end
puts add 1,1
puts add_proc 1,2
puts add_lambda 1,3
I can do a simple addition using: 1. normal function def, 2. using proc and 3. using lambda.
But why and where use lambda in the real world? Any examples where functions cannot be used and lambda should be used.
It's true, you don't need anonymous functions (or lambdas, or whatever you want to call them). But there are a lot of things you don't need. You don't need classes—just pass all the instance variables around to ordinary functions. Then
class Foo
attr_accessor :bar, :baz
def frob(x)
bar = baz*x
end
end
would become
def new_Foo(bar,baz)
[bar,baz]
end
def bar(foo)
foo[0]
end
# Other attribute accessors stripped for brevity's sake
def frob(foo,x)
foo[0] = foo[1]*x
end
Similarly, you don't need any loops except for loop...end with if and break. I could go on and on.1 But you want to program with classes in Ruby. You want to be able to use while loops, or maybe even array.each { |x| ... }, and you want to be able to use unless instead of if not.
Just like these features, anonymous functions are there to help you express things elegantly, concisely, and sensibly. Being able to write some_function(lambda { |x,y| x + f(y) }) is much nicer than having to write
def temp(x,y)
x + f(y)
end
some_function temp
It's much bulkier to have to break off the flow of code to write out a deffed function, which then has to be given a useless name, when it's just as clear to write the operation in-line. It's true that there's nowhere you must use a lambda, but there are lots of places I'd much rather use a lambda.
Ruby solves a lot of the lambda-using cases with blocks: all the functions like each, map, and open which can take a block as an argument are basically taking a special-cased anonymous function. array.map { |x| f(x) + g(x) } is the same as array.map(&lambda { |x| f(x) + g(x) }) (where the & just makes the lambda "special" in the same way that the bare block is). Again, you could write out a separate deffed function every time—but why would you want to?
Languages other than Ruby which support that style of programming don't have blocks, but often support a lighter-weight lambda syntax, such as Haskell's \x -> f x + g x, or C#'s x => f(x) + g(x);2. Any time I have a function which needs to take some abstract behavior, such as map, or each, or on_clicked, I'm going to be thankful for the ability to pass in a lambda instead of a named function, because it's just that much easier. Eventually, you stop thinking of them as somehow special—they're about as exciting as literal syntax for arrays instead of empty().append(1).append(2).append(3). Just another useful part of the language.
1: In the degenerate case, you really only need eight instructions: +-<>[].,. <> move an imaginary "pointer" along an array; +- increment and decrement the integer in the current cell; [] perform a loop-while-non-zero; and ., do input and output. In fact, you really only need just one instruction, such as subleq a b c (subtract a from b and jump to c if the result is less than or equal to zero).
2: I've never actually used C#, so if that syntax is wrong, feel free to correct it.
Blocks are more-or-less the same thing
Well, in Ruby, one doesn't usually use lambda or proc, because blocks are about the same thing and much more convenient.
The uses are infinite, but we can list some typical cases. One normally thinks of functions as lower-level blocks performing a piece of the processing, perhaps written generally and made into a library.
But quite often one wants to automate the wrapper and provide a custom library. Imagine a function that makes an HTTP or HTTPS connection, or a straight TCP one, feeds the I/O to its client, and then closes the connection. Or perhaps just does the same thing with a plain old file.
So in Ruby we would put the function in a library and have it take a block for the user .. the client .. the "caller" to write his application logic.
In another language this would have to be done with a class that implements an interface, or a function pointer. Ruby has blocks, but they are all examples of a lambda-style design pattern.
1) It is just a convenience. You don't need to name certain blocks
special_sort(array, :compare_proc => lambda { |left, right| left.special_param <=> right.special_param }
(imagine if you had to name all these blocks)
2) #lambda is usually used to create clojures:
def generate_multiple_proc(cofactor)
lambda { |element| element * cofactor }
end
[1, 2, 3, 4].map(&generate_multiple_proc(2)) # => [2, 3, 5, 8]
[1, 2, 3, 4].map(&generate_multiple_proc(3)) # => [3, 6, 9, 12]
It comes down to style. Lambdas are a a declarative style, methods are an imperative style. Consider this:
Lambda, blocks, procs, are all different types of closure. Now the question is, when and why to use an anonymous closure. I can answer that - at least in ruby!
Closures contain the lexical context of where they were called from. If you call a method from within a method, you do not get the context of where the method was called. This is due to the way the object chain is stored in the AST.
A Closure (lambda) on the other hand, can be passed WITH lexical context through a method, allowing for lazy evaluation.
Also lambdas naturally lend themselves to recursion and enumeration.
In case of OOP, you should create a function in a class only if there should be such an operation on the class according to your domain modeling.
If you need a quick function which can be written inline such as for comparison etc, use a lambda
Also check these SO posts -
When to use lambda, when to use Proc.new?
C# Lambda expressions: Why should I use them?
When to use a lambda in Ruby on Rails?
They're used as "higher-order" functions. Basically, for cases where you pass one function to another, so that the receiving function can call the passed-in one according to its own logic.
This is common in Ruby for iteration, e.g. some_list.each { |item| ... } to do something to each item of some_list. Although notice here that we don't use the keyword lambda; as noted, a block is basically the same thing.
In Python (since we have a language-agnostic tag on this question) you can't write anything quite like a Ruby block, so the lambda keyword comes up more often. However, you can get a similar "shortcut" effect from list comprehensions and generator expressions.
I found this helpful in understanding the differences:
http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/
But in general the point is sometimes your writing a method but you don't know what you're going to want to do at a certain point in that method, so you let the caller decide.
E.g.:
def iterate_over_two_arrays(arr1, arr2, the_proc)
arr1.each do |x|
arr2.each do |y|
# ok I'm iterating over two arrays, but I could do lots of useful things now
# so I'll leave it up to the caller to decide by passing in a proc
the_proc.call(x,y)
end
end
end
Then instead of writing a iterate_over_two_arrays_and_print_sum method and a iterate_over_two_arrays_and_print_product method you just call:
iterate_over_two_arrays([1,2,3], [4,5,6], Proc.new {|x,y| puts x + y }
or
iterate_over_two_arrays([1,2,3], [4,5,6], Proc.new {|x,y| puts x * y }
so it's more flexible.
What would an equivalent construct of a monad be in Ruby?
The precise technical definition: A monad, in Ruby, would be any class with bind and self.unit methods defined such that for all instances m:
m.class.unit[a].bind[f] == f[a]
m.bind[m.class.unit] == m
m.bind[f].bind[g] == m.bind[lambda {|x| f[x].bind[g]}]
Some practical examples
A very simple example of a monad is the lazy Identity monad, which emulates lazy semantics in Ruby (a strict language):
class Id
def initialize(lam)
#v = lam
end
def force
#v[]
end
def self.unit
lambda {|x| Id.new(lambda { x })}
end
def bind
x = self
lambda {|f| Id.new(lambda { f[x.force] })}
end
end
Using this, you can chain procs together in a lazy manner. For example, in the following, x is a container "containing" 40, but the computation is not performed until the second line, evidenced by the fact that the puts statement doesn't output anything until force is called:
x = Id.new(lambda {20}).bind[lambda {|x| puts x; Id.unit[x * 2]}]
x.force
A somewhat similar, less abstract example would be a monad for getting values out of a database. Let's presume that we have a class Query with a run(c) method that takes a database connection c, and a constructor of Query objects that takes, say, an SQL string. So DatabaseValue represents a value that's coming from the database. DatabaseValue is a monad:
class DatabaseValue
def initialize(lam)
#cont = lam
end
def self.fromQuery(q)
DatabaseValue.new(lambda {|c| q.run(c) })
end
def run(c)
#cont[c]
end
def self.unit
lambda {|x| DatabaseValue.new(lambda {|c| x })}
end
def bind
x = self
lambda {|f| DatabaseValue.new(lambda {|c| f[x.run(c)].run(c) })}
end
end
This would let you chain database calls through a single connection, like so:
q = unit["John"].bind[lambda {|n|
fromQuery(Query.new("select dep_id from emp where name = #{n}")).
bind[lambda {|id|
fromQuery(Query.new("select name from dep where id = #{id}"))}].
bind[lambda { |name| unit[doSomethingWithDeptName(name)] }]
begin
c = openDbConnection
someResult = q.run(c)
rescue
puts "Error #{$!}"
ensure
c.close
end
OK, so why on earth would you do that? Because there are extremely useful functions that can be written once for all monads. So code that you would normally write over and over can be reused for any monad once you simply implement unit and bind. For example, we can define a Monad mixin that endows all such classes with some useful methods:
module Monad
I = lambda {|x| x }
# Structure-preserving transform that applies the given function
# across the monad environment.
def map
lambda {|f| bind[lambda {|x| self.class.unit[f[x]] }]}
end
# Joins a monad environment containing another into one environment.
def flatten
bind[I]
end
# Applies a function internally in the monad.
def ap
lambda {|x| liftM2[I,x] }
end
# Binds a binary function across two environments.
def liftM2
lambda {|f, m|
bind[lambda {|x1|
m.bind[lambda {|x2|
self.class.unit[f[x1,x2]]
}]
}]
}
end
end
And this in turn lets us do even more useful things, like define this function:
# An internal array iterator [m a] => m [a]
def sequence(m)
snoc = lambda {|xs, x| xs + [x]}
lambda {|ms| ms.inject(m.unit[[]], &(lambda {|x, xs| x.liftM2[snoc, xs] }))}
end
The sequence method takes a class that mixes in Monad, and returns a function that takes an array of monadic values and turns it into a monadic value containing an array. They could be Id values (turning an array of Identities into an Identity containing an array), or DatabaseValue objects (turning an array of queries into a query that returns an array), or functions (turning an array of functions into a function that returns an array), or arrays (turning an array of arrays inside-out), or parsers, continuations, state machines, or anything else that could possibly mix in the Monad module (which, as it turns out, is true for almost all data structures).
To add my two cents, I'd say that hzap has misunderstood the concept of monads.
It's not only a « type interface » or a « structure providing some specific functions », it's muck more than that.
It's an abstract structure providing operations (bind (>>=) and unit (return)) which follow, as Ken and Apocalisp said, strict rules.
If you're interested by monads and want to know more about them than the few things said in these answers, I strongly advise you to read : Monads for functional programming (pdf), by Wadler.
See ya!
PS: I see I don't directly answer your question, but Apocalisp already did, and I think (at least hope) that my precisions were worth it
Monads are not language constructs. They're just types that implement a particular interface, and since Ruby is dynamically typed, any class that implement something like collect in arrays, a join method (like flatten but only flattens one level), and a constructor that can wrap anything, is a monad.
Following on the above answers:
You may be interested in checking out Rumonade, a ruby gem which implements a Monad mix-in for Ruby.
Romande is implemented as mix-in, so it expect its host class to implement the methods self.unit and #bind (and optionally, self.empty), and will do the rest to make things work for you.
You can use it to map over Option, as you are used to in Scala, and you can even get some nice multiple-failure return values from validations, a la Scalaz's Validation class.