http://www.osnews.com/story/16980/Closures_101_in_Ruby Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Tue, 10 Nov 2009 08:07:08 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://osnews.com/thread?202884 http://osnews.com/thread?202884 these are easier to understand in lisp than in ruby. Thu, 18 Jan 2007 01:01:00 GMT donotreply@osnews.com (broken_symlink) Comments http://osnews.com/thread?202894 http://osnews.com/thread?202894 I remember last semester I had a teacher who seemed adamant that anonymous methods in C# were bad and shouldn't ever be used: I used them anyway . Thu, 18 Jan 2007 01:25:00 GMT donotreply@osnews.com (ma_d) Comments http://osnews.com/thread?202901 http://osnews.com/thread?202901 And about time! It always drives me mad when i think: hmh, why can't i pass the function itself? I fear FP has dented my brain ;-) Thu, 18 Jan 2007 01:42:00 GMT donotreply@osnews.com (B. Janssen) Comments http://osnews.com/thread?202908 http://osnews.com/thread?202908 The syntax for these things in Ruby is a bit nasty. Literal blocks are denoted as:

{ | args | ... }

But literal blocks are not first-class objects. You can create a procedure object from a literal block with:

f = Proc.new { | args | ... }

and call the result with f.call(args)

In Lisp (and most other languages with first-class closures), the literal block (ie: lambda expression) is an actual first-class object. Ie, in Python, you can do:

f = lambda x: x + 1
f(3)

Unless I'm missing something, the equivalent Ruby code is:

f = Proc.new {|x| x + 1}
f.call(3)

which isn't as elegant. Thu, 18 Jan 2007 02:08:00 GMT donotreply@osnews.com (rayiner) Comments http://osnews.com/thread?202923 http://osnews.com/thread?202923 In Ruby you can also call Proc's using:
f[3]
which is the same as f.call(3)

And, according to WikiBooks, A Proc is a first-class object in Ruby:
http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Method_Calls#M... Thu, 18 Jan 2007 03:03:00 GMT donotreply@osnews.com (steved3298) Comments http://osnews.com/thread?202929 http://osnews.com/thread?202929 Proc's might be first class objects, but blocks are not Proc's. They are syntactic structures that can be converted to Proc's. In other languages that support closures, literal lambda expressions are first-class objects, just like literal numbers or literal strings are first-class objects.

If blocks were first-class objects in Ruby, you could do:

fun = {|x| x + 1}

just like you can do:

num = 5 Thu, 18 Jan 2007 03:29:00 GMT donotreply@osnews.com (rayiner) Comments http://osnews.com/thread?202935 http://osnews.com/thread?202935 lambdas are not closures. Closures have persistent scope.

In python coroutines are the closest you get to closures (new in 2.5).

By the way Ruby code blocks are also not closures... Thu, 18 Jan 2007 04:07:00 GMT donotreply@osnews.com (grfgguvf) Comments http://osnews.com/thread?202938 http://osnews.com/thread?202938 Here is a closure in Lisp:

(defun g (x) (setf v x) (defun f (a) (let ((t v)) (setf v a) t)))

Hope I got the parens right

Anyway give me a Ruby or C# equivalent please... Thu, 18 Jan 2007 04:14:00 GMT donotreply@osnews.com (grfgguvf) Comments http://osnews.com/thread?202939 http://osnews.com/thread?202939 OK here is the "same" in Python (2.5 only):

def g(x): v=x; while True: t=(yield v); if t is not None: v=t; else: raise Error

I believe Ruby has no equivalent but I might be wrong... Thu, 18 Jan 2007 04:25:00 GMT donotreply@osnews.com (grfgguvf) Comments http://osnews.com/thread?202940 http://osnews.com/thread?202940 Javascript can do closures too. I find them very useful in web development. Thu, 18 Jan 2007 04:27:00 GMT donotreply@osnews.com (BigZaphod) Comments http://osnews.com/thread?202947 http://osnews.com/thread?202947 Do you mean Python lambdas, or lambdas in general? I'm pretty sure the term "lambda" in general refers to a closure, since it derives from Lisp's "lambda" construct, which is a closure. Thu, 18 Jan 2007 05:15:00 GMT donotreply@osnews.com (rayiner) Comments http://osnews.com/thread?202951 http://osnews.com/thread?202951 C# also supports keeping the scope of anonymous method. But since I'm not a LISP expert, I cannot make a direct comparison. Yet here is an example that works

void AddCounter(ProgressBar p, Button b)
{
..b.clicked += delegate {
....p.Value++;
..}
}

AddCounter(myProgressBar, myButton);

Compiler generates a special class in order to maintain the scope of the delegate (which contains value of p). So it becomes:

class Temp {
..ProgressBar p;
..
..void HandleDelegate(... on click parameters ...)
..{
....p.Value++;
..}
}

