Question

Is there a good reason for map to not read from @_ (in functions) or @ARGV (anywhere else) when not given an argument list?

Answer 1

I can’t say why Larry didn’t make map, grep and the other list functions operate on @_ like pop and shift do, but I can tell you why I wouldn’t. Default variables used to be in vogue, but Perl programmers have discovered that most of the “default” behaviors cause more problems than they solve. I doubt they would make it into the language today.

The first problem is remembering what a function does when passed no arguments. Does it act on a hidden variable? Which one? You just have to know by rote, and that makes it a lot more work to learn, read and write the language. You’re probably going to get it wrong and that means bugs. This could be mitigated by Perl being consistent about it (ie. ALL functions which take lists operate on @_ and ALL functions which take scalars operate on $_) but there’s more problems.

The second problem is the behavior changes based on context. Take some code outside of a subroutine, or put it into a subroutine, and suddenly it works differently. That makes refactoring harder. If you made it work on just @_ or just @ARGV then this problem goes away.

Third is default variables have a tendency to be quietly modified as well as read. $_ is dangerous for this reason, you never know when something is going to overwrite it. If the use of @_ as the default list variable were adopted, this behavior would likely leak in.

Fourth, it would probably lead to complicated syntax problems. I’d imagine this was one of the original reasons keeping it from being added to the language, back when $_ was in vogue.

Fifth, @ARGV as a default makes some sense when you’re writing scripts that primarily work with @ARGV… but it doesn’t make any sense when working on a library. Perl programmers have shifted from writing quick scripts to writing libraries.

Sixth, using $_ as default is a way of chaining together scalar operations without having to write the variable over and over again. This might have been mitigated if Perl was more consistent about its return values, and if regexes didn’t have special syntax, but there you have it. Lists can already be chained, map { ... } sort { ... } grep /.../, @foo, so that use case is handled by a more efficient mechanism.

Finally, it’s of very limited use. It’s very rare that you want to pass @_ to map and grep. The problems with hidden defaults are far greater than avoiding typing two characters. This space savings might have slightly more sense when Perl was primarily for quick and dirty work, but it makes no sense when writing anything beyond a few pages of code.

PS shift defaulting to @_ has found a niche in my $self = shift, but I find this only shines because Perl’s argument handling is so poor.