>So basically, it would be nice if each, keys, values, etc. could all deal
>with being handed a hash from a code block or subroutine...
In the current Perl World, a function can only return as output to
its caller a LIST, not a HASH nor an ARRAY. Likewise, it can only
receive a LIST, not those other two.
Liberally excerpted:
The Perl model for passing data into and out of a subroutine is
simple: all function parameters are passed as one single, flat list
of scalars, and multiple return values are likewise returned to the
caller as one single, flat list of scalars. As with any R<LIST>,
any arrays or hashes passed in these lists will interpolate their
values into the flattened list, losing their identities--but there
are several ways to get around this, and the automatic list
interpolation is frequently quite useful. Both parameter lists and
return lists may contain as many or as few scalar elements as you'd
like (though you may put constraints on the parameter list using
prototypes). Indeed, Perl is designed around this notion of
I<variadic> functions (those taking any number of arguments), unlike
C, where they're sort of grudgingly kludged in so that you can call
I<printf>(3).
...
Now, if you're going to design a language around the notion of
passing varying numbers of arbitrary arguments, you'd better make
it easy to process those arbitrary lists of arguments. Any arguments
passed to a Perl routine come in as the array C<@_>. If you call
a function with two arguments, they are accessible inside the
function as the first two elements of that array: C<$_[0]> and
C<$_[1]>. Since C<@_> is a just a regular array with an irregular
name, you can do anything to it you'd normally do to an array.<footnote>
This is an area where Perl is I<more> orthogonal than the typical
programming language.</footnote>
--tom
