Re: New Switch Idea
- Posted by jeremy (admin) Mar 27, 2009
- 1131 views
I think that the syntax needs to be ...
switch <expr> [(with | without fallthru)] [label "name"] [do]
case <valuelist> [:]
<statements>
case <valuelist> [:]
<statements>
case <valuelist> [:]
<statements>
. . .
case else
<statements>
end switch
If I remember correctly, we had optional then's and do's added to Euphoria and it was quickly reverted. Maybe do is not the correct word, but Jim suggested "on" which sounds nice. He also suggested case <value> then which keeps with Euphoria syntax.
Where
- <expr> is an expression that evaluates to any Euphoria object
- If there is no 'fallthru' clause then 'without fallthru' is assumed
We agree here.
- <valuelist> is a comma-separated list of one or more discrete values that <expr> can equal to.
I thought that we had decided to add things like this in 4.1? If we do that now, I believe we are changing switch quite a bit and are going to push back 4.0 further. Adding them later on does not change the syntax for switch, it will only make some things easier.
- <statements> is a block of one or more euphoria statements. A zero length statement block is not allowed.
I personally, really liked the idea given by Matt, as copied from C#, of a smart switch that allowed:
switch X do case 1: case 2: case 3: -- do something end switch
Now, with your full proposal of allowing case 1,2,3: I guess the smart switch does make less sense to be excited about because you solve the same problem with allowing a list of items, then the block of code. I am assuming that case 1,2,3 would be written the same as the IL code of case 1: case 2: case 3: ?
- If 'without fallthru' is in operation, once <statements> block is executed, control passes to the 'end switch' line. Any 'break' statements are ignored.
Why ignore a break? What if there were some condition in place that the user wanted to break from?
- If 'with fallthru' is in operation, once a <statements> block is executed and is does not end in a 'break' statement, control passes to the next (if any) lexical <statements> block, otherwise control is passed to the 'end switch'.
I agree also.
- 'goto' can be used to manually change control flow within a switch.
We don't want to make the wrong decision with switch, but I think we should be sensitive to the fact that we are now at 1 year of 4.0 being developed. If there is anything we can enhance in 4.1 without cause syntax incompatabilities, I think it should be strongly considered. With the list type syntax, I know that there were all sorts of ideas. Before moving to a situation like that, it may warrant quite a bit of planning. If we accepted the current syntax of just 1 item per case, that would not conflict with 4.1 allowing multiple values per case. I am a bit concerned that if we rush to allow multiple values per case statement that come 4.1 when we sit down and think long and hard about it that we may create a syntax incompatability, or wish we wouldn't have rushed to make it in 4.0.
Jeremy
