Order of evaluation of expressions

[Mark Jason Dominus]

Is this:

@s = qw(a b);
$z = shift(@s) . shift(@s);
print $z;

guaranteed to print "ab"?

 

[Rafael Garcia-Suarez]

Mark Jason Dominus wrote in comp.lang.perl.misc :

Is this:

@s = qw(a b);
$z = shift(@s) . shift(@s);
print $z;

guaranteed to print "ab"?

I'm not sure what you're asking for. Guarantee across all perl (5) versions ?
Future, past or present ? Guaranteed by the "language spec" (whatever
this may be) ?

Currently, due to the way the optree is constructed and executed, and
due to the implementation of shift, I'd say that your snippet is
guaranteed to produce "ab". But don't rely on it. I don't think Perl 5
will ever show another behavior, but Ponie might, if the internal
optimizer finds it more convenient to evaluate the right side of concat
first.

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is this:

@s = qw(a b);
$z = shift(@s) . shift(@s);
print $z;

guaranteed to print "ab"?

Yes. Unlike C, Perl's order-of-evaluation is well-defined.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP0AmSWPeouIeTNHoEQKBeQCg+Q49AV+cfvYwnHNTFxenN5ktYOAAnjv+
aJGfREuPkOdtbWxNasYNnWz6
=oCju
-----END PGP SIGNATURE-----

 

[Michael P. Broida]

Eric J. Roode ([email protected]) wrote
~~ (e-mail address removed) (Mark Jason Dominus) wrote in ~~ > Is this:
~~ >
~~ > @s = qw(a b);
~~ > $z = shift(@s) . shift(@s);
~~ > print $z;
~~ >
~~ > guaranteed to print "ab"?
~~ >
~~ Yes. Unlike C, Perl's order-of-evaluation is well-defined.

Where is its order of evaluation documented? Where in the documentation
does it say that:
@a = (3, 4, 5);
$z = shift (@a) + shift (@a) * shift (@a);
print $z;
results in 23 being printed?

Unless I'm missing something in your comment, it seems the question
boils down to "what precedence do subroutine/function calls have?"

I don't see "calls" specifically in the operator precedence listing at
the top of "perldoc perlop", but I think the highest priority "terms"
is what the function calls are in this case. Each function call was
evaluated in order left to right as "terms" of the larger expression,
THEN the multiply was done, THEN the addition was done.

This seems to fit the "perldoc perlop" description.

Mike

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Unless I'm missing something in your comment, it seems the
question boils down to "what precedence do subroutine/function
calls have?"

No, not really. Precedence is different than order of evaluation. In C,
for example, precedence is well-defined, but order of evaluation is
famously undefined.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP0E55WPeouIeTNHoEQKsYACg0X/4yuCnTu7pD7cqw0j6Kid9DQsAoN89
L0ZfvJcELWdN3q4IhNZl8Rfl
=FGbJ
-----END PGP SIGNATURE-----

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric J. Roode ([email protected]) wrote on MMMDCXXXIX
September MCMXCIII in
<URL:~~ -----BEGIN
PGP SIGNED MESSAGE----- ~~ Hash: SHA1
~~
~~ (e-mail address removed) (Mark Jason Dominus) wrote in
~~
~~ > Is this:
~~ >
~~ > @s = qw(a b);
~~ > $z = shift(@s) . shift(@s);
~~ > print $z;
~~ >
~~ > guaranteed to print "ab"?
~~ >
~~
~~ Yes. Unlike C, Perl's order-of-evaluation is well-defined.


Where is its order of evaluation documented? Where in the
documentation does it say that:

@a = (3, 4, 5);
$z = shift (@a) + shift (@a) * shift (@a);
print $z;

results in 23 being printed?

Well, I don't know. I could have sworn that I either read it in some
authoritative place, or I heard some authority state it. But searching
through the docs, and searching online, I can't find anything to back up
my statement. I withdraw it.

Thanks for your nice warm fuzzy tone, Abigail.

I also should have noticed who was posing the question. MJD knows much
more about Perl, especially its internals, than I do. If I had noticed
that he was the one who had asked the question, I wouldn't have responded
with my quick, unresearched answer; MJD certainly has as many or more
resources and history of Perl knowledge as myself.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP0E7HWPeouIeTNHoEQJ7hACeNY/pVLoGaPyX5PTTrlD0fymLMlwAoIsL
KIJXOu+HZbq2hmjlHs5PL2js
=UYis
-----END PGP SIGNATURE-----

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quite predictable and in keeping with precedence.

True, but a couple of quick examples does not prove that Perl's precedence
is well-defined.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP0E7aWPeouIeTNHoEQIDxgCg37TORAi1xpN9NK1duUrQYO6B8J0Anj/2
s1cQ1ZvOujiJbOzvRLGU2Bjc
=QxTG
-----END PGP SIGNATURE-----

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(e-mail address removed) wrote in

