ternary if or iif

[Kale]

While I understand your sentiment, OOP isn't really going to help! It's not supposed to be easy on your eyes, it's supposed to be fast!

There is so much wrong with the above statement that i realise your brain is 'mentally mutilated beyond hope of regeneration' so i'm going to bow out now and say no more.

[idle]

Code: Select all

Procedure.s IIFEvals(expr,*y,*n)
If expr
   ProcedureReturn PeekS(*y)
Else
   ProcedureReturn PeekS(*n)
EndIf
EndProcedure

Procedure.i IIFEvali(expr,y,n)
If expr
  ProcedureReturn y
Else
  ProcedureReturn n
EndIf
EndProcedure

Procedure.f IIFEvalf(expr,y.f,n.f)
If expr
  ProcedureReturn y
Else
  ProcedureReturn n
EndIf
EndProcedure

Procedure.d IIFEvald(expr,y.d,n.d)
If expr
  ProcedureReturn y
Else
  ProcedureReturn n
EndIf
EndProcedure

Procedure.q IIFEvalq(expr,y.q,n.q)
If expr
  ProcedureReturn y
Else
  ProcedureReturn n
EndIf
EndProcedure

Macro IIFI(expr,y,n)
IIFEvali((Not(expr)),n,y)
EndMacro

Macro IIFF(expr,y,n)
IIFEvalf((Not(expr)),n,y)
EndMacro

Macro IIFD(expr,y,n)
IIFEvald((Not(expr)),n,y)
EndMacro

Macro IIFQ(expr,y,n)
IIFEvalf((Not(expr)),n,y)
EndMacro

Macro IIFS(expr,y,n)
IIFEvals((Not(expr)),n,y)
EndMacro

Macro IIFfn(expr,a,b)
If expr : a : Else : b : EndIf 
EndMacro 

;================================

Procedure p1(a.s)
   MessageRequester("P1",a)
EndProcedure
Procedure p2(a.s)
 result =  MessageRequester("P2",a,#PB_MessageRequester_YesNo)
 If result = #PB_MessageRequester_Yes
   ProcedureReturn 1 
 Else 
   ProcedureReturn 0
 EndIf      
EndProcedure

a=5
b=4
c=2
d=3
e.f = 5.6
f.f = 5.5
                            
Debug IIFS(5.4 = 5.4,@"yes",@"no") ;string return 
                  
Debug IIFI(a > b,200,100) ;Integer return  
         
Debug IIFF(e > f,200.1234567,100.1234567) ;float return 
        
Debug IIFD(5.5 = 5.6,200.123456789012345,10.123456789012345) ;Double return 
        
Debug IIFQ(a > c,$FFFFFFFFF,$EEEEEEEE) ;quad return 

;function call a regular macro with no return    
IIFfn(a>b And c>d,p1("true"),p1("false"))

; iif as a parameter in a function expecting a string calling a function with the result from the input 
p1(iifs(p2("Click Yes or No"),@"You clicked Yes",@"You clicked No"))

;iif getting the result of a function 
If CreateFile(0, "MacroTest.txt")
CloseFile(0)
Debug "Delete File : " + IIFs(DeleteFile("MacroTest.txt"),@"Yes",@"No")
EndIf

[mesozorn]

As one of the other original proponents of IIF in PB, I will point out that it doesn't really make any difference whatsoever how easy to read the source procedures and macros are (and by the way, they're easy). What matters is that to actually use/call the function, it's as simple and legible as:

Code: Select all

IIFs(5.5>5.4,"yes","no")

The code behind things is always complex-looking if you aren't the one who wrote it. Also I will point out in regard to this statement:

I'm sorry to disturb here, but Fred already announced a Boolean() directive for a future version.since that would change things completely, asking for some IIF with those examples seems a bit aside the roadmap...

The new/upcoming Boolean() function will only help with the evaluation component of the IIF functionality. It would still be necessary to call a separate procedure in order to return one of the two result-values such as "yes" or "no", currently used in the IIF example. Boolean() will presumably only return a 1 or 0, not user-specified result values. Also again, the reason an IIF function is desirable over the regular IF:ELSE:ENDIF is that the former can be used as a parameter in another procedure or statement, whereas the latter cannot.

[Kaeru Gaman]

sure, but after all, it's still not BASIC. (and it looks awful)

and if this

Code: Select all

