Rehashing Switch

[dunbarx]

I am bringing this up again because I am in a bad mood.

Long ago I raised an issue with the "Switch" control structure, that much functionality was left on the table because of the way the 'break" control structure works. I wanted "Switch" to be able to evaluate each case section on its own merits, without terminating the entire structure when any particular case fires:

Code: Select all

on mouseUp
 switch
      case  1= 1
         add 1 to a
      case 1 = 5000
         add 1 to a
      case 2 = 2
        add 1 to a
   end switch
   answer a
end mouseUp

You get a "3" in "a", because without breaks to escape a particular case, all cases fire. I wanted to get a "2", each case firing, again, on its individual merits.

This is something one can only do with "if/then", which can be far more tedious and complex to write, and to read later.

Anyone else care? I will submit another feature request if I get even one vote, just to annoy the team.

Craig

[Klaus]

Hi Craig,

sorry, no idea what you are after?
Could you please give an example in "pseudo code", where and how should the script exit the SWITCH?

Thanks.


Best

Klaus

[bogs]

This is something one can only do with "if/then", which can be far more tedious and complex to write, and to read later.

I'm not entirely sure how ...

Code: Select all

on mouseUp
 switch
      case  1= 1
         add 1 to a
      case 1 = 5000
         add 1 to a
      case 2 = 2
        add 1 to a
   end switch
   answer a
end mouseUp

...is perceived to be better, clearer, or more elegant than...

Code: Select all

on mouseUp
      if  1= 1 then add 1 to a
      if 1 = 5000 then add 1 to a
      if 2 = 2 then  add 1 to a
   answer a
end mouseUp

...or ...

Code: Select all

on mouseUp
	if  1= 1 then 
      		add 1 to a
	else if 1 = 5000 then 
      		add 1 to a
	else if 2 = 2 then  
      		add 1 to a	
      	end if
   answer a
end mouseUp

...or even ....

Code: Select all

on mouseUp
	if  1= 1 then 
      		add 1 to a
	end if
	if 1 = 5000 then 
      		add 1 to a
	end if
	 if 2 = 2 then  
      		add 1 to a	
	end if
   answer a
end mouseUp

Even if you take the long form of if / then, it seems to me you are saving a considerable amount of typing, however the short form is more than sufficient for the example given (it seems to me).

[andresdt]

Hi Craig,
Well everything in this world is relative. It seems to me that the switch is doing what it should do. The other languages that I know the break is part of the switch structure. how @bogs came about It seems to me that in your case what you need are 3 structure (if).

Code: Select all

if 1 = 1 then  add 1 to a
if 1 = 5000 then  add 1 to a
if 2 = 2 then  add 1 to a

or you can use the switch like this.

Code: Select all

 switch
        case 1 = 1 and 2= 2
            add 2 to a
            break
    
        case 1 = 5000
            add 1 to a
            break

        case 1 = 1
        case 2 = 2
            add 1 to a
            break
    end switch

You should always put the cases in order of preority if 2 can meet or simply if they do the same, put one under the other.

[dunbarx]

All.

I know.

I do use "if/then", in all its diverse forms. No problem.

I was hoping that a new variant of "switch" might be attractive, where some form of new "break" control structure, or some other gadget, would allow each "case" to evaluate on its own merits.

Sort of like what if/then does, eh? But in the more compact switch format. Obviously this is getting little traction.

Craig

[bogs]

I was hoping that a new variant of "switch" might be attractive, where some form of new "break" control structure, or some other gadget, would allow each "case" to evaluate on its own merits.

If I recall from the last time this topic came up, that would be achievable without modifying switch just by eliminating the break statement.

Far smarter people were involved in that topic than I, though, so I would really at this point ask -

'what has changed that the previous topic's answers are now insufficient?'

I *think* this was the thread - viewtopic.php?f=8&t=25082&p=130259&hili ... le#p130259

I came back to edit this to add -

... would allow each "case" to evaluate on its own merits.

Sort of like what if/then does, eh? But in the more compact switch format.

I am sorry, there is no way switch case is ever going to be more compact than if / then, especially when you can put an entire if / then statement on one line.

[andresdt]

Reading what is suggested by @Panos I realized that in the example that @Dunbarx puts, you can obtain the result that he expects by using break and changing the order of the cases.

Code: Select all

on mouseUp
    switch
    
        case  1= 1
            add 1 to a
        case 2 = 2
            add 1 to a
            break
            
        case 1 = 5000
            add 1 to a
            break
            
    end switch
    
    answer a
end mouseUp

[SparkOut]

