Order of evaluation of expressions

Discussion in 'Perl Misc' started by Mark Jason Dominus, Aug 17, 2003.

  1. Is this:

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

    guaranteed to print "ab"?
     
    Mark Jason Dominus, Aug 17, 2003
    #1
    1. Advertising

  2. 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
     
    Rafael Garcia-Suarez, Aug 17, 2003
    #2
    1. Advertising

  3. -----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+cfvYwnHNTFxenN5ktYOAAnjv+
    aJGfREuPkOdtbWxNasYNnWz6
    =oCju
    -----END PGP SIGNATURE-----
     
    Eric J. Roode, Aug 18, 2003
    #3
  4. 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
     
    Michael P. Broida, Aug 18, 2003
    #4
  5. -----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-----
     
    Eric J. Roode, Aug 18, 2003
    #5
  6. -----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-----
     
    Eric J. Roode, Aug 18, 2003
    #6
  7. -----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/AwUBP0E7aWPeouIeTNHoEQIDxgCg37TORAi1xpN9NK1duUrQYO6B8J0Anj/2
    s1cQ1ZvOujiJbOzvRLGU2Bjc
    =QxTG
    -----END PGP SIGNATURE-----
     
    Eric J. Roode, Aug 18, 2003
    #7
  8. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    wrote in
    news::

    > 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-----
     
    Eric J. Roode, Aug 18, 2003
    #8
  9. Mark Jason Dominus

    danglesocket Guest

    Re: Regular Expression Help

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

    if not you can find it on cpan.



    __danglesocket__
     
    danglesocket, Aug 18, 2003
    #9
  10. 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
     
    Michael P. Broida, Aug 18, 2003
    #10
  11. "Eric J. Roode" wrote:
    >
    > "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.


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

    Thanks.
    Mike
     
    Michael P. Broida, Aug 18, 2003
    #11
  12. In article <>,
    <> wrote:
    >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, Aug 18, 2003
    #12
  13. In article <>,
    Abigail <> wrote:
    >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.
     
    Mark Jason Dominus, Aug 18, 2003
    #13
  14. Mark Jason Dominus

    Tony Curtis Guest

    >> On Mon, 18 Aug 2003 21:48:51 GMT,
    >> "Michael P. Broida" <> said:


    > "Eric J. Roode" wrote:
    >> "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.


    > 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
     
    Tony Curtis, Aug 18, 2003
    #14
  15. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Purl Gurl <> wrote in
    news::

    > Eric J. Roode wrote:
    >
    >> Purl Gurl wrote:

    >
    > (context removed by Roode)
    >
    > (topic is Perl following classic mathematical order of evaluation)
    >
    >> > Quite predictable and in keeping with precedence.

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

    >
    >
    > 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, Aug 19, 2003
    #15
  16. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

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

    > "Eric J. Roode" wrote:
    >>
    >> 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.

    >
    > 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;
    </blockquote>

    > (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-----
     
    Eric J. Roode, Aug 19, 2003
    #16
  17. Mark Jason Dominus wrote:
    >
    > In article <>,
    > Abigail <> wrote:
    > >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.


    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
    --
    use Perl;
    program
    fulfillment
     
    John W. Krahn, Aug 19, 2003
    #17
  18. Tony Curtis wrote:
    >
    > >> On Mon, 18 Aug 2003 21:48:51 GMT,
    > >> "Michael P. Broida" <> said:

    >
    > > "Eric J. Roode" wrote:
    > >> "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.

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


    No, that's a decent explanation. Thanks.
    Mike
     
    Michael P. Broida, Aug 19, 2003
    #18
  19. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    "John W. Krahn" <> wrote in
    news::

    > Abigail wrote:
    >>
    >> John W. Krahn () wrote on MMMDCXL September MCMXCIII in
    >> <URL:news:>:
    >> ==
    >> == 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. :)
    >>
    >> Precedence isn't the same as order of evaluation.

    >
    > 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-----
     
    Eric J. Roode, Aug 20, 2003
    #19
  20. Mark Jason Dominus

    Anno Siegel Guest

    Mark Jason Dominus <> wrote in comp.lang.perl.misc:
    > In article <>,
    > Abigail <> wrote:
    > >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.


    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
     
    Anno Siegel, Sep 4, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    4
    Views:
    441
    Marcin Kalicinski
    May 20, 2005
  2. Ilias Lazaridis
    Replies:
    2
    Views:
    407
    Ilias Lazaridis
    Apr 24, 2005
  3. Taras_96
    Replies:
    18
    Views:
    528
    James Kanze
    Dec 18, 2008
  4. Ilias Lazaridis
    Replies:
    74
    Views:
    798
    Ilias Lazaridis
    Apr 4, 2005
  5. Ilias Lazaridis
    Replies:
    18
    Views:
    363
    Bill Guindon
    Apr 9, 2005
Loading...

Share This Page