[Implemented] Boolean Expressions

[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:

Code: Select all

 
result = Boolean(X > Y) * value 

The expression in parentheses would simply be anything that may succeed the "IF" keyword.

[horst]

Code: Select all

a = 7
b = 5
Debug #False Or (a>b)

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

[Dare2]

Is the "#False or" required for some cases or will this do?

Code: Select all

Macro Is(boolean)
  (boolean)
EndMacro

[horst]

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.

[Dare2]

Okay, that makes sense.

So far I haven't found a case where the macro failed. Pretty useful.

[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...

[Dare2]

Yeah. I also use Not in unsupported ways, so when it all breaks I'm in trouble ...

[horst]

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.

[jear]

I guess (hope), if Fred will change this at all, he will support a boolean function

I think PB should evaluate

Code: Select all

(a > 60)

in the same manner as it evaluates

Code: Select all

If (a > 60) ...

as #True or #False depending of the value of a. That's all.
Now PB is evaluating

Code: Select all

(a > 60)

as 60 disregarding the actual value of a and this is simply "not true".

I would like code

Code: Select all

DisableGadget(#gg, a>60)

instead

Code: Select all

If a > 60
  DisableGadget(#gg, #True)
Else
  DisableGadget(#gg, #False)
EndIf

[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()