(tye)Re: Why Closures?

[tye]

I assume you've read Why I like functional programming.

Functional programming is where you treat functions like data. That is, you have functions that take functions as arguments and return functions as values. Just using pointers to functions (a.k.a. code references in Perl) allows you to do that to some extent, but not enough to really call it functional programming.

What closures add is the ability to give a subroutine attributes (or rather, add attributes to a reference to a subroutine). So you can write a subroutine that takes arguments and returns a subroutine that has those arguments as parameters. The usual example seems to be:

sub generateMultiplier {
    my( $byWhat )= @_;
    return sub {
        my( $toBeMultiplied )= @_;
        return $toBeMultiplied * $byWhat;
    }
}

my @list= ( 1, 2, 3, 5, 7, 11 );
my $doubler= generateMultiplier( 2 );
my $tripler= generateMultiplier( 3 );
my @twice= map $doubler->($_), @list;
my @thrice= map $tripler->($_), @list;

which also shows how Perl isn't a functional programming language but only allows you to use some functional programming techniques.

        - tye (but my friends call me "Tye")

[tilly]

I was under the impression that it was quite easy to write a function in Perl which expects some of its arguments to be functions, and then generates a new function to return.

In fact I do exactly that quite often, and I am positive that you know how I do it. So I suspect we are talking past each other and mean different things.

Could you explain in more detail what you would want Perl to do which it doesn't?

[tye]

If Perl were a functional programming language, I would expect this:

my @twice= map $doubler->($_), @list;
my @thrice= map $tripler->($_), @list;

to be easier to write than this:

my @twice= map 2*$_, @list;
my @thrice= map 3*$_, @list;

I never said Perl doesn't let you use functional programming techniques (in fact, I said the opposite).

Perl just has a preference for non-functional techniques. map is one example. If you happen to have a closure, then map requires you to write more code. If Perl were a functional programming language, then you'd probably have to create a closure if you had a code block that you wanted to use with map.

        - tye (but my friends call me "Tye")

[dws]

I was under the impression that it was quite easy to write a function in Perl which expects some of its arguments to be functions, and then generates a new function to return.

Yes, you can build closures which hold other closures. Every once in a while I run into some bizarre situation where that is really, really useful.

Closures of closures can also be wickedly hard to debug.

[tilly]

As Tom Christiansen says, You can solve any programming problem with an extra level of indirection, except the problem of too many levels of indirection.

A closure is a level of indirection. "I will take some action" but the action to take is defined elsewhere. When you start to layer levels of indirection, it becomes critical to know what each layer is supposed to do, and that each layer does its job absolutely correctly. This is true no matter what the layers of indirection are.

However with closures it is easy to produce an astonishing number of layers of indirection in very little code. When you write a recursive function that generates closures out of closures, it basically has to work perfectly or it will do something totally bizarre...

Caveat hacker. :-)

[jdporter]

Functional programming is where you treat functions like data. That is, you have functions that take functions as arguments and return functions as values. Just using pointers to functions (a.k.a. code references in Perl) allows you to do that to some extent, but not enough to really call it functional programming.

Sorry, tye, I have to disagree with you. Functional programming is generally defined as programming without side-effects. At its most extreme, this means programming without external state of any kind.

Perl can not be considered a functional language in a purist sense, because it supports non-functional programming. However, it does support functional programming, so it is possible to "use Perl as a functional language", if one chooses.

Also, even given your definition of FP, Perl satisfies the definition perfectly. The only thing LISP-family languages can do that Perl can't, is treat function definitions as runtime-modifiable data. (That is, a lisp program can rewrite any of its functions at will.) But, while powerful, this ability is not generally considered to be essential to the definition of functional programming.

[Jenda]

IMHO it's better to use the positive definition "FP allows you to treat functions as data" than the negative one "FP is without side effects".

If you insisted on the negative definition then even most officialy functional languages would not be functional. And if the FP was only about the restriction it would not be very attractive ;-)

For me FP means two things. Higher order functions+closures (which is something we have in Perl) and a good general type system with real polymorphism (map: (( 'a -> 'b ), 'a list) -> 'b list) (which is something that we don't have in Perl, but since we have no types I don't feel restricted).

Jenda

P.S.: It's a shame Microsloth did not steal either from FP for it's .Net :-(
C# still feels like something 30 years old :-(

[jdporter]

IMHO it's better to use the positive definition "FP allows you to treat functions as data" than the negative one "FP is without side effects".

Suit yourself. You'll find yourself in the minority opinion wrt computer scientists.

If you insisted on the negative definition then even most officialy functional languages would not be functional.

Not true, there are some "pure" FP languages. Of course, like most single-paradigm languages, people don't use them very much!