What is anonymous sub? Why is it better?

[Picker Leon]

From perlsub

To declare subroutines:

sub NAME; # A "forward" declaration.
sub NAME(PROTO); # ditto, but with prototypes
sub NAME : ATTRS; # with attributes
sub NAME(PROTO) : ATTRS; # with attributes and prototypes sub
NAME BLOCK # A declaration and a definition.
sub NAME(PROTO) BLOCK # ditto, but with prototypes
sub NAME : ATTRS BLOCK # with attributes
sub NAME(PROTO) : ATTRS BLOCK # with prototypes and attributesTo define
an anonymous subroutine at runtime:

$subref = sub BLOCK; # no proto
$subref = sub (PROTO) BLOCK; # with proto
$subref = sub : ATTRS BLOCK; # with attributes
$subref = sub (PROTO) : ATTRS BLOCK; # with proto and attributesIt looks
to me that anonymous sub is better just as in file handle, using $FILE is
always better than FILE. right?

 

[A. Sinan Unur]

looks to me that anonymous sub is better just as in file handle, using
$FILE is always better than FILE. right?

Huh? You might want to get a book and try learning things from the ground
up instead of reading random bits and pieces of documentation and then
throwing our way every little question that pops into your mind.

http://www.catb.org/~esr/faqs/smart-questions.html

Sinan.

 

[Uri Guttman]

PL> to me that anonymous sub is better just as in file handle, using
PL> $FILE is always better than FILE. right?

why are you asking all these odd questions when you haven't shown skill
in basic perl yet?

ever heard of closures?

uri

 

[Jay Tilton]

: to me that anonymous sub is better

Anonymous subs are useful.
Named subs are also useful.

Saying one is better than the other depends entirely on what you plan on
doing with the sub.

: just as in file handle, using $FILE is always better than FILE. right?

That's just baffling. Those two have nothing to do with each other.

 

[Tassilo v. Parseval]

Also sprach Picker Leon:

From perlsub

To declare subroutines:

sub NAME; # A "forward" declaration.
sub NAME(PROTO); # ditto, but with prototypes
sub NAME : ATTRS; # with attributes
sub NAME(PROTO) : ATTRS; # with attributes and prototypes sub
NAME BLOCK # A declaration and a definition.
sub NAME(PROTO) BLOCK # ditto, but with prototypes
sub NAME : ATTRS BLOCK # with attributes
sub NAME(PROTO) : ATTRS BLOCK # with prototypes and attributesTo define
an anonymous subroutine at runtime:

$subref = sub BLOCK; # no proto
$subref = sub (PROTO) BLOCK; # with proto
$subref = sub : ATTRS BLOCK; # with attributes
$subref = sub (PROTO) : ATTRS BLOCK; # with proto and attributesIt looks
to me that anonymous sub is better just as in file handle, using $FILE is
always better than FILE. right?

Ah, but this analogy can't be drawn. Suppose you have this code:

sub hello {
my $name = shift;
print "Hello, $name\n";
}
hello("Picker");

If you re-write this using anonymous subroutines, it would become:

my $hello = sub {
my $name = shift;
print "Hello, $name\n";
}
$hello->("Picker");

Do you see any indication why the latter should be preferred over the
first piece of code?

Anonymous subroutines let you encapsulate a function in a variable in
order to do something special with it. For instance, you could pass this
function around. Here's an example from the world of functional
programming, also known as currying:

sub create_func {
my $arg1 = shift;
return sub { $arg1 + shift };
}

print create_func(5)->(6);

This involves two functions actually. Here's the first one:

my $ref = create_func(5);

create_func() returns a new function. 'create_func(5)' would roughly
return this function:

sub _returned_function {
return 5 + shift;
}

In order to create a dynamic amount of functions at runtime, it is
necessary to stuff them into a variable, therefore a reference to the
new function is returned. This new function can then be called via
reference:

my $ref = create_func(5); # $func1 is now the reference
print $ref->(6);
__END__
11

The above should just be an example for the context in which anonymous
subroutines are useful and in fact required. Perl beginners don't
usually indulge with such things. This will come later.

Tassilo

 

[Picker Leon]

How did you know too much about Perl?
I read the perl documents, but find nothing near to what you know. Do you
have super book or super site or something?
The more codes I wrote in perl now and the more problems I am facing.
Before, I can basically find all the answers in perldoc, but now I feel the
explaination in it is not enough for me to understand.

 

[Tassilo v. Parseval]

Also sprach Picker Leon:

How did you know too much about Perl?
I read the perl documents, but find nothing near to what you know. Do you
have super book or super site or something?

