|
Re: Matching and order of evaluation
by japhy (Canon) on Oct 27, 2003 at 21:20 UTC
|
There's no problem with that. If the regex fails, $3 stays the same. If it succeeds, $3 won't be overwritten until after the regex is done.
_____________________________________________________
Jeff[japhy]Pinyan:
Perl,
regex,
and perl
hacker, who'd like a job (NYC-area)
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;
| [reply] |
Re: Matching and order of evaluation
by bart (Canon) on Oct 27, 2003 at 22:18 UTC
|
In perl 5 all order of evaluation is undefined
Not true. There are a few cases for which order of execution is very well defined. One is your example, assignment: the assignment always happens after the expression, the RHS is calculated. That makes sense, as it's only at that point that the value is known.
And two is the shortcircuit operators, and/or and &&/||. The right hand side isn't even calculated if the left hand side is all one needs to know to get the final result of the whole expression.
So this combination is very safe:
sub foo { return 3+$a };
$a = 1;
$a = foo($a) and print $a;
Order of evaluation is as follows:
- The value of $a is set to 1.
- foo($a) is calculated, returning 4.
- The new value is assigned to $a.
- and checks to see if the result of the assignment is true. It is.
- The print is executed, printing 4.
Note that this is different from the following case:
$\ = "\n";
my $x = 12;
{
my $x = $x + 1; # <--- point of interest
print $x;
}
print $x;
Note that in the relevant statement, $x in the left hand side and in the right hand side are actually two different variables, both named $x. The RHS uses the outer scoped variable, the LHS the inner scoped variable. And even though here:
my $x = 123;
{
my $x = 45 and print $x;
}
the assignment does happen before the print, it prints the outer scoped variable, because that's the variable the parameter refers to.
| [reply]
[d/l]
[select] |
|
|
Oh ok, right. I didn't intend to be that general. There are a few select places where execution order is defined. Your example of the RHS computing before the LHS isn't a good one because that part isn't well defined. That only matters where computing the LHS has some sort of external effect on a dependancy of the RHS. Of course, the RHS has to be executed before the assignment but the LHS also has to execute to find the lvalue for the assignment and its that part that can move around. Anyhow, I think I'm clear on when I care about execution order - only when the sub-expressions in a statement depend on each other - say multiple shift statements: sub { ${ shift() } = shift }->( a, b ). In this case sassign wants the LHS as its last argument so the second shift runs first then the first shift and scalar dereference. Execution order matters here because a common element is being altered. Ah well. perl -MO=Concise -e '@ARGV=qw(a b); ${shift()} = shift;' | Idealized optrees from B::Concise
leave
enter
nextstate
aassign
pushmark
const a
const b
pushmark
rv2av
gv
nextstate
sassign
shift
rv2av
gv
rv2sv
scope
shift
rv2av
gv
| [reply]
[d/l]
[select] |
Re: Matching and order of evaluation
by Abigail-II (Bishop) on Oct 27, 2003 at 21:21 UTC
|
None of that should be a problem. You could get problems if
you modify a variable twice between sequence point, but using
it on both sides of an assignment should be fine (usually).
Your example isn't very different from:
$var = $var + 1;
Abigail | [reply]
[d/l] |
|
|
I thought that it was a simple statement but wasn't sure. In fact, I don't know whether your simple example is safe for all $var - does it become unsafe if $var has get-magic or set-magic?
| [reply] |
|
|
Well, if there's magic involved, anything could happen - after
all, you're then back into "user" land. But, assuming nothing
weird happens during the magic, it should be fine. The order
will be: FETCH, evaluate RHS expression, STORE.
Abigail
| [reply] |
|
|
|
|
Re: Matching and order of evaluation
by BrowserUk (Patriarch) on Oct 27, 2003 at 21:25 UTC
|
Both constructs are safe.
Justification: If it were not so, $x = $x + 1; would also be unsafe.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!
| [reply]
[d/l] |
Re: Matching and order of evaluation
by Beechbone (Friar) on Oct 28, 2003 at 21:51 UTC
|
BTW: Even this is save in Perl:
($a, $b) = ($b, $a)
| [reply]
[d/l] |
|
|
Oh yes, right. Perl even goes to special accomodation to handle that. The issue only really comes up when computing something (like the lookups to find the LHS lvalues, or some component in an expression) is going to affect home something else comes out. The really, really common example is what happens when you run `sub ... { my ($arg, ...) = (shift, shift, shift ... )` or `shift -> ( shift ...`.
| [reply] |