in reply to Re^8: next unless condition
in thread next unless condition

Hello RonW,

I’m sorry, but you’re wrong about C:

C also doesn't guarantee order of evaluation
...
Proper evaluation of or doesn't require a particular order for evaluating its operands to get the correct result. This is because or is transitive.

To take the last part first: logical or can’t be transitive, because transitivity applies only to those operators which are also relations, and logical or is not a relation. But suppose it were; and let propositions p, q, r have values false, true, false, respectively. Then p OR q is true, because false OR true is true; and q OR r is also true, because true OR false is true; so, by transitivity, p OR r should also be true. But it isn’t, because false OR false is false.

Now to the important issue. The C standard does guarantee the order of evaluation for logical OR (||):

Unlike the bitwise | operator, the || operator guarantees left-to-right evaluation; if the second operand is evaluated, there is a sequence point between the evaluations of the first and second operands. If the first operand compares unequal to 0, the second operand is not evaluated.1

To the best of my knowledge, this has always been an important feature of C. This is true for logical AND (&&) as well as logical OR. For example, when dealing with pointers it is often necessary to test whether the pointer is null before attempting a dereference:

int *p;
...
if (p && *p > 10)
    ...

[download]

If the order of evaluation of logical AND (&&) were not guaranteed by the C standard (as it is2), the *p operation could be performed on a null pointer before the pointer is checked, causing the program to segfault. This possibility is explicitly excluded by the standard.

1The C11 Standard, document WG14 N1570 (working paper, 2011-04-12), downloaded from here. The behaviour of the logical OR operator is specified in section 6.5.14, paragraph 4.
2Ibid, section 6.5.13, paragraph 4.

Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

Replies are listed 'Best First'.
Re^10: next unless condition
by oiskuu (Hermit) on Apr 06, 2016 at 22:19 UTC

    Quirks and programming. The topic reminded me of an old C book flush with anecdotal wisdom and insight (though old by now: it predates C99). The following note is preserved there: 

    From decvax!harpo!npoiv!alice!research!dmr
Date: Fri Oct 22 01:04:10 1982
Subject: Operator precedence
Newsgroups: net.lang.c

The priorities of && || vs. == etc. came about in the following way.

Early C had no separate operators for & and && or | and ||. (Got that?) Instead it used the notion (inherited from B and BCPL) of "truth-value context": where a Boolean value was expected, after "if" and "while" and so forth, the & and | operators were interpreted as && and || are now; in ordinary expressions, the bitwise interpretations were used. It worked out pretty well, but was hard to explain. (There was the notion of "top-level operators" in a truth-value context.)

The precedence of & and | were as they are now. Primarily at the urging of Alan Snyder, the && and || operators were added. This successfully separated the concepts of bitwise operations and short-circuit Boolean evaluation. However, I had cold feet about the precedence problems. For example, there were lots of programs with things like

	if (a==b & c==d) ...

In retrospect it would have been better to go ahead and change the precedence of & to higher than ==, but it seemed safer just to split & and && without moving & past an existing operator. (After all, we had several hundred kilobytes of source code, and maybe 3 installations....)

Dennis Ritchie

    So, yes, the short-circuiting behavior was part of C from very beginning, even before logical && || were introduced. (And the explanation why bitwise operators have the wrong precedence in C and most other C-like languages.)

[reply]
[d/l]
[select]
      Wow. So Perl wasn't the first to introduce "context"!

      ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,

      [download]
[reply]
[d/l]
        Wow. So Perl wasn't the first to introduce "context"!

        Far from it. Indeed, the "context free language" in reality, is an almost mythological beast. Almost none exist; and (IMO) none of those that do, are useful.

        I'm not enough of an aficionado of language development to assert the absolute origin; but every language that allows you to compare 3.5 < 3 -- and that's most of them -- by auto-promotion of integers to a real, to allow comparisons and numerical operations, is being "context aware".

        Which puts those that decry Perl's context awareness as some kind of aberration and would deem it verboten, whether by best practice or auto-critiquing, firmly in the camp of the "I'm too lazy to understand it, so nobody is allowed to use it" school of thinking. Luckily, most programmers have a mind of their own.

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Seekers of Perl Wisdom