1. New switch/case idea

Hi switchers smile,

Another idea:

Rather than modify 'switch', how about modify 'case' to:

'case' [<case_modifier>] <valuelist> [':' | 'then']

Suppose 'case' without modifier means without fall-through, then we could have a modifier to force fall-through:

For instance, let the keyword continue (to not add a new keyword) represents fall-through, then we could have something like this (based on Jeremy's example):

switch 1 do  
    case 1: ? 1  
    case 2: ? 2  
end switch  
  
-- Output:  
-- 1  

and

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

Features:

  • It doesn't add a new keyword or word;
  • It permits to mix with fall-through and without fall-through cases in the same switch;
  • It is easy to implement;

In fact, one <case_modifier> already exists: 'else' (for the default case).

In the future, more <case_modifiers> could be included, for example: 'in', 'range', ...

- Fernando

new topic     » topic index » view message » categorize

2. Re: New switch/case idea

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: New switch/case idea

Jeremy:

I want fall through to be the default or at least make easy to enable with a single command.

If you have a function and a large switch you can do things like the following which doesn't use break.

 
switch some_value do  
 
value1 case: 
return peek({addr,5}} 
value2 case: 
return peek({addr,32}} 
value3 case: 
return peek({addr,15}} 
value4 case: 
return peek({addr,50}} 
value5 case: 
do_my_procedure(value5, parm1) -- continues through the switch  
value6 case: 
return do_my_function(value6,parm1) 
-- ............. etc. 
end switch 
 
new topic     » goto parent     » topic index » view message » categorize

4. Re: New switch/case idea

bernie said...

I want fall through to be the default or at least make easy to enable with a single command.

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

new topic     » goto parent     » topic index » view message » categorize

5. Re: New switch/case idea

Matt:

The problem with your idea is that instead of having to type all those breaks now I would have to type all of the continues which does it make any easier.

Keep it simple, just let us turn fall through on or off.

new topic     » goto parent     » topic index » view message » categorize

6. Re: New switch/case idea

bernie said...

Matt:

The problem with your idea is that instead of having to type all those breaks now I would have to type all of the continues which does it make any easier.

Keep it simple, just let us turn fall through on or off.

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

new topic     » goto parent     » topic index » view message » categorize

7. Re: New switch/case idea

How about single colon for continue and double colon for break.

The single colon would fall through. When the parser encounters a double colon it would continue until it saw the next case keyword.

This would be easier to parse and eliminates a lot of typing and extra wording and keeps it simple in the Euphoria tradition.

new topic     » goto parent     » topic index » view message » categorize

8. Re: New switch/case idea

bernie said...

How about single colon for continue and double colon for break.

The single colon would fall through. When the parser encounters a double colon it would continue until it saw the next case keyword.

This would be easier to parse and eliminates a lot of typing and extra wording and keeps it simple in the Euphoria tradition.

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

new topic     » goto parent     » topic index » view message » categorize

9. Re: New switch/case idea

jeremy said...
bernie said...

How about single colon for continue and double colon for break.

The single colon would fall through. When the parser encounters a double colon it would continue until it saw the next case keyword.

This would be easier to parse and eliminates a lot of typing and extra wording and keeps it simple in the Euphoria tradition.

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

That's not what I'am talking about thats multiple case not multiple fall through or break.

new topic     » goto parent     » topic index » view message » categorize

10. Re: New switch/case idea

bernie said...
jeremy said...
bernie said...

How about single colon for continue and double colon for break.

The single colon would fall through. When the parser encounters a double colon it would continue until it saw the next case keyword.

This would be easier to parse and eliminates a lot of typing and extra wording and keeps it simple in the Euphoria tradition.

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

That's not what I'am talking about thats multiple case not multiple fall through or break.

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...

X Result Why
1 1 'break' stops the fall thru
2 2 5 no break so case '2' falls thru
3 2 5 no break so case '3' falls thru
4 2 5 no break so case '4' falls thru
5 5 last case
new topic     » goto parent     » topic index » view message » categorize

11. Re: New switch/case idea

The more I read about switch, select, break, continue, do, then etc, the more I'd like to see just something like to old good simplest basic's "on X goto", namely EU version:

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

Regards,
Igor Kachan
kinz@peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

12. Re: New switch/case idea

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  
new topic     » goto parent     » topic index » view message » categorize

13. Re: New switch/case idea

bernie said...

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

It has not yet been removed, but during the final stages before beta we are doing serious thinking on keeping with Euphorian type syntax. The : shouldn't have been added, we feel, in the first place. There are discussions here on EUforum about it also.

Yes, unfortuantly it means you need to change :'s to then's. We all do, especially in Euphoria itself, we have become quite custom to using switch X do... But, one part about using alpha software is that the spec will change, not maybe, but will. We are sorry for making you do that change, but sometimes things just are not found until after a bit of use and exposure, hence the alpha stages.

bernie said...

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.

It's not complex at all. It sticks with Euphoria syntax and it's clear. When quickly scanning code, it'll be hard to pickup an extra colon, or the fact that an extra colon is missing when debugging. I do not think that : vs :: is very Euphoric either. I think : vs :: is a ton of bugs begging to happen.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

14. Re: New switch/case idea

bernie said...

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

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.

new topic     » goto parent     » topic index » view message » categorize

15. Re: New switch/case idea

bernie said...

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

Welcome to alpha testing.

bernie said...

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

Why does ':' obviously mean fall through and '::' obviously mean do not fall through? How is one supposed to remember the difference? In my opinion, it would also be easy to code the wrong thing by accident, even if one did remember which was which. And locating such a bug for the code reader would also be difficult given that ':' and '::' are so similar.

The current syntax makes it explicit and clear what the switch is doing.

bernie said...

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

The style of Euphoria is based on English words and not punctuation symbols, so it was decided that ':' should be replaced by 'then' as it is similar in style to the if statement, of which switch is a variant of.

bernie said...
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  

The final syntax for this is not finalized, but one suggestion is ...

switch X do  -- by default does NOT fallthru 
  case 1 then 
     ? 1  
  case 2, 3, 4 then 
     ? 2  
     fallthru 
  case 5 then 
     ? 5 
     fallthru 
  case 30 then 
     ? 30 
     ? 123 
  case 27 then 
     ? 27 
  case 81 then 
     ? 81 
end switch  

I think that if you do some analysis you will find that the majority of switch usage is non fall through, so we have made that the default setting and this will mean less typing to do.

new topic     » goto parent     » topic index » view message » categorize

16. Re: New switch/case idea

jeremy said...

It has not yet been removed, but during the final stages before beta we are doing serious thinking on keeping with Euphorian type syntax

Jeremy

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

new topic     » goto parent     » topic index » view message » categorize

17. Re: New switch/case idea

DerekParnell said...

I think that if you do some analysis you will find that the majority of switch usage is non fall through, so we have made that the default setting and this will mean less typing to do.

Jeremy argued at one point that switch with fallthru as default was the norm for many other languages. I wonder then, if we're to introduce and welcome those programmers into the Euphoria community, we shouldn't have fallthru be the default, to keep things somewhat similar to them and lessen the learning curve a bit. Yes, I voted for "without fallthru" as default, but I'm having voter's remorse. I think the option "without fallthru" will satiate the dissenters who don't want fallthru as default.

Just throwing that out there for consideration. I don't care one way or the other. smile

new topic     » goto parent     » topic index » view message » categorize

18. Re: New switch/case idea

bernie said...
jeremy said...

It has not yet been removed, but during the final stages before beta we are doing serious thinking on keeping with Euphorian type syntax

Jeremy

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

$ 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).

new topic     » goto parent     » topic index » view message » categorize

19. Re: New switch/case idea

bernie said...

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

You have a good point. The 'X=' set are all binary operators so they are a bit different to the ':' idea which is just a syntax marker. The '$' is an odd case. It has been adopted because it is a useful shorthand for a very lengthly alternative. The ':'/'::' idea doesn't fit well there either, IMO.

new topic     » goto parent     » topic index » view message » categorize

20. Re: New switch/case idea

euphoric said...
DerekParnell said...

I think that if you do some analysis you will find that the majority of switch usage is non fall through, so we have made that the default setting and this will mean less typing to do.

Jeremy argued at one point that switch with fallthru as default was the norm for many other languages. I wonder then, if we're to introduce and welcome those programmers into the Euphoria community, we shouldn't have fallthru be the default, to keep things somewhat similar to them and lessen the learning curve a bit. Yes, I voted for "without fallthru" as default, but I'm having voter's remorse. I think the option "without fallthru" will satiate the dissenters who don't want fallthru as default.

Just throwing that out there for consideration. I don't care one way or the other. smile

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]

new topic     » goto parent     » topic index » view message » categorize

21. Re: New switch/case idea

euphoric said...
DerekParnell said...

I think that if you do some analysis you will find that the majority of switch usage is non fall through, so we have made that the default setting and this will mean less typing to do.

Jeremy argued at one point that switch with fallthru as default was the norm for many other languages. I wonder then, if we're to introduce and welcome those programmers into the Euphoria community, we shouldn't have fallthru be the default, to keep things somewhat similar to them and lessen the learning curve a bit. Yes, I voted for "without fallthru" as default, but I'm having voter's remorse. I think the option "without fallthru" will satiate the dissenters who don't want fallthru as default.

Just throwing that out there for consideration. I don't care one way or the other. smile

I agree that some programmers new to Euphoria are going to assume fallthru by default and end up writing a lot of redundant 'break' statements. And sometimes when they expect something to fall through and it doesn't, they will scratch their head. Hopefully they can read the manual to find out what's going on. The simple solution to that situation is to add the "with fallthru" to their code. No biggie and I think that over time, once they grok the default, they will appreciate not having to write so many damned "break" statements (and not having to worry about forgetting the write 'break' too).

new topic     » goto parent     » topic index » view message » categorize

22. Re: New switch/case idea

euphoric said...

Jeremy argued at one point that switch with fallthru as default was the norm for many other languages. I wonder then, if we're to introduce and welcome those programmers into the Euphoria community, we shouldn't have fallthru be the default, to keep things somewhat similar to them and lessen the learning curve a bit. Yes, I voted for "without fallthru" as default, but I'm having voter's remorse. I think the option "without fallthru" will satiate the dissenters who don't want fallthru as default.

Just throwing that out there for consideration. I don't care one way or the other. smile

Euphoric,

I am having a bit of arguer's remorse getlost 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

new topic     » goto parent     » topic index » view message » categorize

23. Re: New switch/case idea

The following source code modules that contain switch statements default to fall through.

be_alloc.c be_execute.c be_machine.c be_pcre.c be_runtime.c be_task.c

The "C" programming language has been around for 31 years. Don't you think that the default would of been changed if was warranted in 30 years ?

If you want default fall through use switch. If you want default break then you could add continue to select.

new topic     » goto parent     » topic index » view message » categorize

24. Re: New switch/case idea

bernie said...

The following source code modules that contain switch statements default to fall through.

be_alloc.c be_execute.c be_machine.c be_pcre.c be_runtime.c be_task.c

The "C" programming language has been around for 31 years. Don't you think that the default would of been changed if was warranted in 30 years ?

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

new topic     » goto parent     » topic index » view message » categorize

25. Re: New switch/case idea

kinz said...

The more I read about switch, select, break, continue, do, then etc, the more I'd like to see just something like to old good simplest basic's "on X goto", namely EU version:

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

Regards,
Igor Kachan
kinz@peterlink.ru

I happen to agree with Igor on using on X instead of "switch", although I would "re-complicate" it by allowing the "with fallthrough" & break and continue and maybe the "then". I think anyone, whether used to the idea/name "switch" or not would understand it immediatly.

This would also maybe remove the concern that programmers from other languages who expect fallthrough to be the default might be confused if not fallthrough is the default, since the word "switch" would not be there to engender any confusion re past expectations.

Dan

new topic     » goto parent     » topic index » view message » categorize

26. Re: New switch/case idea

DanM said...
kinz said...

The more I read about switch, select, break, continue, do, then etc, the more I'd like to see just something like to old good simplest basic's "on X goto", namely EU version:

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

I happen to agree with Igor on using on X instead of "switch", although I would "re-complicate" it by allowing the "with fallthrough" & break and continue and maybe the "then". I think anyone, whether used to the idea/name "switch" or not would understand it immediatly.

This would also maybe remove the concern that programmers from other languages who expect fallthrough to be the default might be confused if not fallthrough is the default, since the word "switch" would not be there to engender any confusion re past expectations.

Dan

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 smile

Regards,
Igor Kachan
kinz@peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

27. Re: New switch/case idea

kinz said...

Ok, but EU is case-sensitive, so we can have up to 4 options - "on X", "On X", "oN X", "ON X" ...

And a happy April Fool's Day to you too. smile

new topic     » goto parent     » topic index » view message » categorize

28. Re: New switch/case idea

DerekParnell said...
kinz said...

Ok, but EU is case-sensitive, so we can have up to 4 options - "on X", "On X", "oN X", "ON X" ...

And a happy April Fool's Day to you too. smile

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

new topic     » goto parent     » topic index » view message » categorize

29. Re: New switch/case idea

jeremy said...

Instead of making a 50 case switch that has case continue ... then 50 times, we could do a switch X with fallthru do.

Yes, but, sorry, except for the elegance, IMHO, that's not very relevant because:

  1. Currently, most editors have cut&paste and/or macros to do that very fast;
  2. The increase in file length is insignificant;
  3. Euphoria is a verbose language (ex.: 'end function', 'end procedure', ...).

IMHO, a case modifier, like continue, facilitates program reading, since the probability to have a complete case statement in one screen is greater than to have a complete switch statement in one screen.

