OpenEuphoria

1. switch statement

• Posted by Critic Mar 25, 2009
• 1407 views

Are there any reasons for the design of the new switch statement? I thought C's switch was widely critised for its bug-proneness. IMHO, Pascal's case is nicer.

3. Re: switch statement

• Posted by jeremy (admin) Mar 25, 2009
• 1398 views

I did some google searches for buggy C switch and really didn't find anything but I did find a quote on the page of PHP's switch statement (which works just like ours, and most other switch statements):

I tend to agree. That's why it was designed the way it is. There has been talk of implementing a select statement, but it didn't go very far for 4.0 as our plates have been full for a while. I, personally, do not see the reason for it, but others may enjoy not having to type break.

Oh, the php page does a good job of explaining switch, it's a good read for anyone interested.

Jeremy

5. Re: switch statement

• Posted by jeremy (admin) Mar 25, 2009
• 1370 views

With a switch statement, once a case evaluates as true, then all further case statements are ignored and a break will cause the switch to be exited. Here is an example:

sequence value = "red" 
 
switch value do 
  case "apple": 
  case "pear": 
  case "orange": 
    puts(1, "It's a fruit!\n") 
    break 
 
  case "yellow": 
  case "blue": 
  case "red": 
    puts(1, "It's a color!\n") 
    break 
 
  case else 
    puts(1, "I have no clue what it is \n") 
end switch 
 
-- Output is "It's a color!" 

As for break vs. continue, we choose to keep the normal functionality of a switch as defined in just about every language. It would be pretty difficult for anyone who uses multiple languages or has knowledge of another language, to come to Euphoria and start working with a backward switch. That would be serious cause of bugs and errors.

I think what some people are thinking about is actually a select statement:

sequence value = "red" 
 
select value do 
  case "apple": 
    puts(1, "It's an apple\n") 
  case "pear": 
    puts(1, "It's a pear\n") 
  case "orange": 
    puts(1, "It's an orange!\n") 
  case "yellow": 
    puts(1, "It's yellow\n") 
  case "blue": 
    puts(1,"It's blue\n") 
  case "red": 
    puts(1, "It's red\n") 
  case else 
    puts(1, "I have no clue what it is \n") 
end select 
 
-- Output is: "It's red" 

A select statement does not fall-thru. Euphoria does not yet have a select statement, I just was showing the differences.

Jeremy

7. Re: switch statement

• Posted by jeremy (admin) Mar 25, 2009
• 1374 views

I think the answer is we already have a construct (not as nice in some cases as select) that does non-fallthrough, that is the if statement. We did not have a construct that did fall through. Here is another example, built off your example of y, n, q:

sequence answer = prompt_string("Continue (y/n/q)?") 
 
switch answer do 
  case "y": 
  case "Y": 
  case "yes": 
  case "Yes": 
  case "YES": 
    puts(1, "Ok, we will continue\n") 
    break 
 
  case "n": 
  case "N": 
  case "no": 
  case "No": 
  case "NO": 
    puts(1, "Ok, we will not continue\n") 
    break 
 
  case else 
    puts(1, "Ok, we are quitting\n") 
end switch 

Now, there are certainly better way's of doing that example (if upper(answer[1]) = 'Y'), but it's just another example. You can look at the source code for Euphoria and see all sorts of real life examples of a switch. Now, before I finish this message, let's take my original example:

sequence value = "red"  
 
switch value do  
  case "apple":  
  case "pear":  
  case "orange":  
    puts(1, "It's a fruit!\n")  
    break  
  
  case "yellow":  
  case "blue":  
  case "red":  
    puts(1, "It's a color!\n")  
    break  
  
  case else  
    puts(1, "I have no clue what it is \n")  
end switch  

and let's write it as if we didn't have switch at all, i.e. in Euphoria 3.x

sequence value = "red"  
 
if equal(value, "apple") or equal(value, "pear") or equal(value, "orange") then 
  puts(1, "It's a fruit!\n") 
else if equal(value, "yellow") or equal(value, "blue") or equal(value, "red") then 
  puts(1, "It's a color!\n") 
else 
  puts(1, "I have no clue what it is \n")  
end if 

Now, I suppose you could write it a little more simply:

sequence value = "red" 
 
if find(value, { "apple", "pear", "orange" }) > 0 then 
  puts(1, "It's a fruit!\n") 
else if find(value, { "yellow", "blue", "red" }) > 0 then 
  puts(1, "It's a color!\n") 