As far as I know there are 3 or 4 such templates for different needs (no score variables, function parameters, local class access, etc). (Lisp and others probably maintain such internal structures too. i.e: it has to be stored somewhere)Edited 2007-01-18 05:27 Thu, 18 Jan 2007 05:25:00 GMT donotreply@osnews.com (sukru) Comments http://osnews.com/thread?202952 http://osnews.com/thread?202952 ...iolanguage.com Thu, 18 Jan 2007 05:32:00 GMT donotreply@osnews.com (Tuishimi) Comments http://osnews.com/thread?202961 http://osnews.com/thread?202961 I don't blame you, and doing anything short of non-trivial stuff with generics in C# 2.0 is made much easier by using anonymous methods, namely the new System.Predicate constructs. It also leads to more readable code.

Just curious, did he have a reason behind not using anonymous methods? Thu, 18 Jan 2007 06:53:00 GMT donotreply@osnews.com (jayson.knight) Comments http://osnews.com/thread?202962 http://osnews.com/thread?202962 Read this article: http://www.theserverside.net/tt/articles/showarticle.tss?id=Anonymo... Thu, 18 Jan 2007 07:02:00 GMT donotreply@osnews.com (jayson.knight) Comments http://osnews.com/thread?202992 http://osnews.com/thread?202992 A closure should not be mistaken with anonymous method or "code block" or a lambda expression.

A closure is not simply an anonymous method or a lambda expression. You can even create a closure with a named method.

A closure is actually a formed when "function references free variables in it´s lexical environment". It is not the function or code block itself. It is the runtime "thing" that it is created encapsulating the function and the references to the environment.

3.times { puts "Inside the times method." }
does not create a closure. There´s no reference inside the method/code block, to any variables on its same lexical scope.

In the same way, a lamdba expression is not in itself a closure. You will, probably, end up creating closures if you use lambda expressions, but the lambda expressions themselves are not closures and do not, necessarily imply the creation of one.

f = lambda x: x + 1
creates an anonymous function which applied to a number sums 1 to it and assigns that function to f. This does not create a closure. It is simply an anonymous function. The code inside the block does not reference anything outside its lexical scope. Just its own argument.

This
(defun g (x) (setf v x) (defun f (a) (let ((t v)) (setf v a) t)))
does create a closure, as the function f is referencing v, which is not in its own scope but in the environment of f (i.e. it is defined in g).
Closures don´t even have to imply using anonymous methods, as you can see in the example, where f has a perfectly known name.


Closures are an interesting concept, leading to complicated discussions and errors (if not handled properly). And confusing them with the simpler concept of an anonymous function or a code block does not really help people understand them.



P.D. I hope I did explain it properly, but as I´m in a bit of a hurry, please feel free to expand and/or correct me if I said something wrong. Thu, 18 Jan 2007 10:33:00 GMT donotreply@osnews.com (gonzalo) Comments http://osnews.com/thread?202995 http://osnews.com/thread?202995 Although Java doesn't provided a direct method for closures you can simulate them in many(not all by any stretch) cases with inner anonymous classes. Would be better if it had them properly but it's not a bad solution.

I personally don't like using closures in large projects anyway. Often documentation is limited and people use single character arguments names, you don't even have a function name to give you a clue. The closure is usually doing something which would be useful elsewhere and should be factories out into a functor.

I find that they are often a convince for getting things up and running when you don't want to spend your time building another class or search for the code which already does it. But doesn't aid in readability or maintainability.

Note: From the previous post I mean anonymous functions not closures. You cannot do closures in java as far as I'm awareEdited 2007-01-18 10:59 Thu, 18 Jan 2007 10:56:00 GMT donotreply@osnews.com (stefanpa) Comments http://osnews.com/thread?203000 http://osnews.com/thread?203000 As gonzalo pointed out, the point about closures is really capturing variables from the scopes where the closure is defined. If you don't do that it is not a closure but just an anonymous function.

Closures in languages that allow mutable variables are quite useful, but also quite prone to produce difficult errors.

In purely functional languages closures are much saner and safer since they automatically have referential transparency. I think it is kind of disturbing that people rip out features from functional languages to improve their procedural or OO languages without understanding the problems. Thu, 18 Jan 2007 11:07:00 GMT donotreply@osnews.com (tuttle) Comments http://osnews.com/thread?203009 http://osnews.com/thread?203009 In purely functional languages closures are much saner and safer since they automatically have referential transparency. I think it is kind of disturbing that people rip out features from functional languages to improve their procedural or OO languages without understanding the problems.