OutPut( #Channel, "The answer is " + IIFs( value > 5.4 ,"yes" ,"no" ) )

is faster than this

Code: Select all

Out$ = "The answer is "
If 
  Out$ + "yes"
Else
  Out$ + "no"
EndIf
OutPut( #Channel, Out$ )

I dare to doubt.

and no, it doesn't occupy more memory, you just define the Dummy yourself.
the other function also has to store the string somewhere.

an IIF function is simply not necessary, it's just glitter.
there are tons of things on the todo list still missing for full functionality of the present libraries.

[mesozorn]

sure, but after all, it's still not BASIC.

It's definitely BASIC, since it was and is part of Microsoft Visual Basic which is, despite whatever dislike anyone might have for it, still THE most well-known number-one widespread mainstream version of the BASIC programming language on planet Earth. Other versions like PB may have surpassed it in many ways now, but it remains the standard against which everything else is compared. So if VB has it, it's BASIC.

(and it looks awful)

Totally a matter of opinion. I don't see what looks awful about IIFs( value > 5.4 ,"yes" ,"no" ). To me that looks exactly like any other standard basic statement/function one would ever encounter anywhere.

an IIF function is simply not necessary, it's just glitter.

Nothing is necessary. Programming languages aren't necessary, computers aren't necessary, technology isn't necessary. All these things have been brought into existence because they make life easier, not because they are inherently necessary. Why are we all even coding in a great language like PB when we could just be using lower level ASM? Could it be because PB and its syntax/functions make life easier? Isn't that what medium/higher level languages were invented for? Not because they were necessary but because they made programming better/easier?

"Reason not the need!"
- King Lear

Although you may be an IIF-hater that doesn't mean it isn't useful or consistent with other basic dialects.

[Kaeru Gaman]

I do not agree that VB is the ultimate scale for BASIC.
Microsoft tends to put that much extra glitter into their software - it maybe well known, but it does not define standards.

anyhow, I don't really mind putting some IIF function into PureBasic...


it reminds me of the history of Boolean()
when I came here I was shocked that PureBasic had no possibility to use Boolean Expressions in calculations.
I was argueing that it was a BASIC functionality and so handy and almost indispensable...
... and I got used to working without it so I just don't miss it anymore - and now it is announced.


There are things really missing in PB, like e.g. saving 8bit grayscale images or passing image bitmaps to sprites or terrains and vice versa...

[idle]

I guess I should mention again that the reason for the repetition and why it may appear to look ugly is because

1) it's faster
2) you need to specify the types for the compiler
3) it looks like any other PB function PokeB() pokeL() pokeF() pokeD() pokeQ() pokeS()...
4) it works with any other PB function

Also the macro is effectively working as a Boolean evaluator.
(*evaluation may be right to left though)

I don't really care how it would be implemented just as long as it could provide the utility and work efficiently.

[Kaeru Gaman]

1) it's faster

how you say?

... I really doubt it would be faster. it needs a call additionally to the evaluation the classic beforehand If needs not.

[idle]

:facepalm: NO it's not fast enough!
I said it's about ~2x slower than a regular IF in my 1st post hence the request.

[Kaeru Gaman]

awkay... so I don't get the tenor of your last but one posting...

anyhow, this is getting boring.
if one wants a function that enables him to put things in one line at the cost of performance - why not.
put it on the todo with an appropriate low priority and fine.

[idle]

Code: Select all

Procedure.s IIFEvals(expr,*y,*n)
If expr
   ProcedureReturn PeekS(*y)
Else
   ProcedureReturn PeekS(*n)
EndIf
EndProcedure

Procedure.i IIFEvali(expr,y,n)
If expr
  ProcedureReturn y
Else
  ProcedureReturn n
EndIf
EndProcedure

Procedure.f IIFEvalf(expr,y.f,n.f)
If expr
  ProcedureReturn y
Else
  ProcedureReturn n
EndIf
EndProcedure

Procedure.d IIFEvald(expr,y.d,n.d)
If expr
  ProcedureReturn y
Else
  ProcedureReturn n
EndIf
EndProcedure

Procedure.q IIFEvalq(expr,y.q,n.q)
If expr
  ProcedureReturn y
Else
  ProcedureReturn n
EndIf
EndProcedure

Macro IIFI(expr,y,n)
IIFEvali((Not(expr)),n,y)
EndMacro

Macro IIFF(expr,y,n)
IIFEvalf((Not(expr)),n,y)
EndMacro

Macro IIFD(expr,y,n)
IIFEvald((Not(expr)),n,y)
EndMacro