else 
  puts(1, "I have no clue what it is\n") 
end if 

but, I would encourage you to benchmark these three examples. Hm, I can't resist, I just did a benchmark, here are the results (I changed the puts to setting a message as not to have all sorts of IO hiding the timing):

C:\Develop>exwc switchifbench.ex 
  bench_switch: 0.063 
bench_if_equal: 0.187 
 bench_if_find: 0.344 

And actually, when doing a switch on integers, it's much much faster. Anyway, here is my benchmark code if you want to run it on your box:

sequence value = "red" 
sequence message 
 
procedure bench_switch() 
	switch value do 
		case "apple": 
		case "pear": 
		case "orange": 
			message = "It's a fruit!" 
			break 
 
		case "yellow": 
		case "blue": 
		case "red": 
			message = "It's a color!" 
			break 
 
		case else 
			message = "I have no clue what it is" 
	end switch 
end procedure 
 
procedure bench_if_equal() 
	if equal(value, "apple") or equal(value, "pear") or equal(value, "orange") then 
		message = "It's a fruit!" 
	elsif equal(value, "yellow") or equal(value, "blue") or equal(value, "red") then 
		message = "It's a color!" 
	else 
		message = "I have no clue what it is" 
	end if 
end procedure 
 
procedure bench_if_find() 
	if find(value, { "apple", "pear", "orange" }) > 0 then 
		message = "It's a fruit!" 
	elsif find(value, { "yellow", "blue", "red" }) > 0 then 
		message = "It's a color!" 
	else 
		message = "I have no clue what it is" 
	end if 
end procedure 
 
constant ITS=1000000 
atom t1 
t1  = time() 
for i = 1 to ITS do 
	bench_switch() 
end for 
printf(1, "  bench_switch: %.3f\n", { time() - t1 }) 
 
t1  = time() 
for i = 1 to ITS do 
	bench_if_equal() 
end for 
printf(1, "bench_if_equal: %.3f\n", { time() - t1 }) 
 
t1  = time() 
for i = 1 to ITS do 
	bench_if_find() 
end for 
printf(1, " bench_if_find: %.3f\n", { time() - t1 }) 

Jeremy

9. Re: switch statement

• Posted by euphoric (admin) Mar 25, 2009
• 1396 views

sequence value = "red" 
 
switch value do 
  case "apple": 
  case "pear": 
  case "orange": 
    puts(1, "It's a fruit!\n") 
    break 
 
  case "yellow": 
  case "blue": 
  case "red": 
    puts(1, "It's a color!\n") 
    break 
 
  case else 
    puts(1, "I have no clue what it is \n") 
end switch 
 
-- Output is "It's a color!" 

This is still the dumbest conditional construct I've ever encountered. Didn't the devs discover that in most cases, break will be used and, therefore, making it NOT default is the friendlier option?

I understand that your example above is not an optimal use case for switch, but I've never actually seen one either. Can you access the dev list archives? Maybe there was a convincing example there.

And isn't there a select construct available in 4.0? I thought I had seen and even used it.

Anyway, why not something like this:

sequence 
   value = "red" 
  ,fruits = {"apple","pear","orange"} 
 
switch value do 
  case in fruits: 
    puts(1, "It's a fruit!\n") 
 
  case in {"yellow","blue","red"}: 
    puts(1, "It's a color!\n") 
 
  case else 
    puts(1, "I have no clue what it is \n") 
end switch 
 
-- Output is "It's a color!" 

Even this if... statement is better than that stupid switch:

sequence 
    value = "red" 
   ,fruits = {"apple","pear","orange"} 
   ,colors = {"yellow","blue","red"} -- "orange" is valid here, too.  
 
if find(value,fruits) then 
   puts(1, "It's a fruit!\n") 
elsif find(value,colors) then 
    puts(1, "It's a color!\n") 
else 
    puts(1, "I have no clue what it is \n") 
end if 
 
-- Output is "It's a color!" 

By the way, it doesn't look like select or switch are documented in the Manual! Or did I just miss it?

11. Re: switch statement

• Posted by euphoric (admin) Mar 25, 2009
• 1375 views

C:\Develop>exwc switchifbench.ex 
  bench_switch: 0.063 
bench_if_equal: 0.187 
 bench_if_find: 0.344 

Okay, now I remember why it was a good idea. SPEEEEEEEEEED!!!

