OpenEuphoria

2. Re: New switch/case idea

• Posted by jeremy (admin) Mar 30, 2009
• 2008 views
• Last edited Mar 31, 2009

Fernando,

I like this. We had just reached the final decision on the dev list when this came in. Discussions have started as to include this or not in 4.0. We are thinking that it would work together with the switch without fallthru do type syntax. It seems the default of without fallthru has won, so the switch will not have fallthru by default, you will have to enable fallthru by with fallthru. Most people can probably live with the default switch and never use the with fallthru option and with the addition of the case continue syntax you have proposed, that will make it all the more likely not to need with fallthru, however, there are situations where it's nice to have the entire switch support fallthru. For that, we are thinking of keeping the modifier of with fallthru. Instead of making a 50 case switch that has case continue ... then 50 times, we could do a switch X with fallthru do.

We just posed the idea of including this in 4.0 or pushing to 4.1, so I am sure others will chime in here as well.

Jeremy

4. Re: New switch/case idea

• Posted by mattlewis (admin) Mar 31, 2009
• 1981 views

It will be easy to use fall through. It looks like the final result will probably be something like:

switch x with fallthrough do 
    case 1 then 
    ... 
end switch 

There are still some details to be worked out with respect to Fernando's idea. On the dev list, I proposed a slight modification:

switch x do -- NOTE: no fall through by default 
    case 1 then 
       ... 
    -- NOTE: no fall through here 
    case 2,3 then 
 
    -- this one falls through 
    case 4 continue then 
 
    -- also fall through here 
    case else continue 
end switch 

The main change was to move the continue to where the actual fall through is happening. We could put the continue before the case, but I think that could lead to bugs when the coder really wants to use continue to go to the next loop iteration:

for i = 1 to n do 
    switch x[i] do -- NOTE: no fall through by default 
        case 1 then 
           ... 
           continue -- we want to skip "other stuff" at the bottom 
        -- NOTE: no fall through here 
        case 2,3 then 
       
        -- this one falls through 
        case 4 continue then 
 
        -- also fall through here 
        case else continue 
    end switch 
    ... do other stuff ... 
end for 

Matt

6. Re: New switch/case idea

• Posted by jeremy (admin) Mar 31, 2009
• 1983 views

Hey, Bernie! There are very limited uses of \\ in your message. Thank you!

The use of continue would be the exception For a switch that has fallthru turned on, you do not need continue. Here's an example:

X=1 
switch X with fallthru do 
    case 1: ? 1 
    case 2: ? 2 
    case 3: ? 3 
    case 4: ? 4 
    case 5: ? 5 break 
    case 6: ? 6 
    case 7: ? 7 
end switch 

This switch has fallthru turned on, therefore, if you want to stop processing, then you must type break. The above example would print 1, 2, 3, 4, 5.

Now, let's say that you have a switch that has many case statements that do not need fallthru, but one or two do... Then it would be easier to:

switch X do 
    case 1: ? 1 
    case 2: ? 2 
    case 3: ? 3 
    case 4 continue: ? 4 
    case 5 continue: ? 5 
    case 6: ? 6 
    case 7: ? 7 
end switch 

So, cases 1, 2, 3 do not fall thru, 4 and 5 do, then 6 and 7 do not. So, in the end we have a switch that can do just about anything easily.

Jeremy

8. Re: New switch/case idea

• Posted by jeremy (admin) Mar 31, 2009
• 1981 views

Actually, the new proposed syntax does not use : at all, it uses then, to keep with Euphoria syntax:

switch X do 
    case 1 then 
        ? 1 
    case 2, 3, 4, "John" then 
        ? 2 
end switch 

Jeremy

10. Re: New switch/case idea

• Posted by DerekParnell (admin) Mar 31, 2009
• 1994 views

switch X do 
    case 1 then 
        ? 1 
    case 2, 3, 4, "John" then 
        ? 2 
end switch 

Bernie, are you even reading Jeremy's responses?

You said "How about single colon for continue and double colon for break." and Jeremy said that we are not actually using colons anymore. So therefore your suggestion can't be taken up.

Here is how you do fall through now ...

  switch X with fallthru do 
     case 1 then 
        ? 1 
        break 
     case 2, 3, 4 then 
        ? 2 
     case 5 then 
        ? 5 
  end switch 

Notice the with fallthru clause. That means that this switch falls through to the next case action until either a break is found or the end switch is found.

In the example above here are the results for various values of X...

12. Re: New switch/case idea

• Posted by bernie Mar 31, 2009
• 2001 views

When was colon removed ? Does that mean I have to back into my code and remove the colons ?

My suggestion was simple and much easier to code and all it takes is 1 extra colon and no other keywords.

I think that things are being made too complicated with all the extra words.

switch X do   
  case 1:: -- do code until next case is encountered then break 
     ? 1  
  case 2, 3, 4: -- fall through 
     ? 2  
  case 5: -- fall through 
     ? 5 
  case 30:: -- do code until next case is encountered then break 
     ? 30 
     ? 123 
  case 27:: -- do code until next case is encountered then break 
     ? 27 
  case 81: -- fall through 
     ? 81 
end switch  

14. Re: New switch/case idea

• Posted by jimcbrown (admin) Mar 31, 2009
• 1996 views

I personally like your idea. It fits in well with my personal programming philosphy. However, I do feel the use of a colon at all is un-Euphorian, and that the use of the double colon, while clever, simple, useful, and brilliant, would only make the syntax more un-Euphorian.

However, this is otherwise a brilliant solution to the problem.

16. Re: New switch/case idea

• Posted by bernie Mar 31, 2009
• 2051 views

Jeremy

Then you will have to remove &= += -= $ because are not in " keeping with Euphorian type syntax " they are used in "C"

18. Re: New switch/case idea

• Posted by jimcbrown (admin) Mar 31, 2009
• 2017 views

$ is not used in C. I am not sure if &= has any meaning in C, but if it does then the meaning is going to be very different from the usage that &= has in Euphoria.

+= and -= are obvious in their intent. case : vs case :: is not obvious at all and needs to be explained (even though the explanation is a simple one line explanationl).