Thanks for your comments,
Fernando

new topic     » goto parent     » topic index » view message » categorize

30. Re: New switch/case idea

jeremy said...
bernie said...

Matt:

The problem with your idea is that instead of having to type all those breaks now I would have to type all of the continues which does it make any easier.

Keep it simple, just let us turn fall through on or off.

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.

<snip>

How?

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

useless

new topic     » goto parent     » topic index » view message » categorize

31. Re: New switch/case idea

Kat said...
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.

How?

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

LOL! grin I was confused too, Kat. Jeremy cleared it up for me. I don't recall if it was here on the forum or on the dev's list. Basically, after the first case is met, ALL following case bodies are run, disregarding the case statement, unless a break is encountered after which it leaves the switch construct.

I'm sure someone will post a better explanation here shortly.

This is a good reason to have a very clear explanation of switch in the docs... smile

new topic     » goto parent     » topic index » view message » categorize

32. Re: New switch/case idea

euphoric said...
Kat said...
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.

How?

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

LOL! grin I was confused too, Kat. Jeremy cleared it up for me. I don't recall if it was here on the forum or on the dev's list. Basically, after the first case is met, ALL following case bodies are run, disregarding the case statement, unless a break is encountered after which it leaves the switch construct.

I'm sure someone will post a better explanation here shortly.

This is a good reason to have a very clear explanation of switch in the docs... smile

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

new topic     » goto parent     » topic index » view message » categorize

33. Re: New switch/case idea

This is simple, easily read, plain, works great:

switch sendheader[idx][1] do 
   case "GET": tempheader &= sendheader[idx][1] & sendheader[idx][2] & sendheader[idx][3] & " " & httpversion & "\r\n" break -- append the http version and flatten 
   case "POST":  tempheader &= sendheader[idx][1] & sendheader[idx][2] & sendheader[idx][3] & " " & httpversion & "\r\n" break -- append the http version and flatten 
   case else tempheader &= sendheader[idx][1] & sendheader[idx][2] & sendheader[idx][3] & "\r\n" -- else just flatten the sequence 
end switch 
 

Switch doesn't need anything else except range, or executeable case. It doesn't need "with/out fallthru", "then", "do", "continue", etc.

useless

new topic     » goto parent     » topic index » view message » categorize

34. Re: New switch/case idea

Kat said...
euphoric said...

Basically, after the first case is met, ALL following case bodies are run, disregarding the case statement, unless a break is encountered after which it leaves the switch construct.

Case is "if" eye candy...

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! smile

Kat said...

If all the remaining case bodies run regardless of the case line, then this construct is next to me... errr, useless.

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. blink

new topic     » goto parent     » topic index » view message » categorize

35. Re: New switch/case idea

Kat said...

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.

Kat, the example works that way because it has the clause with fallthru on the switch line. If one does not want it to fall through then do not use that clause. In which case only the one case block is executed.

-- 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 

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

Does that help?

new topic     » goto parent     » topic index » view message » categorize

36. Re: New switch/case idea

DerekParnell said...
Kat said...

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.

Kat, the example works that way because it has the clause with fallthru on the switch line. If one does not want it to fall through then do not use that clause. In which case only the one case block is executed.

-- 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 

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

Does that help?

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

new topic     » goto parent     » topic index » view message » categorize

37. Re: New switch/case idea

Kat said...

Your first example is in error because x != 2,3,4, or 5, with or without fallthru.

That is not an error, that is the very nature of fallthru. Think of Duff's device.

Kat said...

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"

Kat, your example (despite the presence of "with fallthru") does not have fallthru.

Kat said...

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

Wrong. The way fall through works, once a case is matched, the blocks for that case and all cases after it are executed. That is how fall through works in C, Java, etc.

What you are asking for, is to disable fallthrough altogether.

new topic     » goto parent     » topic index » view message » categorize

38. Re: New switch/case idea

Kat said...
DerekParnell said...

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

Does that help?

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!

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.

new topic     » goto parent     » topic index » view message » categorize

39. Re: New switch/case idea

DerekParnell said...
Kat said...
DerekParnell said...

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

Does that help?

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!

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.

Ok, i was reading it as english:

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 
DerekParnell said...

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.

I am not objecting to it based on code flow redirection like goto does, i am objecting to it based on logic of not executing the case conditions. I did not realise it was a computed goto. I expected it was a stack of if-elsif- statements. I recoded a section of http.e to use switch based on how it worked 3 days ago, and the new code was beautiful short clean simplicity. It doesn't work that way now, and i must return that code to the stack of if-then statements it was. Or, rather, Jeremy must. Anyhow, i guess i have made my point, and it's not valid to make it work like it did work or how i'd like to see it work.

useless

new topic     » goto parent     » topic index » view message » categorize

40. Re: New switch/case idea

Kat said...

Ok, i was reading it as english:

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 
Kat said...
DerekParnell said...

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.

I recoded a section of http.e to use switch based on how it worked 3 days ago, and the new code was beautiful short clean simplicity. It doesn't work that way now, and i must return that code to the stack of if-then statements it was. Or, rather, Jeremy must. Anyhow, i guess i have made my point, and it's not valid to make it work like it did work or how i'd like to see it work.

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.

new topic     » goto parent     » topic index » view message » categorize

41. Re: New switch/case idea

This theme was voted at dev mail list, but now there are more opinions.

I prefer non fall thru as default, as is common situations like apps processing the next key or token as ed.ex

do is redundant, as is redundant on for instruction but this is solved with auto completion editor. Editor can also add break for each "case"

If use switch cause confusion to C or JAVA users. Change to BASIC style using "select" or "on"

new topic     » goto parent     » topic index » view message » categorize

42. Re: New switch/case idea

achury said...

This theme was voted at dev mail list, but now there are more opinions.

I prefer non fall thru as default, as is common situations like apps processing the next key or token as ed.ex

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.

achury said...

do is redundant, as is redundant on for instruction but this is solved with auto completion editor. Editor can also add break for each "case"

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

achury said...

If use switch cause confusion to C or JAVA users. Change to BASIC style using "select" or "on"

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

new topic     » goto parent     » topic index » view message » categorize

43. Re: New switch/case idea

Sorry if this has been mentioned before, but I would really like to see 'in' and 'to' keywords used in the switch statement;

a) in

Using 'in' (there might be a better choice, this is the one I used) with a sequence;

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 

b) to

Using 'to';

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

Kenneth / ZNorQ

new topic     » goto parent     » topic index » view message » categorize

44. Re: New switch/case idea

znorq2 said...

Sorry if this has been mentioned before, but I would really like to see 'in' and 'to' keywords used in the switch statement;

a) in

Using 'in' (there might be a better choice, this is the one I used) with a sequence;

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 

b) to

Using 'to';

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.

new topic     » goto parent     » topic index » view message » categorize

45. Re: New switch/case idea

DerekParnell said...

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

Please, please, please add them to the tracker. I cannot express how helpful this is. It's very hard to work off the forum as a task list for all the devs. I'll take that back, not hard but nearly impossible. I cannot stress this enough. Putting your feature request or bug report into the tracker on SF.net is a sure way it will get handled, putting it on the forum is almost a sure way of getting it to be forgotten, especially when we move to 4.0 beta. We are going to be working off of the bug list on SF.net.

I'm going to post another message about this in a second, in it's own thread.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

46. Re: New switch/case idea

mattlewis said...
achury said...

do is redundant, as is redundant on for instruction but this is solved with auto completion editor. Editor can also add break for each "case"

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

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

new topic     » goto parent     » topic index » view message » categorize

47. Re: New switch/case idea

kinz said...

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?

I see this as more a problem of how you chose to translate it. Doesn't Russian have a word that means "perform the following action ..."?

new topic     » goto parent     » topic index » view message » categorize

48. Re: New switch/case idea

DerekParnell said...
kinz said...

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?

I see this as more a problem of how you chose to translate it. Doesn't Russian have a word that means "perform the following action ..."?

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?

new topic     » goto parent     » topic index » view message » categorize

49. Re: New switch/case idea

kinz said...
DerekParnell said...
kinz said...

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?

I see this as more a problem of how you chose to translate it. Doesn't Russian have a word that means "perform the following action ..."?

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?

No, he thinks you speak Russian, but that you've read more into the word "do" than is really there, and the translation seems to be affecting your interpretation of the [english] word. As a native english speaker, I can't find any connotations for "cycle" in the word "do".

From Dictionary.com (just the first two):

  1. to perform (an act, duty, role, etc.): Do nothing until you hear the bell.
  2. to execute (a piece or amount of work): to do a hauling job.

