1. New switch/case idea
- Posted by Fernando Mar 30, 2009
- 2022 views
- Last edited Mar 31, 2009
Hi switchers ,
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
2. Re: New switch/case idea
- Posted by jeremy (admin) Mar 30, 2009
- 2008 views
- Last edited Mar 31, 2009
Fernando,
I like this. We had just reached the final decision on the dev list when this came in. Discussions have started as to include this or not in 4.0. We are thinking that it would work together with the switch without fallthru do type syntax. It seems the default of without fallthru has won, so the switch will not have fallthru by default, you will have to enable fallthru by with fallthru. Most people can probably live with the default switch and never use the with fallthru option and with the addition of the case continue syntax you have proposed, that will make it all the more likely not to need with fallthru, however, there are situations where it's nice to have the entire switch support fallthru. For that, we are thinking of keeping the modifier of with fallthru. Instead of making a 50 case switch that has case continue ... then 50 times, we could do a switch X with fallthru do.
We just posed the idea of including this in 4.0 or pushing to 4.1, so I am sure others will chime in here as well.
Jeremy
3. Re: New switch/case idea
- Posted by bernie Mar 31, 2009
- 1985 views
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
4. Re: New switch/case idea
- Posted by mattlewis (admin) Mar 31, 2009
- 1981 views
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
5. Re: New switch/case idea
- Posted by bernie Mar 31, 2009
- 1990 views
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.
6. Re: New switch/case idea
- Posted by jeremy (admin) Mar 31, 2009
- 1983 views
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
7. Re: New switch/case idea
- Posted by bernie Mar 31, 2009
- 1978 views
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.
8. Re: New switch/case idea
- Posted by jeremy (admin) Mar 31, 2009
- 1981 views
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
9. Re: New switch/case idea
- Posted by bernie Mar 31, 2009
- 1969 views
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.
10. Re: New switch/case idea
- Posted by DerekParnell (admin) Mar 31, 2009
- 1994 views
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 |
11. Re: New switch/case idea
- Posted by kinz Mar 31, 2009
- 1992 views
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
12. Re: New switch/case idea
- Posted by bernie Mar 31, 2009
- 2001 views
When was colon removed ? Does that mean I have to back into my code and remove the colons ?
My suggestion was simple and much easier to code and all it takes is 1 extra colon and no other keywords.
I think that things are being made too complicated with all the extra words.
switch X do case 1:: -- do code until next case is encountered then break ? 1 case 2, 3, 4: -- fall through ? 2 case 5: -- fall through ? 5 case 30:: -- do code until next case is encountered then break ? 30 ? 123 case 27:: -- do code until next case is encountered then break ? 27 case 81: -- fall through ? 81 end switch
13. Re: New switch/case idea
- Posted by jeremy (admin) Mar 31, 2009
- 1991 views
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.
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
14. Re: New switch/case idea
- Posted by jimcbrown (admin) Mar 31, 2009
- 1996 views
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.
15. Re: New switch/case idea
- Posted by DerekParnell (admin) Mar 31, 2009
- 1970 views
When was colon removed ? Does that mean I have to back into my code and remove the colons ?
Welcome to alpha testing.
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.
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.
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.
16. Re: New switch/case idea
- Posted by bernie Mar 31, 2009
- 2051 views
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"
17. Re: New switch/case idea
- Posted by euphoric (admin) Mar 31, 2009
- 1967 views
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.
18. Re: New switch/case idea
- Posted by jimcbrown (admin) Mar 31, 2009
- 2017 views
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).
19. Re: New switch/case idea
- Posted by DerekParnell (admin) Mar 31, 2009
- 2018 views
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.
20. Re: New switch/case idea
- Posted by jimcbrown (admin) Mar 31, 2009
- 2031 views
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.
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]
21. Re: New switch/case idea
- Posted by DerekParnell (admin) Mar 31, 2009
- 1977 views
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.
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).
22. Re: New switch/case idea
- Posted by jeremy (admin) Mar 31, 2009
- 1997 views
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.
Euphoric,
I am having a bit of arguer's remorse There are two things that made me change my mind on the default... As I thought more about this, the default (as you have argued many times) is to use break, even for C programers. The way they are going to program a switch to start is probably:
switch X do case 1 then ? 1 break case 2 then ? 2 break end switch
If not simply out of habit. That break is fine there. It does no harm. So, the fact that the majority of switches use break, we cover most people. The fact that the break does not cause a problem, is a benefit.
Now, the second thing that made me change my mind is we moved from : to then, and I think this is the more important change. The reason why is switch no longer looks exactly like the C switch, therefore, it's going to be someone unknown and the C programmer is going to use it cautiously knowing that it may not act how they suppose. case 3 then almost suggests when reading aloud that it's one block of code per case. So, our switch is different enough that C users are not going to simply jump in and use it without a little caution.
I guess there is a third... With the addition of with fallthru and now some form of continue, this makes the switch be able to do anything reasonable. You can default to fallthru, you can override the fallthru action with break, you can default to non-fallthru, you can override that with continue, etc...
Jeremy
23. Re: New switch/case idea
- Posted by bernie Mar 31, 2009
- 1987 views
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.
24. Re: New switch/case idea
- Posted by jeremy (admin) Mar 31, 2009
- 1974 views
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
25. Re: New switch/case idea
- Posted by DanM Mar 31, 2009
- 1970 views
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
26. Re: New switch/case idea
- Posted by kinz Apr 01, 2009
- 1965 views
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
Regards,
Igor Kachan
kinz@peterlink.ru
27. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 01, 2009
- 1962 views
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.
28. Re: New switch/case idea
- Posted by kinz Apr 01, 2009
- 1993 views
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.
HE-he-He-hE, in Russia, it is not Fool's Day, it is Day of Laughter.
Happy Laughter to you
29. Re: New switch/case idea
- Posted by Fernando Apr 01, 2009
- 1951 views
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:
- Currently, most editors have cut&paste and/or macros to do that very fast;
- The increase in file length is insignificant;
- 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
30. Re: New switch/case idea
- Posted by Kat Apr 01, 2009
- 1951 views
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
31. Re: New switch/case idea
- Posted by euphoric (admin) Apr 01, 2009
- 1910 views
X=1 switch X with fallthru do case 1: ? 1 case 2: ? 2 case 3: ? 3 case 4: ? 4 case 5: ? 5 break case 6: ? 6 case 7: ? 7 end switch
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! 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...
32. Re: New switch/case idea
- Posted by Kat Apr 01, 2009
- 1942 views
X=1 switch X with fallthru do case 1: ? 1 case 2: ? 2 case 3: ? 3 case 4: ? 4 case 5: ? 5 break case 6: ? 6 case 7: ? 7 end switch
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! 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...
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
33. Re: New switch/case idea
- Posted by Kat Apr 01, 2009
- 1974 views
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
34. Re: New switch/case idea
- Posted by euphoric (admin) Apr 01, 2009
- 1911 views
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!
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.
35. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 01, 2009
- 1960 views
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?
36. Re: New switch/case idea
- Posted by Kat Apr 01, 2009
- 1947 views
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
37. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 01, 2009
- 1969 views
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.
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.
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.
38. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 01, 2009
- 1948 views
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.
39. Re: New switch/case idea
- Posted by Kat Apr 01, 2009
- 1945 views
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
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
40. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 01, 2009
- 1972 views
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
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.
41. Re: New switch/case idea
- Posted by achury Apr 01, 2009
- 1934 views
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"
42. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 01, 2009
- 1960 views
- Last edited Apr 02, 2009
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.
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.
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
43. Re: New switch/case idea
- Posted by znorq2 Apr 02, 2009
- 1967 views
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
44. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 02, 2009
- 1953 views
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.
45. Re: New switch/case idea
- Posted by jeremy (admin) Apr 02, 2009
- 1958 views
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
46. Re: New switch/case idea
- Posted by kinz Apr 02, 2009
- 1957 views
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
47. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 02, 2009
- 1958 views
In standard Euphoria, "do" is used in the cycle (loop) constructs only.
And in bilingual Euphoria 2.5, in Russian mode, do sounds as cycle.
I just can not translate "do" of switch\select\on as "cycle" again.
So 4.x series transforms to some mumbo-jumbo with these redundant do, which do not represent stgrongly some cycle.
Do you see this side of new syntax problem now?
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 ..."?
48. Re: New switch/case idea
- Posted by kinz Apr 02, 2009
- 1958 views
In standard Euphoria, "do" is used in the cycle (loop) constructs only.
And in bilingual Euphoria 2.5, in Russian mode, do sounds as cycle.
I just can not translate "do" of switch\select\on as "cycle" again.
So 4.x series transforms to some mumbo-jumbo with these redundant do, which do not represent stgrongly some cycle.
Do you see this side of new syntax problem now?
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?
49. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 02, 2009
- 1979 views
In standard Euphoria, "do" is used in the cycle (loop) constructs only. And in bilingual Euphoria 2.5, in Russian mode, do sounds as cycle. I just can not translate "do" of switch\select\on as "cycle" again. So 4.x series transforms to some mumbo-jumbo with these redundant do, which do not represent stgrongly some cycle. Do you see this side of new syntax problem now?
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):
- to perform (an act, duty, role, etc.): Do nothing until you hear the bell.
- 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
50. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 02, 2009
- 2009 views
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".
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
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".
51. Re: New switch/case idea
- Posted by znorq2 Apr 02, 2009
- 1950 views
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
52. Re: New switch/case idea
- Posted by jeremy (admin) Apr 02, 2009
- 1953 views
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
53. Re: New switch/case idea
- Posted by znorq2 Apr 02, 2009
- 1947 views
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
54. Re: New switch/case idea
- Posted by jeremy (admin) Apr 02, 2009
- 1919 views
Already done.
Thank you...
Jeremy
55. Re: New switch/case idea
- Posted by kinz Apr 02, 2009
- 1934 views
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 ...
56. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 02, 2009
- 1954 views
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".
57. Re: New switch/case idea
- Posted by jeremy (admin) Apr 02, 2009
- 1942 views
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
58. Re: New switch/case idea
- Posted by bernie Apr 02, 2009
- 1946 views
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.
59. Re: New switch/case idea
- Posted by jeremy (admin) Apr 02, 2009
- 1933 views
Jeremy:
I disagree with you on this Jeremy.
Igor supports the Russian Euphoria site and needs to translate the source code and documents into Russian so that non English speakers can eaisly grasp and understand Euphoria that is why he needs to get more concise language meaning.
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
60. Re: New switch/case idea
- Posted by kinz Apr 02, 2009
- 1960 views
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.
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???
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.
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?
61. Re: New switch/case idea
- Posted by Kat Apr 02, 2009
- 1964 views
In standard Euphoria, "do" is used in the cycle (loop) constructs only.
And in bilingual Euphoria 2.5, in Russian mode, do sounds as cycle.
I just can not translate "do" of switch\select\on as "cycle" again.
So 4.x series transforms to some mumbo-jumbo with these redundant do, which do not represent stgrongly some cycle.
Do you see this side of new syntax problem now?
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
62. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 02, 2009
- 1925 views
In standard Euphoria, the word "do" does imply namely the looping or cyclic actions, it is used only in cyclic constructs and nowhere else.
for i=1 to n by 2 do ....... end for while a do ....... end while
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.
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.
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.
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.
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
63. Re: New switch/case idea
- Posted by shfrance Apr 02, 2009
- 1950 views
"In standard Euphoria, the word "do" does imply namely the looping or cyclic actions, it is used only in cyclic constructs and nowhere else."
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.
64. Re: New switch/case idea
- Posted by Kat Apr 02, 2009
- 1947 views
"In standard Euphoria, the word "do" does imply namely the looping or cyclic actions, it is used only in cyclic constructs and nowhere else."
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
65. Re: New switch/case idea
- Posted by kinz Apr 02, 2009
- 1925 views
In standard Euphoria, the word "do" does imply namely the looping or cyclic actions, it is used only in cyclic constructs and nowhere else.
for i=1 to n by 2 do ....... end for while a do ....... end while
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.
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.
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.
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.
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.
66. Re: New switch/case idea
- Posted by DanM Apr 02, 2009
- 1930 views
<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
67. Re: New switch/case idea
- Posted by bernie Apr 02, 2009
- 1940 views
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.
68. Re: New switch/case idea
- Posted by kinz Apr 02, 2009
- 1938 views
<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.
69. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 02, 2009
- 1953 views
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.
70. Re: New switch/case idea
- Posted by kinz Apr 02, 2009
- 1938 views
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.
71. Re: New switch/case idea
- Posted by neophyte Apr 02, 2009
- 1874 views
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.
72. Re: New switch/case idea
- Posted by kinz Apr 03, 2009
- 1941 views
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.
73. Re: New switch/case idea
- Posted by kinz Apr 03, 2009
- 1930 views
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.
"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.
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.
One online translation site says "do this" = "kill time".
Cool!
Continue the good work, Kinz.
Thanks!
Regards,
Igor Kachan
kinz@peterlink.ru
74. Re: New switch/case idea
- Posted by bill Apr 03, 2009
- 1924 views
Reading the comments it seems to me that using a fall-through C-type switch is going away from well-structured code. I have mostly programmed in Pascal-type languages (Ada, PL/SQL etc) where sturctures like this do not exist.
It is hard to see how something like Duff's Device is needed in a high-level language. (It is also difficult to see value in a GOTO statement.)
Being able to read my code 6 months later is more important to me than raw speed or extremely succint code.
Obviously not everyone agrees.
75. Re: New switch/case idea
- Posted by kinz Apr 03, 2009
- 1905 views
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...
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.
76. Re: New switch/case idea
- Posted by jeremy (admin) Apr 03, 2009
- 1950 views
Reading the comments it seems to me that using a fall-through C-type switch is going away from well-structured code. I have mostly programmed in Pascal-type languages (Ada, PL/SQL etc) where sturctures like this do not exist.
It is hard to see how something like Duff's Device is needed in a high-level language. (It is also difficult to see value in a GOTO statement.)
Being able to read my code 6 months later is more important to me than raw speed or extremely succint code.
Obviously not everyone agrees.
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
77. Re: New switch/case idea
- Posted by kinz Apr 04, 2009
- 1911 views
In standard Euphoria, the word "do" does imply namely the looping or cyclic actions, it is used only in cyclic constructs and nowhere else.
for i=1 to n by 2 do ....... end for while a do ....... end while
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.
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.
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.
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.
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.
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.
Regards,
Igor Kachan
kinz@peterlink.ru
78. Re: New switch/case idea
- Posted by kinz Apr 04, 2009
- 1895 views
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.
-------- do ..... while c end do --------
Regards,
Igor Kachan
kinz@peterlink.ru
79. Re: New switch/case idea
- Posted by DanM Apr 04, 2009
- 1945 views
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.
Dan
80. Re: New switch/case idea
- Posted by SDPringle Apr 04, 2009
- 1924 views
Continue is a natural thing for a language that has switches with an optional 'without fallthrough' syntax. The reason why continue was shot down was that it might have been confusing with loop control. By putting continue in the case statement itself there is no longer ambiguity.
Sometimes, you have a switch statement and most of the time you have no fallthough but occasionally you need fallthrough. So because a switch needs fallthrough 20% of the time you need to put 'break' in 80% of the switches. With Fernando's proposal the programmer can elect to put 'continue' in 20% of the statements. Look at execute.e's switch statement. Look at all of those breaks, with present syntax we cannot change it to no fallthrough because we actually need fallthrough once and a while but not often.
Presently, you have switch with fallthru for when you need to fallthrough at least once. And switch without fallthru if you never need fallthrough. What a pain if the user chooses the without fallthrough path and then finds that he needs fallthrough later.
With Fernando's proposal, you can use either with fallthrough or without no matter how many times you need to or will need fall through in the cases. The programmer can choose what is the most convienent for the particular situation.
Suppose we keep the ability to choose which default to use in a switch with 'with fallthru' or 'without fallthru' and we allow users to override with the old 'break statement' and the 'continue specifier in the case header. It's only a modification to what was agreed apon, I don't see why we cannot simply vote on that.
I don't think this new idea is mutually exclusive to what was agreed apon earlier regarding the switch statement. We have two kinds of switch statements, one with fallthru and one without. With fallthru we can override a case's behavior with a break statement so that some cases fall through. Fernando's proposal is to me like a mirror image of the break statement for the non-fallthrough world. I vote we integrate it into the existing syntax.
Shawn Pringle
81. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 04, 2009
- 1834 views
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?
82. Re: New switch/case idea
- Posted by bernie Apr 04, 2009
- 1900 views
It is time to cease the debate on the way switch/case should work.
It is time now time to use it in your code and see if it can be used in your code in it's present form.
I am having no problem adopting it to the way I like to work.
83. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 04, 2009
- 1931 views
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
84. Re: New switch/case idea
- Posted by kinz Apr 04, 2009
- 1943 views
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!
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.
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.
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.
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.
Ok, no problem, do you like fresh fish-soup?
Regards,
Igor Kachan
kinz@peterlink.ru
85. Re: New switch/case idea
- Posted by kinz Apr 04, 2009
- 1930 views
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
86. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 04, 2009
- 1915 views
I had prefered switch...on over the current switch...do syntax (and I would still prefer it), but I lost out on this one.
However, this gives me a new argument for switch...do. Since the official version of Russian Euphoria translated do into cykl, and this was considered an official version, we are now stuck with that translation. We can't ask kinz to change that to a different word anymore than he could ask us to change all instances of 'for...do' to 'each...do'. He has to keep cykl as the keyword for backwards compatibility. Good idea or not, mistake or not, mistranslation or not, wrong semantics or not... we are stuck with them.
It seems the best way to translate loop...do {} end loop in Russian, would be to translate it into cykl...cykl {} russian-word-for-end cykl.
I agree that switch..cykl is a bit weird. I recommend that you take the english word "on" from switch...on and translate that into Russian, and then use that Russian word with switch, instead of cykl.
Then, english version of
switch ... do
...
end switch
would become
russian-word-switch ... russian-word-on
...
russian-word-end russian-word-switch
87. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 04, 2009
- 1938 views
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'.
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.
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
88. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 04, 2009
- 1936 views
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 (ì•„í¬) ?
89. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 04, 2009
- 1890 views
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
90. Re: New switch/case idea
- Posted by kinz Apr 05, 2009
- 1938 views
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'.
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.
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
91. Re: New switch/case idea
- Posted by kinz Apr 05, 2009
- 1830 views
I had prefered switch...on over the current switch...do syntax (and I would still prefer it), but I lost out on this one.
However, this gives me a new argument for switch...do. Since the official version of Russian Euphoria translated do into cykl, and this was considered an official version, we are now stuck with that translation. We can't ask kinz to change that to a different word anymore than he could ask us to change all instances of 'for...do' to 'each...do'. He has to keep cykl as the keyword for backwards compatibility. Good idea or not, mistake or not, mistranslation or not, wrong semantics or not... we are stuck with them.
Bilingual EU 2.5 is still beta, so you are free to do what you want.
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
92. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 05, 2009
- 1901 views
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.
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.
93. Re: New switch/case idea
- Posted by jeremy (admin) Apr 05, 2009
- 1811 views
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
94. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 05, 2009
- 1886 views
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.
95. Re: New switch/case idea
- Posted by kinz Apr 05, 2009
- 1897 views
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.
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
96. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 05, 2009
- 1881 views
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
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.
97. Re: New switch/case idea
- Posted by jeremy (admin) Apr 05, 2009
- 1883 views
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
Jeremy
98. Re: New switch/case idea
- Posted by DanM Apr 06, 2009
- 1885 views
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
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
99. Re: New switch/case idea
- Posted by kinz Apr 06, 2009
- 1947 views
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 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.
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.
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.
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.
Regards,
Igor Kachan
kinz@peterlink.ru
100. Re: New switch/case idea
- Posted by irv Apr 06, 2009
- 1780 views
I am failing to detect the logic in this discussion.
switch x -- x = 1, let's say case 1 : print "one" case 2 : print "two"
Why on earth would anyone EVER expect this to print "onetwo", when x = 1?
Can anyone show me a justification for this? Or any example where some other construct wouldn't do the same thing in a clearer way? Or have I simply misread some posts and don't understand?
101. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1784 views
I am failing to detect the logic in this discussion.
switch x -- x = 1, let's say case 1 : print "one" case 2 : print "two"
Why on earth would anyone EVER expect this to print "onetwo", when x = 1?
Can anyone show me a justification for this? Or any example where some other construct wouldn't do the same thing in a clearer way? Or have I simply misread some posts and don't understand?
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
102. Re: New switch/case idea
- Posted by useless Apr 06, 2009
- 1795 views
I am failing to detect the logic in this discussion.
switch x -- x = 1, let's say case 1 : print "one" case 2 : print "two"
Why on earth would anyone EVER expect this to print "onetwo", when x = 1?
Can anyone show me a justification for this? Or any example where some other construct wouldn't do the same thing in a clearer way? Or have I simply misread some posts and don't understand?
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
103. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 06, 2009
- 1847 views
My idea was and is simple.
Agreed.
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.)
I'm not sure about that 'switch ... on' for BEu anymore, sorry.
switch...on only makes sense with case...then.
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
I don't like watching youtube.
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. :/
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.
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.
104. Re: New switch/case idea
- Posted by irv Apr 06, 2009
- 1812 views
case RHS_SUBS then case RHS_SUBS_CHECK then case RHS_SUBS_I then opRHS_SUBS() break
case RHS_SUBS then RHS_SUBS_CHECK then case RHS_SUBS_I then opRHS_SUBS() break
105. Re: New switch/case idea
- Posted by irv Apr 06, 2009
- 1797 views
case RHS_SUBS then case RHS_SUBS_CHECK then case RHS_SUBS_I then opRHS_SUBS() break
case RHS_SUBS or RHS_SUBS_CHECK or RHS_SUBS_I then opRHS_SUBS() break
So, the two above are identical?
106. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 06, 2009
- 1817 views
I am failing to detect the logic in this discussion.
switch x -- x = 1, let's say case 1 : print "one" case 2 : print "two"
Why on earth would anyone EVER expect this to print "onetwo", when x = 1?
Can anyone show me a justification for this? Or any example where some other construct wouldn't do the same thing in a clearer way? Or have I simply misread some posts and don't understand?
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.
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".
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.)
107. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 06, 2009
- 1804 views
case RHS_SUBS then case RHS_SUBS_CHECK then case RHS_SUBS_I then opRHS_SUBS() break
case RHS_SUBS or RHS_SUBS_CHECK or RHS_SUBS_I then opRHS_SUBS() break
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
108. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1822 views
case RHS_SUBS then case RHS_SUBS_CHECK then case RHS_SUBS_I then opRHS_SUBS() break
case RHS_SUBS or RHS_SUBS_CHECK or RHS_SUBS_I then opRHS_SUBS() break
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
109. Re: New switch/case idea
- Posted by irv Apr 06, 2009
- 1764 views
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?
110. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 06, 2009
- 1786 views
case RHS_SUBS then case RHS_SUBS_CHECK then case RHS_SUBS_I then opRHS_SUBS() break
case RHS_SUBS or RHS_SUBS_CHECK or RHS_SUBS_I then opRHS_SUBS() break
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".
111. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 06, 2009
- 1780 views
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.
112. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1811 views
switch op with fallthru do case RETURNT then opRETURNT() break case RHS_SLICE then opRHS_SLICE() break
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 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
113. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 06, 2009
- 1769 views
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.
114. Re: New switch/case idea
- Posted by irv Apr 06, 2009
- 1797 views
OK, one more question. Without specifying "with fallthru" - i.e: using the defaults - then only the matching case will be executed, with or without a break being in there, is this correct? break can be left out?
115. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 06, 2009
- 1792 views
OK, one more question. Without specifying "with fallthru" - i.e: using the defaults - then only the matching case will be executed, with or without a break being in there, is this correct? break can be left out?
This is 100% correct. break can be left out, only one matching case will be executed.
116. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 06, 2009
- 1805 views
OK, one more question. Without specifying "with fallthru" - i.e: using the defaults - then only the matching case will be executed, with or without a break being in there, is this correct? break can be left out?
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()
117. Re: New switch/case idea
- Posted by jemima Apr 06, 2009
- 1796 views
Why not just: case x then ... case y then ... ^ error: "break" or "fallthrough" *MUST* be specified
118. Re: New switch/case idea
- Posted by jemima Apr 06, 2009
- 1776 views
Why not just:
case x then ...
case y then ...
^ error: "break" or "fallthrough" *MUST* be specified
BTW,the preview button is bust
119. Re: New switch/case idea
- Posted by Fernando Apr 06, 2009
- 1795 views
OK, one more question. Without specifying "with fallthru" - i.e: using the defaults - then only the matching case will be executed, with or without a break being in there, is this correct? break can be left out?
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
120. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 06, 2009
- 1823 views
OK, one more question. Without specifying "with fallthru" - i.e: using the defaults - then only the matching case will be executed, with or without a break being in there, is this correct? break can be left out?
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>
121. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1838 views
That should still work in Euphoria too, but it doesn't at the moment. I think this is a bug. To get it to work currently you have to add a label to the break clause...
switch X label "A" do case 1 then . . . if cond then break "A" end if
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
122. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 06, 2009
- 1784 views
That should still work in Euphoria too, but it doesn't at the moment. I think this is a bug. To get it to work currently you have to add a label to the break clause...
switch X label "A" do case 1 then . . . if cond then break "A" end if
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.
123. Re: New switch/case idea
- Posted by DanM Apr 06, 2009
- 1797 views
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
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 chooseinstead 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
124. Re: New switch/case idea
- Posted by useless Apr 06, 2009
- 1814 views
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
125. Re: New switch/case idea
- Posted by Fernando Apr 06, 2009
- 1837 views
That should still work in Euphoria too, but it doesn't at the moment. I think this is a bug. To get it to work currently you have to add a label to the break clause...
switch X label "A" do case 1 then . . . if cond then break "A" end if
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
126. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1784 views
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
127. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 06, 2009
- 1852 views
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
128. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 06, 2009
- 1833 views
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
129. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 06, 2009
- 1822 views
OK, one more question. Without specifying "with fallthru" - i.e: using the defaults - then only the matching case will be executed, with or without a break being in there, is this correct? break can be left out?
This is perhaps a good time to provide a link to the docs for switch.
Matt
130. Re: New switch/case idea
- Posted by Fernando Apr 06, 2009
- 1856 views
OK, one more question. Without specifying "with fallthru" - i.e: using the defaults - then only the matching case will be executed, with or without a break being in there, is this correct? break can be left out?
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
131. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1802 views
- 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
132. Re: New switch/case idea
- Posted by kinz Apr 06, 2009
- 1818 views
switch X -- pure switch case a ?1 case b ?2 else ?3 end switch
cascade X -- instead of switch with fallthrou stage a ?1 stage b ?2 break else ?3 end cascade
I saw Niagara in my dream yesterday ...
133. Re: New switch/case idea
- Posted by useless Apr 06, 2009
- 1800 views
switch X -- pure switch case a ?1 case b ?2 else ?3 end switch
cascade X -- instead of switch with fallthrou stage a ?1 stage b ?2 break else ?3 end cascade
I saw Niagara in my dream yesterday ...
If the switch has "with fallthru", wouldn't it be cascode?
useless
134. Re: New switch/case idea
- Posted by Fernando Apr 06, 2009
- 1807 views
switch X -- pure switch case a ?1 case b ?2 else ?3 end switch
cascade X -- instead of switch with fallthrou stage a ?1 stage b ?2 break else ?3 end cascade
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 ...
goto case X case a ?1 case b ?2 else ?3 end case
- Fernando
135. Re: New switch/case idea
- Posted by Fernando Apr 06, 2009
- 1852 views
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
136. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1798 views
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.
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
137. Re: New switch/case idea
- Posted by Fernando Apr 06, 2009
- 1808 views
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.
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
138. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1807 views
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
139. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 06, 2009
- 1789 views
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.
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
140. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 06, 2009
- 1852 views
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
141. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1817 views
- Last edited Apr 07, 2009
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
142. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 06, 2009
- 1843 views
- Last edited Apr 07, 2009
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.
143. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 06, 2009
- 1827 views
- Last edited Apr 07, 2009
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
144. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1866 views
- Last edited Apr 07, 2009
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.
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.
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
145. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 06, 2009
- 1804 views
- Last edited Apr 07, 2009
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
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 ...
146. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1851 views
- Last edited Apr 07, 2009
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
147. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 06, 2009
- 1841 views
- Last edited Apr 07, 2009
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...
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.
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.
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?
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.
148. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 06, 2009
- 1881 views
- Last edited Apr 07, 2009
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.
149. Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1856 views
- Last edited Apr 07, 2009
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
150. Re: New switch/case idea
- Posted by kinz Apr 07, 2009
- 1829 views
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
151. Re: New switch/case idea
- Posted by kinz Apr 07, 2009
- 1765 views
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 ...
152. Re: New switch/case idea
- Posted by kinz Apr 07, 2009
- 1774 views
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 ...
153. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 07, 2009
- 1768 views
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
154. Re: New switch/case idea
- Posted by jemima Apr 07, 2009
- 1778 views
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???
155. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 07, 2009
- 1759 views
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
156. Re: New switch/case idea
- Posted by jeremy (admin) Apr 07, 2009
- 1755 views
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
157. Re: New switch/case idea
- Posted by Mike777 Apr 07, 2009
- 1764 views
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.
158. Re: New switch/case idea
- Posted by Mike777 Apr 07, 2009
- 1818 views
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.
159. Re: New switch/case idea
- Posted by jeremy (admin) Apr 07, 2009
- 1797 views
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
160. Re: New switch/case idea
- Posted by Mike777 Apr 07, 2009
- 1787 views
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.
161. Re: New switch/case idea
- Posted by jeremy (admin) Apr 07, 2009
- 1837 views
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
162. Re: New switch/case idea
- Posted by kinz Apr 08, 2009
- 1777 views
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
163. Re: New switch/case idea
- Posted by kinz Apr 08, 2009
- 1796 views
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
164. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 08, 2009
- 1788 views
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
165. Re: New switch/case idea
- Posted by kinz Apr 08, 2009
- 1718 views
This was changed
Let's come back? Why not?
166. Re: New switch/case idea
- Posted by DerekParnell (admin) Apr 08, 2009
- 1765 views
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().
167. Re: New switch/case idea
- Posted by jemima Apr 08, 2009
- 1750 views
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.
168. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 08, 2009
- 1728 views
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.
169. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 08, 2009
- 1750 views
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
170. Re: New switch/case idea
- Posted by kinz Apr 08, 2009
- 1753 views
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
171. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 08, 2009
- 1748 views
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
172. Re: New switch/case idea
- Posted by kinz Apr 08, 2009
- 1739 views
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
173. Re: New switch/case idea
- Posted by mattlewis (admin) Apr 08, 2009
- 1758 views
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.
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
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
174. Re: New switch/case idea
- Posted by kinz Apr 08, 2009
- 1753 views
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.
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
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.
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
175. Re: New switch/case idea
- Posted by jeremy (admin) Apr 08, 2009
- 1714 views
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
176. Re: New switch/case idea
- Posted by jeremy (admin) Apr 08, 2009
- 1748 views
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
177. Re: New switch/case idea
- Posted by kinz Apr 09, 2009
- 1803 views
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
178. Re: New switch/case idea
- Posted by kinz Apr 10, 2009
- 1790 views
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.
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
179. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 10, 2009
- 1782 views
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
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.
180. Re: New switch/case idea
- Posted by kinz Apr 10, 2009
- 1769 views
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
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
181. Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 10, 2009
- 1755 views
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).
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.