Re^4: Evaluation Order again.

[oiskuu]

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.

[ikegami]

"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.

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

[oiskuu]

Now you're splitting hairs. "Arguments to subroutines are evaluated in list order: from left to right." Is that better?

Remember, documentation is not written for a person who already knows everything. (I need the clarity to stop imagining unwarranted parallels.)

---

Update. ikegami: human language affords its speakers some latitude. In this case, "arguments" can refer to elements on stack (a technical view); it can refer to tokens of source code (parsing context); or it can refer to the expressions that end up as arguments. All three interpretations (and possibly more) are used in perl documentation. How would you describe f($a, $b, $c)? A function supplied with three expressions?

[ikegami]

No, it's still wrong, and for the same reason. Arguments aren't evaluated. Arguments are values, not code.

You are probably referring to the argument list expression, but it's not necessary evaluated from left-to-right either.

Here's an example that's right-to-left:

$ perl -E'
   sub L :lvalue { say "L"; $L }
   sub R         { say "R"; $R }

   sub { }->( L() = R() );
'
R
L

Here's an example that's neither:

$ perl -E'
   sub X1 :lvalue { say "X1"; $X1 }
   sub X2         { say "X2"; $X2 }
   sub X3         { say "X3"; $X3 }

   sub { }->( X1() = X2() || X3() );
'
X2
X3
X1

[rurban]

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.

[BrowserUk]

Maybe because ... planned for perl6.

Damn man! Way to go, twisting history in your attempt to make a puerile point of no consequence and extremely dubious value. I think you just proved everything dave_the_m said about you. And more.

Perl has undefined subroutine argument evaluation order because C had undefined subroutine argument evaluation order.

And C had it, because when C was defined, the plethora of cpu architectures, with weird and different instruction sets -- RISC, CISC, orthogonal and irregular, 8-bit, 16-bit, 18-bit et al. -- combined with no pipelining, no branch prediction and many clock-cycles for even the simplest of instructions -- giving what by today's standards was absolutely glacial performance -- meant that specifying it one way might be optimal for one architecture, but lead to the worst possible performance on another.

Hence, is was a conscious design decision by K&R to leave it to the implementors of compilers, despite that they acknowledged that it detracted from the generality of the language, placing the onus on the human programmer to avoid, otherwise legal language constructs that were ambiguous -- like the classic: func( a++, ++a );

It was an expedient compromise to the realisation that 'the hardware problem' was beyond the control of programmers and their software.

outlaw any possible parallelization effort ...

That's just garbage. Though in your defense, it is widely misunderstood and disseminated garbage.

A defined evaluation order -- not just subroutine args, but also subexpressions -- would enable the programmer to make informed choices at the source level that would vastly enhance the potential for parallelisation.

It all comes from LISP, which is the only other language which left it undefined,

And that's just plain wrong! Glaringly, verifiably, obviously, wrong.