20. Re: New switch/case idea

• Posted by jimcbrown (admin) Mar 31, 2009
• 2031 views

I voted for "without fallthru" as the default.

While it makes sense to borrow ideas from other languages when they are suitable, not every concept from every language is suitable for use with euphoria.

The concept of a default fall thru is one of these imvho.

http://www.rinkworks.com/stupid/cs_programming.shtml [quote="http://www.rinkworks.com/stupid/cs_programming.shtml"] Days ago I had to fix a bug into our software. The person that originally wrote the module quit, so I had total control of the source code. I totally rewrote half of the code when I found things like:

int i; memset(&i, 0, sizeof(int));

And:

switch (k) { case 9: printf("9\n"); case 8: if (k==8) printf("8\n"); case 7: if (k==7) printf("7\n"); and so on... }

I wondered why he put the "if" clauses, but then I noticed that none of the cases has its "break" statement, so if he found that if k was 9, the program printed 9, 8, 7, etc. So I think he added the "if" clauses to fix that behavior. [/quote]

22. Re: New switch/case idea

• Posted by jeremy (admin) Mar 31, 2009
• 1997 views

Euphoric,

I am having a bit of arguer's remorse There are two things that made me change my mind on the default... As I thought more about this, the default (as you have argued many times) is to use break, even for C programers. The way they are going to program a switch to start is probably:

switch X do 
    case 1 then 
        ? 1 
       break 
    case 2 then 
        ? 2 
        break 
end switch 

If not simply out of habit. That break is fine there. It does no harm. So, the fact that the majority of switches use break, we cover most people. The fact that the break does not cause a problem, is a benefit.

Now, the second thing that made me change my mind is we moved from : to then, and I think this is the more important change. The reason why is switch no longer looks exactly like the C switch, therefore, it's going to be someone unknown and the C programmer is going to use it cautiously knowing that it may not act how they suppose. case 3 then almost suggests when reading aloud that it's one block of code per case. So, our switch is different enough that C users are not going to simply jump in and use it without a little caution.

I guess there is a third... With the addition of with fallthru and now some form of continue, this makes the switch be able to do anything reasonable. You can default to fallthru, you can override the fallthru action with break, you can default to non-fallthru, you can override that with continue, etc...

Jeremy

24. Re: New switch/case idea

• Posted by jeremy (admin) Mar 31, 2009
• 1974 views

No, I don't think it would have been changed. Can you image the millions of billions of lines of C code that would have to be changed? We did a grep of pcre, apache, efte and euphoria. The clear norm was using break with a switch statement. Once you set the standard (in C for example) you're set. We are hoping to not make the same mistake.

We are not taking away fallthru at all, it's still there, this way you can program however you like.

Jeremy

26. Re: New switch/case idea

• Posted by kinz Apr 01, 2009
• 1965 views

on X 
    case 1 
        ? 1  
    case 2, 3, 4, "John" 
        ? 2  
end on 

Ok, but EU is case-sensitive, so we can have up to 4 options - "on X", "On X", "oN X", "ON X" just to avoid all these "with fallthrough" etc and describe the sense of options in documentation.

Same for export/public etc. Say, new "public" is old "export", but new "Public" is old "public". Also for export/public/global we can use just single "visible_N", where N may be from 1 to the maximum deep of includeing, or "includable_N", or just "up_N".

Same about "case", say, "Case" = "case ... break".

Anyway you'll need the careful learning of docs to use these complicated features.

So, the basic option must be the simplest one:

on X 
   case 1 Do(1)  -- then exit on .. end on immediatelly 
   case 2 DO(2)  -- then exit on .. end on immediatelly 
   case 3 dO(3)  -- then exit on .. end on immediatelly 
   else Do_Do()  -- then exit on .. end on - it just ends anyway 
end on 

But if someone needs break, fallthrough etc, he/she has to read docs and then use On X, or oN X, or ON X.

Just my anti-crisis $0.005

Regards,
Igor Kachan
kinz@peterlink.ru

28. Re: New switch/case idea

• Posted by kinz Apr 01, 2009
• 1993 views

HE-he-He-hE, in Russia, it is not Fool's Day, it is Day of Laughter.
Happy Laughter to you

30. Re: New switch/case idea

• Posted by Kat Apr 01, 2009
• 1951 views

X=1 
switch X with fallthru do 
    case 1: ? 1 
    case 2: ? 2 
    case 3: ? 3 
    case 4: ? 4 
    case 5: ? 5 break 
    case 6: ? 6 
    case 7: ? 7 
end switch 

How?

If x = 1, as stated, the "case 1:" is triggered, but why is 2,3,4,5 triggered??

useless

32. Re: New switch/case idea

• Posted by Kat Apr 01, 2009
• 1942 views

X=1 
switch X with fallthru do 
    case 1: ? 1 
    case 2: ? 2 
    case 3: ? 3 
    case 4: ? 4 
    case 5: ? 5 break 
    case 6: ? 6 
    case 7: ? 7 
end switch 

NONONONO!!!!!!!!!!! WAY NOOOOOO

Case is "if" eye candy, no way should another case be run! If all the remaining case bodies run regardless of the case line, then this construct is next to me... errr, useless.

useless

34. Re: New switch/case idea

• Posted by euphoric (admin) Apr 01, 2009
• 1912 views

I used to think that too, but it has a very significant speed advantage. So it's more than just candy. It's candy that's been sprinkled with speed dust!

You'll have to see the examples to understand why it's not useless. In fact, it's been said that not only will the Euphoria switch emulate other known switches, ours will be even more powerful!

Anyway... Don't worry. You are still far more useless than a switch construct.

36. Re: New switch/case idea

• Posted by Kat Apr 01, 2009
• 1947 views

-- WITH FALLTHRU EXAMPLE --- 
X=1 
switch X with fallthru do 
    case 1: ? 1 
    case 2: ? 2 
    case 3: ? 3 
    case 4: ? 4 
    case 5: ? 5 break 
    case 6: ? 6 
    case 7: ? 7 
end switch 
-- OUTPUT: 1 2 3 4 5 

