$@疑点

The interesting thing about & is that you can generate new syntax with it, provided it's in the initial position:

1. sub try (&@) {
2. my($try,$catch) = @_;
3. eval { &$try };
4. if ($@) {
5. local $_ = $@;
6. &$catch;
7. }
8. }
9. sub catch (&) { $_[0] }
11. try {
12. die "phooey";
13. } catch {
14. /phooey/ and print "unphooey\n";
15. };

That prints "unphooey" . (Yes, there are still unresolved issues having to do with visibility of @_ . I'm ignoring that question for the moment. (But note that if we make @_ lexically scoped, those anonymous subroutines can act like closures... (Gee, is this sounding a little Lispish? (Never mind.))))

And here's a reimplementation of the Perl grep operator:

1. sub mygrep (&@) {
2. my $code = shift;
3. my @result;
4. foreach $_ (@_) {
5. push(@result, $_) if &$code;
6. }
7. @result;
8. }

Some folks would prefer full alphanumeric prototypes. Alphanumerics have been intentionally left out of prototypes for the express purpose of someday in the future adding named, formal parameters. The current mechanism's main goal is to let module writers provide better diagnostics for module users. Larry feels the notation quite understandable to Perl programmers, and that it will not intrude greatly upon the meat of the module, nor make it harder to read. The line noise is visually encapsulated into a small pill that's easy to swallow.

If you try to use an alphanumeric sequence in a prototype you will generate an optional warning - "Illegal character in prototype...". Unfortunately earlier versions of Perl allowed the prototype to be used as long as its prefix was a valid prototype. The warning may be upgraded to a fatal error in a future version of Perl once the majority of offending code is fixed.

It's probably best to prototype new functions, not retrofit prototyping into older ones. That's because you must be especially careful about silent impositions of differing list versus scalar contexts. For example, if you decide that a function should take just one parameter, like this:

1. sub func ($) {
2. my $n = shift;
3. print "you gave me $n\n";
4. }

and someone has been calling it with an array or expression returning a list:

1. func(@foo);
2. func( split /:/ );

Then you've just supplied an automatic scalar in front of their argument, which can be more than a bit surprising. The old @foo which used to hold one thing doesn't get passed in. Instead, func() now gets passed in a 1 ; that is, the number of elements in @foo . And the split gets called in scalar context so it starts scribbling on your @_ parameter list. Ouch!

This is all very powerful, of course, and should be used only in moderation to make the world a better place.