Macro IIFQ(expr,y,n)
IIFEvalf((Not(expr)),n,y)
EndMacro

Macro IIFS(expr,y,n)
IIFEvals((Not(expr)),n,y)
EndMacro

Macro IIFfn(expr,a,b)
If expr : a : Else : b : EndIf
EndMacro

;================================

Procedure p1(a.s)
   MessageRequester("P1",a)
EndProcedure
Procedure p2(a.s)
result =  MessageRequester("P2",a,#PB_MessageRequester_YesNo)
If result = #PB_MessageRequester_Yes
   ProcedureReturn 1
Else
   ProcedureReturn 0
EndIf     
EndProcedure

a=5
b=4
c=2
d=3
e.f = 5.6
f.f = 5.5
                           
Debug IIFS(5.4 = 5.4,@"yes",@"no") ;string return
                 
Debug IIFI(a > b,200,100) ;Integer return 
         
Debug IIFF(e > f,200.1234567,100.1234567) ;float return
       
Debug IIFD(5.5 = 5.6,200.123456789012345,10.123456789012345) ;Double return
       
Debug IIFQ(a > c,$FFFFFFFFF,$EEEEEEEE) ;quad return

;function call a regular macro with no return   
IIFfn(a>b And c>d,p1("true"),p1("false"))

; iif as a parameter in a function expecting a string calling a function with the result from the input
p1(iifs(p2("Click Yes or No"),@"You clicked Yes",@"You clicked No"))

;iif getting the result of a function
If CreateFile(0, "MacroTest.txt")
CloseFile(0)
Debug "Delete File : " + IIFs(DeleteFile("MacroTest.txt"),@"Yes",@"No")
EndIf

[naw]

Unix (and therefore I guess Linux) shell scripts (ksh/bsh/bash - perhaps more) use "II" and "&&" in a quite elegant way. Whereas ";" denotes simple synchronous execution. "&&" and "||" are conditional...

Code: Select all

    print "1) Hello"; print "World"                                              # results in "1) HelloWorld"
    print "2) Hello" && print "World"                                          # results in "2) HelloWorld"
    print "3) Hello" || print "World"                                           # results in "3) Hello"
    print "4) Hello"; let X=1/0 && print "World" || print "Mum"     # results in "4) HelloMum"
    print "5) Hello"; let X=1/1 && print "World" || print "Mum"     # results in "5) HelloWorld"

I guess in PB this could be something like:

Code: Select all

  debug "Hello": X=1/0 && debug "World" || debug "Mum"

Why?
In example (1) ";" is used to separate statements (synchronous execution) - the same as PBs ":" separator
In example (2) "&&" is a "conditional and" in other words the second command is only executed if the previous one is successful
in example (3) "II" is a conditional not, so the 2nd command only executes if the previous command fails
(4) is more complex "Hello" is successfully printed. The variable assignment fails so "World" isn't printed, but "Mum" is
with (5) "Hello" is successfully printed. The variable assignment succeeds so "World" is printed, but "Mum" is not

Of course you can do the same thing with lengthy "if/then/else" statements, but I like the compactness and readability of ";" / "&&" / "||"

[Kaeru Gaman]

this is C syntax.
if you like it that much, you can program in C (++/#)
there are tons of compilers out there for C

[moogle]

Of course you can do the same thing with lengthy "if/then/else" statements, but I like the compactness and readability of ";" / "&&" / "||"

Same, would be nice to have it like that
The IIF function is okay but that way or this (variable = condition ? true : false) seems better.

[luis]

this is C syntax.
if you like it that much, you can program in C (++/#)
there are tons of compilers out there for C

You can do that AND you can ask for it this forum

PB already share some common traits here and there with C. Usually toned down but anyway...
That's one of the reason why I liked it. A BETTER BASIC, and fast, and compact (and with a light ide even if quite full featured).

BASIC does not exists anymore. Originally it had FLOATS (but no INTEGERS if I recall correctly), FOR-NEXT, GOTO, DIM, PRINT, GOSUB/RETURN, READ/DATA and not a lot more.

Practically any BASIC out there has a lot of C morphed into it, fortunately.

Unions, Pointers, bitwise arithmetic, all of this and more smells a lot of C.

So it's not outrageous to ask for something like IIF, IMO.

You can still use PB almost as the original Basic, you can gosub/return, you can dim, you can forgot about pointers and make simple (or complicated) programs '60 style, or you can use the full current language.

Anyone can be happy.