-- WITHOUT FALLTHRU EXAMPLE --- 
X=1 
switch X do 
    case 1: ? 1 
    case 2: ? 2 
    case 3: ? 3 
    case 4: ? 4 
    case 5: ? 5 break 
    case 6: ? 6 
    case 7: ? 7 
end switch 
-- OUTPUT: 1 

No.

Your first example is in error because x != 2,3,4, or 5, with or without fallthru. The concept of fallthru is great where a situation is like:

X=1 
switch X with fallthru do 
    case 1: ? 1 
    case 2: ? 2 
    case 3: ? 3 
    case 1,2: ? "1 or 2" 
end switch 

OUTPUT: 1 "1 or 2"

You said:
The with fallthru clause helps in those rarer situations in which a given input is required to trigger multiple case blocks.

But the problem is, in the first example you gave, x is not 2,3,4, or 5, so they should not execute, just as if you had

X=1 
switch X do 
    case 2: ? 2 
    case 3: ? 3 
    case 4: ? 4 
end switch 

OUTPUT: none!

useless

38. Re: New switch/case idea

• Posted by DerekParnell (admin) Apr 01, 2009
• 1948 views

X=1 
switch X with fallthru do 
    case 1: ? 1 
    case 2: ? 2 
    case 3: ? 3 
    case 1,2: ? "1 or 2" 
end switch 

X=1 
switch X do 
    case 2: ? 2 
    case 3: ? 3 
    case 4: ? 4 
end switch 

I really do understand what you are saying, Kat.

Please try to understand what I'm saying. The switch statement is not syntax sugar for an if - elsif - endif series. The case clause is not an executing statement, it can be more thought of as a label.

Here are the examples written out in long hand.

-- WITH FALLTHRU EXAMPLE ---  
X=1  
temp = find(x, {1,2,3,4,5,6,7}) 
if temp = 1 then goto "case_1" end if 
if temp = 2 then goto "case_2" end if 
if temp = 3 then goto "case_3" end if 
if temp = 4 then goto "case_4" end if 
if temp = 5 then goto "case_5" end if 
if temp = 6 then goto "case_6" end if 
if temp = 7 then goto "case_7" end if 
goto "case_end" 
label "case_1" ? 1 
label "case_2" ? 2 
label "case_3" ? 3 
label "case_4" ? 4 
label "case_5" ? 5 goto "case_end" -- break statement 
label "case_6" ? 6 
label "case_7" ? 7 
label "case_end" 
-- OUTPUT: 1 2 3 4 5 

Of course, the actual 'goto' is optimised in Euphoria to be more like a computed goto.

-- WITHOUT FALLTHRU EXAMPLE ---  
X=1  
temp = find(x, {1,2,3,4,5,6,7}) 
if temp = 1 then goto "case_1" end if 
if temp = 2 then goto "case_2" end if 
if temp = 3 then goto "case_3" end if 
if temp = 4 then goto "case_4" end if 
if temp = 5 then goto "case_5" end if 
if temp = 6 then goto "case_6" end if 
if temp = 7 then goto "case_7" end if 
goto "case_end" 
label "case_1" ? 1 goto "case_end" -- because of no-fallthru default 
label "case_2" ? 2 goto "case_end" -- because of no-fallthru default 
label "case_3" ? 3 goto "case_end" -- because of no-fallthru default 
label "case_4" ? 4 goto "case_end" -- because of no-fallthru default 
label "case_5" ? 5 goto "case_end" -- break statement 
label "case_6" ? 6 goto "case_end" -- because of no-fallthru default 
label "case_7" ? 7 goto "case_end" -- because of no-fallthru default 
label "case_end" 
-- OUTPUT: 1  

You are not being forced to use the fallthru clause if its against your coding needs or principles. In the same way the "goto" is one of your coding tools but others refuse to use it, the "with fallthru" clause is a tool that some may choose or use or not, as they see fit.

We have given you the goto because of your persistant pressure and valid arguments for its inclusion. Please see that with fallthru is another coding style much like the goto statement.

40. Re: New switch/case idea

• Posted by DerekParnell (admin) Apr 01, 2009
• 1972 views

X=1 -- x = 1 
switch X do -- switch from linear code flow to "in case" 
    case 1: ? 1 -- in the case where x=1 then print 1 
    case 2: ? 2 -- in the case where x=2 then print 2 
    case 3: ? 3 -- in the case where x=3 then print 3 
    case 1,2: ? "1 or 2" -- if case is 1 or 2, print "1 or 2" 
end switch -- return to linear code flow 

I see. Of course its not English, but it could still be read kinda like...

X=1 -- x = 1 
switch X do -- switch from linear code flow to "in case" 
    case 1: ? 1 -- in the case where x=1 then start here and print 1 
                -- no fallthru so exit the switch 
    case 2: ? 2 -- in the case where x=2 then start here and then print 2 
                -- no fallthru so exit the switch 
    case 3: ? 3 -- in the case where x=3 then start here and then print 3 
                -- no fallthru so exit the switch 
    case 1,2: ? "1 or 2" -- error: these cases are already covered above. 
end switch -- return to linear code flow 

The only thing that doesn't work like you might've expected is the situation of coding a case value more than once. This is not really allowed. Otherwise the switch should work as before. There is no reason to return to a series of if-elsif statements.

42. Re: New switch/case idea

• Posted by mattlewis (admin) Apr 01, 2009
• 1960 views
• Last edited Apr 02, 2009

Non-fall through is the default. The opinions shared here were taken into account, and I really think we came up with a good solution.

'do' is redundant everywhere, but it's standard euphoria.

No, I think we're going to stick with what we've got. It's very usable, and I think fits very well within euphoria. We've taken a common programming structure, and adapted it to euphoria. That said, I think that everyone can probably find something about it that they don't like, which is the nature of compromise and consensus, which is how euphoria's switch evolved.

Matt

44. Re: New switch/case idea

• Posted by DerekParnell (admin) Apr 02, 2009
• 1953 views

myChoices = {1,2,5,"test",-5000}
 myAlpha = "abcdef" 
 switch myVar [with | without falltru] do 
  case in myChoices then [...statements...] 
  case in myAlpha then [...statements...] 
  case else [...statements...] 
 end switch 

