1. annoying problem - or I don't get it
- Posted by jessedavis Jun 17, 2010
- 1087 views
The switch statement requires a constant to test against in each case statement. It works great; however, if one has a lot of tests to do where the case tests a are computed at runtime there is a problem. So>
constant tests = {3,9,12,33} --really a much longer sequence integer x = 12 switch x do case tests[1] then puts(1,"Case = 1\n") break case "" end switch
output follows:
jd@jd-ubuntu:~/euphoria/code/misc_and_test$ eui switch_test.ex
switch_test.ex:4
<0066>:: expected 'then' or ',', not '['
case tests[1] then
^
As you can see the parser cannot handle what is otherwise a perfectly valid statement. tests[1] is a constant. Try creating a bunch of constants one at a time. I know there are other ways of doing this - some are even elegant. I just think it should work!
Regards, jd
any thoughts? anyone?
2. Re: annoying problem - or I don't get it
- Posted by mattlewis (admin) Jun 18, 2010
- 1003 views
The switch statement requires a constant to test against in each case statement. It works great; however, if one has a lot of tests to do where the case tests a are computed at runtime there is a problem. So>
As you can see the parser cannot handle what is otherwise a perfectly valid statement. tests[1] is a constant. Try creating a bunch of constants one at a time. I know there are other ways of doing this - some are even elegant. I just think it should work!
any thoughts? anyone?
Case statements can't handle something like tests[1]. It is certainly possible to allow something like this. I think we've considered using more complex statements inside of cases, and that it would probably happen in the future. Basically, it's a lot more complicated to allow this sort of thing.
If we already knew (at compile time) the value of the constant, and of the subscript, it would be relatively easy to simply fold that operation and substitute the known value. Currently, it is possible that the value of a constant cannot be known at compile time (usually, a constant whose value comes from a function call). In these cases, the value determination is pushed off until run time, at which point we look up the value and put it into the lookup table.
Adding subscripting makes that more complicated. Not impossible, but definitely more complicated. I'd suggest that you create an improvement ticket for this.
Matt