That doesn't "solve" the results that @Craig expects as if you change the line "case 2=2" to "case 2=3" then even though that test is negative, because the case 1=1 has not been terminated with break, the case 2=3 statement is ignored and the second addition is also made.

Code: Select all

on mouseUp
    switch
    
        case  1= 1
            add 1 to a
        case 2 = 3 -- you would think this prevents the next addition, but becase the statement block from the true result in the first case is not terminiated, it also performs that statement (and any others that might be there prior to the "break")
            add 1 to a
            break
            
        case 1 = 5000
            add 1 to a
            break
            
    end switch
    
    answer a
end mouseUp

It it usually argued that a switch structure can reduce the cognitive load in digesting a complex (especially nested) set of if/then/[else] tests, making the code clearer and more elegant.
In the case Craig is arguing for, I think it *could* be possible to make some switch structures that work in that way, but probably the cognitive load would be increased. Certainly I don't see how you could reduce it to "just" case comparisons in an elegant switch structure without some if/then comparisons. So overall, I imagine it would be impossible to make it "more elegant" than the series of one-liner if/then statements.
But I haven't really put any effort in to imagining how a switch structure would work - it got too hard to imagine, so my brain took the easy way and refused to go beyond the one-liner if/then series.

[jacque]

I was hoping that a new variant of "switch" might be attractive, where some form of new "break" control structure, or some other gadget, would allow each "case" to evaluate on its own merits.

Switch is such a standard structure in all programming languages that it's unlikely to change. It has advantages over "if", which has other advantages over "switch". We have two choices depending on what we need. I wouldn't change it.

[dunbarx]

Jacque is correct, as usual.

Sparkout has nailed it concisely, as usual.

@Bogs, without "break" lines, all cases fire, regardless of the validity of evaluation of each case. That is my point, as shown in the example I posted.

The whole idea of this is to create a new switch control structure where, even after the first *valid* case, other, following valid cases may still be examined. Currently, the entire control structure exits at the *first* valid case.

I am not new at this, you know. I have shuffled and juggled "cases"in both "switch" and "if/then" for decades to try to order them to optimize the examination of those cases. My new switch gadget requires none of that. One can create cases any way one desires, knowing that they will all be evaluated on their own merits, without worrying about the flow being terminated before they even get a fair chance to show what they can do.

I stated in the original thread, and again here, that a lot of functionality is "left on the table" by virtue of that "premature" flow exit.

That is all of it.

Craig

[dunbarx]

Jacque.

I wouldn't change it.

Neither would I. I am not a barbarian.

I want to enhance it, Perhaps a new keyWord that can substitute for "break', like "busted":

Code: Select all

on mouseUp
 switch
      case  1= 1
         add 1 to a --fires
         busted
      case 1 = 5000
         add 1 to a --does not fire
         busted
      case 2 = 2
        add 1 to a --fires
        busted
   end switch
   answer a
end mouseUp

The *entire* switch statement gets examined, and you get a 2 in "a".

Craig

[bogs]

@Bogs, without "break" lines, all cases fire, regardless of the validity of evaluation of each case.

I'm pretty sure I said the same thing, from my recollection of the other thread ? You said earlier you wanted all case statements to be considered, eliminating break does just that.

Or else, I am missing something in what you are asking. In any case, it is above my pay grade as a 3rd rate heathen hack.

I'm all for tilting at windmills my friend, but in this case it simply seems to me that the windmill is no more.

[SparkOut]

@Bogs, without "break" lines, all cases fire, regardless of the validity of evaluation of each case.

You said earlier you wanted all case statements to be considered, eliminating break does just that.

No it doesn't, that's Craig's point.
Eliminating break means that if the first case is evaluated true, then all code statements up to the next break will be executed - the second case is not evaluated at all, or if it is, it doesn't matter whether the result is true or false, the following code statements are still executed.

[bogs]

Ah, my misunderstanding then. I still say no case is shorter than a 1 line if / then though

[dunbarx]

Bogs.

You have never struggled with a handler where the nesting required to do what you wanted seemed, er, unseemly? And the chore of breaking "upward" a few levels or so to get back to one particular nesting level, so you could continue the flow of your logic? And without using profanity?

Switch solves all of that sort of if/then travail, because it compartmentalizes each "case" in such an ordered and simple way. What I am talking about is the current strict and well-defined methodology (I will say unfortunately) built into that construct. That is, the explicit exiting of program flow once a single case fires. I want to add another dimension to that construct, to continue program flow to the end.

I believe that it would be far better to have had that particular method be the default from day one, so that some fool might come along to request that a new "break" gadget be added, so that program flow exits at once, regardless of the case statements below.

It is a sort of agglomeration of if/then and switch.

Craig