switch myVar [with | without falltru] do
  case 1 to 50 then [...statements...] 
  case 50 to 100 then [...statements...] 
  case else [...statements...] 
 end switch 

These and other variants will be considered for after v4.0 has been released. We are delaying them because we need to get the basic functionality out there first and make it stable before we start adding the fancy stuff.

These are good suggestions by the way. You should add them to the Sourceforge site so we can track them.

46. Re: New switch/case idea

• Posted by kinz Apr 02, 2009
• 1957 views

In standard Euphoria, "do" is used in the cycle (loop) constructs only.
And in bilingual Euphoria 2.5, in Russian mode, do sounds as cycle.
I just can not translate "do" of switch\select\on as "cycle" again.
So 4.x series transforms to some mumbo-jumbo with these redundant do, which do not represent stgrongly some cycle.
Do you see this side of new syntax problem now?

Regards,
Igor Kachan
kinz@peterlink.ru

48. Re: New switch/case idea

• Posted by kinz Apr 02, 2009
• 1958 views

Yes, we have such a word, literal translation sounds as "delay". But, first, all Russian computer science tell us about cycles for these constructs, and, second, do you think I do not speak Russian?

50. Re: New switch/case idea

• Posted by DerekParnell (admin) Apr 02, 2009
• 2009 views

The English word "delay" is not the same as "do" or "perform", in fact it is almost the opposite. "delay" is used to mean "don't perform the action for now".

That's nice but so what? The word "do" does not imply a looping or cyclic action. It is used as a marker to begin the block of code that is being control by the previous statement. If that previous statement is a looping construct then "do" marks the begining of a loop, if the previous statement is not a looping construct, the "do" marks the begining of a non-looping block. Actually to be very consistent we should be using the syntax ...

if condition do 
  block 
end if 

Of course not. I do however know that I don't speak your language and I believe that English is not your primary language. So therefore, I was confirming if there was a SINGLE Russian word that means the same as the English phrase "perform an action", because that is closer to the meaning we are using "do" for than "cycle". In fact, "cycle" here in English could be a bit confusing.

In the end, I was just trying to see if there might be an alternate Russian word that you can use for all these constructs rather than the Russian that means "cycle".

52. Re: New switch/case idea

• Posted by jeremy (admin) Apr 02, 2009
• 1953 views

Kenneth, it's very easy. It's as easy as using the forum, if not easier... Just access the Add New link and it will take you to the Add Feature Request page. Fill in a subject and description, hit the add button and you're done. That quick! Actually, it's the same as the forum here.

Jeremy

54. Re: New switch/case idea

• Posted by jeremy (admin) Apr 02, 2009
• 1919 views

Thank you...

Jeremy

56. Re: New switch/case idea

• Posted by DerekParnell (admin) Apr 02, 2009
• 1954 views

I apologise for the confusion. Because you earlier used the phrase "do sounds like cycle", I assumed that "... sounds like ... " was your English for "... is Russian for ...".

I now understand you to be saying that there is a Russian word that sounds like the English word "delay" but actually means "perform".

58. Re: New switch/case idea

• Posted by bernie Apr 02, 2009
• 1946 views

Jeremy:

I disagree with you on this Jeremy.

Igor supports the Russian Euphoria site and needs to translate the source code and documents into Russian so that non English speakers can eaisly grasp and understand Euphoria that is why he needs to get more concise language meaning.

60. Re: New switch/case idea

• Posted by kinz Apr 02, 2009
• 1960 views

In standard Euphoria, the word "do" does imply namely the looping or cyclic actions, it is used only in cyclic constructs and nowhere else.

for i=1 to n by 2 do 
     ....... 
end for 
 
while a do 
     ....... 
end while 

So I'm free to translate it in its own sense - as marker of cyclic block.
In Russian it sounds as cycl.

So, what is wrong if the name of the marker of begining of the cyclic actions is cycl, as it is in bilingual EU 2.5 in Russian mode???

if condition do 
  block 
end if 

Wait a minute ... Where did you see if condition do?
The standard Euphoria doesn't have that, it has then marker here, to in Russian mode. And it is very good. In C we have { for all at all markers of begining.

Thanks Derek. Is "cycle" still confusing someone?

62. Re: New switch/case idea

• Posted by mattlewis (admin) Apr 02, 2009
• 1925 views

for i=1 to n by 2 do 
     ....... 
end for 
 
while a do 
     ....... 
end while 

No, the "do" notes the start of the basic block of code. The "for" or the "while" are where the looping semantics come from. "do" is the euphoria equivalent to a curly brace in C-like languages. So is 'then' when looking at an if statement.

You can translate it however you like, but that won't change its intended meaning.

You've put extra meaning into that keyword that was never there. It becomes really apparent now that the usage of 'do' has expanded.

if condition do 
  block 
end if 

You misread what he said. He said that to be perfectly consistent, we'd have if-do blocks instead of if-then blocks. I think the usage of 'then' is largely historical, from BASIC dialects, and is pretty widely understood.

It will perhaps confuse your Russian users, now that 'do' is used for things other than loops. While others have expressed some opinions regarding alternate ways to mark the start of the block, I don't think that anyone else has mistaken the meaning of 'do' the way that you have.

Matt

64. Re: New switch/case idea

• Posted by Kat Apr 02, 2009
• 1947 views

I think it's possible confusing "while x do" possibly being a cycle. Overall, it likely is a cycle, but "do" isn't the cycle. Euphorum has discussed replacing "do" with "then" or even making "do" or "then" be the same word, allowing "while x then" or "if x do". The only explicit loop name is "repeat", and Euphoria has no "if x repeat-until".

I don't know Russian language, i think English is hard enough to understand when two words mean almost the same and some words mean the opposite of the other meaning for the same word. If Kinz has two words to use for "then" and "do", and they are opposed to the "conventional" way of doing things, humans there will make fun of him, deride him, and not deride Euphoria. Especially if it's taught in Russian schools that "do" is English for a "while" cycle start, like "goto" is taught as being bad.

