Page 3 of 3
Posted: Fri Apr 14, 2006 7:45 am
by horst
It seems to me that the issue of boolean expressions is all about
Mixing boolean and arithmetic expressions. But mixing is absolutely unnecessary (although supported in other language flavours). To me that is a typical case of something that has been done, just because it could be done.
I understand that it is difficult to untangle a mixture of arithmetic and boolean expressions.
A boolean function, however, would do the job, and would be easy to implement. Example:
The expression in parentheses would simply be anything that may succeed the "IF" keyword.
Re: Boolean Expressions
Posted: Sat Apr 15, 2006 3:46 am
by horst
I just discovered your solution.
Will this work?
Code: Select all
Macro Is(boolean)
(#False Or (boolean))
EndMacro
Debug Is(12 < 13) * 22
Debug 5* Is(100 = 99+3 Or 7 > 4)
Debug Is(x) * 9
*edited: another pair of parentheses added
Posted: Sat Apr 15, 2006 4:06 am
by Dare2
Is the "#False or" required for some cases or will this do?
Code: Select all
Macro Is(boolean)
(boolean)
EndMacro
Posted: Sat Apr 15, 2006 8:33 am
by horst
Dare2 wrote:
Is the "#False or" required for some cases ...
Actually, this work-around is based on the fact that Fred takes an expression as boolean, as soon as the boolean operators AND,OR, NOT are used in the expression. (At least that's how it seems to be). Examples:
Code: Select all
Debug (12 = 22 Or 5 > 3) * 22
Debug (100 = 99+1 Or d > 8) *5
Simple comparisons (conditions) do not evaluate to #true or #false.
To trick Fred to accept a statement like (A > B) as boolean, we have to "decorate" it with a boolean operator, e.g.: #false or (A > B), which is done by the IS() macro.
Posted: Sat Apr 15, 2006 8:41 am
by Dare2
Okay, that makes sense.
So far I haven't found a case where the macro failed. Pretty useful.
Posted: Sat Apr 15, 2006 9:04 am
by blueznl
and pretty dangerous, as fred has stated this is not supported, so it may be broken at any time in the future...
good bug hunting...
Posted: Sat Apr 15, 2006 9:33 am
by Dare2
Yeah. I also use Not in unsupported ways, so when it all breaks I'm in trouble ...

Posted: Sat Apr 15, 2006 9:50 am
by horst
blueznl wrote:and pretty dangerous, as fred has stated this is not supported, so it may be broken at any time in the future...
I guess (hope), if Fred will change this at all, he will support a boolean function, like IS(BooleanExpression). This would be a clean solution, and should not be complicated, because the complete evaluation procedure exists already.
Posted: Sat Apr 15, 2006 12:43 pm
by jear
I guess (hope), if Fred will change this at all, he will support a boolean function
I think PB should evaluate
in the same manner as it evaluates
as #True or #False depending of the value of a. That's all.
Now PB is evaluating
as
60 disregarding the actual value of a and this is simply "not true".
I would like code
instead
Code: Select all
If a > 60
DisableGadget(#gg, #True)
Else
DisableGadget(#gg, #False)
EndIf
Posted: Sat May 06, 2006 12:39 pm
by dmoc
Hmmm, bummer, just hit this one as well. Tried the following and though it works in isolation it fails in the DisableGadget()...
Code: Select all
Procedure b2i(e.l)
If e: ProcedureReturn 1: EndIf
ProcedureReturn 0
EndProcedure
...
DisableGadget(#myGadget, b2i(anum <> 0))
...
Edit: Yet it works in SetGadgetState()