in reply to (tye)Re: Why Closures?
in thread Why Closures?

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?

Replies are listed 'Best First'.
(tye)Re2: Why Closures?
by tye (Sage) on Apr 26, 2001 at 21:45 UTC

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

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

    [download]
    to be easier to write than this: 
    my @twice= map 2*$_, @list;
my @thrice= map 3*$_, @list;

    [download]
    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")
[reply]
[d/l]
[select]
Re: Re (tilly) 2: Why Closures?
by dws (Chancellor) on Apr 26, 2001 at 21:36 UTC
    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.

[reply]
      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. :-)

[reply]

In Section Meditations