OpenEuphoria

2. Re: New Switch Idea

• Posted by jeremy (admin) Mar 27, 2009
• 1149 views

My thoughts? I personally like the idea and with the "smart switch" ability, I would prefer that the default be without fallthru. That would seem to hit the largest use of switch. Here's an example of how an undecorated switch would work if we had smart switch and the default of without fallthru:

integer X = 2 
switch X do 
  case 1: 
  case 2: 
  case 3: 
  case 4: 
  case 5: 
    puts(1, "5 or less\n") 
  case 6: 
  case 7: 
  case 8: 
  case 9: 
  case 10: 
    puts(1, "at least 6 no more than 10\n") 
  case else 
    puts(1, "less than zero or greater than 10\n") 
end switch 
 
-- output: 
-- 5 or less 

Jeremy

4. Re: New Switch Idea

• Posted by jimcbrown (admin) Mar 27, 2009
• 1113 views

I am for having "without fallthru" or "without break" be the default. I don't see an issue with the user being able to specify what they want (if they are going to be using a switch that is mostly fallthrus such as the Duff's device, then all the more power to "with break" or "with fallthru") as long as there is some mention that fallthru is on.

My personal philosphy - fallthru should be explictly stated.

Also, I know we can just use goto in a select/switch without break statement to achieve the fallthru effect. But I would prefer a new keyword that explictly turns on the fallthru effect, e.g. "fallthru" or "not break". "not break" looks more natural than "goto "some_random_label"" and is less typing (no need for a "label "some_random_label"" after the next case statement), so thats a 2-hit KO! :)

Also, I dislike colons. "switch..do" is ok, but "switch...on" sounds more natural. Also, "case..then"

6. Re: New Switch Idea

• Posted by jeremy (admin) Mar 27, 2009
• 1167 views

Bernie,

Currently sequences are allowed, but finding of one item in a sequence does not work. We are looking to expand switch/case in 4.1 for some of these options. Here are two examples:

switch "apple" do 
    case "pear": ? 1 
    case "banana": ? 2 
    case "apple": ? 3 
    case "orange": ? 4 
end switch 
 
-- Output: 3 
 
switch 1 do 
    case {1,2,3}: ? 1 
    case {4,5,6}: ? 2 
    case else 
        ? -1 
end switch 
 
-- Output: -1 

Jeremy

8. Re: New Switch Idea

• Posted by Kat Mar 27, 2009
• 1145 views

I could swear that when i asked for ranges or match() in the case line, i was told it would be too slow, and was therefore rejected. Same for eval(). Yesterday even.

Truely, useless

10. Re: New Switch Idea

• Posted by jimcbrown (admin) Mar 27, 2009
• 1133 views

I think it was just said that it'd have to wait for 4.1 since it'd need a redesign of switch. After the redesign, we'd have two types of switches (a fast one and a slower one that does eval() and such) but to the 4.1 user its all the same switch.

12. Re: New Switch Idea

• Posted by jeremy (admin) Mar 27, 2009
• 1133 views
• Last edited Mar 28, 2009

switch <expr> [(with | without fallthru)] [label "name"] [do] 
   case <valuelist> [:] 
      <statements> 
   case <valuelist> [:] 
      <statements> 
   case <valuelist> [:] 
      <statements> 
   . . . 
   case else 
      <statements> 
end switch 

If I remember correctly, we had optional then's and do's added to Euphoria and it was quickly reverted. Maybe do is not the correct word, but Jim suggested "on" which sounds nice. He also suggested case <value> then which keeps with Euphoria syntax.

We agree here.

I thought that we had decided to add things like this in 4.1? If we do that now, I believe we are changing switch quite a bit and are going to push back 4.0 further. Adding them later on does not change the syntax for switch, it will only make some things easier.

I personally, really liked the idea given by Matt, as copied from C#, of a smart switch that allowed:

switch X do 
  case 1: 
  case 2: 
  case 3: 
    -- do something 
end switch 

Now, with your full proposal of allowing case 1,2,3: I guess the smart switch does make less sense to be excited about because you solve the same problem with allowing a list of items, then the block of code. I am assuming that case 1,2,3 would be written the same as the IL code of case 1: case 2: case 3: ?

Why ignore a break? What if there were some condition in place that the user wanted to break from?

I agree also.

We don't want to make the wrong decision with switch, but I think we should be sensitive to the fact that we are now at 1 year of 4.0 being developed. If there is anything we can enhance in 4.1 without cause syntax incompatabilities, I think it should be strongly considered. With the list type syntax, I know that there were all sorts of ideas. Before moving to a situation like that, it may warrant quite a bit of planning. If we accepted the current syntax of just 1 item per case, that would not conflict with 4.1 allowing multiple values per case. I am a bit concerned that if we rush to allow multiple values per case statement that come 4.1 when we sit down and think long and hard about it that we may create a syntax incompatability, or wish we wouldn't have rushed to make it in 4.0.

Jeremy

14. Re: New Switch Idea

• Posted by DerekParnell (admin) Mar 27, 2009
• 1129 views
• Last edited Mar 28, 2009

The 'switch' is in a different situation though. In the other cases, anything could possibly occur after the 'do' keyword so it is impossible to recognise where the 'if/while/loop/etc' clause ended and the statement block started. In the 'switch' situation, the only valid thing after the 'do' is the 'case' keyword, and thus the first 'case' occurance signals the end of the 'switch' clause - the 'do' is actually redundant.

Yes 'on' is better than 'do', but is it worth a new keyword that would also be redundant?

I'm sorry, but I don't understand what you mean. Is this instead of the 'switch <expr>' or are just saying that the colon is optional?

Sure leave value lists for 4.1. I'm fine with that. It's not too hard to do anyway.

