Complete Boolean Evaluation

[dummzeuch 1505]

Has anybody ever enabled Complete Boolean Evaluation, and if yes, why?

(see associated poll)

 

Here is a use case (but I still would not do it this way but simply switch the conditions):

 

 

Edited February 11, 2019 by dummzeuch

[Rudy Velthuis 91]

1 hour ago, dummzeuch said:

Has anybody ever enabled Complete Boolean Evaluation, and if yes, why?

(see associated poll)

 

Here is a use case (but I still would not do it this way but simply switch the conditions):

 

 

I can't see the full context of the case, but say you have:

Result := condition1;
...
Result := (functionCall1(x) or functionCall2(y)) and Result;

In the above case, you may want to have both functions called, even if functionCall1(x) already returns True (or another function call returns False in a subexpression with and).

 

But even then, you can call the functions separately, put their results in variables and then combine the results later on. You may need one or more extra Boolean variables for the functoin results and a few lines more, but the code flow will be clearer. So complete Boolean evaluation is never really a necessity. Other languages manage without it too.

 

And of course you can do:

Result := condition1;
...
Result := functionCall1(x) or Result;
Result := functionCall2(y) and Result;

But finding out whether you should use or or and in the two lines above is a bit hairy, IMO, and can be done wrong (I am still not sure I did it correctly, to get the result I expect). I'd prefer separate functon result variables.

Edited February 11, 2019 by Rudy Velthuis

[Ugochukwu Mmaduekwe 42]

because I was been too meticulous.

[Uwe Raabe 2057]

1 hour ago, dummzeuch said:

Has anybody ever enabled Complete Boolean Evaluation, and if yes, why?

The more subtle cases are when code requires to switch that off to work properly and someone compiles with that switch on:

if (something <> nil) and (something.someinstanceaccess) then 

 

[Rudy Velthuis 91]

2 minutes ago, Uwe Raabe said:

The more subtle cases are when code requires to switch that off to work properly and someone compiles with that switch on:

if (something <> nil) and (something.someinstanceaccess) then 

 

Ah, indeed. A construct I use quite often. With complete boolean eval that could crash. But you can avoid such problems:

if something <> nil then
begin
  if something.someinstanceaccess then
    ...

 

Edited February 11, 2019 by Rudy Velthuis

[Mahdi Safsafi 225]

I believe that complete expression evaluation was made for lazy people ! The only useful scenario is that your condition contains a function call that must run on all situations.

Otherwise it's just useless:

Result := Variable and (Variable2 = 5) and Variable3; // completely useless ! additional CPU-time for nothing !
Result := Variable and OtherWork();  // maybe useful. 

It's important to mention that many programming language do not support full expression evaluation and some of them provide logical operators (such && and ||) and name long-circuit (complete expression evaluation) as a flow control (they use 'and', 'or' keyword). Here is an example:

exists($filename) and doWork() or error("Could not open file filename"); // parsed as (exists($filename) and doWork()) or error("Could not open file filename");
exists($filename) and doWork() || error("Could not open file filename"); // parsed as exists($filename) and (doWork() || error("Could not open file filename"));

 

[Rudy Velthuis 91]

11 minutes ago, Mahdi Safsafi said:

I believe that complete expression evaluation was made for lazy people ! The only useful scenario is that your condition contains a function call that must run on all situations.

Otherwise it's just useless:

Result := Variable and (Variable2 = 5) and Variable3; // completely useless ! additional CPU-time for nothing !
Result := Variable and OtherWork();  // maybe useful. 

It's important to mention that many programming language do not support full expression evaluation and some of them provide logical operators (such && and ||) and name long-circuit (complete expression evaluation) as a flow control (they use 'and', 'or' keyword). Here is an example:

exists($filename) and doWork() or error("Could not open file filename"); // parsed as (exists($filename) and doWork()) or error("Could not open file filename");
exists($filename) and doWork() || error("Could not open file filename"); // parsed as exists($filename) and (doWork() || error("Could not open file filename"));

 

I am not so sure. If I remember correctly, in the very olden days, it was the only option (TP3 or some such -- memories about those days have become a little vague). Short-circuit boolean evaluation came later.

 

Also: https://www.gnu-pascal.de/gpc/and.html:

Quote

However, since it seems to be a de-facto standard among ISO Pascal compilers to evaluate both operands of and

For such cases, GNU Pascal even knows the and then construct, to force short-circuit evaluation.

Edited February 11, 2019 by Rudy Velthuis

[Mahdi Safsafi 225]

Quote

Short-circuit boolean evaluation came later.

Oh I didn't notice that (I thought that long-circuit is a part of Delphi and not the ISO).

[Der schöne Günther 316]

I am working on a legacy project which has it enabled. I did not dare to disable it, so all new units get a compiler directive to switch full bool eval off while you have to be extra careful and always keep in mind that full boolean eval is enabled when editing "old" units.

 

Reason? I suppose there was none and "full Boolean evaluation" sounded better than "mediocre Boolean evaluation"

[David Heffernan 2345]

23 hours ago, Rudy Velthuis said:

A construct I use quite often.

So I guess you are happy to rely on the left to right order ......

[Rudy Velthuis 91]

16 minutes ago, David Heffernan said:

So I guess you are happy to rely on the left to right order ......

Wow, that was important for you, I guess.

 

Yes, I am happy to use it. I just use it, and if it doesn't work, I find out soon enough.

 

Just like I always forget the order of directives like virtual, stdcall, static, inline, overload, etc., so I just try out an order and find out if it is wrong. <g>

[Rudy Velthuis 91]

18 hours ago, Der schöne Günther said:

I am working on a legacy project which has it enabled. I did not dare to disable it, so all new units get a compiler directive to switch full bool eval off while you have to be extra careful and always keep in mind that full boolean eval is enabled when editing "old" units.

 

Reason? I suppose there was none and "full Boolean evaluation" sounded better than "mediocre Boolean evaluation"

Not necessarily mediocre, but short-circuit might sound like something went wrong. <g>

Edited February 12, 2019 by Rudy Velthuis