True.
I was thinking only "true"/
-Original Message-
From: Dr. Hawkins
To: How to use LiveCode
Sent: Tue, Jun 26, 2012 12:54 am
Subject: Re: is evaluation order defined, and evaluation of conditionals"and"
to "or
On Monday, June 25, 2012, wrote:
>
&g
On Tue, Jun 26, 2012 at 8:48 AM, Bob Sneidar wrote:
> Foxpro was the same way. I think all modern languages work like that.
Not all--modern Fortran explicitly does not guarantee such things--but
that's part of a design to allow massive optimization for parallelism
--
The Hawkins Law Firm
Richa
Very good point Peter. That could be very useful to know.
Bob
On Jun 26, 2012, at 7:17 AM, Peter M. Brigham wrote:
> It's also useful if you have a general handler that needs to screen out
> certain types of objects, eg:
>
> on mousemove
> if word 1 of the target = "field" and the locktext
Foxpro was the same way. I think all modern languages work like that. It allows
the developer to prioritize statements in the order of least to greatest cost.
For most things no one would notice the difference, but for some operations it
may make a big difference.
Bob
On Jun 25, 2012, at 9:3
learly.
>>
>>
>> Cool. Is this useful?
>>
>>
>> Crig Newman
>>
>>
>>
>> -----Original Message-
>> From: Jerry Jensen
>> To: How to use LiveCode
>> Sent: Mon, Jun 25, 2012 11:29 pm
>> Subject: Re: is evalu
There is a difference between logical and string comparisons.
A logical comparison using 'and/or' will exit as soon as 'false' is
encountered.
A string comparison using '=' (or 'is') or '<>' (or 'is not') will evaluate
both components.
Try func1()= func2() instead.
Hugh Senior
FLCo
> on mouseU
On Monday, June 25, 2012, Jerry Jensen wrote:
> I had that drilled into my alleged mind in the late '60s in a Boolean
> Algebra class I talked my way into. In those days minimization was
> important because each gate cost a few bucks!
Yes, and a 16 pin dip had four 2 input gates. So if you had
I had that drilled into my alleged mind in the late '60s in a Boolean Algebra
class I talked my way into. In those days minimization was important because
each gate cost a few bucks!
It was sort of a geeky joke then that you could actually build any logic net
using nothing but NAND gates.
.Jer
On Monday, June 25, 2012, wrote:
>
>
> "or" is a simpler case, as there is never a need to evaluate after
> a first round "true". Again, at least externally.
>
No, they're not.
OR is "when both inputs are false, output is false (else its true)"
AND is "when both inputs are true, output is true (e
as somehow preocessed internally, with a boolean
decision made at a lower level after
parsing the line as a whole, between two already evaluated terms.
LC just linearly goes along, merrily, almost, doing its thing step by step.
Craig Newman
-Original Message-
From: Dr. Hawkins
To: H
ng
>> through shows this clearly.
>>
>>
>> Cool. Is this useful?
>>
>>
>> Crig Newman
>>
>>
>>
>> -----Original Message-
>> From: Jerry Jensen
>> To: How to use LiveCode
>> Sent: Mon, Jun 25, 2012 11:29 pm
>> Subject:
is useful?
>
>
> Crig Newman
>
>
>
> -Original Message-
> From: Jerry Jensen
> To: How to use LiveCode
> 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
seful?
Crig Newman
-Original Message-
From: Jerry Jensen
To: How to use LiveCode
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
On Monday, June 25, 2012, Jerry Jensen wrote:
>
> 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. Ex
On Monday, June 25, 2012, wrote:
>
> The case specifies a boolean "and". The order is unimportant in this
> example. If either argument is false, the case is ignored. It would not
> matter which was written first. The same would be true for a boolean "or,
> in that the order is not pertinent.
If
"or" is critical, and must be written with care. Usually lots of
> parentheses are required.
>
>
> Order of evaluation is intrinsically important in arithmetic expressions, of
> course.
>
>
>
> Can you restate your problem? Or are you just exploring t
Ahgh Peter, imbibing again? Good on ya mate!
Bob Sneidar
IT Manager
Calvary Chapel CM
Sent from iPhone
On Jun 25, 2012, at 16:40, Peter Haworth wrote:
> If the dead cat does not exist, there will be no check for bad smell.
> Pete
> On Jun 25, 2012 4:17 PM, "Dr. Hawkins" wrote:
>
>> Is the ord
Usually lots of parentheses
are required.
Order of evaluation is intrinsically important in arithmetic expressions, of
course.
Can you restate your problem? Or are you just exploring the language?
Craig Newman
-Original Message-
From: Jerry Jensen
To: How to use LiveCode
Sent: M
Note that exists() is only sensible for objects. From the dictionary:
"You can also specify a chunk of a container, but in this case the exists
function always returns true."
.Jerry
On Jun 25, 2012, at 4:17 PM, Dr. Hawkins wrote:
> Is the order in which expressions will be evaluated defined int
I believe this was discussed in a thread long ago. To my knowledge, logical
expressions are evaluated left to right. Mathematical expressions of course,
follow the order of operations found here:
http://en.wikipedia.org/wiki/Order_of_operations
I will be corrected if I am mistaken.
Bob
On J
If the dead cat does not exist, there will be no check for bad smell.
Pete
On Jun 25, 2012 4:17 PM, "Dr. Hawkins" wrote:
> Is the order in which expressions will be evaluated defined int LiveCode
>
> For example, if I have fields such as live_cats live_dogs and such,
> some but not others of whic
Is the order in which expressions will be evaluated defined int LiveCode
For example, if I have fields such as live_cats live_dogs and such,
some but not others of which have corresponding fields dead_cat,
dead_mouse, etc, can if have a construct that comes to
switch
case exists(dead_cat) and
22 matches
Mail list logo