«

Is this:

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

guaranteed to print "ab"?

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.

--
Uniformity is not *NIX

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

(Mark Jason Dominus) wrote in news:bhok6j$70f$:

> 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+cfvYwnHNTFxenN5 ktYOAAnjv+
aJGfREuPkOdtbWxNasYNnWz6
=oCju
-----END PGP SIGNATURE-----

Abigail wrote:
>
> Eric J. Roode () wrote
> ~~ (Mark Jason Dominus) wrote in news:bhok6j$70f$:
> ~~ > 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

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

"Michael P. Broida" <> wrote in
news::

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

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

Abigail <> wrote in
news::

> Eric J. Roode () wrote on MMMDCXXXIX
> September MCMXCIII in
> <URL:news:Xns93DAD6841E7E9sdn.comcast@206.127.4.25 >: ~~ -----BEGIN
> PGP SIGNED MESSAGE----- ~~ Hash: SHA1
> ~~
> ~~ (Mark Jason Dominus) wrote in
> news:bhok6j$70f$: ~~
> ~~ > 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-----

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

Purl Gurl <> wrote in news:3F408AF4.64C88572
@purlgurl.net:

>
> 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/AwUBP0E7aWPeouIeTNHoEQIDxgCg37TORAi1xpN9NK1duUrQYO 6B8J0Anj/2
s1cQ1ZvOujiJbOzvRLGU2Bjc
=QxTG
-----END PGP SIGNATURE-----

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

wrote in
news: om:

> 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/AwUBP0E8RGPeouIeTNHoEQKGvQCfb09TbFi7fGlIen1zJpfHVY vl61AAoIsu
fop/Vi2oQzOCniaux9OIwpk8
=p2Pn
-----END PGP SIGNATURE-----

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__

Purl Gurl wrote:
>
> Michael P. Broida wrote:
>
<snipped>
>
> > Good example. I was trying to come up with something
> > to show a non-intuitive precedence, but you got it.
>
> 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