If I have 2 or more conditions, does evaluation is done for all or only (like in C) until result is known (first false ends ANDs evaluation or first true ends ORs evaluation)?
The double chevron at that point of an IF action gives you the choice:
OR
AND
NOT OR
NOT AND
I'm not sure if CP answered your question or not, but here's a quote directly from the Architect about your question:
In Keyboard Maestro’s case, all conditions are evaluated asynchronously, simultaneously. Any condition that returns true for an “any” or false for an “all” condition will result in the condition completing with a result.
You can find that quote here:
He speaks further on this topic in that message, so you might want to read the whole thing.
2 Likes
My question is about evaluation - in C lang if one evaluation gives result (for example for OR gives TRUE), the next evaluations are not executed. It is important if I will do some scripts and that scripts will modify environment. If some script will not execute (because the previous gave result tru), their modification will be net observed (because that next script was never executed).
That is also important in performance - if I could check one condition and the result give me an answer, so I do't have to do next condition, which is much more complicated and take more time and resources).
Example - the page in wiki is open for modification when:
- URL is finished by do=edit -easy check with KM
- the page has element with specified Id - I have to execute JavaScript macro, which costs much more
Thanks - I've send my previous post in the same time when you sent your answer 
1 Like
Then the answer is "Yes and no" 
Peter tells us (links above) -- and he should know! -- that the condition completes as soon as overall "truthiness" is determined. He also states that all conditions are evaluated simultaneously.
The first is easy enough to show. This:
...puts up the "Display Text" almost instantly -- it doesn't wait for the "10 second delay" AppleScript to complete. Set the first calculation to 0 and you get the expected delay.
So yes -- conditional evaluation short-circuits. (Sort of -- see below...)
More interesting is what happens to the outstanding evaluations once truthiness is determined -- do they continue, or are they killed? Using Activity Monitor to check, this test pegs my "Keyboard Maestro Engine" CPU usage at ~6% for as long as it takes for AS to count to a million:
...but if we change the calculation to 1 so the condition short-circuits, CPU usage spikes to ~6% for less than a second and is then back to baseline. So we can conclude that the AS gets killed, rather than running to completion.
Reverse the order of the Conditions that the script test is first and the calculation second and the behaviour remains the same. So it looks like the actual order of your conditions doesn't matter (Peter's "all conditions are evaluated asynchronously, simultaneously").
More than that, in fact -- you must not rely on their order. Consider the following, where the first Condition takes time to evaluate and the second throws a dialog as a proxy for "something":
Assuming you've enough folders on your Desktop, the second Condition can take its action before the first completes. So don't include something that makes changes as part of your Condition on the assumption that they won't happen if earlier Conditions can determine overall truthiness.
The "Sort of... see below" bit:
In testing I found that whether an AS-based Condition was immediately cancelled by a short-circuit very much depended on what the script was doing. If the script was doing "core" AS, like simple maths, it was cancelled instantly. But a tell block, like asking the Finder to list a directory's contents, had to complete before the script could be cancelled. That behaviour is the same when cancelling execution in Script Editor, so shouldn't have been a surprise.
So while the evaluation of a Condition may cause a short-circuit, that isn't guaranteed to immediately halt the evaluation of other Conditions. Caveat scripter, and all that...
1 Like
Some of your posts, Nige, should be copied straight to the wiki. Like this one.
Nah -- the Wiki's for the truth! The above is merely confidently-stated speculation...
So based on your description and experiments the conclusion is - never run condition evaluation parts (scripts) inside If_Action - always evaluate before and set result to the local variable. Especially if scripts have side effects or use the same resources.
BTW you encourage me to check behavior of KM engine using instrumentation. Does evaluationsworks always as new processes or maybe as threads - sorry this is my programmer’s curiosity.
You generally don't need to be that prescriptive. The vast majority of your Conditions will work just fine -- it's only weird edge cases you want to watch out for, those that potentially make changes rather than just test current state.
I think it would be very rare that a script Condition made a meaningful change -- mine above is a completely made up example -- and IMO it would be bad practice if it did. Separate checks and changes and your macro's logic will be much clearer when you go to edit it later.
If you evaluate before the "If" you'll always have to do the evaluation, losing any benefit of a possible short-circuit.
With modern hardware it generally makes little difference how you do it -- and I, for one, probably spend more time worrying about optimising than I'll ever get back through those optimisations! And when it does make a difference it'll be pretty obvious.