is evaluation order defined, and evaluation of conditionals

Jerry Jensen jhj at
Tue Jun 26 00:37:59 EDT 2012

Ah, then it must be actualy guaranteed! Thanks!

I'd still try to write it out the long way with "if"s for the sake of the poor reader (probably me later under stress), but thats a matter of personal style I suppose.


On Jun 25, 2012, at 9:25 PM, Mike Bonner wrote:

> Its useful if you have a processor intensive function (say intersect()).
> You can do several bounds checks prior to the intersect, if any of them
> fail the intersect is never done. This was mentioned in the game academy.
> On Mon, Jun 25, 2012 at 10:18 PM, <dunbarx at> wrote:
>> Jerry.
>> Fsscinating example. It seems there is in fact an order to the
>> conditionals, at least as constructed your way. The "false" rendered in the
>> left side seems to (un)satisfy the "and", played out in order. Stepping
>> through shows this clearly.
>> Cool. Is this useful?
>> Crig Newman
>> -----Original Message-----
>> From: Jerry Jensen <jhj at>
>> To: How to use LiveCode <use-livecode at>
>> Sent: Mon, Jun 25, 2012 11:29 pm
>> Subject: Re: is evaluation order defined, and evaluation of conditionals
>> I'm not Richard, but I'm curious too. Here's an example that may point out
>> his
>> issue:
>> In a button script, or somewhere . . .
>> on mouseUp
>>  local tFoo
>>  put func1() and func2() into tFoo
>> end mouseUp
>> function func1
>> return "false"
>> end func1
>> function func2
>>    put "func2 was called"
>>    return "true"
>> end func2
>> In this example, func2() IS NOT called.
>> If func1 returns "true" instead, func2() IS called.
>> This behavior is guaranteed in the C language, but I don't know about
>> guarantees
>> in LiveCode. In C, similarly if "or" is used instead of "and", if the
>> first part
>> evaluates to "true", the second is NOT called. Again, I dunno about
>> LiveCode.
>> Exercise left to the reader (or somebody who knows!)
>> .Jerry

More information about the Use-livecode mailing list