SELECT CASE with relational operators and ELSE CASE like Visual Basic and others

[PeWa]

While improvements of this nature can certainly be beneficial, Fred has expressed an opinion on Select last year :

PB supports multicase and the 'To' keyword which allow ranged tests, which is enough for case IMHO. If you need complex compare, If/ElseIf is the way. viewtopic.php?p=617690&sid=bc7b17e4f0fc ... b1#p617690

I come from a language background where case statements can support multiple variables and conditional tests, which I miss, but we have If/ElseIf.

Thank you for the link, i missed that unfortunatly. If Fred has that opinion, then the disscussion seems useless about it.
I also dont know about the use of the command BOOL in conjunktion with SELECT/ENDSELECT. To compare the SELECT variable with >,< ... was my original intend. Unfortunatly that way it is not possible to compare the SELECT Variable, because we must set the variable always to #true.Or am i wrong ?

Fred: is it really not planned to implement bool native in SELECT ? Yes, we can use IF/ELSE, but for me the reason to use SELECT is the clariness if we have a bunch of cases to compare. We can always use IF, but bool in SELECT make sense in my opinion.

[Quin]

I also dont know about the use of the command BOOL in conjunktion with SELECT/ENDSELECT. To compare the SELECT variable with >,< ... was my original intend. Unfortunatly that way it is not possible to compare the SELECT Variable, because we must set the variable always to #true.Or am i wrong ?

Fred: is it really not planned to implement bool native in SELECT ? Yes, we can use IF/ELSE, but for me the reason to use SELECT is the clariness if we have a bunch of cases to compare. We can always use IF, but bool in SELECT make sense in my opinion.

Would you mind providing an example for what you mean? PB's Select Case statement is one of the most full-featured implementations i've seen and I really like it. Cases can support multiple values, including using the to keyword, and it's super powerful.

[PeWa]

To find an example for my previous post, I quickly threw together a code sample. It didn't turn out particularly well, but it should illustrate what I mean:
the possibility of using CASE ELSE to set a variable or execute a procedure before another CASE occurs, because the subsequent one depends on the one before it. As I said, the example isn't good; I couldn't think of anything better.

Please ignore any logical errors That should be enough for now.

@PeWa: I don't think your example on how a CASE ELSE might be used provides any backing as to why it might be useful. AFor fun, I rewrote your example to show why a CASE ELSE wouldn't be needed:

Code: Select all

; Lets asume, we wrote an adventure. Someone must come over a sea or something.
; several options, and we must be sure that under some circumstances a variable is set
; before a following CASE is a match.

; in this example: raft and paddles
; PaddlesStolen=0 -> Paddles are available, Paddles=1 ->paddles stolen
; OverTheSea 1: Paddles stolen, we must set a variable to excecute some animations
; OverTheSea 2: take a path
; OverTheSea 3: take a boat 
; OverTheSea 4: take a raft

OverTheSea=3 

PaddlesStolen=2 ; The Paddles are faulty

; handle stolen paddles
If OverTheSea = 1
  Debug "The Paddles are stolen.What know ? You cant take the raft or boat"
  PaddlesStolen=1
Else
  Debug "The Paddles are available"
  PaddlesStolen = 0
EndIf 
 
If PaddlesStolen <> 1
  Select OverTheSea
    Case 1 ; {paddles stolen already handled}
    Case 2 ; takes a path
      Debug "He takes the path around the sea"
    Case 3, 4 ; takes a boat or raft
      If OverTheSea = 3
        transport$ = "boat"
      Else
        transport$ = "raft"
      EndIf 

      If PaddlesStolen=2
        Debug "The Paddles are faulty, will you risk to try to come over the see with the " + transport$ + "?" 
        Choice = AskYN() ;return #yes or #no
        If Choice = #no
          Debug "He remains on the shore.  Better to be safe then sorry."
        Else
          Debug "He take the " + transport$ + ", the paddles and try to reach the other side of the sea"
         OverSeaAnimation = 0.0; ranges from 0.0 to 1.0
         ;Do animation of the travelling over the sea
         SeaTravelAnimation(transport$, OverSeaAnimation)
       EndIf
    
    Default 
      Debug "He dont know how to conquer the sea"
    
    EndSelect
    
EndIf

I don't think the addition of a CASE ELSE adds anything of substance.

However, I wouldn't mind some additional functionality but I'm not certain that would actually improve anything, especially with respect to speed and clarity. My understanding is that speed and clarity are two main reasons to use Select/Case instead of If/Else/EndIf. Trying to make Select/Case an all encompassing statement I think will just make it less effective at doing any one of them well. I think it be interesting to test out any ideas to see if they hold water.

Hi Demivec, that is of course a way to progam it. I know, my program was not really good, but i want to show one of the two reasons for an CASE ElSE function that i could find. But if we program it like you, we must use IF. As i stated above, it is always possible to use IF instead of SELECT,or in conjuction with select. i want to show a possible use of CASE ELSE.
I used for fun an example with a fictional adventure, let me show what i mean with an other example, a Procedure Inventory() in an adventure, if the user picks an item, then SELECT ENDSELECT sets a variable to "Visible" in inventory.
In this example the items have a simple number as ID and we have only two items. This example is in this form not usable,
only an example:

