in reply to Choosing between multiple closures

When you write \&increment( @_ ) you take a reference to the output of the increment sub, which already is a reference. And then, you don't return the result, so your do_something sub returns the result of the for statement, which is not what you expect.

You can correct your code by replacing \&increment( @_ ) with return increment(@_) (the & isn't actually useful here).

Replies are listed 'Best First'.
Re^2: Choosing between multiple closures
by oakb (Scribe) on Jun 12, 2014 at 08:00 UTC
    Thank you, Eily. I just made the change to my actual code, and VOILA! It works.

    It makes perfect sense, too. My problem lay in not understanding the need to return the return — I guess having so many returns is counterintuitive to me.

    UPDATE: In the groggy wee morning hours, I understated the number of returns involved... the fix is actually returning the returned return. Yup, that's three returns, folks. No wonder I couldn't get my brain around it before reading Eily's elucidating answer.

    Even though I thanked Mark Jason Dominus in my OP, it was actually Chap. 2 of his book that originally led me astray, since it shows coderefs everywhere an anonymous subroutine is too large to include right in a dispatch table:
    $dispatch_table  =
{  CHDIR     => \&change_dir,
   LOGFILE   => \&open_log_file,
   VERBOSITY => \&set_verbosity,
   ...       =>  ...,
};

    [download]
    (Higher-Order Perl, p. 44)

    Of course, Chap. 2 didn't contemplate returning iterators, which don't really make an appearance until Chap. 4, so this is not a condemnation of MJD or his excellent book — without which I wouldn't even be using iterators in the first place. No, the fault is completely mine for mixing concepts MJD didn't intend to combine at that point in the book. Mea culpa.
[reply]
[d/l]

In Section Seekers of Perl Wisdom