Referential transparency is over-estimated. No body can tell why is it good, yet everyone mentions it. Thu, 18 Jan 2007 12:08:00 GMT donotreply@osnews.com (axilmar) Comments http://osnews.com/thread?203011 http://osnews.com/thread?203011 Defining the language in the language has a number of problems, both efficiency is harmed as is the ease of debugging. So I'm not convinced of the merit of closures. Thu, 18 Jan 2007 12:18:00 GMT donotreply@osnews.com (dmantione) Comments http://osnews.com/thread?203028 http://osnews.com/thread?203028 "Defining the language in the language has a number of problems, both efficiency is harmed as is the ease of debugging. So I'm not convinced of the merit of closures."

Defining the language in language is about macros, not lambdas.

Closures are useful, because they can "remember" the parameters they're constructed with (see my example above).

I don't quite understand why people advocating languages without anonymous methods or closures treat the them as if they're insignificant.

People, please Java is fine as it's. It has it's own pros and cons. And do not attack other languages just because they contain features that Java don't. (Or replace Java here with your language of choice). Thu, 18 Jan 2007 14:06:00 GMT donotreply@osnews.com (sukru) Comments http://osnews.com/thread?203029 http://osnews.com/thread?203029 Of course I can tell you what referential transparency is good for. But that would be quite a long posting. For example it makes concurrent programming much more transparent and easy. And it eliminates whole classes of bugs completely. For example "leaky encapsulation" in complex classes.

You might have a point that mutable variables are a nessecary evil in some situations. But saying that referential transparency is useless is like saying the const keyword in C++ is useless because you can write any program without any const keywords. Thu, 18 Jan 2007 14:09:00 GMT donotreply@osnews.com (tuttle) Comments http://osnews.com/thread?203045 http://osnews.com/thread?203045 > these are easier to understand in lisp than in ruby.

Probably, but you'd have to understand Lisp first, which isn't that easy (based on experience - I know a lot of students who say it's hard as hell).

Teaching functional programming, closures, lambda expressions, and a completely unreadable syntax all at once always proves to be a mistake, but the profs do it again and again anyway... Thu, 18 Jan 2007 15:22:00 GMT donotreply@osnews.com (Morin) Comments http://osnews.com/thread?203047 http://osnews.com/thread?203047 > You cannot do closures in java as far as I'm aware

You can create closures through inner classes, though they are limited in one way: If they are nested inside a method, all accessed local variables from that method must be marked 'final' (they cannot be changed anymore). Thu, 18 Jan 2007 15:28:00 GMT donotreply@osnews.com (Morin) Comments http://osnews.com/thread?203048 http://osnews.com/thread?203048 > Referential transparency is over-estimated. No body can
> tell why is it good, yet everyone mentions it.

The advantage of referential transparency is that the function signature formally tells you what exactly a function does. You could also say that *not* having referential transparency is bad because today's imperative languages allow arbitrary side-effects within a procedure without forcing the programmer to note them down in the procedure signature. It's really a bit like the advantages of a static type system.

Having said that... there are attempts to do exactly what I described: To note down bounds for possible side-effects of a procedure. The confusing part is that this is done in purely functional languages, and for constructs that model side-effects in a pure language (these constructs are called monads). You get this when you combine monads with a static type system.

I would like to see similar things for imperative languages, but I think we'd need better mechanisms for side-effect aliasing first. Thu, 18 Jan 2007 15:37:00 GMT donotreply@osnews.com (Morin) Comments http://osnews.com/thread?203051 http://osnews.com/thread?203051 Actually the equivalent in Ruby is nearly identical to Python:

f = lambda { |x| x + 1 }
f[3]

which is just as elegant (actually I like the syntax better, but that's just an opinion). Thu, 18 Jan 2007 16:03:00 GMT donotreply@osnews.com (zerohalo) Comments http://osnews.com/thread?203120 http://osnews.com/thread?203120 Here's a function that takes a value, and returns a function that can be called to get that value increased by double.

double(val){
. . return function(way){
. . . . if(way == "by_multiplication")
. . . . . . return val * 2;
. . . . if(way == "by_addition")
. . . . . . return val + val;
. . }
}

Now if we do this...

doubler = double(6);

...it is equivalent to doing this...

[i]doubler(way){
. . var val = 6; // Thu, 18 Jan 2007 18:17:00 GMT donotreply@osnews.com (chaosvoyager) Comments http://osnews.com/thread?203395 http://osnews.com/thread?203395 "By the way Ruby code blocks are also not closures..."

Yeah they are:

irb(main):001:0> def make_proc(x)
irb(main):002:1> y = 3
irb(main):003:1> return proc { x + y }
irb(main):004:1> end
=> nil
irb(main):005:0> p = make_proc(2)
=> #
irb(main):006:0> p[]
=> 5Edited 2007-01-19 06:28 Fri, 19 Jan 2007 06:27:00 GMT donotreply@osnews.com (leavengood) Comments