Sounds right, except there is "another rule".

The argument list is just a generic expression evaluated in list context ("LIST"). That expression is commonly a chain of comma operators (e.g., f(1,2,3)), but is not limited to that (e.g., f(@a)).

The exception is when prototypes are used. Prototypes can restrict the expression that can be provided, and they can alters how they are evaluated.

Perl documentation is typically skimpy when it comes to formal specifications. Handwaving and C terminology is used ("undefined behavior") where such parallels can be drawn. I suppose it is prudent to make no promises one might renege later.

So this is certainly news to me. I thought one couldn't really depend on their order of evaluation. If there was such a strong guarantee, I'd have expected the docs to be clear on this. A note in perlsub, perlop or perlfunc; heck, why not all three.

"Subroutine arguments are evaluated from left to right."

Considering that you speak with something of an authority, would it be too much to ask of you to please update the perl documentation with the relevant detail? A prominent, unequivocal, unambiguous notice to this effect would be lovely to have.

"Subroutine arguments are evaluated from left to right" makes no sense. Subroutines arguments aren't evaluated. Subroutine arguments are the pieces of data you get after you execute the expression that follows the call.

You appear to be imagining parallels to C where none are warranted. The documentation makes no mention that the argument list is a series of comma-separated expressions. It says:

To call subroutines:

NAME(LIST);   # & is optional with parentheses.
NAME LIST;    # Parentheses optional if predeclared/imported.
&NAME(LIST);  # Circumvent prototypes.
&NAME;        # Makes current @_ visible to called subroutine.
[download]

LIST isn't documented, but it's consistently used to refer to expression evaluated in list context, and the examples that follow illustrates this.

Maybe because a defined subroutine argument order will outlaw any possible parallelization effort which were at least planned for perl6. They specified ordering for lists and left the argument order unspecified, which is technically the best thing to do.

It all comes from LISP, which is the only other language which left it undefined, leading to possible parallel evaluation of lambda args, even if already nobody does it. Blame SICP.

cperl will never specify the order of subroutine arguments even if native threading as in perl6 is a very long shot. the proper 5.005 threading model which would have allowed fast parallelization is gone. and you can never trust p5p, as they usually have no idea about the background knowledge before 2001, so it is very likely that they will do as you want.