Re^2: Real life uses for closures. (update: disambiguation)

[BrowserUk]

in reply to Re: Real life uses for closures. (update: disambiguation)
in thread Real life uses for closures.

What are "delegates"? Talking about C#?

I don't know C#. My use of the term delegates comes from The D programming language and is best described as a pointer to a method.

That is, it is a pointer to a function that carries an implicit reference to an object instance. Ie. Equivalent to this in perl:

use Some::Class;

my $inst = new Some::Class();
my $delegate = sub{ Some::Class::methodName( $inst, @_ ); };

Closures are NOT synonymous for: ... nor for currying

Agreed. But currying is one use for closures not easily achieved without them.

[LanX]

So did you get enough RL examples of closures or did you mean to ask about functional programming in general?

[BrowserUk]

I've been reading a lot about constructing interpreters and VMs lately, and one thing that seems common to most new ones is the seemingly obligatory inclusion of closures; and the almost equally obligatory tales of woe, sleepless nights and extreme programming hardship that are required in order to implement them in an efficient and elegant manner.

Then the thought that formed in my mind was that whilst I am quite happy to make extensive use of them, I was also quite happily solving my programming problems in languages that don't support them for 15+ years before I became acquainted with them.

So then the questions that came to me were: a) how much use do people make of them in Perl? b) How many of those uses are actually 'killer applications' of closures, rather than trivial or convenient uses of up-values in anonymous subroutines that could just as easily be done using some other mechanism that doesn't impose such demands upon the VM?

One of the 'killer applications' of closures often cited in FP circles, is their links to continuation passing. But continuation passing is just one method of solving a problem that can be solved in various other ways. And most of those other ways seem to impose far less runtime burdens than CP whilst achieving the same goals.

Hence my very open question to try and get a feel for what people do with closures in real-world code.

[LanX]

> I was also quite happily solving my programming problems in languages that don't support them for 15+ years before I became acquainted with them.

I agree and as I said closures are somehow the other side of the OO coin in allowing encapsulated variables.

Just more elegantly done with less code in most languages.

It's like saying why do we need lexical variables, as long as we care about chosing the right package-namespaces we can achieve the same. True, but most of us don't wanna code Perl4 anymore!

> I've been reading a lot about constructing interpreters and VMs lately, and one thing that seems common to most new ones is the seemingly obligatory inclusion of closures;

I think it's also part of the feature competition. Like "What you have no App to shave your legs on your new smartphone"?

OTOH what I really like about JS is that it does FP (almost¹) excatly like Perl, while Ruby and Python suck at closure side-effects.

IMHO it's far easier to port FP-patterns than OO-patterns, and closures are indispensable for it.²

Saying this you might have noticed that some participants in this thread didn't really know what closure.

So yes you, can be a very efficient programmer w/o closures.

¹) well exactly if you have a dialect allowing to swap var with let.

²) And we have this "one package per file" paradigm, which forbids to just add another encapsulation on the fly. (No fun discussing the perl critic addicts)

IIRC correctly there was a nice thread where GrandFather solved a problem with an embedded mini-class where I used closures... If I can find it, I'll update.

[davido]

Apparently they're seen as useful enough that C++11 got them, in its own C++ish way. You're probably already familiar with this new addition to C++, but just in case, C++ lambda functions can capture the state of their enclosing scope. The consensus seems to be that adding this feature to C++ was a big win for the language... something Perl's been doing for decades.

An introductory article on C++11's lambda closures.

One difficulty that C++'s "closures" have is that you can't really share a variable from an enclosing scope across several lambda functions if the variable's outer scope ends. This is because the way C++ implements them, the captured variables are either copies, or references. Copies can't really be shared. References can, but if the target falls out of scope the lambdas are left holding the bitter end of an unfastened rope.

But all is not lost; C++11 got shared reference counted pointers too.

[ikegami]

Oh, I thought you meant "callback" by "delegate". They account for many closures.