I'd like to see the "language spec" (whatever that may be) make a
statement one way or the other.

Making it defined will reduce the scope for optomisations in Ponie.

Making it undefied will break a lot of existing code.

Not an easy choice.

In my humble opinion, as a long-time C and Perl programmer, the language
ought to specify order of evaluation. Imho, it is one of C's great
weaknesses and sources of confusion that it does not define the OOE. This
is a huge confusion for many new programmers, and a continually recurring
theme on comp.lang.c (at least, it had been for years when I stopped
reading c.l.c a couple years ago).

If Perl does not currently guarantee OOE, I would vote that it should. The
potential gain in local platform-dependent optimization is not worth the
non-portability and confusion. My two cents.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP0E8RGPeouIeTNHoEQKGvQCfb09TbFi7fGlIen1zJpfHVYvl61AAoIsu
fop/Vi2oQzOCniaux9OIwpk8
=p2Pn
-----END PGP SIGNATURE-----

 

[danglesocket]

there are many great modules for parsing html, just in case your not aware
and work with a lot of html
One of the 'quick and eas(ier)' ones' is HTML::TokeParser.
it may be one your system.
try:

perldoc HTML::TokeParser
or:
man HTML::TokeParser
or
perldoc HTML:arser

if not you can find it on cpan.



__danglesocket__

 

[Michael P. Broida]

Michael P. Broida wrote:


Are you being nice to compensate for your first article
directed at me, being a troll article?

No,
1) it wasn't a troll article; you never did
understand the point of my post,
2) it was a genuine compliment for saving me the
time trying to come up with an illustration
of a sufficiently complex precedence case,
3) haven't you ever received enough compliments to
gracefully accept them?

Should you listen to Aunt Sally, as many here need to,
you will discover math is very intuitive.
Some of us learned Aunt Sally's math lessons as children.

Without ever hearing of "Aunt Sally", I discovered that
basic math is intuitive 40 years ago; then I proceeded
to get my degrees in Mathematics and Computer Science.
In the course of that, I found that there is a LOT of
"higher" math that is not AT ALL intuitive. Rings, fields,
the "math of math", etc, take quite a bit of brain-twisting
to get to the right viewpoint to understand them.

