Boolean expressions are evaluated sequentially

[dunbarx]

Has this been discussed before?

I am building a CAD-like drawing program in LC, and as a convenience I made a gadget to allow me to hide graphics if I simply click on them with the optionKey. I want only graphics to hide. So I tested three conditions:

Code: Select all

  if the optionKey is down and the mouseControl <> empty and the name of the mouseControl contains "graphic" 
   then hide the mouseControl  --works fine
   
   --if the optionKey is down and the name of the mouseControl contains "graphic" and the mouseControl <> empty
   --then hide the mouseControl  --fails

In version two the condition "and the mouseControl <> empty" comes third, after the other two, as opposed to second, between the other two, in version one. That version fails with "no target found" if I click on empty card space,

The card object is not a mouseControl, the function returning empty.

I assume this means that each condition is evaluated sequentially, and clicking on empty space throws an error since the test for graphic "fails" before the empty result from the function "fails".

The pecking order matters, even though each condition on its own is identical between the two versions. I do not see a reason for this at all.

Expected behavior?

Craig

[FourthWorld]

Yes, like Python and others LC uses "lazy" evaluation of conditions, where it only evaluates as much as is necessary to determine branching.

One benefit of this is performance; it simply saves time evaluating things that don't make a difference in execution flow.

Another benefit is what you've found in your example: it allows you to order your conditions in ways that might otherwise throw errors even where a later condition is inconsequential.

[SparkOut]

I think this is expected, and desired, as a result of lazy evaluation.
With boolean AND tests, if condition 1 fails to return true then the whole test is going to fail, so there's no point in even bothering to check the other conditions.
It follows that where maximum efficiency is desired, conditions should be evaluated in order of most generic to most specific likelihood to fail. But chances are this is unnoticeable in most situations.

[Edit, near simulposting, in agreement with Richard]

[dunbarx]

Lazy evaluation is one thing, and perfect for someone like me. I figured as much, and mentioned that I recall this being discussed a while ago.

But my main point was not that the logic of my string of booleans was not working the way I intended, but that LC threw an error and halted the handler. I get that my gadget has to be carefully constructed. I do not understand the error.

Craig

[SparkOut]

Ah, so the problem is that an error is thrown by a statement that reduces to

Code: Select all

put the name of ""

when the mouseControl is empty, it has no reference to an object from which to extract the name?

[FourthWorld]

...my main point was not that the logic of my string of booleans was not working the way I intended, but that LC threw an error and halted the handler. I get that my gadget has to be carefully constructed. I do not understand the error.

Sparkout got it.

Breaking it down to psuedocode:

Works:
- Test 1: Does the control exist?
- Test 2: What is the name of the control?

Throws error:
Test 1: What is the name of the control?
Test 2: Does the control exist?

Something that doesn't exist can have no name (unless it's a cowboy gunslinger <g>).

[dunbarx]

Aha,

Thanks. That makes sense.

Craig