These fit very well (to me) how euphoria uses do (and the first matches Derek's suggestion). The linked page lists over 50 ways that "do" can be used, but I don't see any that have any cyclical connotations.

Matt

new topic     » goto parent     » topic index » view message » categorize

50. Re: New switch/case idea

kinz said...

Yes, we have such a word, literal translation sounds as "delay".

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".

kinz said...

But, first, all Russian computer science tell us about cycles for these constructs

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 
kinz said...

second, do you think I do not speak Russian?

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".

new topic     » goto parent     » topic index » view message » categorize

51. Re: New switch/case idea

jeremy said...
DerekParnell said...

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

Please, please, please add them to the tracker. I cannot express how helpful this is. It's very hard to work off the forum as a task list for all the devs. I'll take that back, not hard but nearly impossible. I cannot stress this enough. Putting your feature request or bug report into the tracker on SF.net is a sure way it will get handled, putting it on the forum is almost a sure way of getting it to be forgotten, especially when we move to 4.0 beta. We are going to be working off of the bug list on SF.net.

I'm going to post another message about this in a second, in it's own thread.

Jeremy

Hehe, I understand and agree - BUT - I'm not at all familiar with SF and it's functionality, so, please give me some time to familiarize myself with it (when I get the time... :( )

Kenneth / ZNorQ

new topic     » goto parent     » topic index » view message » categorize

52. Re: New switch/case idea

znorq2 said...
jeremy said...

Please, please, please add them to the tracker. I cannot express how helpful this is. It's very hard to work off the forum as a task list for all the devs. I'll take that back, not hard but nearly impossible. I cannot stress this enough. Putting your feature request or bug report into the tracker on SF.net is a sure way it will get handled, putting it on the forum is almost a sure way of getting it to be forgotten, especially when we move to 4.0 beta. We are going to be working off of the bug list on SF.net.

Hehe, I understand and agree - BUT - I'm not at all familiar with SF and it's functionality, so, please give me some time to familiarize myself with it (when I get the time... :( )

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

new topic     » goto parent     » topic index » view message » categorize

53. Re: New switch/case idea

jeremy said...
znorq2 said...
jeremy said...

Please, please, please add them to the tracker. I cannot express how helpful this is. It's very hard to work off the forum as a task list for all the devs. I'll take that back, not hard but nearly impossible. I cannot stress this enough. Putting your feature request or bug report into the tracker on SF.net is a sure way it will get handled, putting it on the forum is almost a sure way of getting it to be forgotten, especially when we move to 4.0 beta. We are going to be working off of the bug list on SF.net.

Hehe, I understand and agree - BUT - I'm not at all familiar with SF and it's functionality, so, please give me some time to familiarize myself with it (when I get the time... :( )

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

Jeremy,

Already done.

Kenneth / ZNorQ

new topic     » goto parent     » topic index » view message » categorize

54. Re: New switch/case idea

znorq2 said...

Already done.

Thank you...

Jeremy

new topic     » goto parent     » topic index » view message » categorize

55. Re: New switch/case idea

DerekParnell said...
kinz said...

Yes, we have such a word, literal translation sounds as "delay".

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".

Derek, yes, Russian word "delay" means same as English word "do" or "perform". Do you see sounds as "delay" above? It is just Latinic Russian, not English "delay".

See please my next post on this subject. Sorry, delay for LOL ...

new topic     » goto parent     » topic index » view message » categorize

56. Re: New switch/case idea

kinz said...
DerekParnell said...
kinz said...

Yes, we have such a word, literal translation sounds as "delay".

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".

Derek, yes, Russian word "delay" means same as English word "do" or "perform". Do you see sounds as "delay" above? It is just Latinic Russian, not English "delay".

See please my next post on this subject. Sorry, delay for LOL ...

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".

new topic     » goto parent     » topic index » view message » categorize

57. Re: New switch/case idea

I guess to me, and I hate to be down on anyone's language, but English is still just about the standard for programming languages. You would do yourself good to learn some of these words and learn to deal with them. Some day, if you use another language, you are going to run into all the same words. The mass amounts of Euphoria programmers are not do not speak Russian but English.

I think Euphoria's key words should be as language neutral as possible, but when in question favor English.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

58. Re: New switch/case idea

jeremy said...

I guess to me, and I hate to be down on anyone's language, but English is still just about the standard for programming languages. You would do yourself good to learn some of these words and learn to deal with them. Some day, if you use another language, you are going to run into all the same words. The mass amounts of Euphoria programmers are not do not speak Russian but English.

I think Euphoria's key words should be as language neutral as possible, but when in question favor English.

Jeremy

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.

new topic     » goto parent     » topic index » view message » categorize

59. Re: New switch/case idea

bernie said...

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.

I forgot about that. He does need a good understanding and I am not against letting him have a good understanding, I am simply saying that I do not think we should change Euphoria keywords just because they are not as clear as they could be in Russian.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

60. Re: New switch/case idea

DerekParnell said...
kinz said...

But, first, all Russian computer science tell us about cycles for these constructs

That's nice but so what? The word "do" does not imply a looping or cyclic action.

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.

DerekParnell said...

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,

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???

DerekParnell said...

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 

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.

DerekParnell said...
kinz said...

second, do you think I do not speak Russian?

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".

Thanks Derek. Is "cycle" still confusing someone?

new topic     » goto parent     » topic index » view message » categorize

61. Re: New switch/case idea

DerekParnell said...
kinz said...

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?

I see this as more a problem of how you chose to translate it. Doesn't Russian have a word that means "perform the following action ..."?

Tiggr has few single Russian words for a verb "cycle" (other than bicycle):
<V=ÑÎÂÅÐØÀÒÜ ÖÈÊË ÐÀÇÂÈÒÈß; ÄÅËÀÒÜ ÎÁÎÐÎÒÛ>

but "cycle.v" != "repeat.v" (and "repeat.v-until" loop.v != "do.v") and "do.v != "cycle.v):
<V=ÏÎÂÒÎÐßÒÜ; ÃÎÂÎÐÈÒÜ ÍÀÈÇÓÑÒÜ; ÐÅÏÅÒÈÐÎÂÀÒÜ; ÐÀÑÑÊÀÇÛÂÀÒÜ; ÏÅÐÅÄÀÂÀÒÜ; ÏÎÂÒÎÐßÒÜÑß; ÍÅÎÄÍÎÊÐÀÒÍÎ ÏÎÂÒÎÐßÒÜÑß; ÂÍÎÂÜ ÂÑÒÐÅ×ÀÒÜÑß; ÍÅÇÀÊÎÍÍÎ ÃÎËÎÑÎÂÀÒÜ ÍÀ ÂÛÁÎÐÀÕ ÍÅÑÊÎËÜÊÎ ÐÀÇ; ÎÒÐÛÃÈÂÀÒÜÑß>

"then.v" = "do.v" (but then, i do not speak Russian)...
anyhoo, this isn't a language course, but "ÄÅËÀÒÜ ÏÅÒËÞ" i think is "do loop(cycle)", and "if-then" = "if-do", so "do" = "ÄÅËÀÒÜ" or "ïðîêëàäûâàòü" or "èñïîëíÿòü" as one Russian word?

Maybe "then" = "ÂÏÐÎ×ÅÌ" or "òîãäà" , and not "ÄÅËÀÒÜ".

"cycle" is not correct for "do one time" in "if-then", so maybe Russian programming instructors have that wrong.

Kinz, i agree, "then" and "do" in programmer's language is silly, and replacing both can mean the same, but different words for different things. I have English-only text tools, and finding case-insensitive words in Russian is not possible, and i do not have Russian fonts in English text applications, so i appologize for capitalizations.

One online translation site says "do this" = "kill time".

Continue the good work, Kinz.

useless

new topic     » goto parent     » topic index » view message » categorize

62. Re: New switch/case idea

kinz said...

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 

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.

kinz said...

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

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

kinz said...
DerekParnell said...

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,

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???

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

kinz said...
DerekParnell said...

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 

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.

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.

kinz said...

Is "cycle" still confusing someone?

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

new topic     » goto parent     » topic index » view message » categorize

63. Re: New switch/case idea

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

You are correct. Standard Euphoria of the past did not use "do" to the full extent of it's meaning.

"do" also implies a beginning of an action, as well as the performing of an action.

new topic     » goto parent     » topic index » view message » categorize

64. Re: New switch/case idea

shfrance said...

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

You are correct. Standard Euphoria of the past did not use "do" to the full extent of it's meaning.

"do" also implies a beginning of an action, as well as the performing of an action.

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

new topic     » goto parent     » topic index » view message » categorize

65. Re: New switch/case idea

mattlewis said...
kinz said...

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 

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.

kinz said...

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

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

kinz said...
DerekParnell said...

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,

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???

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

kinz said...
DerekParnell said...

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 

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.

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.

kinz said...

Is "cycle" still confusing someone?

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, there is one more strange construct with that "do" in 4.0:

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

Why not to use the old good traditional EU style:

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

Then I'll translate it to Russian with great pleasure:

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

But loop do is absolutelly ugly thing in Russian. Same about do case - ugly as ... I do not know as, sorry.

new topic     » goto parent     » topic index » view message » categorize

66. Re: New switch/case idea

kinz said...

<snipped>

Matt, there is one more strange construct with that "do" in 4.0:

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

Why not to use the old good traditional EU style:

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

Then I'll translate it to Russian with great pleasure:

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

But loop do is absolutelly ugly thing in Russian. Same about do case - ugly as ... I do not know as, sorry.

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

new topic     » goto parent     » topic index » view message » categorize

67. Re: New switch/case idea

Igor:

Why don't you write a preprocessor. The preprocessor could then have RUSSIAN as the input.

The preprocessor could then translate to ENGLISH as output.

By doing that you could add any feature you wanted as long as the output matched the way the interpreter wanted to see it.

new topic     » goto parent     » topic index » view message » categorize

68. Re: New switch/case idea

DanM said...
kinz said...

<snipped>

Matt, there is one more strange construct with that "do" in 4.0:

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

Why not to use the old good traditional EU style:

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

Then I'll translate it to Russian with great pleasure:

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

But loop do is absolutelly ugly thing in Russian. Same about do case - ugly as ... I do not know as, sorry.

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.

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.

new topic     » goto parent     » topic index » view message » categorize

69. Re: New switch/case idea

kinz said...

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.

Obviously you can use whatever you feel is appropriate for your Russian speaking users, but please realize that in Euphoria, "do" does not imply a looping construct. It is just a text marker to donote the begining of a block of statements. It is equivalent to the C/C language's open-brace {, which certainly is not a loop indicator.

Prior to Euphoria v4, "do" just happened to only be used in conjunction with loops, and now it is also used with no-loop constructs. We have not changed the language in this regard because it always was used just to mark the start of a block of statements.

My fear is that you are reading into the language syntax, some semantics that were never there.

new topic     » goto parent     » topic index » view message » categorize

70. Re: New switch/case idea

bernie said...

Igor:

Why don't you write a preprocessor. The preprocessor could then have RUSSIAN as the input.

The preprocessor could then translate to ENGLISH as output.

By doing that you could add any feature you wanted as long as the output matched the way the interpreter wanted to see it.

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.

new topic     » goto parent     » topic index » view message » categorize

71. Re: New switch/case idea

My two kpeks worth on the bilingal Euphoria.

While I do not speak Russian I do speak Serbian, a member of Slavic group of languages.

I would like to suggest to Kinz to think of the loop statement not as a Cycl instruction but rather as instruction to commence a петля ( petlya) structure.

new topic     » goto parent     » topic index » view message » categorize

72. Re: New switch/case idea

DerekParnell said...
kinz said...

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.

Obviously you can use whatever you feel is appropriate for your Russian speaking users, but please realize that in Euphoria, "do" does not imply a looping construct. It is just a text marker to donote the begining of a block of statements. It is equivalent to the C/C language's open-brace {, which certainly is not a loop indicator.

Prior to Euphoria v4, "do" just happened to only be used in conjunction with loops, and now it is also used with no-loop constructs. We have not changed the language in this regard because it always was used just to mark the start of a block of statements.

My fear is that you are reading into the language syntax, some semantics that were never there.

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.

new topic     » goto parent     » topic index » view message » categorize

73. Re: New switch/case idea

Kat said...

Tiggr has few single Russian words for a verb "cycle" (other than bicycle):
<V=ÑÎÂÅÐØÀÒÜ ÖÈÊË ÐÀÇÂÈÒÈß; ÄÅËÀÒÜ ÎÁÎÐÎÒÛ>

but "cycle.v" != "repeat.v" (and "repeat.v-until" loop.v != "do.v") and "do.v != "cycle.v):
<V=ÏÎÂÒÎÐßÒÜ; ÃÎÂÎÐÈÒÜ ÍÀÈÇÓÑÒÜ; ÐÅÏÅÒÈÐÎÂÀÒÜ; ÐÀÑÑÊÀÇÛÂÀÒÜ; ÏÅÐÅÄÀÂÀÒÜ; ÏÎÂÒÎÐßÒÜÑß; ÍÅÎÄÍÎÊÐÀÒÍÎ ÏÎÂÒÎÐßÒÜÑß; ÂÍÎÂÜ ÂÑÒÐÅ×ÀÒÜÑß; ÍÅÇÀÊÎÍÍÎ ÃÎËÎÑÎÂÀÒÜ ÍÀ ÂÛÁÎÐÀÕ ÍÅÑÊÎËÜÊÎ ÐÀÇ; ÎÒÐÛÃÈÂÀÒÜÑß>

"then.v" = "do.v" (but then, i do not speak Russian)...
anyhoo, this isn't a language course, but "ÄÅËÀÒÜ ÏÅÒËÞ" i think is "do loop(cycle)", and "if-then" = "if-do", so "do" = "ÄÅËÀÒÜ" or "ïðîêëàäûâàòü" or "èñïîëíÿòü" as one Russian word?

Maybe "then" = "ÂÏÐÎ×ÅÌ" or "òîãäà" , and not "ÄÅËÀÒÜ".

Kat, sorry, it is not a readable encoding on my machine, code page was wrong somewhere.

Kat said...

"cycle" is not correct for "do one time" in "if-then", so maybe Russian programming instructors have that wrong.

We can say zero-cycle here, so it is not a problem.

Kat said...

Kinz, i agree, "then" and "do" in programmer's language is silly, and replacing both can mean the same, but different words for different things. I have English-only text tools, and finding case-insensitive words in Russian is not possible, and i do not have Russian fonts in English text applications, so i appologize for capitalizations.

e-mail please the above text to me with your Pegasus, maybe I'll read it well.

Kat said...

One online translation site says "do this" = "kill time".

Cool! smile

Kat said...

Continue the good work, Kinz.

Thanks!

Regards,
Igor Kachan
kinz@peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

74. Re: New switch/case idea

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.

new topic     » goto parent     » topic index » view message » categorize

75. Re: New switch/case idea

neophyte said...

My two kpeks worth on the bilingal Euphoria.

While I do not speak Russian I do speak Serbian, a member of Slavic group of languages.

I would like to suggest to Kinz to think of the loop statement not as a Cycl instruction but rather as instruction to commence a петля ( petlya) structure.

Thanks for two kpeks! Crisis... smile

Yes, I can do it, for example:

-- English code 
loop do  
    a = a * 2  
    x = x - 1  
until x<=0 
-- Russian code 
do_pory cykl -- "do_pory" means "to needed moment" 
    a = a * 2  
    x = x - 1  
pora x<=0    -- "pora" means "needed moment" 

You see, in Russian version, there is nothing to do with loop (petlya), but Russian version is good, clear and a bit funny. Russian coder will smile here.

The literal translation:

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

It is absolutelly wrong, ugly and laughable/ridiculous.

new topic     » goto parent     » topic index » view message » categorize

76. Re: New switch/case idea

bill said...

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.

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

new topic     » goto parent     » topic index » view message » categorize

77. Re: New switch/case idea

mattlewis said...
kinz said...

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 

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.

Matt, in BASIC language, there is DO...LOOP cyclic construct. And real semantic of this construct is not "looping" but cycling. So DO means start of cycle - and means strongly. It is old good tradition of BASIC world. Yours "do", which is equivalent to a curly brace in C-like languages, looks just as nonsense. English "loop" in program texts smells as jargon and never was translated as "petlja" in Russian computer literature. It is cycle here, in Russia.

mattlewis said...
kinz said...

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

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

My translaion is not my whim or caprice, it is just real meaning of situation. And you'd think about "its intended meaning" once more.

mattlewis said...
kinz said...
DerekParnell said...

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,

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???

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

Why do you say "that was never there"? You'd look up to BASIC, Euphoria is simpler than BASIC. BASIC has these "do", good BASIC's "do", but expanded usage of 'do' in Euphoria 4.0 looks ill-treated.

mattlewis said...
kinz said...
DerekParnell said...

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 

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.

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.

Do not explain me "what he said", please. I just can not believe that if-do is his own invention for future Euphoria, and reask him.
Then, as I can see, you do remember BASIC dialects but just forgot about BASIC's "DO".
I'm sure that BASIC's "DO" is pretty widely understood too, same as 'then', so let's not confuse BASIC's users with unnecessary, "expanded" so to say, "do" of Euphoria 4.0.

mattlewis said...
kinz said...

Is "cycle" still confusing someone?

It will perhaps confuse your Russian users, now that 'do' is used for things other than loops.

I think that yours 'do', used for things other than loops, will confuse all people wanted migrate from BASIC to Euphoria 4.0 - much more than Russians only.

mattlewis said...

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.

I do not think that some new markers are necessary in future Euphoria at all.
If you need new marker, it is a good signal to rethink your solution.
And 'do' as a marker is too bad - it has enormous amount of meanings in English, see please yours post about Dictionary on this subject.
BTW that Dictionary dosn't have one important entry - in BASIC, DO means start of cyclic construct. smile

Regards,
Igor Kachan
kinz@peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

78. Re: New switch/case idea

kinz said...

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.

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. smile

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

Regards,
Igor Kachan
kinz@peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

79. Re: New switch/case idea

kinz said...
mattlewis said...
kinz said...
DerekParnell said...

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 

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.

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.

Do not explain me "what he said", please. I just can not believe that if-do is his own invention for future Euphoria, and reask him.
<snip>

Regards,
Igor Kachan
kinz@peterlink.ru

Igor,

The reason Matt is explaining what Derek said is because, I think, you are misunderstanding what Derek said in this instance. Derek is in no way saying that if-do is "his own invention for future Euphoria". He is not suggesting that if-do should replace if-then.

if-do is an hypothetical example that he did invent to acknowledge that if Euphoria were to strictly follow the idea he is presenting that "...the "do" marks the begining of a non-looping block", then, since an if-then statement is not a LOOPING block, it "should", technically, be if-do.

But since the if-then usage and meaning is historically very clear to most programmers, there would be no good reason to change it to if-do just to be consistent with the use of "do" to mark the beginning of a non-looping block.

Just trying to clarify what I think is a misunderstanding on your part, not trying to teach a sly bear how to catch a slippery fish. blink

Dan

new topic     » goto parent     » topic index » view message » categorize

80. Re: New switch/case idea

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

new topic     » goto parent     » topic index » view message » categorize

81. Re: New switch/case idea

SDPringle said...

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.

I think what you are asking for has already been implemented.

switch 1 do -- Defaults to "without fallthru" 
   case 1 then 
       ? 1 
       fallthru 
   case 2 then 
       ? 2 
   case 3 then 
       ? 3 
end switch 

Output:
1
2

Is that what you are talking about?

new topic     » goto parent     » topic index » view message » categorize

82. Re: New switch/case idea

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.

new topic     » goto parent     » topic index » view message » categorize

83. Re: New switch/case idea

kinz said...

Matt, in BASIC language, there is DO...LOOP cyclic construct. And real semantic of this construct is not "looping" but cycling. So DO means start of cycle - and means strongly. It is old good tradition of BASIC world. Yours "do", which is equivalent to a curly brace in C-like languages, looks just as nonsense. English "loop" in program texts smells as jargon and never was translated as "petlja" in Russian computer literature. It is cycle here, in Russia.

Again, you're not understanding the english. Looping and cycling are pretty much the same thing. My russian is far worse than your english, so I won't tell you how to translate, but you're obviously not understanding the english correctly.

Matt

new topic     » goto parent     » topic index » view message » categorize

84. Re: New switch/case idea

DanM said...
kinz said...
mattlewis said...
kinz said...
DerekParnell said...

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 

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.

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.

Do not explain me "what he said", please. I just can not believe that if-do is his own invention for future Euphoria, and reask him.
<snip>

Igor,

The reason Matt is explaining what Derek said is because, I think, you are misunderstanding what Derek said in this instance. Derek is in no way saying that if-do is "his own invention for future Euphoria".

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! smile

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. smile

DanM said...

He is not suggesting that if-do should replace if-then.

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

DanM said...

if-do is an hypothetical example that he did invent to acknowledge that if Euphoria were to strictly follow the idea he is presenting that "...the "do" marks the begining of a non-looping block", then, since an if-then statement is not a LOOPING block, it "should", technically, be if-do. But since the if-then usage and meaning is historically very clear to most programmers, there would be no good reason to change it to if-do just to be consistent with the use of "do" to mark the beginning of a non-looping block.

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. smile

DanM said...

Just trying to clarify what I think is a misunderstanding on your part, not trying to teach a sly bear how to catch a slippery fish. blink

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

Regards,
Igor Kachan
kinz@peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

85. Re: New switch/case idea

mattlewis said...
kinz said...

Matt, in BASIC language, there is DO...LOOP cyclic construct. And real semantic of this construct is not "looping" but cycling. So DO means start of cycle - and means strongly. It is old good tradition of BASIC world. Yours "do", which is equivalent to a curly brace in C-like languages, looks just as nonsense. English "loop" in program texts smells as jargon and never was translated as "petlja" in Russian computer literature. It is cycle here, in Russia.

Again, you're not understanding the english. Looping and cycling are pretty much the same thing. My russian is far worse than your english, so I won't tell you how to translate, but you're obviously not understanding the english correctly.

Matt, first of all, let's talk about specific English words, not about English as a language on the whole, OK?.

Then, if your Russian is far worse than my English, and my English is not zero, so your Russian is not zero too and we can try to talk almost in Russian.
Let's try?
Loop in Russian - petlya, you know.
Cycle in Russian - cykl, almost same as in English, came from Latin, I believe.
So word "cycle" is much better for English-Russian dialog and for pogram texts than word "loop", "cycle" is an international word.
Petlya is a bit dark, gloomy word in Russian, sometimes it means the instrument for suicide. In computer Russian literature, it is very rare, used just to describe the magnetic tape way.
Loop in English doesn't mean an instrument for suicide, as far as I can find in my dictionaries. But it sounds a bit funny for Russian ear. We have some word, which means a bare head of penis, it gives good rhyme with "looping", sorry.
Do you understand Russians and loop/cycle relations a bit better now?
Very well, so, I never will recommend the "loop do" construct in future Euphoria.


Regards,
Igor Kachan
kinz@peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

86. Re: New switch/case idea

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

new topic     » goto parent     » topic index » view message » categorize

87. Re: New switch/case idea

kinz said...
mattlewis said...

Again, you're not understanding the english. Looping and cycling are pretty much the same thing. My russian is far worse than your english, so I won't tell you how to translate, but you're obviously not understanding the english correctly.

Matt, first of all, let's talk about specific English words, not about English as a language on the whole, OK?.

Yes. I'm talking specifically about 'do' and 'loop' and 'cycle'.

kinz said...

Then, if your Russian is far worse than my English, and my English is not zero, so your Russian is not zero too and we can try to talk almost in Russian.
Let's try?

I'll just take your word on Russian. My knowledge doesn't go much farther than da and nyet.

kinz said...

Loop in Russian - petlya, you know.
Cycle in Russian - cykl, almost same as in English, came from Latin, I believe.
So word "cycle" is much better for English-Russian dialog and for pogram texts than word "loop", "cycle" is an international word.
Petlya is a bit dark, gloomy word in Russian, sometimes it means the instrument for suicide. In computer Russian literature, it is very rare, used just to describe the magnetic tape way.
Loop in English doesn't mean an instrument for suicide, as far as I can find in my dictionaries. But it sounds a bit funny for Russian ear. We have some word, which means a bare head of penis, it gives good rhyme with "looping", sorry.
Do you understand Russians and loop/cycle relations a bit better now?
Very well, so, I never will recommend the "loop do" construct in future Euphoria.

Now it's my turn for random stuff. 'Do' can also refer to a hair style. Cycle can be something to ride.

The best course is probably for Russian programmers to learn english, since that's what most programming languages assume. And most programmers communicate in english, even if it isn't their first language. Jeff Atwood recently has an interesting post regarding english in programming.

Matt

new topic     » goto parent     » topic index » view message » categorize

88. Re: New switch/case idea

mattlewis said...

The best course is probably for Russian programmers to learn english, since that's what most programming languages assume. And most programmers communicate in english, even if it isn't their first language. Jeff Atwood recently has an interesting post regarding english in programming.

Matt

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

new topic     » goto parent     » topic index » view message » categorize

89. Re: New switch/case idea

jimcbrown said...

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

My hangul is a bit rusty, but that looks slightly easier to use than the original Befunge.

Matt

new topic     » goto parent     » topic index » view message » categorize

90. Re: New switch/case idea

mattlewis said...
kinz said...
mattlewis said...

Again, you're not understanding the english. Looping and cycling are pretty much the same thing. My russian is far worse than your english, so I won't tell you how to translate, but you're obviously not understanding the english correctly.

Matt, first of all, let's talk about specific English words, not about English as a language on the whole, OK?.

Yes. I'm talking specifically about 'do' and 'loop' and 'cycle'.

kinz said...

Then, if your Russian is far worse than my English, and my English is not zero, so your Russian is not zero too and we can try to talk almost in Russian.
Let's try?

I'll just take your word on Russian. My knowledge doesn't go much farther than da and nyet.

kinz said...

Loop in Russian - petlya, you know.
Cycle in Russian - cykl, almost same as in English, came from Latin, I believe.
So word "cycle" is much better for English-Russian dialog and for pogram texts than word "loop", "cycle" is an international word.
Petlya is a bit dark, gloomy word in Russian, sometimes it means the instrument for suicide. In computer Russian literature, it is very rare, used just to describe the magnetic tape way.
Loop in English doesn't mean an instrument for suicide, as far as I can find in my dictionaries. But it sounds a bit funny for Russian ear. We have some word, which means a bare head of penis, it gives good rhyme with "looping", sorry.
Do you understand Russians and loop/cycle relations a bit better now?
Very well, so, I never will recommend the "loop do" construct in future Euphoria.

Now it's my turn for random stuff. 'Do' can also refer to a hair style. Cycle can be something to ride.

The best course is probably for Russian programmers to learn english, since that's what most programming languages assume. And most programmers communicate in english, even if it isn't their first language. Jeff Atwood recently has an interesting post regarding english in programming.

Matt

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

new topic     » goto parent     » topic index » view message » categorize

91. Re: New switch/case idea

jimcbrown said...

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.

Bilingual EU 2.5 is still beta, so you are free to do what you want.

jimcbrown said...

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

Thanks jimcbrown for suggestions, but I'd prefer to discuss these things with Russian speaking guy. EU 4.0 is not comfortable for bilingual English-Russian version, sorry.

Regards,
Igor Kachan
kinz@peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

92. Re: New switch/case idea

kinz said...

Bilingual EU 2.5 is still beta, so you are free to do what you want.

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.

kinz said...

Thanks jimcbrown for suggestions, but I'd prefer to discuss these things with Russian speaking guy. EU 4.0 is not comfortable for bilingual English-Russian version, sorry.

Regards,
Igor Kachan
kinz@peterlink.ru

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.

new topic     » goto parent     » topic index » view message » categorize

93. Re: New switch/case idea

jimcbrown said...

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.

switch X on doesn't make quite the same sense to me. If I were to use switch X on, I would think it should be switch on X do case 1 etc... Because we are switching on X.

switch X on 
    case 1 then 
    case 2 then 
end switch 

That reads that we are switching on case 1 or case 2 but we are switching on X, not the case statements. So, switch on X do makes sense, but is more verbose than switch X do, adds no clarity and doesn't get rid of do.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

94. Re: New switch/case idea

jeremy said...

switch X on doesn't make quite the same sense to me. If I were to use switch X on, I would think it should be switch on X do case 1 etc... Because we are switching on X.

switch X on 
    case 1 then 
    case 2 then 
end switch 

That reads that we are switching on case 1 or case 2 but we are switching on X, not the case statements. So, switch on X do makes sense, but is more verbose than switch X do, adds no clarity and doesn't get rid of do.

Jeremy

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.

new topic     » goto parent     » topic index » view message » categorize

95. Re: New switch/case idea

jimcbrown said...
kinz said...

Bilingual EU 2.5 is still beta, so you are free to do what you want.

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.

Good policy, I like it. But I'm ready to make useful changes. But cykl is very good in Russian mode. It is anyway 'do' if you want it to be 'do' in mixed or pure English mode.

jimcbrown said...
kinz said...

Thanks jimcbrown for suggestions, but I'd prefer to discuss these things with Russian speaking guy. EU 4.0 is not comfortable for bilingual English-Russian version, sorry.

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.

I'd like to be a bit more specific, sorry:

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. 

Russian version, for example, not final:

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 

Do you ask me about such a thing? I like it, if so.
But do you use this 'on' somewhere else?
If it means direction of some other switching or such, it will be good idea too.

Regards,
Igor Kachan
kinz@peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

96. Re: New switch/case idea

kinz said...

I'd like to be a bit more specific, sorry:

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. 

Russian version, for example, not final:

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 

Do you ask me about such a thing? I like it, if so.

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 
kinz said...

But do you use this 'on' somewhere else?
If it means direction of some other switching or such, it will be good idea too.

Regards,
Igor Kachan
kinz@peterlink.ru

'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.

new topic     » goto parent     » topic index » view message » categorize

97. Re: New switch/case idea

Since we are still talking about it (although I have no problems what-so-ever of switch X do), another option is choose X from

-D

Jeremy

new topic     » goto parent     » topic index » view message » categorize

98. Re: New switch/case idea

jeremy said...

Since we are still talking about it (although I have no problems what-so-ever of switch X do), another option is choose X from

-D

Jeremy

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

new topic     » goto parent     » topic index » view message » categorize

99. Re: New switch/case idea

jimcbrown said...
kinz said...

I'd like to be a bit more specific, sorry:

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. 

Russian version, for example, not final:

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 

Do you ask me about such a thing? I like it, if so.

I like your example. If I understand your idea correctly, then I give my full support to it.

My idea was and is simple.
First of all, to give some concrete try to your too elastic suggestion "switch ... on" for Bilingual Euphoria - BEu for short - http://www.youtube.com/watch?v=L_L5qaen3Zg smile BEu is very sensitive to slightest changes in syntax and resists against any excess in code over standard Eu. So, work on BEu is not too easy, especially if the English syntax changes too quickly. Imagine please - stitching of Russian and English in Euphoria without puckers.
BEu just now at the same time, can use any mix of English and Russian 100% syntax plus identifiers in any languages - all 128..255 codes are allowed for them.
Try please to find yet another language with these features among 8500 known languages.

Then, 'on' is better than 'do' in 'switch', but it is far from sugar too, it is just some marker here, form of comment or such. But if you have a ready series of constructs with 'on', some time, it can be strongly necessary - see please my post about 3-rd 'do' in cyclic constructs.

jimcbrown said...

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 

Let me change formating of your example:

switch X on case -- two keywords in series, 'on' is new pure marker "just for BEu" 
         a  
         then ?  -- two keywords in series, 'then' is standard keyword in "if...end if" 
         1 
         case b,c,d -- "since we have multiple cases here, the 'then' is necessary"  
         then ?     -- two keywords in series, 'then' is standard keyword. 
         2          -- case b,c,d ?2 is good for parser 
         case else ? -- three keywords in series. 'case' is marker for else or what??? 
         3 
end switch 

If you read my previous posts on this subject, there are some suggestions from BEu side to English syntax.
And Russian version of 'then' keyword, 'to', is good in "if...end if" construct only. It probably will require new keywords for using in other constructs.

switch_on X   
    case a ?1  
    case b ?2  
    else   ?3  
end switch_on 
 
perekluchatt_po X      -- literal translation - from railway, electric circuits etc areas 
           kogda a ?1  -- 'when', literal translation - v_sluchae 
           kogda b ?2  -- 'when', maybe, just 'if' is good here???  
           inache  ?3  -- literal translation 
stop perekluchatt_po 

The new example above looks good for BEu. Without 'switch_' part, it looks more compactly.

jimcbrown said...
kinz said...

But do you use this 'on' somewhere else?
If it means direction of some other switching or such, it will be good idea too.

'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

I'm not sure about that 'switch ... on' for BEu anymore, sorry.

jimcbrown said...

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.

I see, 'on' has 2 pages and 'do' has 2 pages too in my Muller. But 'on' is better for 'switch' thanks to direction, on/off, placement and other suitable meanings.
For Russian-English translation with/without, turn on/off seems to be better than switch on/off - switch can change direction.

So, let's think, guys...
Code of BEu, saved in English mode, seems to work on 4.0, I'll try it later on.
My vegetable garden waits me already, sorry. smile

Regards,
Igor Kachan
kinz@peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

100. Re: New switch/case idea

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?

new topic     » goto parent     » topic index » view message » categorize

101. Re: New switch/case idea

irv said...

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?

Irv, that is the way switch is designed, for many valid reasons. We use switch galore w/your exact situation in Euphoria's internal code (both C and Euphoria).

The problem most new people have with switch is they think of it as if/elsif/elsif/else. It is not. It's more like a goto. Once a case matches, execution of the switch block continues w/o regard for any other case statement. Case statements are just labels, basically, that is used for jumping into the switch at a given location.

A switch with fallthru is not a if/elsif/else statement. Here is a valid example:

switch op with fallthru do 
	case RETURNT then 
		opRETURNT() 
		break 
	case RHS_SLICE then 
		opRHS_SLICE() 
		break 
	case RHS_SUBS then 
	case RHS_SUBS_CHECK then 
	case RHS_SUBS_I then 
		opRHS_SUBS() 
		break 
	case RIGHT_BRACE_2 then 
		opRIGHT_BRACE_2() 
		break 
	case RIGHT_BRACE_N then 
		opRIGHT_BRACE_N() 
		break 
end switch 

See for many, like RHS_SLICE, only one condition should enter the switch. However, for RHS_SUBS_*, all three of them enter and perform the same action. This is very valuable and in more complex situations (which I didn't choose here for space reasons), it saves a ton of time and makes things much clearer once you understand what a switch does. Please see the euphoria source code (both C and Euphoria code) for some pretty complex and valuable examples.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

102. Re: New switch/case idea

irv said...

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?

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

new topic     » goto parent     » topic index » view message » categorize

103. Re: New switch/case idea

kinz said...

My idea was and is simple.

Agreed.

kinz said...

And Russian version of 'then' keyword, 'to', is good in "if...end if" construct only. It probably will require new keywords for using in other constructs.

Ugh! That could be an issue. Even if we can get english eu 4.0 to move to switch..on or some other syntax, case..then will probably be kept. (It makes perfect sense as an english speaker.)

kinz said...

I'm not sure about that 'switch ... on' for BEu anymore, sorry.

switch...on only makes sense with case...then.

kinz said...

First of all, to give some concrete try to your too elastic suggestion "switch ... on" for Bilingual Euphoria - BEu for short - http://www.youtube.com/watch?v=L_L5qaen3Zg smile

I don't like watching youtube.

kinz said...

If you read my previous posts on this subject, there are some suggestions from BEu side to English syntax.

switch_on X   
    case a ?1  
    case b ?2  
    else   ?3  
end switch_on 
 
perekluchatt_po X      -- literal translation - from railway, electric circuits etc areas 
           kogda a ?1  -- 'when', literal translation - v_sluchae 
           kogda b ?2  -- 'when', maybe, just 'if' is good here???  
           inache  ?3  -- literal translation 
stop perekluchatt_po 

The new example above looks good for BEu. Without 'switch_' part, it looks more compactly.

This is very similar to Yuri's proposed optional then-do:

if a 
  ?2 
else 
  ?3 
end if 
 
while c 
 ? 1 
end while 

Which was emphatically rejected on EUforum. :/

kinz said...

So, let's think, guys...
Code of BEu, saved in English mode, seems to work on 4.0, I'll try it later on.
My vegetable garden waits me already, sorry. smile

Regards,
Igor Kachan
kinz@peterlink.ru

The underlying guideline for Euphoria, even EU 4.0, is that syntax must as closely as possible match English. The syntax sugar exists to make it easier for native English speakers to understand and pick up faster.

Applying that guideline for Russian, we can see that the syntax of Russian Euphoria must as closely as possible match Russian. It must make it easier for native Russian speakers to understand and pick up fastly.

Since a lot of the new 4.0 syntax is decidedly ugly to translate to Russian, the Russian version should break away from the English syntax when necessary in favor of forms that are more easily understood in Russian.

Therefore I really like this BEu idea. Having a separate parser for each language, so the syntax matches the native grammar best.

new topic     » goto parent     » topic index » view message » categorize

104. Re: New switch/case idea

	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
new topic     » goto parent     » topic index » view message » categorize

105. Re: New switch/case idea

	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 

So, the two above are identical?

new topic     » goto parent     » topic index » view message » categorize

106. Re: New switch/case idea

irv said...

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?

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.

useless said...

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 

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

useless said...

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

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.)

new topic     » goto parent     » topic index » view message » categorize

107. Re: New switch/case idea

irv said...
	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 

So, the two above are identical?

Yes, they are.

Here is another (this time hypothetical) example:

	case RHS_SUBS_CHECK then  
		SUBS_CHECK() 
	case RHS_SUBS_I then  
		i = get_SUBS_I() 
	case RHS_SUBS then  
		opRHS_SUBS()  
		break 
new topic     » goto parent     » topic index » view message » categorize

108. Re: New switch/case idea

irv said...
	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 

So, the two above are identical?

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

new topic     » goto parent     » topic index » view message » categorize

109. Re: New switch/case idea

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

Just so I understand: If I remove or forget the break after opRETURNT(), then regardless of whether RHS_SLICE is or isn't valid, opRHS_SLICE() gets executed, correct?

new topic     » goto parent     » topic index » view message » categorize

110. Re: New switch/case idea

irv said...
	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 

So, the two above are identical?

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".

new topic     » goto parent     » topic index » view message » categorize

111. Re: New switch/case idea

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

Just so I understand: If I remove or forget the break after opRETURNT(), then regardless of whether RHS_SLICE is or isn't valid, opRHS_SLICE() gets executed, correct?

Since you specified "switch op with fallthru do", yes.

If you had done "switch op without fallthru do" or just "switch op do", then no.

new topic     » goto parent     » topic index » view message » categorize

112. Re: New switch/case idea

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

Just so I understand: If I remove or forget the break after opRETURNT(), then regardless of whether RHS_SLICE is or isn't valid, opRHS_SLICE() gets executed, correct?

Yes. With power comes responsibility smile 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

new topic     » goto parent     » topic index » view message » categorize

113. Re: New switch/case idea

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

Just so I understand: If I remove or forget the break after opRETURNT(), then regardless of whether RHS_SLICE is or isn't valid, opRHS_SLICE() gets executed, correct?

Yes that is correct. This is how the "switch" statement works in C/C/C#/D and a few other programming languages. That is also the reason why we chose to make the default Euphoria switch different from C/C. In Euphoria, you have to explicitly tell it to enable falling through.

new topic     » goto parent     » topic index » view message » categorize

114. Re: New switch/case idea

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?

new topic     » goto parent     » topic index » view message » categorize

115. Re: New switch/case idea

irv said...

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?

This is 100% correct. break can be left out, only one matching case will be executed.

new topic     » goto parent     » topic index » view message » categorize

116. Re: New switch/case idea

irv said...

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?

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()
new topic     » goto parent     » topic index » view message » categorize

117. Re: New switch/case idea

Why not just: case x then ... case y then ... ^ error: "break" or "fallthrough" *MUST* be specified

new topic     » goto parent     » topic index » view message » categorize

118. Re: New switch/case idea

Why not just:

case x then ...

case y then ...

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

BTW,the preview button is bust

new topic     » goto parent     » topic index » view message » categorize

119. Re: New switch/case idea

DerekParnell said...
irv said...

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?

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.

If the break is not the last statement of the case and if it works as in C language, then break has an effect: it aborts the switch statement immediately.

- Fernando

new topic     » goto parent     » topic index » view message » categorize

120. Re: New switch/case idea

Fernando said...
DerekParnell said...
irv said...

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?

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.

If the break is not the last statement of the case and if it works as in C language, then break has an effect: it aborts the switch statement immediately.

- Fernando

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>

new topic     » goto parent     » topic index » view message » categorize

121. Re: New switch/case idea

DerekParnell said...

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 

break will exit the if statement, which I am not sure is something we should actually do. So, your break statement in the example, breaks from the if, not the switch. If you had

integer X = 1 
switch X do 
    case 1 then 
        X  = 2 
        break 
        X  = 3 
end switch 
? X 

it will print 2.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

122. Re: New switch/case idea

DerekParnell said...

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 

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.

new topic     » goto parent     » topic index » view message » categorize

123. Re: New switch/case idea

DanM said...
jeremy said...

Since we are still talking about it (although I have no problems what-so-ever of switch X do), another option is choose X from

-D

Jeremy

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

So, what about Jeremy's idea to use:

choose X from 
  case a then 
  case b then 
  case c then 
end choose 
instead of the word "switch"? I don't know how that translates into Russian (or Greek, or Urdu), but it looks to me to be easier for anyone not familiar with the "switch" statement to almost intuitively understand, unlike "switch".

I'd presume it could still use the same default no fall through, with options to either specify complete fall through or partial fall through as has been decided for "switch"?

Dan

new topic     » goto parent     » topic index » view message » categorize

124. Re: New switch/case idea

DanM said...

instead of the word "switch"? I don't know how that translates into Russian (or Greek, or Urdu)

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

new topic     » goto parent     » topic index » view message » categorize

125. Re: New switch/case idea

DerekParnell said...
DerekParnell said...

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 

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.

Does that mean the meaning of break depends on context ?

For example,

X = 1 
condition = 1 
if condition then 
   switch X with fallthru do 
      case 1 then 
         ? 1 
         break    -- exit switch or if ?? 
      case 2 then 
         ? 2 
   end switch 
   ? 3 
end if 
 
--shows: 
-- 1 ? 
-- or 
-- 1  
-- 3 ? 

- Fernando

new topic     » goto parent     » topic index » view message » categorize

126. Re: New switch/case idea

Fernando said...

Does that mean the meaning of break depends on context ?

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

new topic     » goto parent     » topic index » view message » categorize

127. Re: New switch/case idea

DerekParnell said...
Fernando said...

If the break is not the last statement of the case and if it works as in C language, then break has an effect: it aborts the switch statement immediately.

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 

It's not a bug. It's how the break statement works. Originally, break was added to to exit out of an if block. We didn't want to use exit, since code like this is common:

while x do 
    if foo(x) then 
        exit 
    end if 
end while 

Using similar logic, we decided to use break for the switch statement, and keep exit for loops.

Matt

new topic     » goto parent     » topic index » view message » categorize

128. Re: New switch/case idea

Fernando said...

Does that mean the meaning of break depends on context ?

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

new topic     » goto parent     » topic index » view message » categorize

129. Re: New switch/case idea

irv said...

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?

This is perhaps a good time to provide a link to the docs for switch.

Matt

new topic     » goto parent     » topic index » view message » categorize

130. Re: New switch/case idea

mattlewis said...
irv said...

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?

This is perhaps a good time to provide a link to the docs for switch.

Matt

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

new topic     » goto parent     » topic index » view message » categorize

131. Re: New switch/case idea

Fernando said...
  • 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>[, ...]:

Thanks,

Those have been fixed and committed to SVN. They will be on the web page with the next doc run.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

132. Re: New switch/case idea

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 ...

new topic     » goto parent     » topic index » view message » categorize

133. Re: New switch/case idea

kinz said...
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 ...

If the switch has "with fallthru", wouldn't it be cascode?

useless

new topic     » goto parent     » topic index » view message » categorize

134. Re: New switch/case idea

kinz said...
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 ...

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 ... smile

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

- Fernando

new topic     » goto parent     » topic index » view message » categorize

135. Re: New switch/case idea

mattlewis said...
Fernando said...

Does that mean the meaning of break depends on context ?

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

Thanks Matt, but what I was trying to ask concerning context was:

  • break inside a switch aborts the switch;
  • But if the switch is inside an if-then statement, break aborts the if-then ?, i.e., break works different if the switch is inside an if-then or not ? IIUC, Jeremy replied that break doesn't depend on the context.

Maybe this example helps me:

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

If that is valid, what will be showed ?

- Fernando

new topic     » goto parent     » topic index » view message » categorize

136. Re: New switch/case idea

Fernando said...

IIUC, Jeremy replied that break doesn't depend on the context.

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

Fernando said...

Maybe this example helps me:

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

If that is valid, what will be showed ?

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

new topic     » goto parent     » topic index » view message » categorize

137. Re: New switch/case idea

jeremy said...
Fernando said...

IIUC, Jeremy replied that break doesn't depend on the context.

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

Fernando said...

Maybe this example helps me:

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

If that is valid, what will be showed ?

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

Thanks Jeremy, but that's strange.

Does that mean that break without label inside an if-then statement is useless ?

- Fernando

new topic     » goto parent     » topic index » view message » categorize

138. Re: New switch/case idea

Fernando said...

Thanks Jeremy, but that's strange.

Does that mean that break without label inside an if-then statement is useless ?

Yes, I will wait for Matt to give some input. I do know it can be handy sometimes in nested if's. Maybe we should recosider how it works... Here's how it would work in multiple if's

procedure hi(integer x) 
    if x > 0 label "top" then 
        x += 10 
        if x > 15 then 
            break "top" 
        end if 
 
        x += 20 
    end if 
    ? x 
end procedure 
 
hi(8) -- 18 
hi(1) -- 31 

Jeremy

new topic     » goto parent     » topic index » view message » categorize

139. Re: New switch/case idea

Fernando said...

Thanks Matt, but what I was trying to ask concerning context was:

  • break inside a switch aborts the switch;
  • But if the switch is inside an if-then statement, break aborts the if-then ?, i.e., break works different if the switch is inside an if-then or not ?

I know. I showed you an analogy using exit.

Fernando said...

IIUC, Jeremy replied that break doesn't depend on the context.

Maybe this example helps me:

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

If that is valid, what will be showed ?

It should print 2, because the break jumps out of the if block. Again, this is just like trying to jump out of a while loop from within a for loop within the while loop.

Matt

new topic     » goto parent     » topic index » view message » categorize

140. Re: New switch/case idea

Fernando said...

Does that mean that break without label inside an if-then statement is useless ?

Yes, I suppose it doesn't make much sense. We could ignore the first if block for a naked break, but that might lead to more confusion than it's worth, due to the changing nature of break.

Matt

new topic     » goto parent     » topic index » view message » categorize

141. Re: New switch/case idea

mattlewis said...

Does that mean that break without label inside an if-then statement is useless ?

Yes, I suppose it doesn't make much sense. We could ignore the first if block for a naked break, but that might lead to more confusion than it's worth, due to the changing nature of break. [/quote]

Matt,

I wonder, not changing it, because it would indeed be confusing, but giving a warning if a break is given inside of an if statement w/no label? It almost always means an error. In fact, it would always mean an error? Maybe it should be an error actually? When would it ever be a good thing?

Jeremy

new topic     » goto parent     » topic index » view message » categorize

142. Re: New switch/case idea

jeremy said...

I wonder, not changing it, because it would indeed be confusing, but giving a warning if a break is given inside of an if statement w/no label? It almost always means an error. In fact, it would always mean an error? Maybe it should be an error actually? When would it ever be a good thing?

Jeremy

break is still useful for getting out of nested if statements.

However, it is hard to see a use of break for a single if-statement.

Perhaps we could only allow break to break out of an if-statement if a label is used, otherwise it defaults to break out of the switch (and is an error if there is no label and no switch).

Still, I'm a bit leery about doing this.

new topic     » goto parent     » topic index » view message » categorize

143. Re: New switch/case idea

jeremy said...
mattlewis said...

Yes, I suppose it doesn't make much sense. We could ignore the first if block for a naked break, but that might lead to more confusion than it's worth, due to the changing nature of break.

I wonder, not changing it, because it would indeed be confusing, but giving a warning if a break is given inside of an if statement w/no label? It almost always means an error. In fact, it would always mean an error? Maybe it should be an error actually? When would it ever be a good thing?

It could be 'useful' if you jumped around using goto.

Matt

new topic     » goto parent     » topic index » view message » categorize

144. Re: New switch/case idea

jimcbrown said...
jeremy said...

I wonder, not changing it, because it would indeed be confusing, but giving a warning if a break is given inside of an if statement w/no label? It almost always means an error. In fact, it would always mean an error? Maybe it should be an error actually? When would it ever be a good thing?

Jeremy

break is still useful for getting out of nested if statements.

Indeed. I like break for nested if's.

jimcbrown said...

However, it is hard to see a use of break for a single if-statement.

I can't see any use for it. It's like code after an abort() call, there is no reason, it never will be executed.

jimcbrown said...

Perhaps we could only allow break to break out of an if-statement if a label is used, otherwise it defaults to break out of the switch (and is an error if there is no label and no switch).

Still, I'm a bit leery about doing this.

I don't care for that, would cause too much confusion. I am for throwing a compile error, however in this situation:

if 1 then  
    -- do something 
    break 
end if 

A break w/o label has no place. If a user enters it, it's either because they forgot the label or they do not know what break actually does. In either case, an error should be thrown and then their will either add the label or read as to what break is.

Well, as I am thinking about this, there is one case, and it may not be a very good case, but... say you are debugging and something is wrong with your new section of code, you can add a break and that would cause from then down not to execute, but I'm not sure if that's a good enough reason to make it valid. At bare minimum we should throw a warning, but I think I am in favor of a error... Thinking aloud some more.. We have block comments now, so if you don't want the code to execute, throw a block comment around it.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

145. Re: New switch/case idea

mattlewis said...
jeremy said...
mattlewis said...

Yes, I suppose it doesn't make much sense. We could ignore the first if block for a naked break, but that might lead to more confusion than it's worth, due to the changing nature of break.

I wonder, not changing it, because it would indeed be confusing, but giving a warning if a break is given inside of an if statement w/no label? It almost always means an error. In fact, it would always mean an error? Maybe it should be an error actually? When would it ever be a good thing?

It could be 'useful' if you jumped around using goto.

Matt

LOL grin

Go wash your mouth out with soap right now young man.

  if cond then 
      goto "A" 
    label "C" 
      proc1() 
      break 
    label "B" 
      proc2() 
      goto "C" 
    label "A" 
      proc3() 
      goto "B" 
  end if 

... preparing the gallows as we speak ...

new topic     » goto parent     » topic index » view message » categorize

146. Re: New switch/case idea

mattlewis said...

It could be 'useful' if you jumped around using goto.

In that case you should use a goto to jump out of the if, IMHO. Here is presumably what you are speaking of?

integer X = 1 
if X > 0 then 
    X += 1    
 
    if X = 2 then 
        goto "continue_if" 
    end if 
 
    X = 0 
 
    break 
 
glabel "continue_if" 
    X += 3 
end if 

It enters the first if, making X 1, then the second making X 2, and it jumps and adds 3 more to X, making X 5. However, if X were, say 20, then X would have 1 added to it, then be 21, not meet the 2nd if's condition and become 0.

I'd probably write the above as (if I was that contorted):

integer X = 1 
if X > 0 then 
    X += 1    
 
    if X <> 2 then 
        X = 0 
        goto "done" 
    end if 
 
    X += 3 
end if 
 
glabel "done" 

Thing is it can still be accomplished w/o an empty break and if they are going to be using goto anyway, better for just one jump.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

147. Re: New switch/case idea

jeremy said...
jimcbrown said...

However, it is hard to see a use of break for a single if-statement.

I can't see any use for it. It's like code after an abort() call, there is no reason, it never will be executed.

Actually, break doesn't have an effect in a while loop right? So someone could code up:

if x then 
	while y do 
		if z then 
			retry 
		end if 
		break 
	end while 
end if 

A more fleshed out example:

if fn != -1 then 
	text = "" 
	for i = 1 to nbytes do -- at most read nbytes bytes 
		integer c = getc(fn) 
		s &= c 
		if s != -1 then 
			continue 
		end if 
		break 
	end while 
end if 

Granted, there are much saner ways of doing that...

jeremy said...
jimcbrown said...

Perhaps we could only allow break to break out of an if-statement if a label is used, otherwise it defaults to break out of the switch (and is an error if there is no label and no switch).

Still, I'm a bit leery about doing this.

I don't care for that, would cause too much confusion.

Agreed. It is a bad idea.

jeremy said...

I am for throwing a compile error, however in this situation:

if 1 then  
    -- do something 
    break 
end if 

A break w/o label has no place. If a user enters it, it's either because they forgot the label or they do not know what break actually does. In either case, an error should be thrown and then their will either add the label or read as to what break is.

Require all breaks in an if-statement to have a label? I'm still a bit leery about doing that as well.

jeremy said...

Well, as I am thinking about this, there is one case, and it may not be a very good case, but... say you are debugging and something is wrong with your new section of code, you can add a break and that would cause from then down not to execute, but I'm not sure if that's a good enough reason to make it valid. At bare minimum we should throw a warning, but I think I am in favor of a error...

At the moment we have the same situation with the return keyword. I used to just stick a return in a function to have it ignore the code below, though that would generate a warning.

With multiline coments though, do we really still need this?

jeremy said...

Thinking aloud some more.. We have block comments now, so if you don't want the code to execute, throw a block comment around it.

Jeremy

Or use an ifdef, etc.

new topic     » goto parent     » topic index » view message » categorize

148. Re: New switch/case idea

jeremy said...
mattlewis said...

It could be 'useful' if you jumped around using goto.

In that case you should use a goto to jump out of the if, IMHO. Here is presumably what you are speaking of?

integer X = 1 
if X > 0 then 
    X += 1    
 
    if X = 2 then 
        goto "continue_if" 
    end if 
 
    X = 0 
 
    break 
 
glabel "continue_if" 
    X += 3 
end if 

It enters the first if, making X 1, then the second making X 2, and it jumps and adds 3 more to X, making X 5. However, if X were, say 20, then X would have 1 added to it, then be 21, not meet the 2nd if's condition and become 0.

I'd probably write the above as (if I was that contorted):

integer X = 1 
if X > 0 then 
    X += 1    
 
    if X <> 2 then 
        X = 0 
        goto "done" 
    end if 
 
    X += 3 
end if 
 
glabel "done" 

Thing is it can still be accomplished w/o an empty break and if they are going to be using goto anyway, better for just one jump.

Jeremy

Really? I'd write it more like ...

if X > 0 then 
    X += 1    
 
    if X = 2 then 
        X = 5 
    else 
        X = 0 
    end if 
 
end if 

No labels nor goto.

new topic     » goto parent     » topic index » view message » categorize

149. Re: New switch/case idea

DerekParnell said...

Really? I'd write it more like ...

No, I wouldn't write it how I did. Something as simple as what I suggested would be much easier how you wrote it, no sane person would write it as I did. I was just making a simple/easy to follow example of what Matt suggested for the need of having a bare break statement. He suggested that it could be useful if there was a goto statement jumping around the break. So, I coded an example w/a goto jumping around the break, then showed how the goto jump could still work w/o the break.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

150. Re: New switch/case idea

kinz said...
switch X  -- pure switch 
  case a ?1 
  case b ? 
  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 ...

It seems to be not that bad, but I can do cyclic switch and cascade in bilingual mode ...

switch X do -- cyclic switch, thanks to 'do' keyword 
  case a ?1 
  case b X+=1 
  else exit 
end switch 
cascade X do -- cyclic caskade, thanks to 'do' keyword 
  stage a ?1 
  stage b X-=1 
  else exit 
end cascade 


BEu

new topic     » goto parent     » topic index » view message » categorize

151. Re: New switch/case idea

kinz said...
BEu said...
switch X  -- pure switch 
  case a ?1 
  case b ? 
  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 ...

It seems to be not that bad, but I can do cyclic switch and cascade in bilingual mode ...

switch X do -- cyclic switch, thanks to 'do' keyword 
  case a ?1 
  case b X+=1 
  else exit 
end switch 
cascade X do -- cyclic caskade, thanks to 'do' keyword 
  stage a ?1 
  stage b X-=1 
  else exit 
end cascade 


BEu

Yes, I just didn't see Niagara turned up-down, up-down ...

new topic     » goto parent     » topic index » view message » categorize

152. Re: New switch/case idea

kinz said...
kinz said...
BEu said...
switch X  -- pure switch 
  case a ?1 
  case b ? 
  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 ...

It seems to be not that bad, but I can do cyclic switch and cascade in bilingual mode ...

switch X do -- cyclic switch, thanks to 'do' keyword 
  case a ?1 
  case b X+=1 
  else exit 
end switch 
cascade X do -- cyclic caskade, thanks to 'do' keyword 
  stage a ?1 
  stage b X-=1 
  else exit 
end cascade 


BEu

Yes, I just didn't see Niagara turned up-down, up-down ...

Maybe we can delete some doubles, BEu, let's try:

try X [do] -- with 'do' cyclic, without 'do' simple one go 
  stage a ?1   -- cascadeing part  
  stage b X-=1 
  case  c ?2   -- switching part 
  case  d ?3   
  else exit 
end try 

Hmm... Hmm... Seems to work in bilingual mode too ...

new topic     » goto parent     » topic index » view message » categorize

153. Re: New switch/case idea

jeremy said...
DerekParnell said...

Really? I'd write it more like ...

No, I wouldn't write it how I did. Something as simple as what I suggested would be much easier how you wrote it, no sane person would write it as I did. I was just making a simple/easy to follow example of what Matt suggested for the need of having a bare break statement. He suggested that it could be useful if there was a goto statement jumping around the break. So, I coded an example w/a goto jumping around the break, then showed how the goto jump could still work w/o the break.

For the record, I wasn't advocating anything there. And I didn't say it was useful. I said it was 'useful'. I didn't say that we needed it, either.

I can't imagine ever trying to do that, unless I were intentionally writing obfuscated code. A compiler error probably makes sense for this. If you're determined to do this, then you can use a label for your if statement.

Matt

new topic     » goto parent     » topic index » view message » categorize

154. Re: New switch/case idea

jeremy said...
Fernando said...
X = 1 
condition = 1 
switch X do 
   case 1 then 
      if condition then break end if 
      X = 2 
end switch 
? X 

If that is valid, what will be showed ?

That will print 2.

You have clearly all gone stark raving bonkers...

What happened to the concept of READABLE code???

new topic     » goto parent     » topic index » view message » categorize

155. Re: New switch/case idea

jemima said...
jeremy said...
Fernando said...
X = 1 
condition = 1 
switch X do 
   case 1 then 
      if condition then break end if 
      X = 2 
end switch 
? X 

If that is valid, what will be showed ?

That will print 2.

You have clearly all gone stark raving bonkers...

What happened to the concept of READABLE code???

Nothing. Does that mean that we shouldn't explore edge cases, and consider fully the consequences of syntax decisions? This is an important part of language design. I'm not sure what your point is...

Matt

new topic     » goto parent     » topic index » view message » categorize

156. Re: New switch/case idea

jemima said...

You have clearly all gone stark raving bonkers...

What happened to the concept of READABLE code???

We were exploring what would happen under rare cases. The example was not something that would actually be programmed. You can program contorted things with any of our constructs and make totally unreadable code. However, when switch is used correctly it makes very maintainable, clear, beautiful code.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

157. Re: New switch/case idea

said...

At the moment we have the same situation with the return keyword. I used to just stick a return in a function to have it ignore the code below, though that would generate a warning.

With multiline coments though, do we really still need this?

Absolutely. If I'm testing something and want to quickly disable 7 blocks of code, I need the break and to force me to block comment would be a huge drain.

new topic     » goto parent     » topic index » view message » categorize

158. Re: New switch/case idea

jemima said...
jeremy said...
Fernando said...
X = 1 
condition = 1 
switch X do 
   case 1 then 
      if condition then break end if 
      X = 2 
end switch 
? X 

If that is valid, what will be showed ?

That will print 2.

You have clearly all gone stark raving bonkers...

What happened to the concept of READABLE code???

I think you are ignoring the fact that these examples are merely proof of concept. There are many circumstances where code will appear to be less than perfectly efficient, but will be perfectly appropriate because it self-documents a process which mimics the real world. Substitute "IRS_audits_me" for condition and then see if you don't want a placeholder in your code as you design, and debug, a complete response.

new topic     » goto parent     » topic index » view message » categorize

159. Re: New switch/case idea

Mike777 said...
said...

At the moment we have the same situation with the return keyword. I used to just stick a return in a function to have it ignore the code below, though that would generate a warning.

With multiline coments though, do we really still need this?

Absolutely. If I'm testing something and want to quickly disable 7 blocks of code, I need the break and to force me to block comment would be a huge drain.

I disagree totally here. break can introduce bugs as it changes the logical flow of your code. You may be breaking to a place you didn't count on. When you comment the code out, you comment it out and it's gone. You know what I mean by block/multi-line comments, right?

This is now valid in Euphoria:

if TRUE then 
    a = 10 
    b = 20 
 
    -- there is some bug here, let's get rid of this code 
    /* 

    a = b * 20 
    b = c * 90 
    d = a + b / 39 
    */ 
end if 

That whole block of code is now gone from IL. It's all a comment. There is no reason to:

if TRUE then 
    a = 10 
    b = 20 
 
    -- there is some bug here, let's get rid of this code 
    --a = b * 20 
    --b = c * 90 
    --d = a + b / 39 
end if 

anymore since we have multi-line comments. A multi-line comment is much more clear, robust and much less error prone then trying to use break or goto to skip a section of code that you are testing/not testing.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

160. Re: New switch/case idea

jeremy said...
Mike777 said...
said...

At the moment we have the same situation with the return keyword. I used to just stick a return in a function to have it ignore the code below, though that would generate a warning.

With multiline coments though, do we really still need this?

Absolutely. If I'm testing something and want to quickly disable 7 blocks of code, I need the break and to force me to block comment would be a huge drain.

I disagree totally here. break can introduce bugs as it changes the logical flow of your code. You may be breaking to a place you didn't count on. When you comment the code out, you comment it out and it's gone. You know what I mean by block/multi-line comments, right?

This is now valid in Euphoria:

if TRUE then 
    a = 10 
    b = 20 
 
    -- there is some bug here, let's get rid of this code 
    /* 

    a = b * 20 
    b = c * 90 
    d = a + b / 39 
    */ 
end if 

That whole block of code is now gone from IL. It's all a comment. There is no reason to:

if TRUE then 
    a = 10 
    b = 20 
 
    -- there is some bug here, let's get rid of this code 
    --a = b * 20 
    --b = c * 90 
    --d = a + b / 39 
end if 

anymore since we have multi-line comments. A multi-line comment is much more clear, robust and much less error prone then trying to use break or goto to skip a section of code that you are testing/not testing.

Jeremy

Well, I can't argue with the fact that a break can potentially change the logic flow. If that is the only criteria for disallowing it in this circumstance, I feel the argument is fairly weak. If there is one area where Euphoria does not shine it is in the area of debugging, so I would err on the side of aiding that effort, even if it allowed me some rope that I *might* end up hanging myself with.

Encasing a short bit of code in a block comment is not a problem.

But just like the comment I made a few posts ago, don't confuse these short examples for real-world programs. I might have a SWITCH (or any other logic selection statement) associated with blocks of code that are multiple-screens long. And I might have 30 of them, rather than just one or two. And if you force me to find both the top and the bottom of each section, to insert the block comment indicators (or remove them), I promise you I will instead use the GOTO construct.

new topic     » goto parent     » topic index » view message » categorize

161. Re: New switch/case idea

Mike777 said...

Well, I can't argue with the fact that a break can potentially change the logic flow. If that is the only criteria for disallowing it in this circumstance, I feel the argument is fairly weak. If there is one area where Euphoria does not shine it is in the area of debugging, so I would err on the side of aiding that effort, even if it allowed me some rope that I *might* end up hanging myself with.

Encasing a short bit of code in a block comment is not a problem.

But just like the comment I made a few posts ago, don't confuse these short examples for real-world programs. I might have a SWITCH (or any other logic selection statement) associated with blocks of code that are multiple-screens long. And I might have 30 of them, rather than just one or two. And if you force me to find both the top and the bottom of each section, to insert the block comment indicators (or remove them), I promise you I will instead use the GOTO construct.

I would argue the larger the switch gets the more complex "break" for a debug construct gets. BTW... In Euphoria's source code, we have switches that are > 200 case statements long.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

162. Re: New switch/case idea

Dear Devs,

Let's see one specific example of switch, used in compile.e :

  switch name do 
    case "AND_BITS": 
       operation[i] = routine_id("opAND_BITS") 
	   break 
				 
			 
    case "AND": 
       operation[i] = routine_id("opAND") 
	   break 
				 
			 
    case "APPEND": 
       operation[i] = routine_id("opAPPEND") 
 	   break 
				 
			 
    case "ARCTAN": 
       operation[i] = routine_id("opARCTAN") 
	   break 
			 
			 
    case "ASSIGN_I": 
	operation[i] = routine_id("opASSIGN_I") 
	   break 
		 
			 
    case "ASSIGN_OP_SLICE": 
	operation[i] = routine_id("opASSIGN_OP_SLICE") 
	   break 
	 
            ... 

Why not to code this strongly switching, not cascadeing, part just as:

sequence routine_name 
 
   routine_name = { 
  
   "opAND_BITS",         -- AND_BITS 
   "opAND",              -- AND 
   "opAPPEND",           -- APPEND 
   "opARCTAN",           -- ARCTAN 
   "opASSIGN_I",         -- ASSIGN_I 
   "opASSIGN_OP_SLICE",  -- ASSIGN_OP_SLICE 
   } 
 
   for i=1 to length(routine_name) do 
              operation[i] = routine_id(routine_name[i]) 
   end for 
 

Or, maybe :

sequence Name 
 
   Name = { 
   "AND_BITS", 
   "AND", 
   "APPEND", 
   "ARCTAN", 
   "ASSIGN_I", 
   "ASSIGN_OP_SLICE", 
   ... 
   } 
 
   for i=1 to length(Name) do 
              operation[i] = routine_id("op" & Name[i]) 
   end for 

Just curious... Looks just as reordering and renameing of opnames ...
Anyway you reorder and rename them by hands in switch blok code, no?


kinz

new topic     » goto parent     » topic index » view message » categorize

163. Re: New switch/case idea

Let's see the first cascadeing section:

case "ASSIGN_OP_SUBS": 
case "PASSIGN_OP_SUBS": 
case "RHS_SUBS_CHECK": 
case "RHS_SUBS_I": 
   operation[i] = routine_id("opRHS_SUBS") 
            break 

I'd just add section to routine_name sequence with same names,
routine_id will just emite same numbers.

  ...    
"opRHS_SUBS", --ASSIGN_OP_SUBS  -- same routine_id for series of opnames 
"opRHS_SUBS", --PASSIGN_OP_SUBS 
"opRHS_SUBS", --RHS_SUBS_CHECK 
"opRHS_SUBS", --RHS_SUBS_I 
  ... 

Again curious ... Where am I wrong???


kinz

new topic     » goto parent     » topic index » view message » categorize

164. Re: New switch/case idea

kinz said...

Dear Devs,

Let's see one specific example of switch, used in compile.e :

Why not to code this strongly switching, not cascadeing, part just as:

sequence routine_name 
 
   routine_name = { 
  
   "opAND_BITS",         -- AND_BITS 
   "opAND",              -- AND 
   "opAPPEND",           -- APPEND 
   "opARCTAN",           -- ARCTAN 
   "opASSIGN_I",         -- ASSIGN_I 
   "opASSIGN_OP_SLICE",  -- ASSIGN_OP_SLICE 
   } 
 
   for i=1 to length(routine_name) do 
              operation[i] = routine_id(routine_name[i]) 
   end for 
 

Just curious... Looks just as reordering and renameing of opnames ...
Anyway you reorder and rename them by hands in switch blok code, no?


kinz

This is what the old version of the code (before switch was added) used to do.

This was changed

new topic     » goto parent     » topic index » view message » categorize

165. Re: New switch/case idea

jimcbrown said...

This was changed

Let's come back? Why not?

new topic     » goto parent     » topic index » view message » categorize

166. Re: New switch/case idea

kinz said...
jimcbrown said...

This was changed

Let's come back? Why not?

By having the routine_id function call with a literal string is faster than using a runtime string expression. The value of the routine_id can be determined at parse-time once with literals, otherwise it has to do a look up every time its executed when using string expressions. Also, with literals, the bind program (and a future optimised translator) can see which routines are referenced and can strip out unreferenced routines. If you have even one routine_id() that uses a runtime string expression, then bind cannot strip out any routines just in case you need it at runtime evaluation of routine_id().

new topic     » goto parent     » topic index » view message » categorize

167. Re: New switch/case idea

mattlewis said...
jemima said...
jeremy said...
Fernando said...
X = 1 
condition = 1 
switch X do 
   case 1 then 
      if condition then break end if 
      X = 2 
end switch 
? X 

If that is valid, what will be showed ?

That will print 2.

You have clearly all gone stark raving bonkers...

What happened to the concept of READABLE code???

Nothing. Does that mean that we shouldn't explore edge cases, and consider fully the consequences of syntax decisions? This is an important part of language design. I'm not sure what your point is...

Matt

Ah, I see. What you are all saying is "this is precisely why we must NOT implement it this way". I misunderstood. You didn't make that clear.

new topic     » goto parent     » topic index » view message » categorize

168. Re: New switch/case idea

jemima said...

Ah, I see. What you are all saying is "this is precisely why we must NOT implement it this way". I misunderstood. You didn't make that clear.

This is still being debated. We may just leave that alone, exactly the same as it is now. We are still debating whether or not it should be implemented this way.

new topic     » goto parent     » topic index » view message » categorize

169. Re: New switch/case idea

jemima said...
mattlewis said...
jemima said...

You have clearly all gone stark raving bonkers...

What happened to the concept of READABLE code???

Nothing. Does that mean that we shouldn't explore edge cases, and consider fully the consequences of syntax decisions? This is an important part of language design. I'm not sure what your point is...

Ah, I see. What you are all saying is "this is precisely why we must NOT implement it this way". I misunderstood. You didn't make that clear.

No, that's not what I was saying. I'll rephrase slightly. When changes to a language are proposed, it's important to look at the consequences, and the different ways that something can be used. If it can be abused, it will be. Sometimes the benefits outweigh the abuse, sometimes not.

This thread was one examination of the consequences of the current implementation of break.

Matt

new topic     » goto parent     » topic index » view message » categorize

170. Re: New switch/case idea

DerekParnell said...
kinz said...
jimcbrown said...

This was changed

Let's come back? Why not?

By having the routine_id function call with a literal string is faster than using a runtime string expression. The value of the routine_id can be determined at parse-time once with literals, otherwise it has to do a look up every time its executed when using string expressions. Also, with literals, the bind program (and a future optimised translator) can see which routines are referenced and can strip out unreferenced routines. If you have even one routine_id() that uses a runtime string expression, then bind cannot strip out any routines just in case you need it at runtime evaluation of routine_id().

jimcbrown and me are talking about the global procedure init_opcodes() of the compile.e file. This procedure only used in the local function InitBackEnd() of the traninit.e lib. Used once, just one call, as far as I can see. It prepares the sequence with routine numbers (routine_ids). So, the testing of the real speed of different versions of such a procedure seems to be not very difficult. The sequence of routine_ids has the 'operation' name. Once it is filled with routine_ids, the init_opcodes() procedure is done. So, I do not see the runtime string expressions which compete with literal strings at runtime frequently in this case. Just one call to init something.
There are yet another switches in source code, I didn't see them for now.


kinz

new topic     » goto parent     » topic index » view message » categorize

171. Re: New switch/case idea

kinz said...
DerekParnell said...

By having the routine_id function call with a literal string is faster than using a runtime string expression. The value of the routine_id can be determined at parse-time once with literals, otherwise it has to do a look up every time its executed when using string expressions. Also, with literals, the bind program (and a future optimised translator) can see which routines are referenced and can strip out unreferenced routines. If you have even one routine_id() that uses a runtime string expression, then bind cannot strip out any routines just in case you need it at runtime evaluation of routine_id().

jimcbrown and me are talking about the global procedure init_opcodes() of the compile.e file. This procedure only used in the local function InitBackEnd() of the traninit.e lib. Used once, just one call, as far as I can see. It prepares the sequence with routine numbers (routine_ids). So, the testing of the real speed of different versions of such a procedure seems to be not very difficult. The sequence of routine_ids has the 'operation' name. Once it is filled with routine_ids, the init_opcodes() procedure is done. So, I do not see the runtime string expressions which compete with literal strings at runtime frequently in this case. Just one call to init something.
There are yet another switches in source code, I didn't see them for now.

Igor, please read Derek's response again. You missed a key point: namely, which routines can be stripped out, either by the binder or the translator.

The overhead of this many routine ids isn't very significant, ultimately, though it would probably be faster to do away with routine ids to begin with, and call the routines directly. When this was done with execute.e, speed was increased by about 5-7%.

Matt

new topic     » goto parent     » topic index » view message » categorize

172. Re: New switch/case idea

mattlewis said...

Igor, please read Derek's response again. You missed a key point: namely, which routines can be stripped out, either by the binder or the translator.

The overhead of this many routine ids isn't very significant, ultimately, though it would probably be faster to do away with routine ids to begin with, and call the routines directly. When this was done with execute.e, speed was increased by about 5-7%.

Matt

Matt, what specific function or procedure are you talking about? Euphoria 4.0 is Open Source, let me know, please. I can read the concrete Euphoria code. Then I can ask about concrete things. 'Translator or binder' ... it is same thing as to say 'in America'. 4.0 now is alpha, isn't it? You asked about new switch/case ideas. I can provide the specific code sometimes. I asked - Where am I wrong. I'm not talking about some principles, I'm talking about concrete code now. You say execute.e, I'll see execute.e. But compile.e seems to have a problem, sorry.
Let's take time out, OK? I need some break, sorry.


kinz

new topic     » goto parent     » topic index » view message » categorize

173. Re: New switch/case idea

kinz said...
mattlewis said...

Igor, please read Derek's response again. You missed a key point: namely, which routines can be stripped out, either by the binder or the translator.

The overhead of this many routine ids isn't very significant, ultimately, though it would probably be faster to do away with routine ids to begin with, and call the routines directly. When this was done with execute.e, speed was increased by about 5-7%.

Matt, what specific function or procedure are you talking about?

Take a look at do_exec() in execute.e. There are actually two versions, but the old, routine id based stuff is ifdef'd out by default. It should probably be removed at this point. It was initially ifdef'd out for comparison purposes, and just in case we wanted to restore it. But I think the speed benefits are substantial enough for eu.ex that it's worth keeping.

kinz said...

Euphoria 4.0 is Open Source, let me know, please. I can read the concrete Euphoria code. Then I can ask about concrete things. 'Translator or binder' ... it is same thing as to say 'in America'.

I don't understand what you're asking. The translator and the binder are specific things. I suspect you know about them smile

kinz said...

4.0 now is alpha, isn't it? You asked about new switch/case ideas. I can provide the specific code sometimes. I asked - Where am I wrong. I'm not talking about some principles, I'm talking about concrete code now. You say execute.e, I'll see execute.e. But compile.e seems to have a problem, sorry.

What's the problem with compile.e? It works fine. Derek explained why he changed it the way he did. You addressed the speed issue (which is probably pretty insignificant, I think we both agree), but not the issue of the translator or binder knowing which routines are routine_id targets, and the benefits of being able to do that.

Matt

new topic     » goto parent     » topic index » view message » categorize

174. Re: New switch/case idea

mattlewis said...
kinz said...
mattlewis said...

Igor, please read Derek's response again. You missed a key point: namely, which routines can be stripped out, either by the binder or the translator.

The overhead of this many routine ids isn't very significant, ultimately, though it would probably be faster to do away with routine ids to begin with, and call the routines directly. When this was done with execute.e, speed was increased by about 5-7%.

Matt, what specific function or procedure are you talking about?

Take a look at do_exec() in execute.e. There are actually two versions, but the old, routine id based stuff is ifdef'd out by default. It should probably be removed at this point. It was initially ifdef'd out for comparison purposes, and just in case we wanted to restore it. But I think the speed benefits are substantial enough for eu.ex that it's worth keeping.

Ok, thanks, it seems to be a good landmark, I'll see do_exec() in execute.e.

mattlewis said...
kinz said...

Euphoria 4.0 is Open Source, let me know, please. I can read the concrete Euphoria code. Then I can ask about concrete things. 'Translator or binder' ... it is same thing as to say 'in America'.

I don't understand what you're asking. The translator and the binder are specific things. I suspect you know about them smile

Matt, I was asking about America, don't you see? Why you jumped to some do_exec() in execute.e? Is it America? I have that do_exec() on my machine.

mattlewis said...
kinz said...

4.0 now is alpha, isn't it? You asked about new switch/case ideas. I can provide the specific code sometimes. I asked - Where am I wrong. I'm not talking about some principles, I'm talking about concrete code now. You say execute.e, I'll see execute.e. But compile.e seems to have a problem, sorry.

What's the problem with compile.e? It works fine. Derek explained why he changed it the way he did. You addressed the speed issue (which is probably pretty insignificant, I think we both agree), but not the issue of the translator or binder knowing which routines are routine_id targets, and the benefits of being able to do that.

I reported about ascii.ex compiled with Watcom, it crashes with message from CW.
Who knows why it crashes? And you say 'fine'. ascii.ex is a simplest program. Crashes translated/compiled. BEu complains. So do not tell me about benefits for now, please.

Good luck!


kinz

new topic     » goto parent     » topic index » view message » categorize

175. Re: New switch/case idea

kinz said...

I reported about ascii.ex compiled with Watcom, it crashes with message from CW.
Who knows why it crashes? And you say 'fine'. ascii.ex is a simplest program. Crashes translated/compiled. BEu complains. So do not tell me about benefits for now, please.

It had the old switch syntax. Now what do you mean it crashes? I updated 4 :'s to be then's and it runs fine here. It never crashed, it did show a compile error, but not a crash.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

176. Re: New switch/case idea

jeremy said...
kinz said...

I reported about ascii.ex compiled with Watcom, it crashes with message from CW.
Who knows why it crashes? And you say 'fine'. ascii.ex is a simplest program. Crashes translated/compiled. BEu complains. So do not tell me about benefits for now, please.

It had the old switch syntax. Now what do you mean it crashes? I updated 4 :'s to be then's and it runs fine here. It never crashed, it did show a compile error, but not a crash.

Jeremy

Oh, I committed it to SVN, so you can SVN up and get rev 1873. It's fixed there.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

177. Re: New switch/case idea

mattlewis said...

Take a look at do_exec() in execute.e. There are actually two versions, but the old, routine id based stuff is ifdef'd out by default. It should probably be removed at this point. It was initially ifdef'd out for comparison purposes, and just in case we wanted to restore it. But I think the speed benefits are substantial enough for eu.ex that it's worth keeping.

Ok, my break is over, I've recoded that switch in BEu-style, so to say:

switch op [do] -- 'do' reserved for possible optional cyclic mode 
   case ABORT opABORT() ------ pure switching entry 
   case AND opAND() 
   case AND_BITS opAND_BITS() 
   case APPEND opAPPEND() 
   case ARCTAN opARCTAN() 
  stage ASSIGN --------------- cascadeing entry 
  stage ASSIGN_I opASSIGN() -- cascade ends, switch quits 
   case ASSIGN_OP_SLICE opASSIGN_OP_SLICE() 
   ... 
  stage ELSE 
  stage EXIT 
  stage ENDWHILE 
  stage RETRY opELSE() 
exit -- 2 separate cascade bloks 
  stage ENDFOR_GENERAL 
  stage ENDFOR_UP 
  stage ENDFOR_DOWN 
  stage ENDFOR_INT_UP 
  stage ENDFOR_INT_DOWN 
  stage ENDFOR_INT_DOWN1 opENDFOR_GENERAL() 
   case ENDFOR_INT_UP1 opENDFOR_INT_UP1() 
   ... 
   case TASK_SELF opTASK_SELF() 
 -------------------------- an example of the original code 
   case res:TASK_STATUS: -- undocumented feature ?  
	opTASK_STATUS()  -- 
	 break 
 -------------------------				 
   case TASK_SUSPEND opTASK_SUSPEND() 
   ... 
   case XOR_BITS opXOR_BITS() 
else -- common *else* for cascade and switch modes 
      RTFatal( sprintf("Unknown opcode: %d", op ) ) 
end switch 

It has 212 lines instead of 537 of original version, requires just 2 exit commands, and looks better for reading and understanding, I think. It is 100% compartible with bilingual mode and can be cyclic.
Anyway I'm out of town now, so can not reply.
As far as I can see, 'break' means delay in main process sometimes, so 'exit' is much better for BEu. Let's change 'break' to 'stage' - one key word plus, one key word minus.


kinz

new topic     » goto parent     » topic index » view message » categorize

178. Re: New switch/case idea

mattlewis said...

You addressed the speed issue (which is probably pretty insignificant, I think we both agree),

I've tested the swithing and usual versions of that procedure,
init_opcodes(), and init_opcodes_my() - 10000 iterations on P4 1.8GHz:

exw.exe 
 
9.531   11.766    9.015  -- switching time 
6.062    6.156    6.187  -- usual time 
 
ex.exe 
 
8.294    8.359    8.349  -- switching time 
6.092    6.371    6.096  -- usual time 

Usual one looks better - about 50% faster.
ex.exe tends to be faster on that task.

mattlewis said...

but not the issue of the translator or binder knowing which routines are routine_id targets, and the benefits of being able to do that.

I do not know your plans. If you want to optimise the translator or binder some way, that procedure doesn't seem to be a good place for experiments with switch - it is too actual code.
You can get my test program here:
http://www.private.peterlink.ru/kinz/test_switch.zip

kinz

new topic     » goto parent     » topic index » view message » categorize

179. Re: New switch/case idea

kinz said...
mattlewis said...

You addressed the speed issue (which is probably pretty insignificant, I think we both agree),

I've tested the swithing and usual versions of that procedure,
init_opcodes(), and init_opcodes_my() - 10000 iterations on P4 1.8GHz:

<snip>

Usual one looks better - about 50% faster.
ex.exe tends to be faster on that task.

You can get my test program here:
http://www.private.peterlink.ru/kinz/test_switch.zip

kinz

Sorry, doesn't count. Your test program has a for loop for the operation[i] = routine_id(opName[i]), but then it stupidly uses the exact same for loop with the switch inside.

Also, the example uses strings, which are slower. If we were to switch on integers (such as in the do_exec() loop) then switch would speed up.

Finally, there is the effort involved in keeping all three sequences involved in sync. If opnames and opName had an off-by-one error (someone swapped two lines), we'd have problems. This is why the old version of the loop used find() instead of the parallel array technique.

switch is probably not as fast as the parallel array technique, but it is less error prone

kinz said...
mattlewis said...

but not the issue of the translator or binder knowing which routines are routine_id targets, and the benefits of being able to do that.

I do not know your plans. If you want to optimise the translator or binder some way, that procedure doesn't seem to be a good place for experiments with switch - it is too actual code.

The optimization to the translator and the binder is unrelated to the use of switch.

However, neither are experiments, rather they are definite improvements to the system.

new topic     » goto parent     » topic index » view message » categorize

180. Re: New switch/case idea

jimcbrown said...

Sorry, doesn't count. Your test program has a for loop for the operation[i] = routine_id(opName[i]),

There are 2 tested procedures in my program:

  init_opcodes()     -- from EU 4.0, switching one, from compile.e 
  init_opcodes_my()  -- my version just with sequence, without any switch, simple 
jimcbrown said...

but then it stupidly uses the exact same for loop with the switch inside.

Yes, but that one is switching procedure from compile.e, it is not my procedure.
Both procedures give strongly equal output.
But my procedure is 50% faster, no?

Try them once more, please.

I'm out of town again, do not be in a hurry.


kinz

new topic     » goto parent     » topic index » view message » categorize

181. Re: New switch/case idea

kinz said...
jimcbrown said...

Sorry, doesn't count. Your test program has a for loop for the operation[i] = routine_id(opName[i]), but then it stupidly uses the exact same for loop with the switch inside.

Yes, but that one is switching procedure from compile.e, it is not my procedure.

Ok, I didn't notice. It was from an old version of compile.e (as it had the wrong syntax), but that was easy enough to deal with.

I also had to add a couple of routines to handle some missing routines, again no big deal.

Functionality-wise, you are right. This is the InitBackend() from compile.e (oddly, the InitBackend() from execute.e matches your other routine).

kinz said...

Both procedures give strongly equal output.
But my procedure is 50% faster, no?

However, if we change init_opcodes() to use switch on integers instead of on strings, we go from 14.4 to 7.85

So much for the speed advantage.

In any case, InitBackend() is not a speed critical routine, so making the code easy to read and change and debug is more important. The switch statement method is better for this purpose than the parallel arrays version, for the reason I already stated.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu