I must concur that this argument about your pedantic definition of the word "argument" is neither helpful nor enlightening.

On my first try, I found:

A value or reference passed to a function, procedure, subroutine, command or program, by the caller. For example, in the function definition

    square(x) = x * x
[download]

x is the formal argument or "parameter", and in the call

    y = square(3+4)
[download]

3+4 is the actual argument.

Clearly, "3+4" is not a value, it is an expression.

Yes, in the case of Perl 5, things get a little more muddled and one way to conceptualize things in an attempt to unmuddle them is to declare that the invocation of a Perl sub does not take a list of "actual arguments", but instead, a single expression that might result in multiple values and thus the presence of a comma is not really separating (actual) argument (expression)s.

But talking about Perl sub arguments in the standard manner doesn't run into problems in the majority of cases. And even when it does, there are other ways to unmuddle things that don't require throwing out the familiar model and language just because it doesn't quite fit for some cases.

So stop insisting people are wrong just because they choose to use one word in a traditional and widely-understood manner.

I actually believe that Perl's comma operator is just a descendant of the use of comma to separate actual argument (expression)s in function calls. And the list-flattening behavior really isn't enough reason to insist that everybody abandon that way of understanding them and talking about them.

Shell scripts have an analogous situation but my copy of "man bash" deals with that without your pedantic gymnastics:

Unquoted implicit null arguments, resulting from the expansion of parameters that have no values, are removed.

and

yank-nth-arg (M-C-y)

Insert the first argument to the previous command (usually the second word on the previous line) at point.

You see, they don't feel ashamed to occasionally talk about an expression as an "argument" even though, based on their definition, it strictly (pedantically) isn't:

The words that are not variable assignments or redirections are expanded. If any words remain after expansion, the first word is taken to be the name of the command and the remaining words are the arguments.

Writing clear documentation is an exercise in pedantry. If someone is argue that the documentation should be changed, I consider the choice of words in the proposed revision to be very important. In this case, it could easily be fixed by replacing "the arguments" with "the argument list". I don't why there's no much resistance to this. It's silly that so much fuss is being made about this since the point I was making is that proposed statement is still wrong when you fix the wording.

If you argue that "3+4" is the actual argument in "f(3+4)", then you get in the ridiculous situation where you say that "@a" is the actual argument in "f(@a)".

Writing clear documentation is an exercise in pedantry.

Uh, no. So very much, no. Pedantry is too far along the spectrum to the point that it actual interferes with communication and reduces clarity. Clear documentation is usually helped by some precision in verbiage. Becoming pedantic leads to wasting time splitting hairs, making the documentation harder to follow.

It's silly that so much fuss is being made about this since the point I was making is that proposed statement is still wrong when you fix the wording.

Unfortunately, you are so committed to this particular pedantry that you believe this, but I went over what you wrote several times trying to find the non-pedantic point being obscured by your zeal for proper use of one word and I'm pretty sure it isn't there, else I'd not have responded as I did.

For example, your sub { }->( X1() = X2() || X3() ); response doesn't demonstrate a flaw in the proposed explanation. It is again just laser focused on how "argument" is the wrong word. When (mildly) misusing "argument" (by using the common definition when talking about Perl), the order of evaluation of "arguments" does not apply in sub { }->( X1() = X2() || X3() ); because there is only one 'actual' argument (expression) in that call. Yes, of course, it isn't hard to realize that more than 1 or even 0 values might result as the list of argument values actually passed to the subroutine. It isn't hard to realize so being pedantic about the word choice more hurts than helps understanding.

You aren't demonstrating the incorrectness of the concepts behind the statement. You are still picking the wrong concept to use in your interpretation of the statement simply because the word "argument" was used. You are demonstrating that your pedantry has prevented you from understanding the intended statement.

If you were less pedantic about it, you might have succeeded in communicating (or perhaps even understanding yourself?) that making a statement about evaluation order of (actual) "arguments" should really be a statement about "lists (of expressions separated by commas)" or (less clearly but more precisely) about "the comma operator". But such a statement can be made clearer by bowing to the reality that the comma operator is still strongly conceptually tied to its origin as a way to separate subroutine arguments. So make a statement about lists and/or commas but add something like "including the list of expressions used as the arguments for a call to a subroutine".

I got that point by reading what your wrote... eventually. But, boy, was it a struggle to pierce the pedantry to be able to get that point.

The fact that order of evaluation applies to the list of actual argument expressions in a subroutine invocation is an important one. And it is helpful to explicitly point that out, and not to just imply it by noting that "these aren't subroutine arguments, they are just uses of the same comma operator". As you point it out, you can also point out the sameness, but even doing that pedantically makes it harder to understand.

- tye        

You are probably referring to the argument list expression

That sub only has one argument; the result of evaluating a single expression.

So, no "list" involved, and your argument is pure pedantic fallaciousness.

Pretty much your trademark. Make an unsupportable statement and then defend it to the death by cloaking the issue in a string of non sequiturs.

Please ignore the parent post. It's completely wrong.

• They are lying about me saying there was more than one argument.
• They are lying when he said it's not an argument list. I got the name from perlsub. I called it the "expression that follows the call" before that. The name isn't even relevant!
• They are lying about my claim is indefensible. You can run the code yourself to ascertain that the expression that follows the call (which perlsub calls the argument list) isn't always evaluated from left to right.

{sigh} See what I mean folks.

An accusation of lies and a vehement defence of 3 things nobody said. Obfuscation at its most blatant.

Nobody said you stated there was more than one argument in your post; but to address the concerns expressed in the post to which you replied; and for you to be able to talk about "argument expression list" (which you did, but you've probably edited that out like always), there would have to be more than one argument. A list of one doesn't address oiskuu's concerns.

I didn't say "it's not an argument list". More obfuscation.

The indefensible claim comes in a much earlier post; but as always, your memory of your earlier faux pas in defense of your idée fixe are like those of a gold fish; gone in seconds.

And it is on that you rely to induce folie à plusieurs amongst your readers. Who could possible care to go back and check the facts.