However, computer language operator precedence is not ALWAYS
the same as mathematical operator precedence. (Many of the
computer language operators don't even exist in mathematics.)
SOME older languages didn't have such things as operator
precedence; it was all "left-to-right", when they allowed
more than one operation in a single statement.

Also, (in case you hadn't noticed) computer expressions don't
make valid mathematical equations. "a = a+1" is invalid math
(at least in the basic sense) yet works quite nicely in many
(most?) computer languages.

Annoys me to read those arguing precedence order needs to
be defined.

I wasn't arguing that at all. Read my post. The first
thing I did was go to "perldoc perlop" and see the
precedence order description right at the top. Looks
to me like it's defined very well.

If Perl's order of precedence was not well defined, intuitively,
this topic would have come up, many years back.

Yet this topic HAS come up, over and over again, as new
people try to use Perl (or any other language that they
don't take the time to "learn" from the bottom up).

Mike

 

[Michael P. Broida]

No, not really. Precedence is different than order of evaluation. In C,
for example, precedence is well-defined, but order of evaluation is
famously undefined.

Ah, I -think- I see what you're saying. Maybe. <grin>

Thanks.
Mike

 

[Mark Jason Dominus]

I suspect that MJD is asking precisely to bring to the fore the fact
that the "language spec" (whatever that may be) currently doesn't
comment one way or the other.

Actually, I was asking because I thought I remembered that it did, or
else that the consensus on P5P was that it was an undocumented
guaranteed feature, or else that Larry had said something along those
lines, but I couldn't remember which, if any, of those things were real.

 

[Mark Jason Dominus]

Where is its order of evaluation documented? Where in the documentation
does it say that:

Yes, that's what I would like to know.
Or, if it doesn't say that, I would like to know that it doesn't.

Does anyone have any actual facts?

I wasn't able to find anything about it in the manuals, but the
manuals are pretty badly organized on basic matters like this, so I'm
not sure I was looking in the right places.

 

[Tony Curtis]

Ah, I -think- I see what you're saying. Maybe.
<grin>

Precedence tells you how to construct the syntax tree for
e.g.

a + b * c

+
a * a + (b * c)
b c

as opposed to

*
+ c (a + b) * c
a b

Order of evaluation OTOH tells you in e.g. from the 2nd
interpretation:

a + b

whether "a" or "b" will be evaluated first (e.g. "a" may
contain a side-effect that touches "b") which is partly a
tree-walking consideration. We still know that (a + b)
will be evaluated in toto before the multiplication.

(Probably hideously over-simplified, compiler-writers take
pity on me

hth
t

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(context removed by Roode)

(topic is Perl following classic mathematical order of evaluation)




Your comment infers you know of code which proves
Perl's precedence order is not defined.

Pardon me, I mis-spoke. Perl's operator precedence is well-defined and
well-documented. I apologize.

However, that does not mean that Perl's order of evaluation is well-
defined. The examples you posted are consistent with the assumption that
Perl's order of evaluation parallels its operator precedence and
associativity, but they are but two examples. Perhaps there is a counter
example which shows that in some circumstances Perl's evaluation happens
in a different order. That is what I meant.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP0F6dmPeouIeTNHoEQKgQACfZqacadZnzaxMNOCJwwPps/KydNsAoIRM
fJ8LxWR0h2TREToTthL7XCcg
=ikWD
-----END PGP SIGNATURE-----

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I always found that just breaking complex expressions down into
simpler expressions will guarantee the order you desire. Yes,
it makes for longer, more wordy, programs, but it will do EXACTLY
what you told it to do, without worrying about the language.

That's NOT to say that the language shouldn't specify and
guarantee some specific order. It's just that you can avoid
any potential ordering problems by making it explicit in the
extreme:
$a = $b + $c;
$a = $a * $z;
$a = $a - $x;

- From Harbison & Steele, 4ed, p 227:

<blockquote>
To control the order of evaluation, the programmer can
use assignments to temporary variables. However, a good
optimizing compiler might even rearrange computations
such as this:

int temp1, temp2;
...
/* Compute q=(a+b)+(c+d), exactly that way. */
temp1 = a+b;
temp2 = c+d;
q = temp1 + temp2;

(For something THAT simple, I would keep it one line and use
parens to force the order I want, even if it matches the
language. The difference in the compile step is negligible.)

Once again, in a language such as C in which order of evaluation is not
defined, parentheses do *not* affect order of evaluation! They affect
precedence only.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP0F7xGPeouIeTNHoEQKcsACgolRH5jZ54iYhdfh4gDLP6oHeDhwAnRVn
ckrsHx6MAAFEtV3k3fQ6BH55
=nkWs
-----END PGP SIGNATURE-----

 

[John W. Krahn]

Yes, that's what I would like to know.
Or, if it doesn't say that, I would like to know that it doesn't.

Does anyone have any actual facts?

I wasn't able to find anything about it in the manuals, but the
manuals are pretty badly organized on basic matters like this, so I'm
not sure I was looking in the right places.

Just going by perlop.pod, shift() is a named unary operator which has
lower precedence than . and . is left associative which would mean it
would evaluate the left side first. Correct me if I'm wrong.


John

 

[Michael P. Broida]

Precedence tells you how to construct the syntax tree for
e.g.

a + b * c

+
a * a + (b * c)
b c

as opposed to

*
+ c (a + b) * c
a b

Order of evaluation OTOH tells you in e.g. from the 2nd
interpretation:

a + b

whether "a" or "b" will be evaluated first (e.g. "a" may
contain a side-effect that touches "b") which is partly a
tree-walking consideration. We still know that (a + b)
will be evaluated in toto before the multiplication.

(Probably hideously over-simplified, compiler-writers take
pity on me

No, that's a decent explanation. Thanks.
Mike

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes I know. What I was trying to say is that the concatenation
operator is left associative so that:

shift(@a) . shift(@b) . shift(@c) . shift(@d)

will be always be evaluated as:

( ( shift(@a) . shift(@b) ) . shift(@c) ) . shift(@d)

Parentheses don't control order of evaluation. Associativity is more
related to precedence than to order of evaluation.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP0LX+2PeouIeTNHoEQLCngCg8JhjLtdgN8+m/TZx4YmG3nyVW/4AniIa
Ei0TcxPoCAipEY6BQF5wmt1O
=DvP3
-----END PGP SIGNATURE-----

 

[Anno Siegel]

Yes, that's what I would like to know.
Or, if it doesn't say that, I would like to know that it doesn't.

Does anyone have any actual facts?

I wasn't able to find anything about it in the manuals, but the
manuals are pretty badly organized on basic matters like this, so I'm
not sure I was looking in the right places.

Like you, I was never able to find a general commitment in the docs.
While Perl documentation is huge, and a moving target, I think it's
safe to say that it is silent about the point. I mean, *someone*
would have found it by now

Only some (few) operators are described individually as having left-right
evaluation order. Some that come to mind are the short-circuiting boolean
operators, the list- and comma operators (both ","), and (I think)
assignment ("="), though I'm not entirely sure of the latter.

The most consequential conclusion can probably be drawn from the
list operator: it guarantees that function arguments are evaluated
in order.

I know I'm following up late, but I thought I'd add my two cents.

Anno