>>>>> "DP" == Deborah Ariel Pickett <[EMAIL PROTECTED]>
writes:
DP> One thing that the C comma operator promises is that its left
DP> operand (and all side effects) is completely evaluated before work
DP> starts on the right operand. (This may not be strictly true in
DP> the Perl interpretation of the operator; can a Perl5 developer
DP> comment?)
It's a matter of some controversy exactly what "promises" with regards
to order of operation Perl5 provides. Unlike C, there's no separate
standard describing what Perl should do: just an implementation, and
some documentation.
As a matter of implementation, I believe both scalar and list comma
operators have always evaluated their arguments from left to right.
(This also applies to the comma separating sub arguments, if you count
that separately from list comma).
As for documentation, both the POD and the Camel book use language
that strongly suggests left-to-right evaluation for the scalar comma
("it evaluates its left argument, throws that value away, then
evaluates its right argument and returns that value") as well as
referring to it as "just like" the C comma. By contrast, they don't
say anything directly about the evaluation order of the list comma.
On the other hand, there is the following example from perldata (I
can't find it in the Camel, but I can't grep the Camel):
# A "reverse comma operator".
return (pop(@foo),pop(@foo))[0];
which only makes sense if list comma is guaranteed to evaluate left to
right.
DP> I'm pretty sure that for a Perl list, the order of evaluation of
DP> elements isn't guaranteed, meaning that C<next> may evaluate
DP> before C<warn> in the above example if it were treated exactly
DP> like a list. (Again, can someone refute or support this?)
[The example again is 'foo() or (warn("blah"), next);']
Note that neither argument to "or" can be a list, so that comma isn't
a list comma. It's actually in a void context there, so it's a scalar
comma. (The rule "void context is a kind of scalar context" seems
rather arbitrary in the abstract, and the reasons for it are at least
partially historical, but it does seem to me to give the right answer
here).
-- Stephen
