Re^5: Evaluation Order again.

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