Speaking of such, Kinz, "while x" = "test x again". It might not be a loop. This is why some want to use "then" and "do" in same place, because they really mean the same thing in programming. Different English words are used to make English people happy, they simply want to say words with that placement. In Russian, perhaps you can use the same word!

useless

66. Re: New switch/case idea

• Posted by DanM Apr 02, 2009
• 1930 views

loop do 
    a = a * 2 
    x = x - 1 
until x<=0 

do 
    a = a * 2 
    x = x - 1 
  until x<=0 
end do 

cycl 
    a = a * 2 
    x = x - 1 
 kogda x<=0 -- kogda means when 
stop cycl 

Is there perhaps a Russian word for "proceed" that would work for you?

"cycle proceed" and "stop cycle" don't look too bad in English.

Dan

68. Re: New switch/case idea

• Posted by kinz Apr 02, 2009
• 1938 views

loop do 
    a = a * 2 
    x = x - 1 
until x<=0 

do 
    a = a * 2 
    x = x - 1 
  until x<=0 
end do 

cycl 
    a = a * 2 
    x = x - 1 
 kogda x<=0 -- kogda means when 
stop cycl 

Yes, why not, detailes depend on context, but Russian "cykl dalee" seems to be good for English "cycle proceed" ("cykl" is better than "cycl" in Russian).

There is interesting thing - the traditional Euphoria syntax is very convenient for adequate translation to Russian. I didn't have any questions to Rob at all.

70. Re: New switch/case idea

• Posted by kinz Apr 02, 2009
• 1938 views

Bernie, I do have the tool for translation the Russian code to English and the English code to Russian in bilingual EU 2.5. My version of ed.ex, red.ex, on 't' key translates win32lib and Judith IDE to Russian just for 1 second or so. And then exw_r.exe runs them in Russian OK. And red.ex (100% Russian code) translates itself to 100% English and ex.exe/ec.exe run it OK, same as ex_r.exe.
So this problem was solved years ago.
I use bilingual 2.5 constantly, ex_r.exe and exw_r.exe are rocky stable on DOS and Windows, but there is unknown bug in Linux version and it crashes.

72. Re: New switch/case idea

• Posted by kinz Apr 03, 2009
• 1941 views

Derek, the standard Euphoria is good thanks to almost total absence of markers similar to begin/end of Algol or Pascal, {/} of C/C and so on. We had just 2 very relevant "do". But now we have other unnecessary "do" just for so named "Euphoria style"...
They are just for extra typing, not for good economical style.
Yes, 3-rd "do" is good in loop, but without loop. Then we'll have clear series of cyclic constructs:

-------- 
for i=1 to N by 2 do 
  ..... 
end for 
-------- 
while a do 
  ..... 
end while 
-------- 
do 
  ..... 
until b 
end do 
-------- 

In such a series of constructs, "do" is not superfluous, it stands rocky.

74. Re: New switch/case idea

• Posted by bill Apr 03, 2009
• 1924 views

Reading the comments it seems to me that using a fall-through C-type switch is going away from well-structured code. I have mostly programmed in Pascal-type languages (Ada, PL/SQL etc) where sturctures like this do not exist.

It is hard to see how something like Duff's Device is needed in a high-level language. (It is also difficult to see value in a GOTO statement.)

Being able to read my code 6 months later is more important to me than raw speed or extremely succint code.

Obviously not everyone agrees.

76. Re: New switch/case idea

• Posted by jeremy (admin) Apr 03, 2009
• 1950 views

What you are able to read is what you know. Someone from from another language may come to ours and get totally tripped up the idea of a sequence, but you've been using them, thus they are easy. switch has some serious value, just look at Euphoria's source code. Switch has made life much, much easier maintaining Euphoria itself, both in the C backend and in the Euphoria front end.

Spend a little time working with it and I'm sure that you will agree.

It's like the while statement. There was a time, when it was first introduced, that people were baffled around it. They cried it's unnecessary, it'll never make it, it's so hard to follow, we have goto, there is no need for a while statement, you're just complicating the language!

switch is the same thing. Learn it and you'll love it. Almost always, if you are testing one condition, a switch is a much cleaner interface, so much easier to read than an if statement. If statements are for multiple (or complex) tests, switches are for single tests. Here's what I mean:

-- This is the reason to use an if statement: 
if validOption(optName) then 
    -- handle option 
elsif equal("--", optName) and has_verbose = TRUE then 
    -- do something 
elsif not has_shown_help and unknownOption(optName) then 
    -- show help and set has_shown_help flag 
elsif open_database_log_file(LOG_FILE) = ERROR then 
    -- exit the app with an error message 
end if 

So, in that I have multiple conditions on different values, use an if. Now, here is a valid use of a switch statement:

switch optName do 
    case "--blue", "--yellow", "--red", "--purple", "--black", "--green", "--orange" then 
        -- set the color of the background 
 
    case "--log-file", "-log-file" then 
        -- set the log file name 
 
    case "--verbose", "--max-logging" then 
        -- turn on verbose logging 
 
    case else 
        -- show help and exit, invalid option 
end switch 

Now, look how readable the switch statement is. Let's rewrite that exact simple switch in an if statement:

if find(optName, { "--blue", "--yellow", "--red", "--purple", "--black", "--green", "--orange" }) then 
    -- set the color of the background 
elsif equal(optName, "--log-file") or equal(optName, "-log-file") then 
    -- set the log file name 
elsif equal(optName, "--verbose") or equal(optName, "--max-logging") then 
    -- turn on verbose logging 
else 
    -- show help and exit, invalid option 
end if 

Which one is more clear, let typing and easier to add to, subtract from? Now, this is an easy example, you can do things differently to make both easier to understand, but it's just an example. As your application becomes more complex, the switch statement gains in clarity exponentially.

Jeremy

78. Re: New switch/case idea

• Posted by kinz Apr 04, 2009
• 1895 views

-------- 
for i=1 to N by 2 do 
  ..... 
end for 
-------- 
while a do 
  ..... 
end while 
-------- 
do 
  ..... 
until b 
end do 
-------- 

