Difference between revisions of "$boolEval"

From Free Pascal wiki
Jump to navigationJump to search
m (Fixed template loop; categorised page)
(substitute legacy syntaxhighlight syntax; update date (2018 → 2020) for statement still being true; typography; link FPC again, as that was removed in previous edit)
Line 1: Line 1:
 
{{LanguageBar}}
 
{{LanguageBar}}
  
The Free Pascal compiler [[local compiler directives|compiler directive]] <syntaxhighlight lang="pascal" enclose="none">{$boolEval}</syntaxhighlight> determines, whether short-circuit evaluation (also known as “lazy evaluation”) of [[Boolean]] expressions is performed.
+
The Free Pascal compiler [[local compiler directives|compiler directive]] <syntaxhighlight lang="pascal" inline>{$boolEval}</syntaxhighlight> determines, whether short-circuit evaluation (also known as “lazy evaluation”) of [[Boolean]] expressions is performed.
  
 
== Explanation ==
 
== Explanation ==
  
 
[[Standard Pascal|Pascal]] defines, that terms of logical expressions are always evaluated from start to finish.
 
[[Standard Pascal|Pascal]] defines, that terms of logical expressions are always evaluated from start to finish.
However, in certain cases of expressions containing [[And|<syntaxhighlight lang="pascal" enclose="none">and</syntaxhighlight>]] or [[Or|<syntaxhighlight lang="pascal" enclose="none">or</syntaxhighlight>]] further evaluation can be skipped, since the final result can be deduced from the intermediate result, thus saving computation time.
+
However, in certain cases of expressions containing [[And|<syntaxhighlight lang="pascal" inline>and</syntaxhighlight>]] or [[Or|<syntaxhighlight lang="pascal" inline>or</syntaxhighlight>]] further evaluation can be skipped, since the final result can be deduced from the intermediate result, thus saving computation time.
This is similar to shell's <syntaxhighlight lang="bash" enclose="none">&&</syntaxhighlight> and <syntaxhighlight lang="bash" enclose="none">||</syntaxhighlight>.
+
This is similar to shell’s <syntaxhighlight lang="bash" inline>&&</syntaxhighlight> and <syntaxhighlight lang="bash" inline>||</syntaxhighlight>.
 
But Pascal consciously decided against such behavior.
 
But Pascal consciously decided against such behavior.
 
Ratio:
 
Ratio:
Expressions can consist of function calls, those returning a <syntaxhighlight lang="pascal" enclose="none">boolean</syntaxhighlight> value, and if their definitions trigger side-effects a short-circuit evaluation could prevent such being executed.
+
Expressions can consist of function calls, those returning a <syntaxhighlight lang="pascal" inline>boolean</syntaxhighlight> value, and if their definitions trigger side-effects a short-circuit evaluation could prevent such being executed.
That is contrary to Pascal's paradigm, that the programmer is not required to know of (implicit) optimizations (that actually change a program's behavior), but what she writes is what is being executed.
+
That is contrary to Pascal’s paradigm, that the programmer is not required to know of (implicit) optimizations (that actually change a program’s behavior), but what she writes is what is being executed.
 
The order one writes terms in is not supposed to matter, since <math>\land</math> and <math>\lor</math> are associative operators, too.
 
The order one writes terms in is not supposed to matter, since <math>\land</math> and <math>\lor</math> are associative operators, too.
  
Line 27: Line 27:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
But this requires the reader to ''know'' <syntaxhighlight lang="pascal" enclose="none">isTired</syntaxhighlight> is possibly not called, if <syntaxhighlight lang="pascal" enclose="none">itIsLate</syntaxhighlight> returned [[false and true|<syntaxhighlight lang="pascal" enclose="none">false</syntaxhighlight>]].
+
But this requires the reader to ''know'' <syntaxhighlight lang="pascal" inline>isTired</syntaxhighlight> is possibly not called, if <syntaxhighlight lang="pascal" inline>itIsLate</syntaxhighlight> returned [[false and true|<syntaxhighlight lang="pascal" inline>false</syntaxhighlight>]].
 
