Most of the functions we're speaking in this node
(sort, keys, map, stat) just don't have mush sense in scalar sense.
I mean, perl is designed (?) so that you
can not get caught by calling a function in scalar context
when you'd mean a list context.
Suppose for example that you want to use stat.
You know what it does, so you expect an array from it.
As you want to use some specific entries of the array,
you won't write code like
$permissions= stat $filename; that just means
nothing. If you use something as a list, you
automatically call it in array context.
Compare this with the other way.
Calling a function that you expect to return one single value
IS a possible trap, for example,
you might accidentally write
warn "customer arrived at ", localtime;
and expect that localtime returns a timestamp like "Thu May 13 20:26:09 2004"
as it does in scalar context.
This kind of trap is
really dangerous, I
think anyone learning Perl has fallen to it at least once.
(The most dangerous are operations that have entirely different side effects in different contexts, like /g regexps.)
So, returning to the list functions, some of
these have no meaning in scalar context (like sort, @arr[@inds],
map), and Perl typically gives a warning whe you use them that way.
Others are typically used in list context (grep, @array, stat, keys)
so you would only use them in scalar context
if you already expect some sort of behavior (that is,
you have read the manual).
Others are both used in list and scalar contexts equally often,
like readline, readdir, m//g, the comma operator,
the yadda-yadda operator; these really perform two different
things in the two contexts. Yes, you have to know this type,
but still, you won't probably get trapped by excepting something else as
a scalar value if you only know the list value, only
the other way round. (Well, maybe with m//g, yes.)