I think now, that we can change 'until' to 'while' and delete 'until' from new keywords list at all - "delete double" principle. Anti-Crisis action.

-------- 
do 
  ..... 
while c 
end do 
-------- 

Regards,
Igor Kachan
kinz@peterlink.ru

80. Re: New switch/case idea

• Posted by SDPringle Apr 04, 2009
• 1924 views

Continue is a natural thing for a language that has switches with an optional 'without fallthrough' syntax. The reason why continue was shot down was that it might have been confusing with loop control. By putting continue in the case statement itself there is no longer ambiguity.

Sometimes, you have a switch statement and most of the time you have no fallthough but occasionally you need fallthrough. So because a switch needs fallthrough 20% of the time you need to put 'break' in 80% of the switches. With Fernando's proposal the programmer can elect to put 'continue' in 20% of the statements. Look at execute.e's switch statement. Look at all of those breaks, with present syntax we cannot change it to no fallthrough because we actually need fallthrough once and a while but not often.

Presently, you have switch with fallthru for when you need to fallthrough at least once. And switch without fallthru if you never need fallthrough. What a pain if the user chooses the without fallthrough path and then finds that he needs fallthrough later.

With Fernando's proposal, you can use either with fallthrough or without no matter how many times you need to or will need fall through in the cases. The programmer can choose what is the most convienent for the particular situation.

Suppose we keep the ability to choose which default to use in a switch with 'with fallthru' or 'without fallthru' and we allow users to override with the old 'break statement' and the 'continue specifier in the case header. It's only a modification to what was agreed apon, I don't see why we cannot simply vote on that.

I don't think this new idea is mutually exclusive to what was agreed apon earlier regarding the switch statement. We have two kinds of switch statements, one with fallthru and one without. With fallthru we can override a case's behavior with a break statement so that some cases fall through. Fernando's proposal is to me like a mirror image of the break statement for the non-fallthrough world. I vote we integrate it into the existing syntax.

Shawn Pringle

82. Re: New switch/case idea

• Posted by bernie Apr 04, 2009
• 1900 views

It is time to cease the debate on the way switch/case should work.

It is time now time to use it in your code and see if it can be used in your code in it's present form.

I am having no problem adopting it to the way I like to work.

84. Re: New switch/case idea

• Posted by kinz Apr 04, 2009
• 1943 views

if condition do 
  block 
end if 

Let's better see just once more my question to Derek. I ask him - "where did you see that thing", so my understanding is - Derek, maybe, saw that thing somewere in other language. Nothing more. No? Read my words in my question to Derek again, please, and see please a paragraph after them.
Yes? Then just read once more my next words about our very good Euphoria.
To be outspoken, these my words can not be any news for Derek, I intended them for other public, nothing more.
Where is my misreading of Derek? Shoot me, I do not see!

Let's read Matt's wordings about my misreading of Derek once more.
I do not have new comments, Matt is here, his words... Maybe he wants to comment his own words and his own understanding of my misreading again.

Maybe yes, maybe no. Who knows? His own words are: "Actually to be very consistent we should be using the syntax ..." - see please above.

Ok, Dan, thanks, I do understand all these things well enough, be sure.

Our respected and dear Devs asked for new ideas on future EU, I hope my Anti-Crisis efforts were not too poor.

Ok, no problem, do you like fresh fish-soup?

Regards,
Igor Kachan
kinz@peterlink.ru

86. Re: New switch/case idea

• Posted by jimcbrown (admin) Apr 04, 2009
• 1915 views

I had prefered switch...on over the current switch...do syntax (and I would still prefer it), but I lost out on this one.

However, this gives me a new argument for switch...do. Since the official version of Russian Euphoria translated do into cykl, and this was considered an official version, we are now stuck with that translation. We can't ask kinz to change that to a different word anymore than he could ask us to change all instances of 'for...do' to 'each...do'. He has to keep cykl as the keyword for backwards compatibility. Good idea or not, mistake or not, mistranslation or not, wrong semantics or not... we are stuck with them.

It seems the best way to translate loop...do {} end loop in Russian, would be to translate it into cykl...cykl {} russian-word-for-end cykl.

I agree that switch..cykl is a bit weird. I recommend that you take the english word "on" from switch...on and translate that into Russian, and then use that Russian word with switch, instead of cykl.

Then, english version of

switch ... do

...

end switch

would become

russian-word-switch ... russian-word-on

...

russian-word-end russian-word-switch

88. Re: New switch/case idea

• Posted by jimcbrown (admin) Apr 04, 2009
• 1936 views

May I be the first to recommend that Matt Lewis take up learning Aheui (아희) ?

90. Re: New switch/case idea

• Posted by kinz Apr 05, 2009
• 1938 views

Matt, it seems to me that you won on your turn. Due to your new-invented "do-style for Euphoria", EU 4.0 is very uncomfortable for translation to 100% bilingual English-Russian version. I am really sorry.

Regards,
Igor Kachan
kinz@peterlink.ru

92. Re: New switch/case idea

• Posted by jimcbrown (admin) Apr 05, 2009
• 1901 views

The current policy is that keywords and API changes (at least major ones) are not allowed once beta has been hit. I feel that this should apply to the Russian version as well, which means that the keyword cykl is set in stone.

I still feel that changing away from switch...do to switch...on (in the English EU 4.0) is a good idea if it helps make EU 4.0 more comfortable for bilingual English-Russian version.

94. Re: New switch/case idea

• Posted by jimcbrown (admin) Apr 05, 2009
• 1886 views

switch X on 
    case 1 then 
    case 2 then 
end switch 

switch X on ... would be read in english as the following sentence:

switch X on the the following cases: on case 1 then do this, on case 2 then do that, etc.

That seems perfectly clear to me. Alternatively,

switch X from ... would be read in english as the following:

switch on X from cases 1 .. to 9: on case 1 then do this, on case 2 then do that, etc.

Although, switch X from uses an existing keyword (which means it might cause the same problem in the Russian version as 'do') and from is two more characters to type out than do or on.

96. Re: New switch/case idea

• Posted by jimcbrown (admin) Apr 05, 2009
• 1881 views

