Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Defining a sub within a sub: OK?

by moritz (Cardinal)
on Oct 14, 2009 at 22:40 UTC ( #801229=note: print w/ replies, xml ) Need Help??


in reply to Defining a sub within a sub: OK?

As others have pointed out already there's no sub inside a sub in your code. I'll answer the question asked in your title though:

I consider it a bad idea to define a named sub within another sub. It's visible from the outside still, but obeys rather unintuitive scoping rules:

use strict; use warnings; sub a { my $x = 3; sub b { print $x, $/; } } b(); __END__ Variable "$x" will not stay shared at foo.pl line 7. Use of uninitialized value $x in print at foo.pl line 7.

There's no sane way in which perl could handle a call to b() from the outside.

However there's nothing wrong with defining an anonymous subroutine inside another sub. Actually it's quite common, and used very often in functional programming.

Perl 6 - links to (nearly) everything that is Perl 6.


Comment on Re: Defining a sub within a sub: OK?
Select or Download Code
Re^2: Defining a sub within a sub: OK?
by Joost (Canon) on Oct 14, 2009 at 22:52 UTC
    There's no sane way in which perl could handle a call to b() from the outside.

    However there's nothing wrong with defining an anonymous subroutine inside another sub. Actually it's quite common, and used very often in functional programming.

    Those two points are related: logically, any call to a() would redefine b() in that code, like my example below, which would only be silly. Also, that would mean that you couldn't call b() before calling a() at least once. But named subroutines are defined only once, at compile time*, which makes the whole construct iffy.

    sub a { my $x = 3; *b = sub { print $x, $/; }; }
    * The reasoning behind sub NAME { } constructs being realized early is so that you can call subroutines even if their definition is "later" in the code.

      * The reasoning behind sub NAME { } constructs being realized early is so that you can call subroutines even if their definition is "later" in the code.

      That's mostly true, but not very precise.

      If a subroutine is defined after it is called, the call has to use parenthesis. If it doesn't, it's interpreted as a string literal (or as an error if strict subs are in effect).

      $ perl -E 'say 1, foo; sub foo { 3 }' 1foo $ perl -E 'sub foo { 3 }; say 1, foo' 13 $ perl -E 'say 1, foo(); sub foo { 3 }' 13

      However it the call uses parenthesis, there's no need it has to be know at compile time at all:

      $ perl -E 'eval "sub foo { 3 }"; say 1, foo();' 13

      But I think for this discussion it's more important to ask when the lexical pad of sub a is being built and destroyed. As long as the a is not part of the call chain, $x is in no lex pad, and sub b can't work in a meaningful way.

      Perl 6 - links to (nearly) everything that is Perl 6.

        If a subroutine is defined after it is called, the call has to use parenthesis.

        Not quite. If a subroutine is declared after it is called, the call has to use parenthesis. You can always define it afterwards.

        >perl -wle"sub foo; foo; sub foo { print 'Hi!' }" Hi!

        Granted, it's very rare for a subroutine to be declared somewhere other than when it's being defined.

Re^2: Defining a sub within a sub: OK?
by ikegami (Pope) on Oct 15, 2009 at 00:07 UTC

    I consider it a bad idea to define a named sub within another sub

    I agree 100%. Anon subs are another story. For example, I use constructs such as

    sub foo { my $shared_with_all_recur = ...; local *_recur = sub { ... _recur(...); ... }; _recur(...); }
      Aside from the fact that the approach given in your reply is 'cleaner' and therefore, to my mind, preferable to something like
      sub foo { my $shared_with_all_recur = ...; my $_recur; $_recur = sub { ... $_recur->(...); ... }; $_recur->(...); }
      is there any advantage to using a localized glob rather than a lexical scalar?

        It leaks memory.

        use Devel::Peek; sub foo { my $_recur; $_recur = sub { $_recur->(); }; my $x; Dump($x); Dump($_recur,0); } foo();
        SV = NULL(0x0) at 0x182a4d4 REFCNT = 1 FLAGS = (PADMY) SV = RV(0x182a1e0) at 0x182a1d4 REFCNT = 2 FLAGS = (PADMY,ROK) RV = 0x2381a4

        Compare the refcount of $x (which will get freed) to $_recur's (which won't).

        The problem is that the sub referenced by $_recur captures $_recur, and thus you have a memory loop. If you wanted a lexical, you would need to use

        sub foo { my $shared_with_all_recur = ...; my $_recur; $_recur = sub { ... $_recur->(...); ... }; $_recur->(...); undef $_recur; }

        This is a lot messier.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://801229]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (8)
As of 2014-12-18 23:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (67 votes), past polls