Code: Select all

Item=2 ; the user takes a lantern, 1 is a candle

Procedure VisibleItemsInventory()

Select item

CASE 1
candlevisible=1
CASE ELSE candlevisible=0

CASE 2
lanternvisible=1
CASE ELSE lanternvisible=0

Endselect

EndProcedure

It is only an example why a CASE ELSE could be useful. Can we use IF instead ? Sure. Can we program it another way ? Sure. But we can react if a CASE is not a match. imagin we have in that fictional adventure hundrets of items. I belief the main reason to use SELECT is the clarity, if we have a big bunch of cases. In your post you say that is also a reason for you.
If we use IF, ELSE, ELSEIF ELSEIF ELSEIF ... in that case that clarity is gone. Must we then not ask, why we not only implement in a programming langueage IF/ELSE and forget other commands like SELECT ? Of course, this is a matter we can discuss endless The advantages of IF or SELECT are clear i think.
An the second case where CASE ELSE might be usefull is my bad try with the paddle/Raft-boat example. I want to show that it could make sense to set with CASE ELSE a variable or call a function that is important for a following CASE that is a match. Eventually that wasnt really clear. If someone have a better example, i am curious.

An implementation of >,< ... is that what i find really useful.

[PeWa]

I also dont know about the use of the command BOOL in conjunktion with SELECT/ENDSELECT. To compare the SELECT variable with >,< ... was my original intend. Unfortunatly that way it is not possible to compare the SELECT Variable, because we must set the variable always to #true.Or am i wrong ?

Fred: is it really not planned to implement bool native in SELECT ? Yes, we can use IF/ELSE, but for me the reason to use SELECT is the clariness if we have a bunch of cases to compare. We can always use IF, but bool in SELECT make sense in my opinion.

Would you mind providing an example for what you mean? PB's Select Case statement is one of the most full-featured implementations i've seen and I really like it. Cases can support multiple values, including using the to keyword, and it's super powerful.

If we use bool in Select, the Select Variable must be 1. We can test the variable with bool, but the value can not change .
Or miss i something or be wrong ?
Example:

Code: Select all

sc=#True ; if SC is something other than 1 or true, we cant use bool
Select sc
  Case Bool(sc > 0)
    Debug "Bool !"
     
EndSelect

;Bool not working: (if i dont make a mistake)
SC=2

Select sc
  Case Bool(sc > 0); we cant test sc
    Debug "Bool not working Example 2 !"
   
     
EndSelect

Except that, you are right, the Purebasic SELECT command is really one of the most full-featured implementations and i like it very much.

[PeWa]

I also dont know about the use of the command BOOL in conjunktion with SELECT/ENDSELECT. To compare the SELECT variable with >,< ... was my original intend. Unfortunatly that way it is not possible to compare the SELECT Variable, because we must set the variable always to #true.Or am i wrong ?

Fred: is it really not planned to implement bool native in SELECT ? Yes, we can use IF/ELSE, but for me the reason to use SELECT is the clariness if we have a bunch of cases to compare. We can always use IF, but bool in SELECT make sense in my opinion.

Would you mind providing an example for what you mean? PB's Select Case statement is one of the most full-featured implementations i've seen and I really like it. Cases can support multiple values, including using the to keyword, and it's super powerful.

Besides my previous post, if we use a second variable bool works in SELECT. I dont saw that before, but again, we cant use the SELECT Variable directly.But it seems not to be a big matter.

Code: Select all

SC=#True
s=2
Select sc
  Case Bool(s=2); we cant test sc, but use a second variable to test.We must use this variable in our program
    Debug "Bool working Example 2 !"
EndSelect

Who is responsible for the documentation ? I think it is a good idea to write an hint or example in the SELECT doc for the use of BOOL in SELECT/ENDSELECT. Much not so expirienced users like me in PB could miss the use of BOOL

[Demivec]

I used for fun an example with a finctional adventure, let me show what i mean with an other example, a Procedure Inventory() in an adventure, if the user picks an item, then SELECT ENDSELECT sets a variable to "Visible" in inventory.
In this example the items have a simple number as ID and we have only two items.

Code: Select all

Item=2 ; the user takes a lantern, 1 is a candle

Procedure VisibleItemsInventory()

Select item

CASE 1
candlevisible=1
CASE ELSE candlevisible=0

CASE 2
lanternvisible=1
CASE ELSE lanternvisible=0

Endselect

EndProcedure

It is only an example why a CASE ELSE could be useful. Can we use IF instead ? Sure. Can we program it another way ? Sure. But we can react if a CASE is not a match. imagin we have in that fictional adventure hundrets of items. I belief the main reason to use SELECT is the clarity, if we have a big bunch of cases.

It is not uncommon for a programmer to want a command called 'DoTheRest()' or 'DoTheHardPart()' or even 'DoEverything()' that carries out a task without any additional effort from the programmer. Such a function is the equivalent of getting another programmer to do everything the first programmer doesn't want to do. That would be awesome but who would need the programmer now?