Such implicit “removal” of code, that the order one writes expressions in is relevant, is depreciated by Pascal.
 
Such implicit “removal” of code, that the order one writes expressions in is relevant, is depreciated by Pascal.
 
Instead one writes:
 
Instead one writes:
Line 42: Line 42:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
By default the FPC uses shortcut Boolean evaluation.
+
By default the [[FPC]] uses shortcut Boolean evaluation.
[[Extended Pascal]], which as of 2018 FPC plans to support one day, defines the additional logical operators <syntaxhighlight lang="pascal" enclose="none">and_then</syntaxhighlight> and <syntaxhighlight lang="pascal" enclose="none">or_else</syntaxhighlight> which do exactly this, lazy evaluation, but on the ''explicit'' request of the programmer.
+
[[Extended Pascal]], which as of 2020 FPC plans to support one day, defines the additional logical operators <syntaxhighlight lang="pascal" inline>and_then</syntaxhighlight> and <syntaxhighlight lang="pascal" inline>or_else</syntaxhighlight> which do exactly this, lazy evaluation, but on the ''explicit'' request of the programmer.
  
 
== See also ==
 
== See also ==
  
* [https://www.freepascal.org/docs-html/prog/progsu4.html <syntaxhighlight lang="pascal" enclose="none">{$B}</syntaxhighlight> or <syntaxhighlight lang="pascal" enclose="none">{$boolEval}</syntaxhighlight>: complete Boolean evaluation in “Free Pascal programmer's guide”]
+
* [https://www.freepascal.org/docs-html/prog/progsu4.html <syntaxhighlight lang="pascal" inline>{$B}</syntaxhighlight> or <syntaxhighlight lang="pascal" inline>{$boolEval}</syntaxhighlight>: complete Boolean evaluation in “Free Pascal programmer's guide”]
* {{Doc|package=RTL|unit=math|identifier=ifthen|text=<syntaxhighlight lang="pascal" enclose="none">math.ifThen</syntaxhighlight>}}, the mock ternary operator that always computes both possible results.
+
* {{Doc|package=RTL|unit=math|identifier=ifthen|text=<syntaxhighlight lang="pascal" inline>math.ifThen</syntaxhighlight>}}, the mock ternary operator that always computes both possible results.
  
 
[[Category:Compiler directives]]
 
[[Category:Compiler directives]]

Revision as of 02:11, 19 June 2020

English (en)

The Free Pascal compiler compiler directive {$boolEval} determines, whether short-circuit evaluation (also known as “lazy evaluation”) of Boolean expressions is performed.

Explanation

Pascal defines, that terms of logical expressions are always evaluated from start to finish. However, in certain cases of expressions containing and or or further evaluation can be skipped, since the final result can be deduced from the intermediate result, thus saving computation time. This is similar to shell’s && and ||. But Pascal consciously decided against such behavior. Ratio: Expressions can consist of function calls, those returning a boolean value, and if their definitions trigger side-effects a short-circuit evaluation could prevent such being executed. That is contrary to Pascal’s paradigm, that the programmer is not required to know of (implicit) optimizations (that actually change a program’s behavior), but what she writes is what is being executed. The order one writes terms in is not supposed to matter, since [math]\displaystyle{ \land }[/math] and [math]\displaystyle{ \lor }[/math] are associative operators, too.

The following two examples are semantically identical:

{$push}
{$boolEval off} // enable lazy evaluation
if itIsLate(now) and isTired(me) then
{$pop}
begin
	brushTeeth;
	goToBed;
end;

But this requires the reader to know isTired is possibly not called, if itIsLate returned false. Such implicit “removal” of code, that the order one writes expressions in is relevant, is depreciated by Pascal. Instead one writes:

if itIsLate(now) then
begin
	if isTired(me) then
	begin
		brushTeeth;
		goToBed;
	end;
end;

By default the FPC uses shortcut Boolean evaluation. Extended Pascal, which as of 2020 FPC plans to support one day, defines the additional logical operators and_then and or_else which do exactly this, lazy evaluation, but on the explicit request of the programmer.

See also