switch X on  -- this 'on' is a specific sensible and intelligent 
   case a ?1 -- marker, it is clear constuct for translation 
   case b ?2 -- to Russian and using it in pure Russian, pure 
   else   ?3 -- English or any mixed English-Russian mode. 
end switch   -- It is good known word from BASIC. 

vetvv X na   -- means branch X on 
   putt a ?1 -- means way 
   putt b ?2 -- means way 
   inache ?3 -- means else 
stop vetvv   -- means end branch 

I like your example. If I understand your idea correctly, then I give my full support to it. I think the final english syntax should be something like this:

switch X on 
   case a then 
	?1 
   case b,c,d then -- since we have multiple cases here, the 'then' is necessary 
   	?2 
   case else 
  	?3 
end switch 

'on' would be a new keyword, so for now it would not be used anywhere else. Once 4.0 beta is released (at most 1 or 2 weeks from now), the earliest a new usage of 'on' could be introduced would be for EU 4.1

However, in english 'on' has a meaning of on/off that is similar to with/without or have/not have, as well as a meaning of allow/not allow. I think 'on' has more meanings in english than 'do' does.

98. Re: New switch/case idea

• Posted by DanM Apr 06, 2009
• 1885 views

FWIW, I very much prefer your suggestion of choose over switch, although I don't exactly see how the meaning of the word "choose" differs much from "select", which I also strongly prefered over "switch" for the sake of more easily understanding what the statement means, for those like myself who are or have been unfamiliar with the term "switch" as a programming statement.

And I also like the use of "from" in the statement, because it also helps make the usage/meaning clearer.

Dan

100. Re: New switch/case idea

• Posted by irv Apr 06, 2009
• 1780 views

I am failing to detect the logic in this discussion.

switch x -- x = 1, let's say 
   case 1 : print "one" 
   case 2 : print "two" 

Why on earth would anyone EVER expect this to print "onetwo", when x = 1?

Can anyone show me a justification for this? Or any example where some other construct wouldn't do the same thing in a clearer way? Or have I simply misread some posts and don't understand?

102. Re: New switch/case idea

• Posted by useless Apr 06, 2009
• 1795 views

switch x -- x = 1, let's say 
   case 1 : print "one" 
   case 2 : print "two" 

It's NOT a logical switch, it's a closeted goto stack.

You haveto add "break" on each line.

switch x -- x = 1, let's say 
   case 1 : print "one" break 
   case 2 : print "two" break 

Sorry, Irv, i asked for goto, and sure enough, we got spagetti code from someone. Just chalk this up to "it works like this for historical C reasons" which have nothing to do with reading the source like it was a natural language. It does what it was designed to do: be a stack of goto targets, not a stack of if-thens evaluations. If it doesn't work like you want, make an if-then stack and add a goto "endofstack" to shortcut evaluation. Or, errr, no, we don't have OOEU's eval yet(?) so we cannot goto the value we seek to execute upon it being so. <cough>

useless

104. Re: New switch/case idea

• Posted by irv Apr 06, 2009
• 1812 views

	case RHS_SUBS then  
	case RHS_SUBS_CHECK then  
	case RHS_SUBS_I then  
		opRHS_SUBS()  
		break 

    	case RHS_SUBS then  
 RHS_SUBS_CHECK then  
	case RHS_SUBS_I then  
		opRHS_SUBS()  
		break

106. Re: New switch/case idea

• Posted by jimcbrown (admin) Apr 06, 2009
• 1817 views

switch x -- x = 1, let's say 
   case 1 : print "one" 
   case 2 : print "two" 

Jeremy already addressed this. However, I'd like to add that even though "switch x do" will default to without fallthru (and thus print out only "one"), you can still do this:

switch x do 
	case 1 then 
		? 1 
		fallthru 
	case 2 then 
		? 2 
		fallthru 
	case 3 then 
		? 3 
		fallthru 
	case else 
		? 0 
end switch 

At least this is more readable, since you have an explicit keyword that tells you that the case is about to fall through to the next case.

switch x -- x = 1, let's say 
   case 1 : print "one" break 
   case 2 : print "two" break 

Not any more. break is necessary now only if the entire switch is changed to "with fallthru".

If you can write the code to make the interpreter do this, you will probably getit in the next version of Eu. (I'd say more, but I'm not exactly sure what you are asking for here.)

108. Re: New switch/case idea

• Posted by jeremy (admin) Apr 06, 2009
• 1822 views

	case RHS_SUBS then  
	case RHS_SUBS_CHECK then  
	case RHS_SUBS_I then  
		opRHS_SUBS()  
		break 

    	case RHS_SUBS  
        or RHS_SUBS_CHECK   
	or RHS_SUBS_I then  
		opRHS_SUBS()  
		break 

Sort of. The later does not provide the same level of functionality, if required. For the example, they are. But say you had to increment i if RHS_SUBS, but not for RHS_SUBS_CHECK and RHS_SUBS_I... With your example of or, it would not be very easy, however, with the multiple case statement and fall thru, it's easy:

	case RHS_SUBS then  
		i += 1 
	case RHS_SUBS_CHECK then  
	case RHS_SUBS_I then  
		opRHS_SUBS()  
		break 

If it was RHS_SUBS i would be incremented by 1 and the next line to execute would be opRHS_SUBS().

Jeremy

110. Re: New switch/case idea

• Posted by DerekParnell (admin) Apr 06, 2009
• 1786 views

	case RHS_SUBS then  
	case RHS_SUBS_CHECK then  
	case RHS_SUBS_I then  
		opRHS_SUBS()  
		break 

    	case RHS_SUBS  
        or RHS_SUBS_CHECK   
	or RHS_SUBS_I then  
		opRHS_SUBS()  
		break 

Kind of ... except that we don't allow 'or' or 'and' in the case clause, and only if the first example has the "with fallthru" on its switch statement. However below are equivalent ...

    switch with fallthru do 
	case RHS_SUBS then  
	case RHS_SUBS_CHECK then  
	case RHS_SUBS_I then  
		opRHS_SUBS()  
		break 

    switch do 
    	case RHS_SUBS, RHS_SUBS_CHECK, RHS_SUBS_I then  
		opRHS_SUBS()  