13. Re: switch statement

• Posted by jeremy (admin) Mar 25, 2009
• 1371 views

sequence value = "red" 
 
switch value do 
  case "apple": 
  case "pear": 
  case "orange": 
    puts(1, "It's a fruit!\n") 
    break 
 
  case "yellow": 
  case "blue": 
  case "red": 
    puts(1, "It's a color!\n") 
    break 
 
  case else 
    puts(1, "I have no clue what it is \n") 
end switch 
 
-- Output is "It's a color!" 

And go against every other programming languages definition of a switch, I don't think that would be wise. Sure, we are not PHP, but people understand an if statement. What if we were to flip it around? People would be totally confused.

if 1=1 then 
  puts(1, "1 is not = 1\n") 
else 
  puts(1, "1 is 1\n") 
end if 

This is the same as changing the way switch works. It's totally foreign for the switch construct.

Um, actually my example of the colors, fruits, etc... is a valid construct for switch. There's nothing wrong with that example.

No.

sequence 
   value = "red" 
  ,fruits = {"apple","pear","orange"} 
 
switch value do 
  case in fruits: 
    puts(1, "It's a fruit!\n") 
 
  case in {"yellow","blue","red"}: 
    puts(1, "It's a color!\n") 
 
  case else 
    puts(1, "I have no clue what it is \n") 
end switch 
 
-- Output is "It's a color!" 

This takes away quite a bit of power from switch as you cannot do specific things based on one item. I was working up an example and then I saw that ghaberek just posted one...

http://openeuphoria.org/docs/eu400_0010.html#_103_switchstatement

Jeremy

15. Re: switch statement

• Posted by mattlewis (admin) Mar 25, 2009
• 1398 views

value = {1,2,3} 
switch value do 
 
