Why is the switch statement restricted to int-like and char[]?  If there is no compile-time switch code available, it should be easy enough to devolve the switch to an if/then/else style expression, right?

Kevin

In article <c8gf5i$4v9$1@digitaldaemon.com>, Kevin Bealer says...
>
>Why is the switch statement restricted to int-like and char[]?  If there is no compile-time switch code available, it should be easy enough to devolve the switch to an if/then/else style expression, right?
>
>Kevin
>

I should be more elaborate when I post:  what I mean is to allow arbitrary object comparison, not just the integer and string cases where lookup can be accelerated easily.

Also, static or even on-the-fly constructed objects for the comparisons.  If it works as a hash table, great, otherwise, if-then-else is built.  Some compilers will work harder at generating fast searches.

class range_test {
    int _x, _y;
    this(int x, int y)
    {
        _x = x; _y = y;
    }

In article <c8gf5i$4v9$1@digitaldaemon.com>, Kevin Bealer says...
>
>Why is the switch statement restricted to int-like and char[]?  If there is no compile-time switch code available, it should be easy enough to devolve the switch to an if/then/else style expression, right?
>
>Kevin
>

I should be more elaborate when I post:  what I mean is to allow arbitrary object comparison, not just the integer and string cases where lookup can be accelerated easily.

Also, static or even on-the-fly constructed objects for the comparisons.  If it works as a hash table, great, otherwise, if-then-else is built.  Some compilers will work harder at generating fast searches.

class range_test {
    int _x, _y;
    this(int x, int y)
    {
        _x = x; _y = y;
    }

In article <c8gf5i$4v9$1@digitaldaemon.com>, Kevin Bealer says...
>
>Why is the switch statement restricted to int-like and char[]?  If there is no compile-time switch code available, it should be easy enough to devolve the switch to an if/then/else style expression, right?
>
>Kevin
>

I should be more elaborate when I post:  what I mean is to allow arbitrary object comparison, not just the integer and string cases where lookup can be accelerated easily.

Also, static or even on-the-fly constructed objects for the comparisons.  If it works as a hash table, great, otherwise, if-then-else is built.  Some compilers will work harder at generating fast searches.

class range_test {
    int _x, _y;
    this(int x, int y)
    {
        _x = x; _y = y;
    }

In article <c8h5au$1fkb$1@digitaldaemon.com>, Kevin Bealer says...
>
>In article <c8gf5i$4v9$1@digitaldaemon.com>, Kevin Bealer says...
>>
>>Why is the switch statement restricted to int-like and char[]?  If there is no compile-time switch code available, it should be easy enough to devolve the switch to an if/then/else style expression, right?
>>
>>Kevin
>>
>

(that got truncated, ill try again..)

I should be more elaborate when I post:  what I mean is to allow arbitrary object comparison, not just the integer and string cases where lookup can be accelerated easily.

Also, static or even on-the-fly constructed objects for the comparisons.  If it works as a hash table, great, otherwise, if-then-else is built.  Some compilers will work harder at generating fast searches.

class range_test {
int _x, _y;
this(int x, int y)
{
_x = x; _y = y;
}

int opCmp(int q)
{
if (q <= x) return -1;
if (q >= y) return 1;
return 0;
}
};

void code(int x)
{
static range set1(0,10);
static range set2(11,20);
static range set1(90,100);

switch(x) {
case set1: /+ handle 0-10 +/ break;
case set2: /+etc+/ break;
case set3: /+etc+/ break;
case 72:
case 33:
case 357:
/+ something else +/
break;
}
}

All of which is possible if switches - or parts of switches - can be runtime features.  In some cases, the compiler can do fancy accelerations, other times not, but in all cases, syntax is expressive and clean (if you like "switch".)

Consider all the code that looks like:

switch(x) {
//... many static cases...

default:
if (isalpha(x)) {
} else if (isnum(x)) {
//...
} else ... {
}
}

Kevin

Kevin Bealer wrote:

> 
> void code(int x)
> {
> static range set1(0,10);
> static range set2(11,20);
> static range set1(90,100);
> 
> switch(x) {
> case set1: /+ handle 0-10 +/ break;
> case set2: /+etc+/ break;
> case set3: /+etc+/ break;
> case 72:
> case 33:
> case 357:
> /+ something else +/
> break;
> }
> }
> 

how do you plan to tackle overlapping intervals,
e.g.:

static range set1(0,100); // I changed this
static range set2(11,20);
static range set3(90,100);

instead of your original code,

this would mean "case set1: ...; break;" is executed and set2, and set3 cases never.

regards,
roel

In article <c8hsu7$2jqj$1@digitaldaemon.com>, Roel Mathys says...
>
>Kevin Bealer wrote:
>
>> 
>> void code(int x)
>> {
>> static range set1(0,10);
>> static range set2(11,20);
>> static range set1(90,100);
>> 
>> switch(x) {
>> case set1: /+ handle 0-10 +/ break;
>> case set2: /+etc+/ break;
>> case set3: /+etc+/ break;
>> case 72:
>> case 33:
>> case 357:
>> /+ something else +/
>> break;
>> }
>> }
>> 
>
>how do you plan to tackle overlapping intervals,
>e.g.:
>
>static range set1(0,100); // I changed this
>static range set2(11,20);
>static range set3(90,100);
>
>instead of your original code,
>
>this would mean "case set1: ...; break;" is executed and set2, and set3 cases never.
>
>regards,
>roel

I didn't really plan, but I would expect that a simple decision could be made, i.e. take the first match.  It works that way now, but only because the values must be unique.

So for a switch like:

switch(x) {
case 10: A(); break;
case 20: B(); break;
case 30: C(); break;
case range(25,40): D(); break;
case phil: E(); /* where phil is a variable */
case 99:  X(); break;
case 101: Y(); break;
case 203: Z(); break;
};

.. Would potentially use an optimized switching technique to decide between the first three, then use "==" to decide the range and variable, then possibly another optimized table for the last set.

This is clean and readable, and still affords optimization in cases where it doesn't affect determinism.  Determinism is critical for robustness.  When speed is important the coder would organize the list accordingly.  But picking 203 from a table before checking (x == phil) would be illegal.

The simplest implementation would devolve the switch into runs of compile time pieces and if-then-else pieces (with "goto"s as needed for fall through), then compile with current techniques.

But in most cases, (x == some_obj) will inline into x.q == some_obj.q, which after register-izing variables, will become a static switch test.  When we define equality for an operator, it usually compares against one or more internal primitives.

Kevin