Editing Short-circuit evaluation (section)

{{Short description|Programming language construct}}
{{Distinguish|Short-circuit test}}
{{More citations needed|date=August 2013}}
{{Evaluation strategy}}
'''Short-circuit evaluation''', '''minimal evaluation''', or '''McCarthy evaluation''' (after [[John McCarthy (computer scientist)|John McCarthy]]) is the semantics of some [[Logical connective|Boolean operators]] in some [[programming language]]s in which the second argument is executed or evaluated only if the first argument does not suffice to determine the value of the expression: when the first argument of the <code>AND</code> function evaluates to <code>false</code>, the overall value must be <code>false</code>; and when the first argument of the <code>OR</code> function evaluates to <code>true</code>, the overall value must be <code>true</code>.

In programming languages with [[lazy evaluation]] ([[Lisp (programming language)|Lisp]], [[Perl]], [[Haskell]]), the usual [[Boolean expression|Boolean operators]] short-circuit. In others ([[Ada (programming language)|Ada]], [[Java (programming language)|Java]], [[Delphi (software)|Delphi]]), both short-circuit and standard Boolean operators are available. For some Boolean operations, like ''[[exclusive or]]'' (XOR), it is impossible to short-circuit, because both operands are always needed to determine a result.

Short-circuit operators are, in effect, [[control structure]]s rather than simple arithmetic operators, as they are not [[Strict function|strict]]. In [[imperative language]] terms (notably [[C (programming language)|C]] and [[C++]]), where side effects are important, short-circuit operators introduce a [[sequence point]]: they completely evaluate the first argument, including any [[Side effect (computer science)|side effects]], before (optionally) processing the second argument. [[ALGOL 68]] used ''proceduring'' to achieve ''user-defined'' short-circuit operators and procedures.

The use of short-circuit operators has been criticized as problematic:
{{Quote 
|text = The conditional connectives — "<u>cand</u>" and "<u>cor</u>" for short — are ... less innocent than they might seem at first sight. For instance, <u>cor</u> does not distribute over <u>cand</u>: compare
:(A <u>cand</u> B) <u>cor</u> C ''with'' (A <u>cor</u> C) <u>cand</u> (B <u>cor</u> C);
in the case ¬A ∧ C , the second expression requires B to be defined, the first one does not. Because the conditional connectives thus complicate the formal reasoning about programs, they are better avoided.
|author = [[Edsger W. Dijkstra]]<ref>[[Edsger W. Dijkstra]] "On a somewhat disappointing correspondence", EWD1009-0, 25 May 1987 [http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1009.PDF full text]</ref>}}