Programming doesn't have to be hard but it can frequently become tedious. It can be hard because programmers are creating something, sometimes something that has never existed before. It becomes tedious because it details the steps to accomplish something while preventing other unwanted things from happening. It's normal to desire less tedious solutions. I think your desires for how SELECT/CASE should function are similar to choices in what algorithm to use to accomplish a task. IMHO, the tasks you want to accomplish can be done better and more efficiently using a different algorithm and consequently not burdening SELECT/CASE to do anything more than what it already does.

In your inventory example you are imagining hundreds of inventory items. A CASE ELSE is being used to update a variable showing each thing is visible or not visible depending on if it is the inventory item being used. If a SELECT/CASE is used it would not update the variables after the first matching CASE because no more CASEs or CASE ELSEs would be executed. It would be better to create a larger collection, such as an array or list of the inventory items and loop through them all and update their visibility status. You acknowledge this by asking and answering the rhetorical question, 'Can we program it another way ? Sure.'

An implementation of >,< ... is that what i find really useful.

My example on using conditions for the CASE statements covers this. A typical use of SELECT/CASE is to compare a single expression or variable value to a variety of values or ranges of values. In my opinion this is its optimal and intended use. If clarity is more important than speed it can also be used to compare multiple conditions to find the first one that is either true or false.

The way to compare multiple expressions is to use 'Select 1' and for each case use a Bool() function to evaluate the condition. Since Bool() always evaluates to either 1 or 0 the first Case condition that evaluates to true will be selected. Bool() can handle conditional statements with {<, <=, =, >=, >, And, Or, Not} and as many variables or function calls as you want. The example I posted for PBJim shows this adequately I think.

One aspect of SELECT/CASE that is missing from PureBasic is the possibility of fall through. This occurs when a Case statement evaluates to true and executes it's statements and then executes the statements of each of the following cases without examining their individual Case values. Even though this functionality is not native to PureBasic it can be implemented without too much effort if needed.https://www.purebasic.fr/english/viewtopic.php?p=529042#p529042

[SMaag]

Code: Select all

Item=2 ; the user takes a lantern, 1 is a candle

Procedure VisibleItemsInventory()

Select item

CASE 1
candlevisible=1

; if you do a CASE ELSE here, you will never get a Check for CASE 2, CASE 3!
CASE ELSE candlevisible=0

CASE 2
lanternvisible=1
CASE ELSE lanternvisible=0

Endselect

EndProcedure

Stop the discussion! PeWa has to understand first the CASE Function and the consequences in detail!
What PeWa likes to do is logical impossible construction!

@PeWa
try to do your construction first with an IF, ELSEIF construction. If it won't work, do not think about a SELECT to solve your problem - you are the problem!

Code: Select all

[PeWa]

In your inventory example you are imagining hundreds of inventory items. A CASE ELSE is being used to update a variable showing each thing is visible or not visible depending on if it is the inventory item being used. If a SELECT/CASE is used it would not update the variables after the first matching CASE because no more CASEs or CASE ELSEs would be executed. It would be better to create a larger collection, such as an array or list of the inventory items and loop through them all and update their visibility status. You acknowledge this by asking and answering the rhetorical question, 'Can we program it another way ? Sure.'

Demivec, you're right.
I just wanted to find an example for Quin of a possible use of CASE ELSE.
However, I made a different assumption with CASE ELSE:
With SELECT, the variable is checked, and if a match is found, CASE is executed. CASE ELSE is executed if the variable does not match the value.
So, with a possible CASE ELSE, I assumed that the other CASEs would continue to be checked despite the CASE ELSE being executed, since the variable does not match the CASE, and that is the normal behavior of SELECT.
If this is implemented differently, my examples obviously make no sense, and CASE ELSE is probably only rarely useable.

[PeWa]

Code: Select all

Select item

CASE 1
candlevisible=1

; if you do a CASE ELSE here, you will never get a Check for CASE 2, CASE 3!
CASE ELSE candlevisible=0

CASE 2
lanternvisible=1
CASE ELSE lanternvisible=0

Endselect

EndProcedure

Stop the discussion!

I agree, Features and Wishlist is not the right place for long discussions

PeWa has to understand first the CASE Function
What PeWa likes to do is logical impossible construction!

I know the CASE function, i made a diffent assumtion,see my reply to Demivec:

However, I made a different assumption with CASE ELSE:
With SELECT, the variable is checked, and if a match is found, CASE is executed.
So, with a possible CASE ELSE, I assumed that the other CASEs would continue to be checked despite the CASE ELSE being executed, since the variable does not match the CASE, and that is the normal behavior of SELECT.
If this is implemented differently, my examples obviously make no sense, and CASE ELSE is probably only rarely useable.

@PeWa
try to do your construction first with an IF, ELSEIF construction. If it won't work, do not think about a SELECT to solve your problem - you are the problem!

The use of IF was not the question from Quin: he wants an example for CASE ELSE.
And i believe there are no problems at all (I know what you mean)