Neither of that. I am using the same documentation others use. The
information are all scattered somewhere in the perldocs.

Another invaluable source besides the standard documentation is this
newsgroup. Some of the most infamous Perl hackers post here regularly.

The more codes I wrote in perl now and the more problems I am facing.
Before, I can basically find all the answers in perldoc, but now I feel the
explaination in it is not enough for me to understand.

Maybe you are too impatient. Perl is quite feature-rich and you happen
to occupy with some of the more interesting things right at the start.
Some might suggest to take a gentler approch. However, practice, the
occasional read in the perldocs (even if you don't understand all of it)
and in this group is enough to teach you some decent Perl skills.

Tassilo

 

[Randal L. Schwartz]

Uri> ever heard of closures?

But what does that have to do with anonymous subs?

Being anonymous is an orthogonal property to being a closure.
There are anonymous non-closures, and named closures.

print "Just another Perl hacker," # the original JAPH

 

[Uri Guttman]

Uri> ever heard of closures?

RLS> But what does that have to do with anonymous subs?

RLS> Being anonymous is an orthogonal property to being a closure.
RLS> There are anonymous non-closures, and named closures.

that is a debateable point. some prefer to only call closures only anon
subs with lexicals. some claim all subs which have such lexicals are
closures. i won't debate you on that but i prefer to only call the anon
subs such. named subs that have external lexicals just have external
lexicals. my view of closures is the ability to make new subs with new
values of those private lexicals and named subs can't do that.

in any case, the OP is delving into stuff way over his head and he
barely know any perl. and he still doesn't seem to be reading any
responses here as he doesn't post where he gets his crazy code.

uri

 

[Tassilo v. Parseval]

Also sprach Uri Guttman:

Uri> ever heard of closures?

RLS> But what does that have to do with anonymous subs?

RLS> Being anonymous is an orthogonal property to being a closure.
RLS> There are anonymous non-closures, and named closures.

that is a debateable point. some prefer to only call closures only anon
subs with lexicals. some claim all subs which have such lexicals are
closures. i won't debate you on that but i prefer to only call the anon
subs such. named subs that have external lexicals just have external
lexicals. my view of closures is the ability to make new subs with new
values of those private lexicals and named subs can't do that.

Here is what for instance wikipedia has to say on closures. I find
similar definitions elsewhere:

Closure (computer science)

In programming languages, a closure is an abstraction representing a
function, plus the lexical environment in which the function was
created.

Closures are typically implemented with a special data structure
that contains a pointer to the function code, plus a representation
of the function's lexical environment (i.e., the set of available
variables and their values) at the time when the closure was
created.

So these definitions include the nature of a closure (first paragraph)
along with their common implementation (second paragraph). So you and
Randal are probably both right.

in any case, the OP is delving into stuff way over his head and he
barely know any perl. and he still doesn't seem to be reading any
responses here as he doesn't post where he gets his crazy code.

I can't quite agree with the first point. If a beginner was following
the advice of using modules for common tasks, he'd sooner or later
encounter closures (closures according to your definition). Some very
common modules make use of them, such as XML:arser (when using
handlers) or File::Find. Other methods often proposed to newbies involve
them as well, for instance dispatch-tables.

I therefore do endorse it when people want to tackle them very early.
Once they understand how they work, they understand quite a bit of Perl
and its mindset. Thus they'll pick up other essential things en-passant,
such as scoping rules and references.

Tassilo

 

[Uri Guttman]

TvP> Also sprach Uri Guttman:

TvP> I can't quite agree with the first point. If a beginner was following
TvP> the advice of using modules for common tasks, he'd sooner or later
TvP> encounter closures (closures according to your definition). Some very
TvP> common modules make use of them, such as XML:arser (when using
TvP> handlers) or File::Find. Other methods often proposed to newbies involve
TvP> them as well, for instance dispatch-tables.

those modules use callbacks which can be closures. they can also call
any code refs you pass in. closures are useful there but not needed. i
have used callbacks with named subs in a class just fine.

TvP> I therefore do endorse it when people want to tackle them very early.
TvP> Once they understand how they work, they understand quite a bit of Perl
TvP> and its mindset. Thus they'll pick up other essential things en-passant,
TvP> such as scoping rules and references.

in general i would agree with you. but the OP is bouncing around all
over perl and conflating all sorts of stuff (eval vs my vs
local????). it just seems like the OP is trying to learn all of perl in
one fell swoop and showing poor signs of programming skills along the
way. in his case, i would recommend learning basic perl first and not
jump into using powerful modules with callback apis.

uri