case 1: -- code, break 
case (1+1): -- code runs if value = 2, break 
case (var - 12): -- code , break 
case (value < 4): -- if all the elements of value are < 4, break 
case (match("cow,value)): 
end switch 

Future versions of switch may behave this way, or at least support more complex cases (no promises ). One of the motivations of the current switch was to offer a faster and sometimes more expressive construct than the existing if-elsif-else option.

This sort of thing (executable code) would definitely remove a lot of the speed value, though obviously not the expressiveness.

switch sendheader[idx][1] do  

Yes, it's not really any different than any other use of a subscript. Basically, it creates a temp as the result of the subscript, and uses that value to direct the flow.

switch value do 
      case a: 
break case b: 
break case c: 
end switch 

No, it doesn't care about line breaks. That's just a different type of white space, as far as the scanner/parser are concerned.

Matt

17. Re: switch statement

• Posted by euphoric (admin) Mar 25, 2009
• 1380 views

P.S. I think his example is in C, not Euphoria.

19. Re: switch statement

• Posted by jeremy (admin) Mar 25, 2009
• 1375 views

That page is a function reference. Maybe the title should be changed to be "Library Reference" instead of "Language Reference" now that you bring that up. Currently all language constructs are defined in the section "Euphoria Reference"

http://openeuphoria.org/docs/eu400_0006.html

Jeremy

21. Re: switch statement

• Posted by Kat Mar 25, 2009
• 1363 views

value = {1,2,3} 
switch value do 
 
case 1: -- code, break 
case (1+1): -- code runs if value = 2, break 
case (var - 12): -- code , break 
case (value < 4): -- if all the elements of value are < 4, break 
case (match("cow,value)): 
end switch 

Would it be faster to eval() when and only when () are encountered, or code like this:

case 1:
case 2:
case 3:

vs

case (x<4):

useless

23. Re: switch statement

• Posted by mattlewis (admin) Mar 25, 2009
• 1364 views

C actually, but it's a good example of a use for fall through.

Matt

25. Re: switch statement

• Posted by achury Mar 25, 2009
• 1366 views
• Last edited Mar 26, 2009

Note how qbasic does it:

SELECT CASE Expression 
    CASE IS >= 5 
          ... 
    CASE 2 TO 4 
          ... 
    CASE 1 
         ... 
    CASE ELSE 
         ... 
END SELECT 

The "IS" token precedes complex expression, this way simple expressions get a fast processing.

Will be great if the switch can process sequences. But may become very complex like this

for i=1 to 5 do 
 
  select case my_sequence[i] 
  case "" 
    ... 
  case other_sequence[i] 
    ... 
  case else 
    ... 
  end select 
 

May be a very powerfull, but not easy to eval

27. Re: switch statement

• Posted by ghaberek (admin) Mar 26, 2009
• 1327 views

That was my point, that you can see how useful it is in C. I'd be nice to be able to do such things in Euphoria.

-Greg

29. Re: switch statement

• Posted by jeremy (admin) Mar 26, 2009
• 1346 views

Did you ignore everything else that was said in this thread?

Jeremy

31. Re: switch statement

• Posted by mattlewis (admin) Mar 26, 2009
• 1360 views

Bad syntax is often subjective.

Not all if-elsif-else statements can be optimized this way (think side effectsbad practice, but still needs to be taken into account), but your statement is just referring to a trivial isomorphism between a switch and if-elsif-else blocks. By which I mean that all switches (that don't use fallthrough) can be trivially altered to be an if-elsif-else.

Matt

33. Re: switch statement

• Posted by Critic Mar 26, 2009
• 1323 views

Well, if the compiler does common subexpression elimination, it is easy to optimize an if-elif-chain into a jump table. Speed is no justification for a switch/select statement nowadays, if you are going to have a proper optimizer anyway. But please get me right: I love "select"-statements. It's just that speed is no good argument to introduce them.

35. Re: switch statement

• Posted by mattlewis (admin) Mar 26, 2009
• 1343 views

Yes, for certain if-elsif-else scenarios it's easy, which is exactly what I said (trivial isomorphism, etc, etc).

Speed is never a good reason to do anything, until you need it. And then it's a good thing.

Matt

37. Re: switch statement

• Posted by jeremy (admin) Mar 26, 2009
• 1335 views

I ask again, have you read any of this thread actually? Also, switch is only C based languages? how many have you used? Switch can be found all over, but who cares if it is from a C based language? I was not aware that we are bound by our lineage, that's a new rule to me in developing a language.

I'm going to suggest this again, please thread the thread. Any more silly questions/statements, I'm simply going to ignore, I have better things to do that to repeat what has already been said and demonstraighted.

Jeremy

39. Re: switch statement

• Posted by Critic Mar 26, 2009
• 1363 views

Read again. I said C syntax based languages. By which I basically meant curly braces. "Braces are the defacto standard, so lets introduce them." - Not a good argument, do you agree?

41. Re: switch statement

• Posted by euphoric (admin) Mar 26, 2009
• 1317 views

I say it's irrelevant what C has. Our objective is not to emulate or copy C, it's to make a language that is relatively easy to use for n00bs and yet has extremely powerful elements (no pun intended) that give experts lots of leeway when building programs.

If we have an if statement, it's because it's maximally functional and minimally inefficient.

Same with switch with fallthru. If we're going to have it, the positives have to outweigh the negatives. You say one of the positives is "many other languages use it that way," but consensus (or an appeal to numbers) is ultimately irrelevant when it comes to computer science. It is also easily countered with, "most instances of switch usage will use break, so break should be the default."

Anyway, in a battle of efficiency vs. tradition, efficiency always wins out in my book (unless the traditional method is the most efficient, of course ).

43. Re: switch statement

• Posted by bernie Mar 26, 2009
• 1367 views

Critic: You seem to think you can compare "C" and Pascal's switch and select to Euphoria.

I thought that "C" and Pascal were compilers and Euphoria is an interpreter so how can you compare different optimization techniques that they use verses Euphoria.

45. Re: switch statement

• Posted by DerekParnell (admin) Mar 26, 2009
• 1360 views

It seems that you are saying that every operation is transformed from a single action into multiple actions by Euphoria. If this is actually what you are saying, can you give me an example to help me understand your point of view?

47. Re: switch statement

• Posted by kinz Mar 27, 2009
• 1320 views

  switch x do 
     case "first": 
          action1() 
          break 
     case "second": 
          action2() 
          break 
     case "another": 
          action3() 
          break 
     . . . 
 end switch 

I'd still like to see this construct
without "do" and ":" :

  switch x 
     case "first" 
          action1() 
          break 
     case "second" 
          action2() 
          break 
     case "another" 
          action3() 
          break 
     . . . 
 end switch 

Looks much better (on my ultra conservative taste)

Regards,
Igor Kachan
kinz@peterlink.ru

49. Re: switch statement

• Posted by DerekParnell (admin) Mar 27, 2009
• 1298 views

The colon is already optional. I'll think through the optional 'do' a bit more.