switch X do 
  case 1: 
  case 2: 
  case 3: 
    -- do something 
end switch 

At first reading I thought the empty case fallthru was a good idea too, but later I realized it would introduce an exceptional situation that may be more confusing to have than not have. It would mean that sometimes there is automatic fall though and sometimes there is not, with similar looking syntax. By not allowing zero-length statement blocks, it means that all 'case' clauses have the same default behaviour with in a switch statement.

And yes, the value list would generated IL that used the same jump-table logic as currently happens. It is just a syntax-sugar with much reduced typing.

Maybe it was poor wording on my part. What I meant was that in effect any explicit break statement at the end of the statement block would be ignored because all statement blocks would behave as if there was a 'break' already there.

Of course. But I only recall two value-list suggestions, one with braces and one with out. It was agreed that the braces would not be useful after all and could be omitted and still have a valid list.

16. Re: New Switch Idea

• Posted by Critic Mar 28, 2009
• 1099 views

My proposal:

select value do 
  case 1, 2, 3, 5..78: doA() 
  case 6, 99: doB() 
  else doC() 
end select 
 
switch value do 
  case 1, 2, 3, 5..78: doA() 
  case 6, 99: doB() 
  else doC() 
end switch 

The only difference between "switch" and "select" is that "switch" falls through, "select" does not. To avoid a fallthrough inside a "switch" a "break" statement could be allowed. Personally, I would omit "switch" completely as it is not often needed and confusing, especially since EU also targets hobby programmers. But I included it in my proposal because others want the feature.

18. Re: New Switch Idea

• Posted by jeremy (admin) Mar 28, 2009
• 1066 views

integer X = 1  
switch X with fallthru 
  case 1 
    ? 1  
  case 2  
    ? 2  
end switch  
  
-- output: 
-- 1 
-- 2  

-- output: 
-- 1 

with fallthru means that the execution will fall right thru any case statements it may find, i.e. pay no attention to them, once (and only once) a case statement caused it to start executing code in the switch. His example is correct.

switch 1 with fallthru do 
    case 1: ? 1 
    case 2: ? 2 
    case 3: ? 3 break 
    case 4: ? 4 
    case 5: ? 5 
end switch 
 
-- Output is: 
-- 1 
-- 2 
-- 3 
-- 
-- If it would have been switch 4, the output would have been 
-- 4 
-- 5 

The action you are describing would be without fallthru, i.e. switch does not just fall right through the next case statement. The next case statement after a match was found is treated as a break case.

switch 1 without fallthru do 
    case 1: ? 1 
    case 2: ? 2 
    case 3: ? 3 
    case 4: ? 4 
end switch 
 
-- Output: 
--   1 

Jeremy

20. Re: New Switch Idea

• Posted by SDPringle Mar 28, 2009
• 1096 views

Why say with or without fallthru when you could say without or with break?

switch without break -- default C like switch current behavior 
 
switch with break -- BASIC select like behavior: automatically put breaks in before each case 

Equivalent to the current idea except you don't introduce yet another keyword.

Shawn Pringle

22. Re: New Switch Idea

• Posted by mattlewis (admin) Mar 28, 2009
• 1112 views

switch without break -- default C like switch current behavior 
 
switch with break -- BASIC select like behavior: automatically put breaks in before each case 

Yes, I agree, but I think the with statement should be mandatory. Also, I'm not sure I follow the discussion regarding do. People have said that it's used for while in order to be a separator, but this isn't really true. IIRC, we put do in the switch construct to keep it consistent with other euphoria paradigms. We always have a do or then to start a code block.

I think that we should keep this consistent with switch. I'm not against using some other word, but I think we should have something there.

Matt

24. Re: New Switch Idea

• Posted by euphoric (admin) Mar 28, 2009
• 1090 views

Thanks Jeremy.

26. Re: New Switch Idea

• Posted by mattlewis (admin) Mar 28, 2009
• 1090 views

switch X do 
    case 10 then 
        ? 0 
    case 20, 30, 40, 50 then 
        ? 1 
end switch 

That does seem more euphorian.

Matt

28. Re: New Switch Idea

• Posted by Critic Mar 30, 2009
• 1090 views

Implement "select" then. Some users have already complained they don't want/understand fallthrough.

Yes, EU is quite verbose already - don't make it worse! Fallthrough is not "crystal clear", it is a wierd concept that no other control statement uses.

Provide a command line tool to rename an EU identifier. This will be very useful anyway and is not hard to do.

30. Re: New Switch Idea

• Posted by mattlewis (admin) Mar 30, 2009
• 1059 views

Yes, which is why we're discussing changing the current implementation of switch.

Yes, no other control statement uses it. So what? No other control statement besides for uses 'by'. I understand that you disagree with fall through completely. That's fine. But Euphoria will have a switch with fall through, even though probably not as the default.

It's crystal clear in that a reader could not be confused as to whether the switch was using fall through or not. Obviously, that isn't meant to explain what fall through is.

Yes, that would be useful. But it still doesn't remove the downside to adding keywords.

Matt

32. Re: New Switch Idea

• Posted by jimcbrown (admin) Mar 30, 2009
• 1034 views

Someone would still have the headache of running the tool against old source code to fix it. Doing it all at once would be a big job, and while doing it as each source file is needed (to be reused in a new app) in a step by step process might be more reasonable, this is also more drawn out.

This is the whole point of getting all such changes in 4.0 - we only want to deal with this hassle once. After 4.0 the goal is to avoid changes that break source code.

34. Re: New Switch Idea

• Posted by irv Mar 30, 2009
• 1063 views

"Critic" is beginning to sound very much like someone who got himself fired some years ago for trolling the Euphoria list.

Looking up language concepts in your schoolbooks is easy. Implementing them is not so easy. I doubt he's up to that.