Note that by default, that is if you do not put the "with fallthru" modifier in, then switch works like you thought it would. It does NOT execute anymore than one case clause. If you really want it to execute multiple case clauses you must also add the "with fallthru".

112. Re: New switch/case idea

• Posted by jeremy (admin) Apr 06, 2009
• 1811 views

switch op with fallthru do  
	case RETURNT then  
		opRETURNT()  
		break  
	case RHS_SLICE then  
		opRHS_SLICE()  
		break  

Yes. With power comes responsibility The same for while loops:

while 1 do 
    -- do something 
 
    if condition = FALSE then 
        -- let's break out of the loop here 
    end if 
 
    -- more code 
end while 

Opps! We forgot a exit there.

Jeremy

114. Re: New switch/case idea

• Posted by irv Apr 06, 2009
• 1797 views

OK, one more question. Without specifying "with fallthru" - i.e: using the defaults - then only the matching case will be executed, with or without a break being in there, is this correct? break can be left out?

116. Re: New switch/case idea

• Posted by DerekParnell (admin) Apr 06, 2009
• 1805 views

Yes. "break" is optional if you do not have "with fallthru".

If you use it, it has no effect because you don't fall through anyway.

But in the same manner, when not using "with fallthru", you can use "fallthru" at the end of the case block to force the logic flow into the next case block - if that's what you really need to do.

x = 1 
switch x do 
  case 1 then 
    procA() 
    fallthru 
  case 2 then 
    procB() 
  case 3,4 then 
    procC() 
end switch 

The logic flow does

• procA()
• procB()

118. Re: New switch/case idea

• Posted by jemima Apr 06, 2009
• 1776 views

Why not just:

case x then ...

case y then ...

^ error: "break" or "fallthrough" *MUST* be specified

BTW,the preview button is bust

120. Re: New switch/case idea

• Posted by DerekParnell (admin) Apr 06, 2009
• 1823 views

That should still work in Euphoria too, but it doesn't at the moment. I think this is a bug. To get it to work currently you have to add a label to the break clause...

  switch X label "A" do 
      case 1 then 
      . . . 
         if cond then 
             break "A" 
         end if 

</eucode>

122. Re: New switch/case idea

• Posted by DerekParnell (admin) Apr 06, 2009
• 1784 views

  switch X label "A" do 
      case 1 then 
      . . . 
         if cond then 
             break "A" 
         end if 

Oops, no its not a bug. The break statement can also be used inside if statements to break out of a deeply nested if. So a break without a label and inside an if just skips to the end if line.

124. Re: New switch/case idea

• Posted by useless Apr 06, 2009
• 1814 views

The romanized Urdu for choose is chunna or intikhaab karnaa. I'd post the cyrillic, but i don't seem to have any luck with that.

useless

126. Re: New switch/case idea

• Posted by jeremy (admin) Apr 06, 2009
• 1784 views

break will always break the inner most construct, unless given a label:

X = 1 
condition = 1 
if condition label "top_if" then 
   switch X with fallthru do 
      case 1 then 
         ? 1 
         break "top_if" 
      case 2 then 
         ? 2 
   end switch 
   ? 3 
end if 

Jeremy

128. Re: New switch/case idea

• Posted by mattlewis (admin) Apr 06, 2009
• 1833 views

Yes, just like exit or continue or retry (the last two are new in 4.0). This is to prevent having to invent extra flags and create extremely convoluted control flow:

integer exit_i = 0 
for i = 1 to 10 do 
    for j = 1 to 10 do 
        if foo(j) > bar(i) then 
            exit_i = 1 
            exit 
        end if 
    end for 
    if exit_i then 
        exit 
    end if 
end for 

That code could (in 4.0) be simplified:

for i = 1 to 10 label "i" do 
    for j = 1 to 10 do 
        if foo(j) > bar(i) then 
            exit "i" 
        end if 
    end for 
end for 

Matt

130. Re: New switch/case idea

• Posted by Fernando Apr 06, 2009
• 1856 views

switch <expr> [with fallthru] [label "<label name>"] do  
    case <val1>[, val2,...] then  
        [code block 1]  
        [break]  
    case <val2>[,...] then  
        [code block 2]  
        [break]  
    case <val3>[, ...]:  
        [code block 3]  
        [break]  
    ...  
  
    [case else]  
        [code block 4]  
        [break]  
end switch  

• It doesn't have the optional label with break in the syntax of switch statement;
• It's possible to have break inside any code block;
• Note the colon in case <val3>[, ...]:

-Fernando

132. Re: New switch/case idea

• Posted by kinz Apr 06, 2009
• 1818 views

switch X  -- pure switch 
  case a ?1 
  case b ?2 
  else   ?3 
end switch 

cascade X -- instead of switch with fallthrou 
  stage a ?1 
  stage b ?2 break 
  else    ?3 
end cascade 

I saw Niagara in my dream yesterday ...

134. Re: New switch/case idea

• Posted by Fernando Apr 06, 2009
• 1807 views

switch X  -- pure switch 
  case a ?1 
  case b ?2 
  else   ?3 
end switch 

cascade X -- instead of switch with fallthrou 
  stage a ?1 
  stage b ?2 break 
  else    ?3 
end cascade 

Here is another one using your example, which is very clear and doesn't need a new keyword like: switch or select or choose or ...

goto case X 
  case a ?1 
  case b ?2 
  else   ?3 
end case 

- Fernando

136. Re: New switch/case idea

• Posted by jeremy (admin) Apr 06, 2009
• 1798 views

I said that break breaks from it's enclosing statement, whatever that may be, a switch or if.

X = 1 
condition = 1 
switch X do 
   case 1 then 
      if condition then break end if 
      X = 2 
end switch 
? X 

That will print 2. break broke from the if, not the switch. Now, if you want it to break from the switch, you would:

X = 1 
condition = 1 
switch X label "top_switch" do 
   case 1 then 
      if condition then break "top_switch" end if 
      X = 2 
end switch 
? X 

Now X will print 1.

Jeremy